Как повторно синхронизировать Mysql DB, если Master и Slave имеют разные базы данных в случае репликации Mysql? - PullRequest
130 голосов
/ 02 марта 2010

Mysql Server1 работает как MASTER .
Mysql Server2 работает как SLAVE .

Теперь репликация БД происходит от MASTER до SLAVE .

Server2 удален из сети и повторно подключите его через 1 день. После этого происходит несоответствие в базе данных в ведущем и ведомом устройствах.

Как выполнить повторную синхронизацию БД, поскольку после восстановления БД, переданной от ведущего к ведомому, проблема также не решается?

Ответы [ 13 ]

270 голосов
/ 12 июля 2010

Это полная пошаговая процедура для повторной синхронизации репликации главный-подчиненный с нуля:

У мастера:

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

И скопировать значения результата последней команды куда-нибудь.

Не закрывая соединение с клиентом (поскольку это снимет блокировку чтения), введите команду для получения дампа мастера:

mysqldump -u root -p --all-databases > /a/path/mysqldump.sql

Теперь вы можете снять блокировку, даже если дамп еще не закончился. Для этого выполните следующую команду в клиенте MySQL:

UNLOCK TABLES;

Теперь скопируйте файл дампа на ведомое устройство, используя scp или предпочитаемый вами инструмент.

У раба:

Откройте соединение с MySQL и введите:

STOP SLAVE;

Загрузить дамп данных мастера с помощью этой команды консоли:

mysql -uroot -p < mysqldump.sql

Синхронизировать ведомые и ведущие журналы:

RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98;

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

Наконец, введите:

START SLAVE;

Чтобы проверить, что все снова работает, после ввода:

SHOW SLAVE STATUS;

вы должны увидеть:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Вот и все!

24 голосов
/ 29 октября 2013

Документация по этому вопросу на сайте MySQL крайне устарела и изобилует ножными ружьями (такими как interactive_timeout). Выдача FLUSH TABLES с READ LOCK как часть экспорта мастера обычно имеет смысл только при координации со снимком хранилища / файловой системы, такой как LVM или zfs.

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

Предположим, что главное устройство - 192.168.100.50, а ведомое - 192.168.100.51, для каждого сервера настроен отдельный идентификатор сервера, для главного устройства есть двоичный вход в систему, а для ведомого устройства только для чтения = 1 в my.cnf

Чтобы подготовить подчиненное устройство к возможности начать репликацию сразу после импорта дампа, введите команду CHANGE MASTER, но пропустите имя и позицию файла журнала:

slaveserver> CHANGE MASTER TO MASTER_HOST='192.168.100.50', MASTER_USER='replica', MASTER_PASSWORD='asdmk3qwdq1';

Выпустите GRANT на ведущем устройстве для использования ведомым:

masterserver> GRANT REPLICATION SLAVE ON *.* TO 'replica'@'192.168.100.51' IDENTIFIED BY 'asdmk3qwdq1';

Экспорт мастера (на экране) с использованием сжатия и автоматической фиксации правильных двоичных лог-координат:

mysqldump --master-data --all-databases --flush-privileges | gzip -1 > replication.sql.gz

Скопируйте файл replication.sql.gz на ведомое устройство, а затем импортируйте его с zcat в экземпляр MySQL, работающий на ведомом устройстве:

zcat replication.sql.gz | mysql

Запустите репликацию, введя команду на ведомое устройство:

slaveserver> START SLAVE;

При необходимости обновите файл /root/.my.cnf на ведомом устройстве, чтобы сохранить тот же пароль root, что и на главном устройстве.

Если вы используете 5.1+, лучше сначала установить binlog_format мастера на MIXED или ROW. Помните, что события, зарегистрированные в строке, являются медленными для таблиц, в которых отсутствует первичный ключ. Обычно это лучше, чем альтернативная (и используемая по умолчанию) конфигурация оператора binlog_format = (на ведущем устройстве), поскольку с меньшей вероятностью выдает неверные данные на ведомом устройстве.

Если вы должны (но, вероятно, не должны) фильтровать репликацию, сделайте это с опциями ведомого устройства replicate-wild-do-table = dbname.% Или replicate-wild-ignore-table = badDB.% И используйте только binlog_format = row

Этот процесс будет удерживать глобальную блокировку на мастере на время выполнения команды mysqldump, но не будет влиять на мастер.

Если у вас возникает соблазн использовать mysqldump --master-data --all-database --single -action (поскольку вы используете только таблицы InnoDB), возможно, вам лучше использовать MySQL Enterprise Backup или реализацию с открытым исходным кодом, называемую xtrabackup. (любезно предоставлено Percona)

17 голосов
/ 09 марта 2010

Если вы не пишете напрямую на подчиненное устройство (Сервер2), единственной проблемой должно быть то, что на Сервере2 отсутствуют какие-либо обновления, произошедшие с момента его отключения. Просто перезапустите раб с помощью «START SLAVE;» должно вернуть все на скорость.

7 голосов
/ 02 марта 2010

Я думаю, утилиты Maatkit помогут вам! Вы можете использовать mk-table-sync. Пожалуйста, смотрите эту ссылку: http://www.maatkit.org/doc/mk-table-sync.html

5 голосов
/ 20 января 2016

Я очень опоздал на этот вопрос, однако я столкнулся с этой проблемой, и после долгих поисков я нашел эту информацию от Брайана Кеннеди: http://plusbryan.com/mysql-replication-without-downtime

На Master сделайте резервную копию следующим образом:
mysqldump --skip-lock-tables - одиночные транзакции --flush-logs --hex-blob --master-data = 2 -A> ~ / dump.sql

