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