Совсем недавно при настройке репликации в MySQL при запуске slave была выдана ошибка: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs
Ниже я расскажу ее причину и как быстро ее устранить.
Исходные данные: ОС Ubuntu 18.04, Oracle MySQL 5.7.33;
Задача: Решить проблему с запуском slave — The slave I/O thread stops because master and slave have equal MySQL server UUIDs
На работе коллеги самостоятельно установили MySQL для нужд своего специфического софта, далее они клонировали виртуальную машину и решили развернуть Master -> Slave репликацию, но у них это не получилось.
При выполнении команды start slave они получили ошибку «Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs»
Увидеть ее можно было при выполнении команды show slave status\G на ведомом (slave) сервере, смотрите вывод ниже:
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State:
Master_Host: 172.XX.XX.XX
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000622
Read_Master_Log_Pos: 1886
Relay_Log_File: mysql-relay-bin.000002
Relay_Log_Pos: 4
Relay_Master_Log_File: mysql-bin.000622
Slave_IO_Running: No
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: 0
Exec_Master_Log_Pos: 1886
Relay_Log_Space: 154
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: 1593
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID:
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 210304 11:24:43
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
Мы видим, что I/O поток не запустился с ошибкой 1593 — Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
Смысл ошибки очень простой — Ведомый (slave) сервер имеет тот же UUID, что и ведущий (master). Но как? А все дело в том, что VM была полным клоном мастера.
В идентичности UUID легко убедиться, для этого выполним команду ниже на ведущем (master) и на ведомом (slave) сервере:
mysql> show variables like '%server_uuid%'; +---------------+--------------------------------------+ | Variable_name | Value | +---------------+--------------------------------------+ | server_uuid | 54460172-c5d3-11e9-b76c-000c298bc5b7 | +---------------+--------------------------------------+ 1 row in set (0.01 sec)
Они покажут одно и тоже «54460172-c5d3-11e9-b76c-000c298bc5b7».
Как исправить UUID?
Все просто, для Oracle MySQL он храниться в файле /var/lib/mysql/auto.cnf
Проверим, для этого на ведомом (slave) сервере выполним:
# cat /var/lib/mysql/auto.cnf [auto] server-uuid=54460172-c5d3-11e9-b76c-000c298bc5b7
Теперь остановим MySQL на ведомом (slave) сервере, удалим файл /var/lib/mysql/auto.cnf и запустим MySQL:
# systemctl stop mysql # rm -f /var/lib/mysql/auto.cnf # systemctl start mysql
Снова проверим UUID на ведомом (slave) сервере:
mysql> show variables like '%server_uuid%'; +---------------+--------------------------------------+ | Variable_name | Value | +---------------+--------------------------------------+ | server_uuid | 6e8f33d6-7cdc-11eb-8dc5-00505682dbdc | +---------------+--------------------------------------+ 1 row in set (0.01 sec)
Мы видим, что UUID стал другим. Отлично. Теперь проверим статус репликации:
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.XX.XX.XX
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000622
Read_Master_Log_Pos: 1886
Relay_Log_File: mysql-relay-bin.000004
Relay_Log_Pos: 320
Relay_Master_Log_File: mysql-bin.000622
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: 0
Exec_Master_Log_Pos: 1886
Relay_Log_Space: 527
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: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 54460172-c5d3-11e9-b76c-000c298bc5b7
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
Мы видим, что Slave_IO_Running стал Yes, а ошибка пропала, то есть репликация заработала. Так же мы можем видеть, что в строке Master_UUID появился уже знакомый UUID ведущего сервера, мы его не меняли.
На этом все, до скорых встреч. Если у Вас возникли вопросы или Вы хотите чтобы я помог Вам, то Вы всегда можете связаться со мной разными доступными способами.
Оставить комментарий