DRBD с MySQL
Вопрос об использовании DRBD для обеспечения HA для MySQL.
Мне нужно быть уверенным, что мой резервный экземпляр MySQL всегда будет в рабочем состоянии, когда происходит аварийное переключение. Что произойдет, например, если основной сервер умирает частично в результате совершения транзакции?
Собираемся ли мы в конечном итоге получить данные, скопированные на вторичный сервер, который не может обработать mysql? Или, что если сеть пропадает во время синхронизации, и не все данные передаются по ней?
Кажется, что возможно войти в состояние, когда неполные данные на вторичном сервере делают невозможным запуск MySQL и чтение базы данных.
Я что-то пропустил?
5 ответов
Это зависит, естественно, от характера аварийного переключения. Похоже, вы уже знаете ответ на свой вопрос.
DRBD - это, по сути, сетевое зеркалирование RAID. Блокирует в -> блокирует. Вы можете работать синхронно или асинхронно, в зависимости от ваших требований к задержке. То, что вы выберете, очень сильно влияет на то, является ли ваша реплика устойчивой к сбоям или нет.
Ваш вопрос сводится к следующему: "что происходит, когда MySQL запускается и читает файлы данных?" Либо ваши данные правильно сформированы и приостановлены, и они запускаются без сбоев, либо они устойчивы к сбоям, и у вас могут возникнуть проблемы с согласованностью. (Конечно, также существует вероятность повреждения диска, и это также может быть проблемой с DRBD, особенно если вы каким-то образом попадаете в сценарий с разделенным мозгом.) Обычно он может восстановиться, воспроизведя журналы, если вы используете транзакционный движок, но иногда у вас будут более серьезные проблемы. Это верно как для DRBD, так и для других общих хранилищ блоков, таких как общий том SAN или (не дай бог) файлы базы данных в NFS.
Гипотетически, ACID-совместимая база данных всегда должна корректно восстанавливаться после незавершенных транзакций. На практике, и особенно с некоторыми версиями MySQL, это не всегда так (в основном потому, что MySQL не обладает наибольшим наследием соответствия ACID, хотя в последние годы ситуация улучшилась). Хранение частых резервных копий всегда разумно.
Невозможно гарантировать, что любая система высокой доступности всегда будет продолжать работать при сбое. Лучшее, что вы можете сделать, - это принимать правильные решения при разработке своего решения высокой доступности и проверять их на себе, чтобы подтвердить свои предположения о том, как оно будет себя вести, когда что-то пойдет не так.
В вашем случае вы можете рассмотреть вопрос о резервном подчиненном устройстве, если вы столкнулись с проблемой согласованности на диске мастера. Конечно, для его продвижения требуется ручная работа, но, по крайней мере, вы не будете восстанавливать данные за несколько часов или дней.
Если ты
- Запустить DRBD в синхронном режиме (мне кажется, режим C?)
- Используйте STONITH (ограждение, чтобы, когда DRBD выбирает узел, он мог отключить другой узел с помощью механизма "вне границ" (т. Е. Интеллектуальный удлинитель питания APC, свет, drac и т. Д.). Это гарантирует, что будет только один "мастер". ' возможный.
- убедитесь, что ваши диски / RAID-контроллер не лгут о фактической записи на диск. (Или они имеют кэш с резервным питанием от батареи)
- тщательно проверить все режимы отказа. (Питание, сеть, тупая команда администратора, тупое приложение)
Тогда вы можете быть уверены, что ваша база данных очень доступна. В вашем примере, если произойдет сбой в середине транзакции, оно будет прервано, и, надеюсь, ваше приложение должно повторить попытку и должно иметь возможность подключиться ко второму узлу, который, как мы надеемся, будет иметь согласованную копию данных (поскольку все записи выполняются синхронно записывается в оба узла перед возвратом в базу данных, в которой оно было записано).
Я не думаю, что DRBD является правильным решением здесь.
В зависимости от вашей рабочей нагрузки вы, вероятно, хотите один или комбинацию ниже
- Мастер - ведомая репликация
- Мастер - Мастер
- Мастер - Мастер с рабами
- MySQL кластер
Первый довольно прост в настройке, второй имеет несколько предостережений, таких как Split brain, STONITH (Shoot The Other Node In The Head) и другие.
Это может быть сложной темой, и я рекомендую вам исследовать и углубленно тестировать для предполагаемого использования. Есть множество руководств для каждого из них.
Если у вас есть контроль над кодом приложения, вы можете использовать синхронную репликацию MySQL Galera вместо DRBD. В Galera требуется нечетное количество членов узла кластера, предпочтительно не менее трех, так что большинство голосов побеждает за правильные данные. Вы можете дополнить MySQL Galera с помощью HAProxy. Таким образом, на каждом веб-кирпиче вы запускаете HAProxy, который затем подключается и проверяет, работают ли серверы MySQL.
Вот некоторые из ограничений http://www.codership.com/wiki/doku.php?id=limitations
Я пробовал DRBD несколько лет назад, но у меня было много проблем после отработки отказа.
Я удалил DRBD с картинки, переместив все данные и журналы на отдельный дисковый массив, подключенный через два контроллера SAS. Для этого мы используем IBM DS-3525. Что хорошо в этой настройке, так это то, что вторичная система всегда подключена, просто не смонтирован раздел. Я использовал Corosync для управления переключением при сбое. Когда первичный возвращается, Corosync выключает MySQL, размонтирует разделы, перемонтирует их на главном сервере, запускает MySQL для резервного копирования. Даже если главная машина погибнет в середине транзакции, InnoDB восстановится.
В этом диапазоне дисковые массивы стоят около 15-20 тысяч долларов. Если принять во внимание, что вам нужно 2 из всего (не говоря уже о том, что вам нужно эквивалентное оборудование на узел), затраты на массив вполне оправданы. Еще одним преимуществом Drive Array является скорость. В моем случае я использую драйверы Multi-path, чтобы системы могли использовать оба контроллера одновременно. Пропускная способность по сравнению с внутренним рейдом обычно намного выше.
Кристиан упомянул Галеру. Проверьте Перкона кластера. Он использует Galera и является очень многообещающим дополнением для повышения надежности MySQL.