Назад | Перейти на главную страницу

Репликация MySQL с использованием DRBD, распределенного диспетчера блокировок?

Мне нужно реализовать конфигурацию Linux-HA на двух серверах. Я решил использовать DRBD для репликации на уровне блоков на обоих хостах, в основном для репликации данных MySQL.

Насколько я понимаю, в конфигурации DRBD всегда есть первичный сервер, остальные - подчиненные (у которых может быть свой подчиненный). Репликация передается только от мастеров к ведомым, а не наоборот.

Итак, что произойдет, если у меня есть процессы MySQL, выполняющие запись на обоих серверах одновременно, один из которых является главным, а другой подчиненным?

Подчиненное устройство может выполнять запись, но данные не записываются?

При условии, что эта конфигурация будет работать вместе с Heartbeat, это будет задача Heartbeats - гарантировать, что MySQL работает только на главном сервере, но давайте предположим на данный момент, что Heartbeat по какой-то причине не удалось.

Насколько мне известно, DRBD выполняет репликацию на уровне разделов. Подчиненное устройство не монтирует раздел, поэтому не может писать в него. Когда возникает проблема в главном устройстве, подчиненное устройство монтирует раздел и начинает работать.

Таким образом, оба сервера не могут записывать одни и те же данные.

Обычно используемая конфигурация, которую я использовал раньше, состоит в том, чтобы иметь два узла с некоторыми ресурсами между ними. Эти ресурсы представляют собой блочное устройство хранения DRBD, демон MySQL и IP-адрес.

Ресурсы могут быть включены только на основном узле. Heartbeat заботится о том, чтобы выбрать, какой узел является основным, и запустить ресурсы в правильном порядке: указать DRBD, чтобы он стал основным, смонтировать BD, запустить MySQL и поднять IP. Они выполняются в таком порядке для обеспечения согласованности данных. Вы можете переключаться между первичным и вторичным узлами вручную по своему выбору, понижая уровень первичного или вторичного.

Пока первичный находится в рабочем состоянии, единственные действия, которые выполняет вторичный, - это репликация данных DRBD и участие в коммуникациях Heartbeat, чтобы сказать, что он жив. Во время работы в качестве вторичного сервера MySQL никогда не запускается, и вы не можете использовать блочное устройство хранения. Ресурсы могут использоваться одновременно только на одной машине.

Эта установка отличается от обычной «ленивой репликации» MySQL, когда вторичная машина запускает MySQL и хранит свою собственную копию данных. У обоих есть свои плюсы и минусы. По моему опыту, если HB настроен правильно и к тому же у вас есть хорошая политика резервного копирования, то подход LinuxHA может обеспечить гораздо лучшую высокую доступность.

«Не может быть». DRBD гарантирует, что блочное устройство будет активным одновременно только на одном сервере. Если вы получаете "разделенный мозг", когда оба хоста DRBD думают, что другой мертв (так что они оба активны), они не будут повторно подключаться, и вам нужно устранить несоответствие вручную (обычно отбрасывайте изменения на одном главном или другой).

Лучшее решение для MySQL HA - использовать круговую репликацию MySQL. Эта статья объясняет это далее, но основная предпосылка состоит в том, чтобы сделать каждый сервер подчиненным для другого. Вам нужно будет заранее настроить какой-то балансировщик нагрузки.

Одна вещь, о которой следует беспокоиться, заключается в том, что соединения с базой данных могут быть долгоживущими, и вам нужно будет настроить приложения для повторного подключения в случае их смерти.

Если вам нужен DRBD «в основном» для репликации MySQL, может быть, проще использовать функции репликации, встроенные в MySQL?