Теперь проверьте заголовок файла и запишите значения для MASTER_LOG_FILE и MASTER_LOG_POS. Они понадобятся вам позже: head dump.sql -n80 | grep "MASTER_LOG"

Скопируйте файл "dump.sql" в Slave и восстановите его: mysql -u mysql-user -p <~ / dump.sql </strong>

Подключитесь к Slave mysql и выполните команду, подобную этой: ИЗМЕНИТЬ MASTER TO MASTER_HOST = 'master-server-ip', MASTER_USER = 'replication-user', MASTER_PASSWORD = 'slave-server-password', MASTER_LOG_FILE = 'значение сверху', MASTER_LOG_POS = значение сверху; НАЧАТЬ РАБА;

Чтобы проверить прогресс Раба: ПОКАЗАТЬ СТАТУС РАБА;

Если все хорошо, Last_Error будет пустым, а Slave_IO_State сообщит «Ожидание, когда мастер отправит событие». Ищите Seconds_Behind_Master, который указывает, насколько далеко он позади. YMMV. :)

5 голосов
/ 22 апреля 2013

Продолжение ответа Дэвида ...

Использование SHOW SLAVE STATUS\G даст читабельный вывод.

5 голосов
/ 19 марта 2010

Вот что я обычно делаю, когда раб MySQL отключается от синхронизации. Я посмотрел на mk-table-sync, но подумал, что раздел «Риски» выглядит страшно.

На Мастере:

SHOW MASTER STATUS

Выведенные столбцы (File, Position) пригодятся нам немного позже.

На подчиненном:

STOP SLAVE

Затем сбросьте главную базу данных и импортируйте ее в подчиненную базу данных.

Затем выполните следующее:

CHANGE MASTER TO
  MASTER_LOG_FILE='[File]',
  MASTER_LOG_POS=[Position];
START SLAVE;

Где [File] и [Position] - значения, выведенные из "SHOW MASTER STATUS", запущенного выше.

Надеюсь, это поможет!

4 голосов
/ 15 октября 2014

иногда вам просто нужно дать удар рабу тоже

попробовать

stop slave;    
reset slave;    
start slave;    
show slave status;

довольно часто, рабы, они просто застряли, ребята:)

2 голосов
/ 22 мая 2013

Добавление к популярному ответу для включения этой ошибки:

"ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO",

Репликация с раба в один выстрел:

В одном окне терминала:

mysql -h <Master_IP_Address> -uroot -p

После подключения

RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Статус выглядит следующим образом: Обратите внимание, что номер позиции меняется!

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      98  | your_DB      |                  |
+------------------+----------+--------------+------------------+

Экспортируйте дамп, аналогично тому, как он описал «, используя другой терминал »!

Выйдите и подключитесь к своей собственной БД (которая является подчиненной):

mysql -u root -p

Введите следующие команды:

STOP SLAVE;

Импортируйте дамп, как указано (в другом терминале, конечно же!), И введите следующие команды:

RESET SLAVE;
CHANGE MASTER TO 
  MASTER_HOST = 'Master_IP_Address', 
  MASTER_USER = 'your_Master_user', // usually the "root" user
  MASTER_PASSWORD = 'Your_MasterDB_Password', 
  MASTER_PORT = 3306, 
  MASTER_LOG_FILE = 'mysql-bin.000001', 
  MASTER_LOG_POS = 98; // In this case

После регистрации установите параметр server_id (обычно для новых / нереплицированных БД по умолчанию это не установлено),

set global server_id=4000;

Теперь запустите раб.

START SLAVE;
SHOW SLAVE STATUS\G;

Вывод должен быть таким же, как он описал.

  Slave_IO_Running: Yes
  Slave_SQL_Running: Yes

Примечание. После репликации главный и подчиненный устройства используют один и тот же пароль!

2 голосов
/ 05 октября 2011

Вот полный ответ, который, надеюсь, поможет другим ...


Я хочу настроить репликацию mysql, используя master и slave, и поскольку я знал только то, что он использует файлы журналов для синхронизации, если slave переходит в автономный режим и выходит из синхронизации, теоретически ему нужно только подключиться к своему мастеру и продолжить чтение файла журнала с того места, где он остановился, как упомянул пользователь malonso.

Итак, вот результаты теста после настройки главного и подчиненного, как указано: http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html ...

При условии, что вы используете рекомендуемую конфигурацию master / slave и не записываете на slave, он и я, где прав (в отношении mysql-server 5.x). Мне даже не нужно было использовать «START SLAVE;», он просто догнал своего хозяина. Но по умолчанию 88000 что-то повторяет каждые 60 секунд, так что я думаю, если вы исчерпали, что вам, возможно, придется запустить или перезапустить подчиненное устройство. В любом случае, для тех, кто, как я, хотел знать, требуется ли ручное вмешательство для перехода в автономный режим и резервного копирования. Нет, это не так.

Может быть, оригинальный постер был поврежден в лог-файле (файлах)? Но, скорее всего, это не просто отключение сервера на один день.


извлечено из /usr/share/doc/mysql-server-5.1/README.Debian.gz, что, вероятно, имеет смысл и для серверов, не являющихся debian:

* FURTHER NOTES ON REPLICATION
===============================
If the MySQL server is acting as a replication slave, you should not
set --tmpdir to point to a directory on a memory-based filesystem or to
a directory that is cleared when the server host restarts. A replication
slave needs some of its temporary files to survive a machine restart so
that it can replicate temporary tables or LOAD DATA INFILE operations. If
files in the temporary file directory are lost when the server restarts,
replication fails.

вы можете использовать что-то вроде sql: показать переменные типа 'tmpdir'; , чтобы узнать.

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