Моя организация изучает, как географически распределить наши серверы, сохраняя при этом резервные копии в актуальном состоянии и в идеале распределяя нагрузку.
Вначале я имел в виду Rails on MySQL. Скорость записи не слишком высока (статьи / комментарии оставляются менее 1 в минуту, хотя у некоторых есть большие медиа-вложения).
Так,
Мы используем репликацию в центрах обработки данных в нескольких европейских странах (поэтому они не находятся в разных частях света друг от друга, но определенно не являются локальными), и это работает без каких-либо проблем.
Если возможно, репликация автоматически перезапустится. Если есть проблема с запросом (например, база данных присутствует на главном устройстве, а не на подчиненном, и запрос использует его), то по умолчанию потребуется ручное исправление (но вы можете настроить его так, чтобы такие ошибки игнорировались). Если базы данных являются точными зеркалами, вам никогда не придется перезапускать репликацию вручную.
Если у вас есть два сервера и главный исчезает, то чтобы превратить подчиненное устройство в «главное», просто остановите репликацию и измените свой код (для записи в новый «главный»). Если у вас есть три или более серверов, и главный исчезает, остановите репликацию на подчиненных, измените их на использование нового главного и начните заново. Если они не совсем синхронизированы (зависит от того, сколько данных передается, насколько загружены серверы, насколько хорошее сетевое соединение и т. Д.), Вам, возможно, придется выполнить больше работы. В разделе репликации документации MySQL это рассматривается более подробно..
Я бы посоветовал вам убедиться, что вы реплицируете через SSL (т.е. установите для пользователя репликации требование SSL-соединения).
Репликация сильно изменилась в MySQL 5.1. В версии 5.0 использовалась только репликация на основе операторов. Теперь у вас есть возможность выполнять репликацию на основе строк или смешанную репликацию. Это сильно повлияет на репликацию через глобальную сеть.
Если у вас есть возможность: A) Принять IP-адрес (если ваши серверы географически разделены, это маловероятно) B) Вносить гибкие изменения DNS. Вы можете избежать изменения кода / конфигурации приложения для смены мастеров. Мы используем внутренний DNS с коротким кешированием и поддельными доменами .internal. Если нам нужно изменить masterdb.internal на какой-то другой сервер, через 5 секунд изменение вступит в силу.
В рамках единого центра обработки данных мы используем IP-захват. Все серверы БД имеют виртуальные интерфейсы (eth0: 1, eth0: 2, eth0: 3), которые не запускаются при загрузке. Если одно из ведомых устройств должно взять на себя управление, вы просто запустите eth0: 2, и он станет мастером. В этом сценарии eth0 - это «если», которое мы используем для оболочки и тому подобное. Приложения подключаются к eth0: 1, который не будет активирован при загрузке, если мой скрипт обнаружит, что IP-адрес занят. (википедия STONITH) Другие «если» предназначены для перехвата IP-адресов мастеров, которые, возможно, потребуется переключить.
Я бы не рекомендовал пересекать океаны при использовании репликации MySQL. Однажды я попытался выполнить репликацию от мастера в Европе, пока раб был в Техасе. Репликация ломалась почти каждый день, пока мы не отказались от этого проекта. Конечно, это может сработать, но оно становится тем более хрупким, чем больше расстояние между ведущим и ведомым.