MySQL высокая доступность, отработка отказа и репликация с задержкой

Мы находимся в процессе внедрения новой CMS (Drupal 6.x), которая работает на MySQL. У нас есть два центра обработки данных - основной и дополнительный - с известной задержкой между ними. Мы не уверены, какую версию MySQL мы будем запускать ... Community или Enterprise, но это TBD. Похоже, что мы будем использовать движок InnoDB, ОС будет RedHat EL 5.5. Первичные серверы будут активными, а вторичные будут пассивными или горячими резервами.

Я хотел бы реализовать репликацию, высокую доступность и автоматическое переключение при сбое в MySQL в двух центрах обработки данных.

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

Мне интересно знать, какие технологии / инструменты / лучшие практики могут быть использованы для решения / решения этих проблем. Кроме того, любые моменты или ах-ха очень ценились бы также. Я читал о репликации MySQL, кластеризации и некоторых сторонних инструментах, таких как Tungsten и Dolphinics, но я не уверен, как лучше действовать.

Спасибо за ваше время!

KM

Для простоты я рекомендую только кольцевую репликацию MySQL. Вот почему:

Существует много технологий и топологий, которые намного превосходят кольцевую репликацию MySQL. Мой любимый, с рук вниз, это DRBD (распределенное реплицированное блочное устройство) . Однако DRBD отлично работает, когда пара серверов находится в одном корпусе, центре обработки данных и стойке. Еще лучше, если использовать перекрестный кабель в подсети 192.168.xx между DRBD Primary и DRBD Secondary. К сожалению , DRBD имеет ужасную производительность на расстоянии между двумя местоположениями, хотя DRBD все еще может работать. Не существует сетевых топологий, обеспечивающих удовлетворительную производительность DRBD между двумя центрами обработки данных.

После настройки кольцевой репликации MySQL между двумя серверами БД в двух разных центрах обработки данных требуется только настройка сети. По сути, производительность репликации является функцией сетевых настроек (скорость / задержка передачи двоичного журнала в MySQL Replication Setup) и дискового ввода-вывода (DRBD).

Альтернатива, которую вы можете пожелать для лучшей избыточности, заключается в следующем:

Настройте пару DRBD в обоих местах.
Пара DRBD на сайте № 1 с VIP 111.111.111.111.
Пара DRBD на сайте № 2 с VIP 222.222.222.222.

Настройте кольцевую репликацию MySQL между первичными серверами DRBD в следующих условиях:
Для сайта # 1 используйте 222.222.222.222 в качестве Master_Host в MySQL.
Для сайта # 2 используйте 111.111.111.111 в качестве Master_Host в MySQL.

Несмотря на введение уровня сложности, теперь у вас есть два уровня избыточности: DRBD внутри каждого сайта и кольцевая репликация MySQL между сайтами. У вас есть дополнительные преимущества запуска резервного копирования через mysqldump на DRBD Primary сервера горячего резервирования.

Что касается аварийного переключения, DRBD обеспечивает автоматическое аварийное переключение на любом сайте.

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

ОБНОВИТЬ

Я просто сделал двойной дубль и заметил, что вы используете Drupal6. Я рад, что вы будете конвертировать все таблицы drupal в InnoDB. Это исключит любую возможность обновления таблиц MyISAM, что приведет к блокировке таблиц для замораживания соединений с БД, которые просто читают таблицы MyISAM. Любое обновление DML (INSERT, UPDATE, DELETE) для таблицы MyISAM ВСЕГДА БУДЕТ ПОЛНОСТЬЮ БЛОКИРОВАТЬ ТАБЛИЦУ !!! Использование InnoDB представит блокировку на уровне строк, которая устраняет полные блокировки таблиц.

Кроме того, DRBD становится вашим другом, когда все является InnoDB, потому что восстановление после сбоя будет согласованным между парой DRBD. И наоборот, DRBD с MyISAM ничего не покупает, потому что разбитая таблица MyISAM на первичном DRBD просто дублируется на вторичный DRBD, как вы уже догадались , разбитая таблица MyISAM.

ОБНОВЛЕНИЕ № 2

Вы должны использовать два уровня избыточности

Уровень 1. В каждом центре баз данных используйте DRBD.
http://dev.mysql.com/doc/refman/5.1/en/ha-drbd.html

Настроить пару серверов БД при
запуске DRBD при
запуске MySQL на DRBD Primary

Это создает избыточные данные на уровне диска.

Уровень 2: Вы должны настроить кольцевую репликацию MySQL между
DRBD Primary DataCenter # 1 и DRBD Primary DataCenter # 2

Каждый DRBD Primary будет работать под управлением MySQL и будет
одновременно и ведущим, и подчиненным.

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