Недавняя серия статей («Памятка евангелиста PostgreSQL: критикуем MySQL грамотно» 1,2,3) зацепила за живое.
Так получилось, что моя команда унаследовала, истеорически сложившуюся систему, с 300+ объектами, где одним из ключевых компонентов системы выступает именно MySQL. На некоторых объектах также используется репликация. ПО использующее MySQL от стороннего разработчика.
Большинство объектов находится в удалённых от «человека разумного» регионах (горы, степь). Некоторые объекты находятся в ~200км от ближайшего населённого пункта. Перебои с электропитанием на этих объектах, дело вполне обычное и регулярное. ИБП очень выручают, но иногда и они не в состоянии спасти от продолжительного блэкаута. А чаще всего от серии блэкаутов. Тоесть ИБП ещё не зарядился, оборудование уже включено и работает, пишет данные в БД, и тут ЭП начинает пропадать и появляться, и снова пропадать. Системы падают.
До апгрейда MySQL до версии 5.6.23, в месяц приходилось восстанавливать вручную две-три БД. Сейчас восстанавливать приходится реже, но всё равно приходится. С августа месяца восстанавливали всего две БД.
После одной из статей kaamos, мы начали тестировать 5.6.26 и тестирование показало, что эта версия ещё более живуча. Однако условия сайтов, полноценно симулировать мы не можем (около 20 типов сайтов). Профиль нагрузки на всех этих типах разный, хотя модель БД одна.
Итак, ключевое условие проблемы:
У нас есть таблицы с внешними ключами и ON DELETE CASCADE ON UPDATE CASCADE, на некоторых таблицах которые референцируются на вышеназванные, установлены триггеры.
Вполне возможно, — это плохой дизайн модели данных для MySQL. Почему? Только сегодня наткнулся на следующее утверждение:
The InnoDB engine is fully ACID compliant, but fails the standard definition of consistency when using a combination of InnoDB, foreign keys with cascading actions and triggers. This is the result of triggers being implemented at MySQL's SQL layer and foreign keys being implemented at the InnoDB Storage Engine level.
Если данное утверждение верно, то буква 'C' из ACID, в нашем случае совершенно не гарантирована.
И тогда не стоит удивляться сообщениям об ошибках вида:
[ERROR] Table ./database/table has no primary key in InnoDB data dictionary, but has one in MySQL!
Также похоже не стоит на 100% надеяться на консистентность при репликации.
Возможно данная проблема решена в 5.7, и как только он появится в пакетной базе нашего дистрибутива, мы начнём обновлять системы и счастливо забудем о проблеме.
Однако, сколько ещё сюрпризов таит в себе многоуровневая архитектура MySQL?
Так получилось, что моя команда унаследовала, ист
Большинство объектов находится в удалённых от «человека разумного» регионах (горы, степь). Некоторые объекты находятся в ~200км от ближайшего населённого пункта. Перебои с электропитанием на этих объектах, дело вполне обычное и регулярное. ИБП очень выручают, но иногда и они не в состоянии спасти от продолжительного блэкаута. А чаще всего от серии блэкаутов. Тоесть ИБП ещё не зарядился, оборудование уже включено и работает, пишет данные в БД, и тут ЭП начинает пропадать и появляться, и снова пропадать. Системы падают.
До апгрейда MySQL до версии 5.6.23, в месяц приходилось восстанавливать вручную две-три БД. Сейчас восстанавливать приходится реже, но всё равно приходится. С августа месяца восстанавливали всего две БД.
После одной из статей kaamos, мы начали тестировать 5.6.26 и тестирование показало, что эта версия ещё более живуча. Однако условия сайтов, полноценно симулировать мы не можем (около 20 типов сайтов). Профиль нагрузки на всех этих типах разный, хотя модель БД одна.
Итак, ключевое условие проблемы:
У нас есть таблицы с внешними ключами и ON DELETE CASCADE ON UPDATE CASCADE, на некоторых таблицах которые референцируются на вышеназванные, установлены триггеры.
Вполне возможно, — это плохой дизайн модели данных для MySQL. Почему? Только сегодня наткнулся на следующее утверждение:
The InnoDB engine is fully ACID compliant, but fails the standard definition of consistency when using a combination of InnoDB, foreign keys with cascading actions and triggers. This is the result of triggers being implemented at MySQL's SQL layer and foreign keys being implemented at the InnoDB Storage Engine level.
Если данное утверждение верно, то буква 'C' из ACID, в нашем случае совершенно не гарантирована.
И тогда не стоит удивляться сообщениям об ошибках вида:
[ERROR] Table ./database/table has no primary key in InnoDB data dictionary, but has one in MySQL!
Также похоже не стоит на 100% надеяться на консистентность при репликации.
Возможно данная проблема решена в 5.7, и как только он появится в пакетной базе нашего дистрибутива, мы начнём обновлять системы и счастливо забудем о проблеме.
Однако, сколько ещё сюрпризов таит в себе многоуровневая архитектура MySQL?