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

Сочетание Multi-Master Replication (MMR) с Linux-HA

Я заинтересован в использовании MMR (http://mysql-mmm.org/) для обеспечения высокой доступности и репликации. Проблема в том, что меня также интересует использование Linux-HA для других сервисов, таких как Apache. Они пересекаются, когда дело доходит до определенных вещей, таких как замена виртуальных IP-интерфейсов и т. Д.

Есть ли у кого-нибудь подобная установка и есть лучшие практики / решения для проблемы, указанной выше?

Другие услуги на тем же машины?

Если нет, то у вас нет перекрытия (Linux-HA на одном наборе машин с виртуальным IP-адресом и MMR на другом наборе машин)

Если есть другие услуги, возможно, рассмотрите виртуализация или переместите их на другие машины, так как это упростит управление сетевым интерфейсом (вы не сможете столкнуться с конфликтами между двумя методами управления виртуальным IP).

Просто убедитесь, что виртуальные мастера находятся на разных хостах, иначе отказ хост-машины приведет к потере всех ваших экземпляров MySQL!

У нас он отлично работает.

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

Linux-HA и MMR по отдельности могут быть сложными для начала работы. Если ваша основная забота - взаимодействие, самый простой способ ограничить его - разрозненное оборудование / сеть. Если это невозможно, сложность коробки увеличится. Поэтому лучше всего разделить ваши виртуальные адреса и IP-адреса как можно больше, чтобы вы могли сосредоточить конфигурацию Linux-HA и MMR на подмножестве интерфейсов и меньше беспокоиться о том, что они мешают друг другу. Я бы также серьезно подумал, нужна ли вам репликация мастер-мастер. Это может быть очень сложно, а сложность подвержена неудачам.

Возможно, вам будет лучше обслуживаться с помощью главного подчиненного устройства или сниженного уровня обслуживания в случае основного отказа. Если вам все еще нужен master / master, вы можете посмотреть postgres (хотя вариантов mmr много). Я также ненавижу упоминать об этом, но было бы упущением, если бы я этого не сделал, но по моему опыту, если MMR имеет значение и не может быть решено архитектурно или другими способами, вы можете захотеть взглянуть на коммерческую базу данных, такую ​​как Oracle или DB2, оба из которые реализуют MMR на основе журнала через общее хранилище и очень надежны.

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

Мне не удалось найти ссылки на аналогичные конфигурации, поэтому я думаю, вам просто придется потрудиться и провести много тестов.

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

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

У нас есть производственный кластер, который может быть похож на то, что вам интересно:

  • MySQL MMM для синхронизации баз данных между обоими серверами.
  • OCFS2 на вершине DRBD 0.8 в режиме с несколькими мастерами, чтобы синхронизировать веб-файлы и файлы конфигурации между обоими серверами.
  • Keepalived на резервных брандмауэрах перед веб-кластером, который отслеживает, какие серверы включены, и равномерно распределяет клиентские соединения между ними.

Его достаточно просто реализовать и продолжать работать, а также обеспечивает превосходно производительность. Keepalived может быть немного неудобным, потому что он не помещает суперпользовательские ошибки в системный журнал о сломанных конфигурациях, но как только он заработает, он прочен. DRBD - это лучшее решение, отличное от SAN, для обеспечения синхронизации целых файловых систем между машинами, а OCFS2 (в наших тестах) является наиболее производительной кластерной файловой системой с открытым исходным кодом, и ее настройка также очень проста.

Единственное реальное предостережение, связанное с этим, заключается в том, что если пользовательские соединения направляются на один сервер, а затем они переключаются на другой сервер, он потеряет сеанс Apache / PHP и данные состояния (если только это не все хранится в базе данных). . Это не имеет большого значения, поскольку keepalived имеет режим, который гарантирует, что одни и те же клиентские IP-адреса всегда подключаются к одним и тем же внутренним серверам (при условии, что они не работают).

Какую ОС (Linux) используете? обычно, когда вам нужно настроить кластер Mysql / Apache, у меня много времени на настройку для нашего клиента

| SAN Box |

| | Узел1 Узел2

запущенные службы

VIP Mysql / Apache LVM / GFS / GFS2

и я предлагаю следующую ссылку для настройки

http://kbase.redhat.com/faq/docs/DOC-5648