Создайте подчиненный 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, чтобы мастер мог различить двух ведомых.