Принцип, лежащий в основе репликации MySQL, прост: если вы начинаете с двух одинаковых наборов данных, и каждый раз, когда вы меняете один, вы меняете другой, тогда эти два набора данных останутся идентичными.Вот как работает репликация MySQL: вы начинаете с двух одинаковых серверов, либо полностью пустых, либо с одного, являющегося точным снимком другого, и репликация просто выполняет одно и то же на обоих серверах.
Репликация выполняется через двоичный журнал ("binlog"), который фиксирует все изменения в мастере.В стандартной асинхронной репликации MySQL - как используется в RDS - реплика имеет два потока, предназначенных для конкретных целей, поток ввода-вывода, который подключается к мастеру и захватывает события репликации из бинарника мастера и записывает их во временную область хранения, которая называется релейный журнал и поток SQL, который читает из релейного журнала и применяет изменения к реплике.
На реплике запрос SHOW SLAVE STATUS; сообщит вам, являются ли эти два потокабегут, или нет.Если они работают, реплика исправна, хотя она может находиться позади мастера, о чем свидетельствует значение Seconds_Behind_Master, которое вы также найдете в выходных данных этого запроса.В противном случае вы обнаружите возникшую ошибку, приводящую к остановке одного или других потоков.
Теоретически реплика MySQL никогда не выйдет из синхронизации, если не произойдет одно из трех:
- вы делаете то, что не должны делать реплику несовместимой с мастером - например, делаете реплику доступной для записи и записываете в нее.
- в исходном коде MySQL есть ошибкаэто вызывает несогласованность
- , реплика отключается от мастера на достаточно длительный период времени, так что мастер уже отбрасывает некоторые из событий репликации, которые реплика никогда не видела.
Первая проблема приведет к остановке потока SQL, поскольку он пытается применить бессмысленное изменение - обычно удаляя несуществующую строку, обновляя несуществующую или не совпадающую строку, вставляя уже существующую строкунастоящее и т. д.
Вторая проблема может вызвать проблемы с потоком ввода-вывода или потоком SQL, ноЭто должно быть редко.
Последняя проблема приведет к остановке потока ввода-вывода, поскольку он запоминает, где он остановился на главном устройстве, и если двоичный файл журнала не доступен на главном устройстве в этот момент, он находится втупик.RDS должен предотвратить это, удерживая журналы на главном сервере до тех пор, пока все управляемые реплики не захватят их.
Итак, ответ general состоит в том, что вы можете исправить реплику чтения MySQL, принеся всеего данные точно в том состоянии, в котором они должны быть, в зависимости от состояния мастера в момент времени, на который в данный момент указывает поток SQL репликации, в журналах ретрансляции.
Это немного сложнее вRDS, потому что у вас нет привилегии SUPER, но это все еще возможно.Тем не менее ...
tl; dr: нарушенная репликация является лишь симптомом - вы должны выяснить, в чем на самом деле проблема.
Вы должны уметьопределить, что пошло не так, и принять меры для исправления.Проблема в том, что, когда репликация останавливается, если у вас нет четкого понимания того, что именно произошло, вы на самом деле не знаете, насколько плохи могут быть реплики.
Вспоминая принцип, упомянутый выше -- начинать с двух одинаковых наборов данных и каждый раз, когда вы меняете один, менять другой - следующее, на что следует обратить внимание, - это то, что MySQL не имеет встроенных механизмов для обеспечения согласованности при отсутствии фактических ошибок репликации.Два сервера могут сильно расходиться, но репликация будет продолжаться до тех пор, пока поток SQL не столкнется с чем-то, что он не может реплицировать.Вам нужна сторонняя утилита, которая может сравнивать данные на двух серверах и выявлять любые расхождения.
Если вы четко понимаете, что пошло не так, вы можете временно сделать реплику доступной для записи (используя настройку группы параметров для системной переменной read_only), внести исправления и перезапустить репликацию.В RDS вы можете перезапустить только с текущего указателя на событие, перезагрузив реплику, поскольку у вас нет привилегии SUPER, или вы можете привести реплику в состояние, в котором она должна была быть после проблемное событие реплицируется, а затем используйте обходной путь, который они предусматривают для этого, используя CALL mysql.rds_skip_repl_error();. Не используйте этот , не понимая, что он делает - в частности, он игнорирует сбой и переходит к следующему событию, абсолютно оставляя вашу реплику в несовместимом состоянии, если вы вручную не привели реплику в согласованное состояние.Он должен быть зарезервирован только для экстренных случаев, когда поддержание текущей реплики важнее, чем сохранение правильной реплики, поскольку пропуск ошибки по существу гарантирует больше ошибок в будущем.
Восстановление реплики не является тривиальным упражнением.Это задача для опытного администратора баз данных.В RDS лучшим вариантом, как правило, является отказ от реплики и создание новой, но поскольку ошибки репликации никогда не должны возникать - это не то, что вам когда-либо придется делать.Если вы это сделаете, вам нужно выяснить, почему.