MariaDB - ошибка чтения журнала ретрансляции: не удалось проанализировать запись события журнала ретрансляции
Получение следующей ошибки при проверке статуса ведомого
Ошибка чтения журнала ретрансляции: не удалось проанализировать запись о событии в журнале ретрансляции. Возможные причины: двоичный журнал ведущего поврежден (вы можете проверить это, запустив mysqlbinlog в двоичном журнале), поврежден журнал ретрансляции подчиненного устройства (вы можете проверить это, запустив 'mysqlbinlog' в журнале ретрансляции), сетевая проблема или ошибка в коде MySQL ведущего или подчиненного устройства. Если вы хотите проверить двоичный журнал ведущего устройства или журнал реле ведомого устройства, вы сможете узнать их имена, выполнив команду 'SHOW SLAVE STATUS' на этом ведомом устройстве.
Я использую MariaDB от Bitnami с репликацией, где у меня есть 1 главный и 2 подчиненных узла, из которых один узел кажется поврежденным, и появляется вышеуказанная ошибка.
Объясняя шаги, которые я предпринял после того, как узел перестал работать
- Был зависший запрос system_user, пытался убить его, но, к сожалению, он не удалялся.
- Перезапустил подчиненный узел, чтобы обновить все запросы.
- После перезапуска сервера MySQL перестал работать и выдавал ошибку сокета.
Помогите, ребята, с решением. Не могу пройти через эту ошибку
Ответы 1
Я решил ту же проблему с помощью следующих шагов.
Чтобы проверить текущий статус ведомого устройства, выполните команду:
show slave status\G
Вы должны увидеть результат, подобный этому:
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: provisioner-peer
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mysql-bin.000149
Read_Master_Log_Pos: 919065590
Relay_Log_File: mysql-relay-bin.000450
Relay_Log_Pos: 884188250
**Relay_Master_Log_File: mysql-bin.000149**
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: 1594
Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by run
ning 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or
slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
Skip_Counter: 0
**Exec_Master_Log_Pos: 884187951**
Relay_Log_Space: 919067911
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
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1594
Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by run
ning 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or
slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
Replicate_Ignore_Server_Ids:
Master_Server_Id: 287
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Slave_DDL_Groups: 0
Slave_Non_Transactional_Groups: 0
Slave_Transactional_Groups: 1
1 row in set (0.000 sec)
Следует обратить внимание на важные значения: Relay_Master_Log_File и Exec_Master_Log_Pos. Они понадобятся вам для корректного перезапуска репликации на вашем подчиненном устройстве.
Для перезапуска репликации выполните следующие команды:
STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO master_log_file='mysql-bin.000149', master_log_pos=884187951;
START SLAVE;
Чтобы проверить, работает ли репликация, снова выполните команду:
show slave status\G
Прежде чем вы вызовете подчиненное устройство как синхронизированное, проверьте значение параметра Seconds_Behind_Master из команды состояния. В нашем случае я увидел значение (7971 секунд):
Секунды_за_мастером: 7971
В течение следующих нескольких минут репликация снова синхронизировалась с мастером, и задержка репликации была равна 0 с.
Примечание. В целях безопасности сначала сделайте резервную копию базы данных.