Создайте подчиненный MySQL из другого ведомого, но направьте его на мастер

проблема

У меня есть настройка репликации MySQL между 2 серверами, master (A) и slave (B). Мне нужно добавить нового раба в смесь (С). Я хочу, чтобы это ведомое устройство получало обновления непосредственно от главного устройства, я не хочу репликации цепей от подчиненного устройства. Тем не менее, мастер "горячий", я обычно использую Xtrabackup для создания полной резервной копии мастера, но это блокирует его на хорошие 10 минут, так как размер базы данных составляет около 20 ГБ.

Возможное решение

ПРОМЫШЛЕННЫЕ СТОЛЫ С ЧИТАЮЩЕЙСЯ БЛОКИРОВКОЙ на подчиненном устройстве B, используйте SHOW SLAVE STATUS на B, запишите binlog и position. Затем создайте резервную копию базы данных с помощью Xtrabackup, отправьте резервную копию на C и используйте ее для создания ведомого устройства и установите для репликации указатель на A с позицией binlog, которую я только что записал.

Вопрос

Есть ли лучший способ, который не требует, чтобы я заблокировал B так долго? Или что-то, что легче автоматизировать?

6 ответов

Решение

Эй, я знаю сумасшедший способ создания ведомого без увеличения какой-либо операции ведущего (ServerA) или ведомого (ServerB)

Шаг 1) Настройте новый сервер (ServerC)

Шаг 2) На ServerC, установите MySQL (той же версии, что и ServerB)

Шаг 3) На сервере С остановка службы mysql

Шаг 4) Скопируйте /etc/my.cnf с сервера B на сервер C

Шаг 5) На ServerC измените server_id на значение, отличное от ServerA и ServerB

Шаг 6) rsync /var/lib/mysql с сервера B на сервер C

Шаг 7) Когда rsync завершится, запустите "STOP SLAVE;" на сервере B

Шаг 8) rsync /var/lib/mysql на сервере B для сервера C

Шаг 9) На сервере B запустите "START SLAVE;"

Шаг 10) На сервере С запускается служба mysql

Шаг 11) На сервере C запустите "НАЧАТЬ РАБА;" (Сделайте это, если skip-slave-start находится в /etc/my.cnf)

Попробуйте!

Кстати, я абсолютно уверен, что это сработает, потому что я только что сделал это для клиента за последние 2 дня. Клиент имел 2,7 ТБ данных на ведомом устройстве. Я rsyncd на другой сервер, пока ведомое устройство было еще активно. rsync занял около 11 часов. Я тогда побежал ОСТАНОВИТЬ РАБА; на первом рабе и снова запустил rsync. Это заняло еще час. Затем я выполнил вышеуказанный шаг, и все готово.

Когда мы добавляем раба в наш микс, мы делаем следующее:

  • отключить одного раба
  • скопируйте каталог данных базы данных на нового ведомого устройства (настройки подчиненного устройства -binlog position, master host и т. д. - будут правильными, поскольку мы скопировали с подчиненного устройства)
  • запустить первоначальный раб
  • изменить идентификатор сервера в my.cnf для нового ведомого
  • начать новый раб

Я сделал то, что предлагает @RolandoMySQLDBA, но также добавил шаги 6' и 8' (это решает то, что комментирует @Hussain Tamboli.):

Шаг 1) Настройте новый сервер (ServerC)

Шаг 2) На ServerC, установите MySQL (той же версии, что и ServerB)

Шаг 3) На сервере С остановка службы mysql

Шаг 4) Скопируйте /etc/my.cnf с сервера B на сервер C

Шаг 5) На ServerC измените server_id на значение, отличное от ServerA и ServerB

Шаг 6) rsync /var/lib/mysql с сервера B на сервер C

Шаг 6') rsync / var /log/ mysql с сервера B на сервер C

Шаг 7) Когда rsync завершится, запустите "STOP SLAVE;" на сервере B

Шаг 8) rsync /var/lib/mysql на сервере B для сервера C

Шаг 8 ') rsync / var /log/ mysql с сервера B на сервер C

Шаг 9) На сервере B запустите "START SLAVE;"

Шаг 10) На сервере С запускается служба mysql

Шаг 11) На сервере C запустите "НАЧАТЬ РАБА;" (Сделайте это, если skip-slave-start находится в /etc/my.cnf)

У вас есть опция "ЗАГРУЗИТЬ ДАННЫЕ ИЗ МАСТЕРА", но это крайне не рекомендуется.

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

Я попробовал ответы Роландо и работал нормально, но он начал воспроизводиться с самого начала, и мне пришлось добавить больше кода ошибки, чтобы пропустить (я знаю, что это не рекомендуется, но я знаю, что я делал).

После выполнения шага 7 я проверил журнал mysql, записал имя и позицию журнала бина и продолжил до 9-го шага. Перед 10-м шагом я просто выполнил change master для файла журнала и позиции журнала. И продолжил с шага 11. Все выглядит нормально для меня.

Вам нужно изменить ведомый uuid в auto.cnf, чтобы мастер мог различить двух ведомых.

Другие вопросы по тегам