Проблемы с MySQL MyISAM — дублирование записей и крэш больших таблиц

Question

[ilya_compman]

Совершенно внезапно на рабочем проекте стали твориться непонятные вещи:

• отваливаются две самые большие таблицы — одна на гигабайт и порядка 70 миллионов записей, другая на 500 мегабайт и 700 000 записей. Примерно 100-1000 инсертов в секунду в первую и 2-5 во вторую. Из второй данные активно select'ятся
• периодически по неизвестным причинам база начинает выдавать ошибку too many connections. Скрипты оптимизированы, один скрипт — один экземпляр соединения (класс БД — «одиночка»)
• сегодня ни с того ни с сего данные начали дублироваться, один запрос проходил от двух до 13 раз. Причем не один какой-то запрос, а сразу несколько, которые идут друг за другом.

Скрипты проверил, всё в порядке, давно ничего не менялась, проект со средней посещаемостью. Никаких всплесков за сегодня нет.
Сервер выделенный, настройки стандартные, ОС — CentOS. Версия MySQL — 5.0.77

В чем может быть причина? Я с подобным никогда не сталкивался, никак не могу понять, что происходит.

Answer 1

[pentarh]

Too many connections — енто я объясню. На myisam нельзя делать так как вы описали. Активные селекты блокируют всю таблицу и инсерты ждут снятия блокировки. Получается, если ваш селект тормознул хотя бы на секунду, то по вашим данным в очереди набилось уже 1000 инсертов. Вот вам и too many connections.
Переключайтесь на иннодб, она помедленнее, но блокировки там на уровне строки и от сбоя она хорошо восстанавливается.
И лучше сделать один extended insert на 1000 строк, чем 1000 инсертов по одной строке. Подумайте над этим.

Answer 2

[resurection]

FaceBook по вашему не серьёзный проект?

Comments

[rtzra]

Там стоит MySQL «из коробки»? Один на всю фейсбучину? :-)

[eternals]

Я не очень знаю про facebook, поэтому предложу посмотреть вот это: www.insight-it.ru/masshtabiruemost/arkhitektura-facebook/
На «MySQL — используется как хранилище пар ключ-значение, никаких join'ов» (там ещё пояснения внизу).

И ещё вот здесь: www.facebook.com/Engineering#!/Engineering?v=info есть про тысячи databases и кластер.

[resurection]

rtzra, а это уже совсем другой вопрос. eternals написал что «никто и никогда». Я же написал, что «иногда, если руки прямые, то и для очень серьёзных проектов можно». Естественно там допиленный и донастроенный MySQL.
Например, если в одной таблице очень много записей (70 млн.), то можно использовать партиции.

[eternals]

Пожалуйста, не передёргивайте на свой лад мои формулировки. Они предельно точны. И в данном случае к словам, что вы привели, не имеют никакого отношения. Я, конечно, понимаю, что здесь засилие школоты, которые не думают, что пишут, но всё же в моём случае, ссылаясь на меня, соизвольте использовать точные цитаты или хотя бы смысл верно передавайте. Спасибо. Пожалуйста.

[rtzra]

resurection: вот если я возьму запорожец и напильником его доточу до вертолета — плюсик запорожцу ли мне? И можно ли будет получившийся вертолет называть запорожцем в его новом виде?
Вот поэтому я и говорил «из коробки». Понятно что если засучить рукава, разобраться где и от чего глючит, посмотреть explain, поточить код и т.д. — оно заработает на ура. И дело тут не в мускуле, постгресе и прочем — здесь важен подход. Поэтому крики ilya_compman в принципе бесполезны — понятнее-то не становится. Пусть обновляет мускул, смотрит софт, анализирует где и что сбоит. Если не может сам — думаю не составит проблемы попросить о помощи или нанять любого фрилансера.

Answer 3

[Zorkus]

Замечу для тех, кто люто срет кирпичами выше — 70 миллионов записей в самой большой таблице — это не так уж много. Совсем не много, чтобы заявлять — «Например, если в одной таблице очень много записей (70 млн.), то можно использовать партиции».

7 миллиардов — и десятки терабайт общего размера базы — вот это очень много.

Answer 4

[Искандер Гиниятуллин]

при большом количестве инсертов ваш выбор innodb

Answer 5

[Wott]

Надо смотреть блокировки в mysql и iostat и вообще что там может быть с диском связано.
А вообще как-то странно видеть MyISAM для таблиц в которые часто пишут.

Comments

[eternals]

А как у нас блокировки, iostat и диск связаны с дублированием данных, «too many connections» и прочим?

[Wott]

Блокировки подвешивают сессии и они тупо заканчиваются. Задержки сброса записей на диск могут приводит к тем же результатам. Дублирование данных может происходит вследствие разнесенных по времени проверок на уникальность и самих записей. А задержки из-за отложенных записей увеличивают их вероятность.
В целом это все конечно неправильная архитектура, поскольку правильная не приводит к разрушению целостности данных ни при каких обстоятельствах.

[ilya_compman]

Отложенных записей нет. Просто подряд несколько insert'ов. Никаких ухищрений, хитрых запросов и т.д.

[Wott]

а что по вашему происходит при insert-е? никаких ухищрений и не надо — достаточно сделать несколько insert-ов на фоне активной выборки select-ами. При чем это может работать все время, но достаточно одного сбоя в работе диска и база посыпалась. Читайте мануал dev.mysql.com/doc/refman/5.0/en/table-locking.html

На самом деле ставить диагноз по телефону врачам запрещено — смотрите сами что происходит с базой.
Если не знаете куда смотреть — есть два скрипта mysqlreport и tuning-primer.sh — они легко ищутся в сети.
Запускаем и смотрим где оно ругается.

[ilya_compman]

По логам ничего странного не происходило уже долгое время. Вчера немного увеличил размеры буферов в конфиге, надеюсь, что поможет