Репликация БД
by Евгений Викторович Арбатский - Прошло полгода эксплуатации тестовой архитектуры для чата (с сентября 2007). В ходе этих месяцев выявились следующие узкие места такой связки:
1) На основном СУБД стало нехватать места для бинарных логов (поэтому сделали ежедневную очистку, за день журнал увеличивался где-то на 100Мб).
2) В результате некоторых сбоев в работе сервера с репликой часть записей требовала ручной коррекции (это было только пару раз).
3) После длительных сбоев (которые захватывали очистку логов) БД не начинала работать без полного копирования с основной СУБД.
4) Был проверен вариант запуска реплики без полного восстановления (предполагалось что заменяемые данные успеют измениться до того, как станут востребованы), но это вылилось в то, что запросы на основном СУБД и реплике стали выдавать различные данные.
Вывод:
I) Использование механизма реплик в mySQL требует:
Интересный эффект происходит при следующих действиях (работает один скрипт):
1) Запись изменений в БД (основную)
2) Чтение всех нужных состояний (из реплики)
3) Вывод формы / данных
Между п.1 и п.2. происходит настолько мало времени, что СУБД просто не успевает занести данные в реплику. Поэтому данные при выводе могут быть не равны тем данным, что в БД.
1) На основном СУБД стало нехватать места для бинарных логов (поэтому сделали ежедневную очистку, за день журнал увеличивался где-то на 100Мб).
2) В результате некоторых сбоев в работе сервера с репликой часть записей требовала ручной коррекции (это было только пару раз).
3) После длительных сбоев (которые захватывали очистку логов) БД не начинала работать без полного копирования с основной СУБД.
4) Был проверен вариант запуска реплики без полного восстановления (предполагалось что заменяемые данные успеют измениться до того, как станут востребованы), но это вылилось в то, что запросы на основном СУБД и реплике стали выдавать различные данные.
Вывод:
I) Использование механизма реплик в mySQL требует:
а) достаточно продуманной политики в отношении наличия свободного места под журналы, их очистку / архивацию.II) Для промышленного использования пока рано применять, либо надо рассматривать все возможные и невозможные варианты сбоев и способы их устранения.
б) доработки mySQL, чтобы было возможным загружать основную БД в реплику без сложных действий (обещают в версии 5.1).
Интересный эффект происходит при следующих действиях (работает один скрипт):
1) Запись изменений в БД (основную)
2) Чтение всех нужных состояний (из реплики)
3) Вывод формы / данных
Между п.1 и п.2. происходит настолько мало времени, что СУБД просто не успевает занести данные в реплику. Поэтому данные при выводе могут быть не равны тем данным, что в БД.