MySQL двойное ведущее устройство

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

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

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

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

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

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

будет сломана система. И если что-то сначала сломается, вся система остановится.

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

будет сломана система. И если что-то сначала сломается, вся система остановится.

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

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

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

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

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

Было хорошим упражнением быть частью, но я бы не стал делать это снова. Не в MySQL.

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

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

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

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