当搭建MySQL主从架构的时候的,检查是否配置成功的方式是在从库检查 show slave status\G;
要求红色框内Slave_IO_Running: Yes;Slave_SQL_Running: Yes。
如果配置不成功,可以通过观察Last_error属性描述来定位分析问题。
以上面的异常举例,可以看到如下错误信息中提示我们可以在performance_schema.replication_applier_status_by_worker中查看更多错误细节
Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction ‘ANONYMOUS’ at master log mysql-bin.000003, end_log_pos 410. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
【注意】在处理类似的问题的时候不要把别人的解决方式拿来就用,要根据当前出现的具体问题在做处理,当时我因为比较急错误的使用了很多被人的解决方式,结果浪费了很多时间,走了很多弯路。
在从库查看当前表查看更多的信息
select * from performance_schema.replication_applier_status_by_worker\G;
错误1:retry-time: 60 retries: 4 message: Authentication plugin ‘caching_sha2_password’ reported error: Authentication requires secure connection.
错误1 Error ‘Operation ALTER USER failed for ‘slave’@’%‘’ on query. Default database: ‘test’. Query: ‘ALTER USER ‘slave’@’%’ IDENTIFIED WITH ‘sha256_password’ AS ‘ 5 5 5w7S{>l1A5<wYKyRE$kdTTxTlafSNx1oc7UbDHtEKm5kXA4468N/OCJR41XN4’’*
经过排查,发现该问题是因为MySQL 8以上版本的密码认证机制和MySQL5.7版本不同。mysql 8 全部采用了 caching_sha2_password 的方式,这导致很多之前可以使用的工具以及工作的方式都需要改变。
快速低成本解决方法:
在my.cnf 中添加下面一行,将MYSQL 与MYSQL 5.7 的密码认证方式一致,则上面的问题解决
default_authentication_plugin=mysql_native_password
重新启动数据库服务,上面的问题可以解决
错误3:Error executing row event: ‘Unknown database ‘test’’
第二个问题是因为自己的测试过程中在主库执行了创建库语句,但是我是先在从库配置主库的binlog的position,然后在主库执行了该SQL语句,导致日志点不一致,这个可以通过手动创建库或者修改从库的master日志position修改。
重新启动和绑定
stop slave;change master to master_host='192.168.XXXX', master_port=3306,master_user='slave', master_password='123456', master_log_file='mysql-bin.000001', master_log_pos=2347;start slave;show slave status\G