У меня есть система репликации мастер-мастер. Однако из-за проблемы с автоинкрементом у меня возникла ошибка репликации ... и репликация прекратилась.
Кто-то сказал мне сделать:
stop slave; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; start slave;
Это не сработало. Потом они сказали мне сделать:
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2;
Это не сработало. Затем, чтобы проверить это, я сделал:
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 99999;
Он запускается, но не обновляется. Я создал таблицу в DB1 ... и она не отображается в DB2 ...
Ниже показан СТАТУС SHOW для моего DB1 и DB2 (я ударил их вместе):
mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000605
Position: 2019727
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)
mysql> show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host:
Master_User:
Master_Port:
Connect_Retry: 60
Master_Log_File: mysql-bin.000605
Read_Master_Log_Pos: 2008810
Relay_Log_File: mysqld-relay-bin.001731
Relay_Log_Pos: 10176595
Relay_Master_Log_File: mysql-bin.000470
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 4255373725
Exec_Master_Log_Pos: 10176458
Relay_Log_Space: 135062517347
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 1376343
1 row in set (0.00 sec)
Как мне исправить это, чтобы они снова синхронизировались? Спасибо.
Вы действительно не понимаете, что делаете. Сначала вы должны получить дамп данных для защиты от любых повреждений.
Итак, вы используете репликацию Мастер-Мастер, верно?
Это звучит странно, поскольку вы предоставляете только один статус SLAVE и один статус MASTER, но нам понадобятся оба выхода статуса MASTER и оба SLAVE. Кроме того, здесь нет операторов replicate_ignore_ *, это не похоже на репликацию Master-Master. Кроме того, в СОСТОЯНИИ ПОДЧИНЕНИЯ нет сообщений об ошибках. Они бы показали любые ошибки репликации.
Как это исправить: получить чистый дамп от каждого мастера и вставить его на другой мастер. Это описано в руководстве по mysql, вот краткая версия:
mysql> FLUSH TABLES WITH READ LOCK;
$> mysqldump -uroot -p<pass> --opt --all-databases | gzip --fast > dump_master1.sql.gz
mysql> UNLOCK TABLES;
Помните: не выполняйте просто команду, которую вам сказали! Сначала посмотрите его в руководстве и проверьте, что он делает. Установка вашего SKIP_SLAVE_COUNTER на что-то вроде 9999 является причиной того, что ваша вновь созданная таблица не отображается на вашем ведомом устройстве, поскольку оно пропускает 9999 операторов sql, чего, вероятно, еще не произошло! Обычно вы не устанавливаете SKIP_SLAVE_COUNTER больше 1, затем выполняете START SLAVE и смотрите с помощью SHOW SLAVE STATUS, есть ли новые ошибки.
Если вам нужно сбросить подчиненные устройства и у вас есть хороший дамп с информацией об основных данных (mysqldump с параметром --master-data), вы можете использовать последний дамп для повторной синхронизации:
Подключитесь к ведомому устройству MySQL и выполните:
STOP SLAVE;
RESET SLAVE;
CHANGE MASTER to MASTER_USER='master user', MASTER_PASSWORD='master user password';
На подчиненном устройстве перезагрузите подчиненную базу данных из последнего имеющегося у вас главного дампа:
gzip -dc masterdump.sql.gz |mysql --user=username --password=password
Перезагрузите раб:
START SLAVE
Если все пойдет хорошо, ведомое устройство начнет репликацию с места последнего загруженного дампа. Это может занять некоторое время, поэтому проверьте SECONDS BEHIND MASTER, чтобы подождать, пока он догонит.
Seconds_Behind_Master: 1376343
Вот почему вы не видите созданную вами базу данных, потому что ведомое устройство все еще обрабатывает двоичный журнал мастера. Когда отстает от ведущего на 0 секунд, вы начнете видеть, как изменения, которые вы делаете, реплицируются на ведомое устройство.
Если ничего не помогает, удалите "плохой" мастер из службы, сделайте дамп и восстановите новую чистую копию базы данных. Для этого выполните обычные шаги для «добавления другого мастера».
Попробуйте посмотреть, не проблема ли это в брандмауэре. Попробуйте остановить и перезапустить раб. это: Slave_IO_Running: Да Slave_SQL_Running: Да означает, что вроде все в порядке ... не могли бы вы пропустить настройки репликации?
Обратите внимание, что, пропуская 99 999 событий журнала, ваш ведущий и ведомый, скорее всего, не будут содержать одинаковые данные. Вы можете использовать mk-table-контрольная сумма сценарий для проверки содержимого ведущего и ведомого.
Я никогда не пропускаю более одного события за раз и всегда стараюсь понять причину любых ошибок репликации. Если я получаю несколько / много ошибок репликации подряд, это обычно является признаком других проблем (например, повреждение таблицы / диска).