Репликация MySQL через географически отдельные серверы

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

Первоначально я имею в виду Rails на MySQL. Скорость записи не слишком высока (статьи / комментарии оставляются со скоростью менее 1 в минуту, хотя некоторые имеют большие медиа-вложения).

Так,

• репликация MySQL хорошо работает в глобальных сетях?
• Означает ли обрыв соединения (или подчиненного сервера), что требуется ручное вмешательство (когда два сервера снова могут общаться друг с другом), или восстановление происходит автоматически?
• Если мастер исчезает, что требуется для превращения раба в мастера? Существуют ли стандартные сценарии / инструменты, помогающие справиться с этим?
• Любые другие ошибки и т. Д.?

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

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

Если у вас есть два сервера, и мастер исчезает, то, чтобы превратить подчиненное устройство в «мастер», просто остановите репликацию и измените свой код (чтобы записать новый «мастер»). Если у вас есть три или более серверов, и мастер исчезает, остановите репликацию на ведомых, измените их на использование нового мастера и начните снова. Если они не синхронизированы (зависит от того, сколько данных передается, насколько заняты серверы, насколько хорошо сетевое соединение и т. Д.), Вам, возможно, придется выполнять больше работы, чем это. Раздел репликации документации MySQL описывает это более подробно .

Я бы посоветовал вам убедиться в том, что вы выполняете репликацию по SSL (т. Е. Настроить для пользователя репликации требование SSL-соединения).

Репликация резко изменилась в MySQL 5.1. В 5.0 использовалась только репликация на основе операторов. Теперь у вас есть возможность выполнять репликацию на основе строк или смешанную репликацию. Это сильно повлияет на вашу репликацию по глобальной сети.

Если у вас есть возможность: A) Принимать IP-адреса (если ваши серверы географически разделены, это маловероятно) B) Внести гибкие изменения DNS Вы можете избежать изменения кода / конфигурации приложения для изменения мастеров. Мы используем внутренний DNS с коротким кэшированием и поддельными доменами .internal. Если нам нужно изменить masterdb.internal на какой-то другой сервер, то через 5 секунд изменение вступит в силу.

В рамках одного центра обработки данных мы используем IP-контроль. Все серверы БД имеют виртуальные интерфейсы (eth0: 1, eth0: 2, eth0: 3), которые не загружаются при загрузке. Если один из рабов должен вступить во владение, вы просто ifup eth0: 2, и это хозяин. В этом сценарии eth0 - это «если», которое мы используем для оболочки и тому подобное. Приложения подключаются по eth0: 1, который не будет активирован при загрузке, если мой скрипт обнаружит, что IP-адрес занят. (Википедия STONITH) Другие ifs для принятия IP-адресов мастеров, которые могут потребоваться для отказа.

Я бы не рекомендовал пересекать океаны при использовании репликации MySQL. Я пытался однажды повторить реплику от хозяина в Европе, пока раб был в Техасе. Репликация нарушалась почти каждый день, пока мы не отказались от этого проекта. Конечно, это может сработать, но, как правило, оно становится более хрупким, чем больше расстояние между хозяином и рабом.