Каким будет мой лучший метод синхронизации MySQL?

Question

Мы перемещаем службу социальных сетей в отдельные центры обработки данных, так как весь центр обработки данных нашего другого хостинг-провайдера снизился. Дважды.

Это означает, что оба сайта должны быть синхронизированы в некотором смысле - меня меньше беспокоит код страниц, который достаточно прост для синхронизации, но они должны иметь одни и те же данные базы данных.

Из моих исследований на SO, кажется, MySQL репликация является хорошим вариантом, но руководство MySQL, для масштабирования, говорит, что его лучше всего, когда есть гораздо больше чтений, то есть записи/обновления: http://dev.mysql.com/doc/refman/5.0/en/replication-solutions-scaleout.html

В нашем случае это примерно одинаково. Сейчас мы получаем около 200-300 тысяч запросов в день, и мы можем быстро расти. Каждый запрос является запросом на чтение и запись.

Что было бы лучшим методом или инструментом для этого?

Answer 1

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

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

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

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

Кроме того, наш главный узел находится на двух разных интернет-провайдерах, поэтому один провайдер, который работает, не сводит нас с ума.

Answer 2

Достаточно ли скорость соединения между двумя центрами обработки данных? Вы можете копировать файлы на новый сервер и перемещать туда базу данных. А затем настройте старый сервер, чтобы он подключался к базе данных MySQL нового сервера в другом DC? Конечно, это будет медленнее, но в зависимости от характера ваших запросов это может быть приемлемым. Как только DNS или что-то изменится/закончится, вы просто отключите старый сервер, если на него больше нет запросов.

Answer 3

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

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

Например, если ваш RPO не потерял транзакции и не восстановился через 5 минут, тогда решение будет отличаться, если вы можете позволить себе потерять 5 минут транзакций и час для восстановления.

Еще один вопрос, который я задал бы, если вы используете хранилище SAN вообще? Это дает вам варианты репликации на уровне хранилища (массив SAN в массив SAN), а не на уровне базы данных (например, репликация MySQL).

также рассмотреть расстояние между датацентров (например Timewise вы можете себе позволить, чтобы выполнить синхронное запись в обеих базах данных, или же асинхронный подход репликации более уместно)