Как вы синхронизируете изменения основной базы данных MySQL с изменениями ведомой базы данных, если мастер отключается?

11

MySQL Server 1 работает как Master.
MySQL Server 2 работает как Slave.

С обеими БД в сети они находятся в "идеальной синхронизации". Если Slave переходит в автономный режим, нет проблем, если Мастер все еще в сети; они вернутся к синхронизации, как только ведомый снова будет в сети.

Помимо конфигурации сервера, я перенаправил соединение (с кодом JSP) для подчиненной БД, если мастер переходит в автономный режим (я тестировал, конечно, с /etc/init.d/mysqld stop).

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

mysql replication

— RolandoMySQLDBA
источник

8

Один хороший способ добиться чего-то подобного - настроить репликацию Master-Master или кольцевую репликацию. Это не следует путать с MultiMaster Replciation.

Настроить кольцевую репликацию на самом деле очень просто, если у вас есть настройка Master-Slave Replication. Вот что вам нужно сделать, чтобы настроить его.

В этом примере мы будем предполагать, что репликация Master-Slave активна, но у вас будет некоторое время простоя (1-2 минуты):

Шаг 1) Добавьте эту строку в /etc/my.cnf на Мастере.

войти рабское обновление

Шаг 2) Добавьте эти строки в /etc/my.cnf на подчиненном устройстве:

log-bin = mysql-bin (или иметь то, что мастер имеет для этого) log-slave-updates

ВНИМАНИЕ: Вот краткий момент простоя !!!

Шаг 3) На ведомом, перезапуск службы mysql

Это активирует двоичные журналы на ведомом

Шаг 4) На Мастере, остановка службы mysql

Шаг 5) Используйте rsync, чтобы скопировать папку / var / lib / mysql Ведомого в Мастер.

ВНИМАНИЕ: Вот и более длительный момент простоя !!!

Шаг 6) На ведомом, остановка службы mysql

Шаг 7) На ведомом устройстве найдите последний двоичный журнал

Шаг 8) На ведомом устройстве выясните размер файла последнего двоичного журнала

Шаг 9) Используйте rsync, чтобы скопировать папку / var / lib / mysql Ведомого в Мастер. Это должно быть более быстрой копией.

Шаг 10) На
ведущем устройстве отредактируйте строку 2 master.info с последним двоичным журналом ведомого устройства.
Строка 3 из master.info с размером файла последнего двоичного журнала ведомого устройства.
Строка 4 из master.info с IP Ведомого.
Строка 5 - это идентификатор пользователя пользователя репликации (НЕ ПРИКАСАЙТЕСЬ)
Строка 6 - это пароль пользователя репликации (НЕ ПРИКАСАЙТЕСЬ)

Шаг 11) Удалите все двоичные журналы и двоичный индексный файл журнала Мастера.

Шаг 12) На Slave запустите службу mysql, подождите 15 секунд

Шаг 13) На Мастере запускается служба mysql

Шаг 14) На Мастере запустите STOP SLAVE; ПОКАЗАТЬ МАСТЕР СТАТУС;

Шаг 15) На ведомом устройстве запустите команду CHANGE MASTER TO MASTER_HOST = 'IP подчиненного устройства', MASTER_USER = 'ИД пользователя-пользователя репликации из шага 10', MASTER_PASSWORD = 'пароль пользователя репликации из шага 10', MASTER_LOG_FILE = 'двоичный журнал из шага 14', MASTER_LOG_POS = LogPos с шага 14.

Шаг 16) На ведомом устройстве запустите START SLAVE;

Шаг 17) На Мастере запустите START SLAVE;

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

Попробуйте!

— RolandoMySQLDBA
источник

Очень хорошо! Возможно ли иметь более одной ведомой базы данных, синхронизирующейся с мастером, больше похоже на решение «Мастер-Мастер-Мастер»?

— Герберт Амарал,

Это сломало мои настройки без возможности ремонта. Пришлось полностью переустановить мой VPS. Я думаю, что сделаю снимок, прежде чем читать хитрый совет в следующий раз.

— Василий Сиракис

@VasiliSyrakis Мне жаль, что вы чувствуете, что мой совет был хитрым. Несмотря на это, за 10 лет работы в качестве администратора баз данных MySQL я ни разу не уничтожил установку VPS или MySQL при изменении конфигурации двоичных журналов для репликации. Я делал это для клиентов Drupal и Wordpress много лет без происшествий. Извините за мой совет.

— RolandoMySQLDBA

Хм. Я бы не рекомендовал использовать rsync для копирования работающего экземпляра. Я бы использовал Percona XtraBackup для повторной инициализации мастера из подчиненного . Также вам не нужно, log-slave-updatesесли у хозяев не будет дополнительных рабов.

— Билл Карвин

2

Не с асинхронной репликацией, которую предлагает MySQL. Вы только что пришли к общему признанию того, почему репликация MySQL «из коробки» (до 5.5) сама по себе не является решением высокой доступности. Вещи становятся немного лучше с 5.5 с полусинхронной репликацией (http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html), но за счет более медленного времени транзакции, поскольку мастер ожидает Ack от раба.

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

Многие известные MySQL люди считали, что репликация Master to Master больше проблем, чем пользы (даже сама MySQL AB больше не рекомендует ее в качестве решения высокой доступности). Итак, я думаю, что использование DRBD для синхронизации активного мастера и пассивного ведомого с использованием копий на уровне блоков - это то, что вам действительно нужно здесь.

— TechieGurl
источник

1

Я люблю DRBD сам. Я работаю с ним регулярно со многими клиентами, использующими ucarp в качестве механизма восстановления после отказа. DRBD на самом деле очень хорош и предпочтителен для HA, при условии, что база данных - это InnoDB. Любая таблица MyISAM, открытая во время аварийного переключения, помечается как сбойная даже во вторичном сервере DRBD. InnoDB просто проходит восстановление после сбоя при переключении на новый DRBD Primary. Итак, я вижу, что DRBD и InnoDB используются вместе. Спасибо за ваш здравый смысл, чтобы поднять DRBD. +1 за ваш ответ.

— RolandoMySQLDBA

Спасибо :) и я предполагаю, что в своем ответе я предполагаю, что если вы так сильно заботитесь о согласованности данных между своими репликами, то вы уже все или в основном InnoDB :)

— TechieGurl

1

ИМХО, во-первых, в конфигурации не с несколькими хозяевами (ведущий / ведомый) ваш ведомый никогда не должен принимать записи. Должен быть настроен slave my.cnf, а сервер запущен с:

# Flag to not take writes from network
read-only

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

Наконец, если этот сценарий простоя / простоя является даже возможностью в будущем , найдите время, чтобы настроить оба хоста как мультимастерные (журнал, идентификатор сервера, смещения и т. Д.). Это поможет вам в некоторой степени уменьшить простои и простои.

Если вам нужно запустить master / slave , по крайней мере, получите несколько бонусных баллов за разделение пользовательских подключений для чтения и записи в вашем ACL и приложениях.

— randomx
источник