Назад | Перейти на главную страницу

Репликация MySQL для каждой базы данных?

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

Поэтому он попросил меня установить на новом сервере еще один экземпляр MySQL, позволить подчиненному устройству почти как есть и сделать новый экземпляр новым главным устройством постепенно, по одной базе данных за раз. Возможно ли, то есть я могу перенести базу данных «x» со старого ведущего на новый ведущий и просто сказать ведомому устройству синхронизировать «x» с новым ведущим с этого момента?

Я читал в этой старой ветке ( Mysql Replication - возможны ли потоки для каждой базы данных? ), что в то время это было невозможно. Это можно сделать сейчас?

Спасибо!

Лукас Брахер.

Да, ты можешь это сделать. Репликация MySQL позволяет вам указать, какие схемы реплицировать [1] или нет, ищите параметр replicate_wild_do_table.

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

[1] Подчиненное устройство по-прежнему будет получать полный бинлог, но выполнять только операторы, соответствующие фильтру (ам)

Вы мог сделать что-то подобное, но пользы нет.

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

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

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

Но давайте сделаем шаг назад и посмотрим, что вы действительно пытаюсь сделать:

Вы хотите перейти на новый сервер и позволить ведомому устройству быть «главным» для одной базы данных за раз.

Это просто.

Итак, вот ваша репликация: Master -> Slave

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

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

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

Поэтому, если вы можете изменить конфигурацию своего приложения, чтобы использовать другую базу данных mysql для каждой базы данных, которую он пытается использовать, вы можете мигрировать на db за раз.

Просто.

Нет - репликация MySQL - это все или ничего (иш). Вы не можете подчинить один сервер MySQL двум отдельным мастерам.