(no subject)
Jun. 27th, 2008 04:04 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
b_a_tНа днях пришлось опять провести всю ночь без сна, восстанавливая mySQL slaves из-за очень странной ошибки на мастере.
Проявилась данная ошибка в том, что за меньше, чем сутки мастер умудрился залить на slaves 250Гб апдейтов, после чего там кончилось место(а не то он бы еще залил). Анализ дат binlogs показал, что новый гигабайтный лог добавлялся каждые три минуты. Очевидно, что даже при 100% загрузке сервера столько изменений нагенерить было нереально. Откуда же тогда взялись все эти данные? Так бы и осталась эта загадка нерешенной, если бы один из девелоперов не предложил сравнить соседние логи. Простого cmp оказалось достаточно, чтобы выяснить, что все 250 фалов - суть копия одного и того же файла!
Это как минимум объясняет, откуда взялся такой устойчивый мощный поток данных. Но, конечно, так и не ясно, что же взглюкнуло на сервере, что у него не изменялся внутренний счетчик binlogs.
В общем - beware, here live dragons.
Проявилась данная ошибка в том, что за меньше, чем сутки мастер умудрился залить на slaves 250Гб апдейтов, после чего там кончилось место(а не то он бы еще залил). Анализ дат binlogs показал, что новый гигабайтный лог добавлялся каждые три минуты. Очевидно, что даже при 100% загрузке сервера столько изменений нагенерить было нереально. Откуда же тогда взялись все эти данные? Так бы и осталась эта загадка нерешенной, если бы один из девелоперов не предложил сравнить соседние логи. Простого cmp оказалось достаточно, чтобы выяснить, что все 250 фалов - суть копия одного и того же файла!
Это как минимум объясняет, откуда взялся такой устойчивый мощный поток данных. Но, конечно, так и не ясно, что же взглюкнуло на сервере, что у него не изменялся внутренний счетчик binlogs.
В общем - beware, here live dragons.
