MySQL Dual Master

Question

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

Кроме того, мне любопытно, какие у меня есть другие варианты решения этой проблемы; мы рассматриваем очереди сообщений.

Спасибо!

Answer 1

Просто примечание о технических аспектах вашего плана: вы должны знать, что MySQL официально не поддерживает мультимастерную репликацию (только MySQL Cluster обеспечивает поддержку синхронной репликации).

Но есть по крайней мере один «взлом», который делает возможной репликацию с несколькими хозяевами даже при обычной настройке репликации MySQL. Пожалуйста, см. Патрик Гэлбрейт "MySQL Multi-Master Replication" для возможного решения. У меня нет никакого опыта с этой установкой, поэтому я не осмелюсь судить о том, насколько осуществимым будет такой подход.

Answer 2

Настройка mysql как dual master на самом деле работает нормально в правильном сценарии, выполненном правильно. Но я не уверен, что это очень хорошо вписывается в ваш сценарий.

Прежде всего, настройка двойного мастера в mysql - это действительно настройка вызова. Сервер A определен как ведущий для B, в то время как B в то же время определен как ведущий для A, поэтому оба сервера действуют как ведущие и ведомые. Репликация работает путем отправки двоичного журнала, содержащего операторы sql, которые ведомое устройство вставляет по своему усмотрению, что обычно происходит сразу же. Но если вы забиваете его локальными вставками, потребуется некоторое время, чтобы наверстать упущенное. Кстати, ведомые вставки являются последовательными, поэтому вы не получите никакой выгоды от использования нескольких ядер и т. Д.

Основное использование двойного мастера mysql - резервирование на уровне сервера с автоматическим переключением при сбое (часто с использованием beatbeat в linux). За исключением mysql-cluster (по разным причинам), это единственное используемое автоматическое аварийное переключение для mysql. Настройка для базового двойного мастера легко найти в google . Сердцебиение - это немного больше работы. Но на самом деле это не то, о чем вы спрашивали, потому что это действительно ведет себя как один сервер базы данных.

Если вам нужна настройка двойного мастера, потому что вы всегда хотите писать в локальную базу данных (пишите в обе из них одновременно), вам нужно будет написать ваше приложение с учетом этого. Вы никогда не можете иметь автоматически увеличивающиеся значения в базе данных, и когда у вас есть уникальные значения, вы должны убедиться, что в двух местах никогда не записывается одно и то же значение. Например, местоположение A может записывать нечетные уникальные числа, а местоположение B может записывать четные уникальные числа. Причина в том, что вы не гарантированы, что серверы синхронизированы в любой момент времени, поэтому, если вы вставили уникальную строку в A, а затем пересекающуюся уникальную строку в B до того, как второй сервер перехватит, вы будете иметь сломанную систему. И если что-то сначала сломается, вся система остановится.

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

Answer 3

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

Answer 4

Из-за архитектуры репликации MySQL «один ко многим» необходимо иметь кольцо репликации с несколькими хозяевами, то есть каждый реплицируется из следующего в цикле. На двоих они дублируют друг друга. Это было поддержано еще в v3.23.

В предыдущем месте, где я работал, мы делали это с v3.23 с довольно большим количеством клиентов, чтобы предоставить именно то, что вы просите. Для репликации мы использовали SSH-туннели через Интернет. Нам потребовалось некоторое время, чтобы сделать его надежным, и несколько раз нам приходилось делать двоичные копии одной базы данных в другую (к счастью, ни одна из них не занимала более 2 ГБ и не нуждалась в 24-часовом доступе). Кроме того, репликация в v3 была не такой стабильной, как в v4, но даже в v5 она просто остановится, если обнаружит какую-либо ошибку.

Чтобы учесть неизбежную задержку репликации, мы реструктурировали приложение так, чтобы оно не полагалось на поля AUTOINCREMENT (и удалили этот атрибут из таблиц). Это было достаточно просто из-за уровня доступа к данным, который мы разработали; вместо того, чтобы использовать mysql_insert_id() для новых объектов, он сначала создал новый идентификатор и вставил его вместе с остальной частью строки. Мы также внедрили идентификаторы сайтов, которые мы сохранили в верхней половине идентификатора, потому что они были BIGINT с. Это также означало, что нам не нужно было менять приложение, когда у нас был клиент, которому нужна база данных в трех местах. : -)

Это не было на 100% устойчиво. InnoDB только что получил некоторую видимость, поэтому мы не могли легко использовать транзакции, хотя мы это и рассматривали. Поэтому иногда возникали условия гонки, когда два объекта пытались создать с одинаковым идентификатором. Это означало один сбой, и мы попытались сообщить об этом в приложении. Но это все еще была значительная часть чьей-то работы - следить за репликацией и исправлять ее, когда она сломалась. Важно, чтобы исправить это, прежде чем мы слишком далеко вышли из синхронизации, потому что в некоторых случаях базы данных использовались на на обоих сайтах, и было бы очень трудно реинтегрировать, если бы нам пришлось перестраивать один. 1012 *

Это было хорошее упражнение - участвовать, но я бы не стал его делать снова. Не в MySQL.