当搭建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