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

Question

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

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

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

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

Какой будет лучший метод или инструмент для этого?

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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