1.主从复制故障分析及处理
1.1线程不工作
1.1.1 IO线程的常见故障
1.IO的工作：连接主库，请求日志，存储日志。
2.连接主库存储着网络，ip，port，firewalld，user，password，网络不通
如果是这些信息不对的话，在从库上show slave时会报Slave_io_Running:Connecting;
解决的方法：
首先在从库上将stop slave;
然后在从库上重新执行change master to 里面的信息，
修改成正确的ip，port，user，password
最后再启动 start slave；
2.1.如果是查看ip，port，user，password和firewalld都是正确的，
那就是网络的问题，如果网络是能ping通（因为ping是小的数据包，不需要拆分很多次），
但是有丢包的现象（两台服务器中，各有两个网卡，其中这两台服务器中的两张网卡绑定成一张网卡，
两台服务器通过两台交换机链接，但是交换机没有做绑定（堆叠），
导致导大的数据包，会将大的数据包拆分成小的数据包进行传输，
但是主从走的是不同的线路，在合包的时候访问不到，导致网络阻塞）
2.1.1 解决办法：
A 第一种解决办法
在默认的情况下，网卡和交换机走的是负载均衡的模式，可以将交换机和网卡做成主备的模式。
B 第二种解决办法
将交换机做堆叠
3.请求日志的常见错误
3.1 日志位置点错误（搭建过程的问题）
解决的方法：
重新change master to 即可
3.2 主库的二进制文件（binlog）损坏，误删等操作（slave_io_Running:NO）
第一种解决办法 ：
最好是重新搭建主从(最靠谱的方法）;
第二种解决的方法：
stop slave;
reset slave all;
show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 177 |
| mysql-bin.000002 | 444 |
+------------------+-----------+
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=177, # 指定的file_size的号
MASTER_CONNECT_RETRY=10;
start slave；
show slave status \G
4.存储日志的常见错误
4.1 relaylog损坏，丢失，不连续
解决办法：
relaylog有自动清理
1.1.2 SQL线程的常见错误
1.SQL的主要功能是回放relaylog，即回放二进制日志，日志里存放的SQL语句，
但是二进制文件不存储查询类的语句
2.常见的问题
2.1 创建对象失败：权限不足，库或表已经存在（主库创建成功，但是从库创建失败），
一些特殊的关键字
从库被误写入（误将从库当成主库，先在从库上创建一个A表，
然后再到主库上创建A表，show databases的时候都有A这两张表，在主库上use A，然后craete table ，
再插入一条数据 instert into t1 ，在show * from t1;的时候报错，看起来主从不同步，
其实首先我们要查看一下主从的状态，
即在从库上show slave status \G 查看的时候Slave_SQL_Running的状态是NO，
*** 当出现Slave_SQL_Running的状态是NO的情况一般是因为
要删除的对象不存在或者是创建的对象已经存在再或者是因为从库宕机，导致数据不连续 ;版本，SQL_mode和配置的不一致也会导致；***
这种情况的解决办法：
第一种办法：跳过该错误（生产中不建议这样）
第二种办法：首先在主库上删除这张表即drop
databases，然后再次start slave；查看主从的状态，即show slave status \G,如果成功可以查看一下即可，use 表；
然后show tables；select * from t1 查看即可
预防的方案：
1.将从库设定的权限为只读
db03 [(none)]>show variables like '%read_only%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_read_only | OFF |
| read_only | OFF |
| super_read_only | OFF |
| transaction_read_only | OFF |
| tx_read_only | OFF |
+-----------------------+-------+
注释：其中read_only是对普通用户的限制，super_read_only是对超级用户的限制；
将这两个的设置成1或者是on即可
db03 [(none)]>set global read_only=on;
db03 [(none)]>set global super_read_only=on;
db03 [(none)]>show variables like '%read_only%' ;
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_read_only | OFF |
| read_only | ON |
| super_read_only | ON |
| transaction_read_only | OFF |
| tx_read_only | OFF |
+-----------------------+-------+
2.配合中间件（读写分离）
2.2 DML语句执行失败主库（有A表，但从库没有A表。因为主从复制是一个异步的过程）
解决办法：
认为校验主从不一致的原因，将有问题的操作补上，修复数据
首先在主库中show create table A ;查看A表的结构，并将里面的信息复制出来，并在从库上执行一次，然后select * from A；
可是没有数据，可以start slave；查看一下show * from t2查看数据是否存在，
最后show slave status \G 查看Slove_SQL_Running的状态即可
2.3 约束冲突：主键自增列冲突（8.0版本以前的故障）
描述故障：一般情况下在主机出现过宕机后，比如在主库上的id有为十的表，然后从库上早已有id为十的表
解决办法：
首先在主库和从库上查找到这张表 select * from t3 where id=10;。若都为10就可以跳过，操作为：stop slave; set global sql_slave_skip_counter=1;
start slave；
；如果这两个值不相同的话，手动的变成一致的，以主库为主
