Смешивание Multi-Master Replication (MMR) с Linux-HA

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

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

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

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

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

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

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

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

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

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

Он достаточно прост в реализации и продолжает работать и обеспечивает отличную производительность. 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