репликация mysql - от ведущего к ведомому

Я успешно настроил мастер-ведомую среду, и она определенно работает нормально.

Единственная проблема, с которой я сталкиваюсь, заключается в том, что при выборе количества из таблицы они не совпадают, НО при выборе через 5 минут от мастера создается 50 строк, а на подчиненном устройстве также создается 50 строк (поэтому я сказал, что я уверен, что работает нормально)

Владелец:

+----------+
| COUNT(*) |
+----------+
|    77634 |
+----------+
1 row in set (0.00 sec)

Раб:

+----------+
| COUNT(*) |
+----------+
|    76932 |
+----------+
1 row in set (0.00 sec)

Есть идеи, почему это произошло? возможно ли, что когда я изменил ведомое устройство, чтобы оно указывало на ведущее устройство с помощью команды «CHANGE MASTER TO», позиция двоичного файла журнала @ ведущего устройства уже изменилась?


person hex4    schedule 07.09.2011    source источник
comment
ваш подчиненный не содержит последний снимок перед запуском репликации   -  person ajreal    schedule 07.09.2011
comment
Вы имеете в виду, что я не использовал правильную позицию двоичного файла журнала с sqldump, который я взял?   -  person hex4    schedule 07.09.2011
comment
Скорее всего, вы не заблокировали master от записи при создании дампа.   -  person ajreal    schedule 07.09.2011


Ответы (2)


Попробуйте 'SHOW SLAVE STATUS' на подчиненном устройстве, чтобы увидеть, не возникли ли какие-либо ошибки.

Вы также можете попробовать загрузить данные с мастера, чтобы восстановить синхронизацию.

person John M    schedule 07.09.2011

Репликация MySQL не является «надежной» и не может автоматически повторно синхронизироваться, если что-то пойдет не так. Есть много способов, как это может пойти не так, даже без незапланированных перезагрузок и т. д.

Вам нужно АКТИВНО следить за ним, чтобы иметь шанс на то, что он будет работать в течение любого промежутка времени.

Вам нужно, по крайней мере, сделать две вещи:

  1. Проверьте выходные данные SHOW SLAVE STATUS (на каждом ведомом устройстве), чтобы убедиться, что потоки работают, об ошибках не сообщается, а значение second_behind_master не слишком велико.
  2. Периодически запускайте какую-то проверку согласованности на каждом ведомом/ведущем — я рекомендую mk-table-checksum с опцией --replication

И подключите результаты этих проверок к вашей системе мониторинга, чтобы ваш операционный персонал был предупрежден.

Ваш оперативный персонал также должен знать, как это исправить (дамп/восстановление или какое-то другое исправление). Вам обязательно нужно будет написать какую-нибудь статью в базу знаний для Ops.

Я делал это раньше - это не тривиально, и вы можете легко ошибиться.

person MarkR    schedule 07.09.2011