DB1 и DB2.
Я внес изменения в DB1, и, похоже, его нет в DB2. Когда я выполняю "SHOW SLAVE STATUS \ G" в DB2, похоже, возникает ошибка:
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.0005496
Read_Master_Log_Pos: 5445649315
Relay_Log_File: mysqld-relay-bin.0041705
Relay_Log_Pos: 1624302119
Relay_Master_Log_File: mysql-bin.0004461
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 1062
Last_Error: Error 'Duplicate entry '4779' for key 1' on query. Default database: 'falc'. Query: 'INSERT INTO `log` (`anon_id`, `created_at`, `query`, `episode_url`, `detail_id`, `ip`) VALUES ('fdzn1d45kMavF4qbyePv', '2009-11-19 04:19:13', 'amazon', '', '', '130.126.40.57')'
Skip_Counter: 0
Exec_Master_Log_Pos: 162301982
Relay_Log_Space: 136505187184
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: NULL
1 row in set (0.00 sec)
Затем я сделал показать таблицы, и похоже, что в DB2 отсутствует таблица, которую я создал на DB1 ... это означает, что по какой-то причине DB2 перестала синхронизироваться с DB1.
Как я могу просто позволить им снова полностью синхронизироваться?
Все, что я хочу, - это чтобы DB2 была точно такой же, как DB1!
Конфликтов первичных ключей можно избежать, установив значения auto_increment_increment и auto_increment_offset на обоих серверах.
Установите auto_increment_increment на одно и то же значение на обоих серверах (например, 4). Установите auto_increment_offset на РАЗНЫЕ значения на обоих серверах (например, 1 на сервере A, 2 на сервере B).
Это поможет избежать конфликта первичных ключей автоматического увеличения в будущем. Оба сервера mysql необходимо перезапустить, чтобы эта схема вступила в силу, и в идеале они должны быть синхронизированы, когда вы их перезапускаете.
Ваш системный администратор, вероятно, уже сделал все это, но это действительно похоже на конфликт ключей auto_increment.
Что касается вашего текущего затруднительного положения, проверьте строку с идентификатором 4779 в log таблица на обоих серверах. Если строки точно такие же, вы можете безопасно запустить SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; НАЧАТЬ РАБ; чтобы снова запустить репликацию.
Если они разные, вам нужно будет решить, какой из них оставить.
Имейте в виду, что любой оператор SQL insert / update / delete, который вы вводите, чтобы исправить это, в конечном итоге будет запущен на обоих серверах, поэтому подумайте очень внимательно.
Вы можете использовать SQL_LOG_BIN = 0; инструкция для запуска оператора только на одном ящике, чтобы исправить ошибку репликации.
Удачи!
Я предполагаю, что у вас где-то плохая расстановка стола. Репликация остановлена из-за сбоя репликационного запроса:
Повторяющаяся запись 4779 для ключа 1 в запросе
вы можете установить счетчик пропущенных запросов равным 1, а затем продолжить обработку, чтобы репликант пропустил неверный оператор и продолжил репликацию. Ваша таблица (возможно) появится вскоре после возобновления репликации. Однако вы должны спросить себя: «Почему этот запрос репликации завершился неудачно?». И тогда вы должны спросить себя: «Тебе повезло?» панк. Ну, а?
Репликация MySQL - это A-> B, а не A <-> B, поэтому убедитесь, что вы обновляете главную базу данных (A), которая реплицируется в подчиненную базу данных (B). Если нет, то, вероятно, это ваша проблема.