📢📢📢📣📣📣
哈喽！大家好，我是【IT邦德】，江湖人称jeames007，10年DBA工作经验
一位上进心十足的【大数据领域博主】！😜😜😜
中国DBA联盟(ACDU)成员，目前从事DBA及程序编程
擅长主流数据Oracle、MySQL、PG 运维开发，备份恢复，安装迁移，性能优化、故障应急处理等。
✨ 如果有对【数据库】感兴趣的【小可爱】，欢迎关注【IT邦德】💞💞💞
❤️❤️❤️感谢各位大可爱小可爱！❤️❤️❤️

文章目录

• 前言
• • 🚀 1.主从复制状态
  • • 🌈 1.1 从库查询
    • 🌈 1.2 主库查询
  • 🚀 2.主从数据不一致的原因
  • 🚀 3.主从复制常见问题
  • • 🌈 3.1 IO_thread 异常
    • 🌈 3.2.sql_thread 异常
  • 🚀 4.主键错误模拟及解决

前言

在实际的生产中，为了解决Mysql的单点故障已经提高MySQL的整体服务性能，一般都会采用「主从复制」

🚀 1.主从复制状态

🌈 1.1 从库查询

🚩🚩 show slave status \G;

Master_Log_File= Relay_Master_Log_File
Read_Master_Log_Pos= Exec_Master_Log_Pos
证明目前没有主从延迟状态。
Seconds_Behind_Master: 0 #从库的延迟
Slave_IO_Running：从库上 I/O thread 负责请求和接收主库传递来的 binlog 信息。
Slave_SQL_Running：从库上 SQL thread 负责应用 relay 中的 binlog 的信息。

🌈 1.2 主库查询

🚩🚩 mysql> show master status;

🚩🚩 show slave hosts;

🚀 2.主从数据不一致的原因

（一）MySQL 主从复制什么原因会造成不一致，如何预防及解决？
1、人为原因导致从库与主库数据不一致（从库写入）
2、主从复制过程中，主库异常宕机
3、设置了 ignore/do/rewrite 等 replication 等规则
4、binlog 非 row 格式
5、异步复制本身不保证，半同步存在提交读的问题，增强半同步起来比较完美。
但对于异常重启（Replication Crash Safe），从库写数据（GTID）的防范，还需要策略来保证。
6、从库中断很久，binlog 应用不连续，监控并及时修复主从
7、从库启用了诸如存储过程，从库禁用存储过程等
8、数据库大小版本/分支版本导致数据不一致？主从版本统一
9、备份的时候没有指定参数例如 mysqldump --single-transaction --master-data=2 等
10、主从 sql_mode 不一致
11、一主二从环境，二从的 server id 一致
12、MySQL 自增列主从不一致
13、主从信息保存在文件里面，文件本身的刷新是非事务的，导致从库重启后开始执行点大于实际执行点
14、采用 5.6 的 after_commit 方式半同步，主库当机可能会引起主从不一致，要看 binlog 是否传到了从库
15、启用增强半同步了（5.7 的 after_sync 方式），但是从库延迟超时自动切换成异步复制

（二）预防和解决的方案有：
1、master:innodb_flush_log_at_trx_commit=1&sync_binlog=1 --双1参数
2、slave:master_info_repository=“TABLE”&relay_log_info_repository=“TABLE”&relay_log_recovery=1
3、设置从库为只读模式
4、可以使用 5.7 增强半同步避免数据丢失等
5、binlog row 格式
6、必须引定期的数据校验机制
7、当使用延迟复制的时候，此时主从数据也是不一致的（计划内），但在切换中，不要把延迟从提升为主库哦~
8、mha 在主从切换的过程中，因主库系统宕机，可能造成主从不一致（mha 本身机制导致这个问题）

🚀 3.主从复制常见问题

🌈 3.1 IO_thread 异常

IO_thread 异常，状态往往是 Slave_IO_Running:Connecting 或 NO。
IO_thread 是向 Master 发送请求读取 master binlog，如果处于 Connecting 状态，说明无法正确地与 Master 进行连接，可能的原因有：
① 网络不通（是否打开防火墙）
② 复制用户的用户名、密码、端口不对
③ master 的 IP 不对
④ master 没有启动
⑤ master 连接数上限
⑥ master 压力太大
⑦ master上的 mysql-bin.xxxxxx 被误删
⑧ 主库磁盘空间满了
⑨ 主从库的 UUID 不能一样（The slave I/O thread stops because master and slave have equal MySQL server UUIDs;these
UUIDs must be different for replicatIOn to work.）
⑩ 主从在同一台机器，对于 MySQL5.6 应该设置 skip-name-resolve 为 1

🌈 3.2.sql_thread 异常

sql_thread 发生异常，状态就会变为 Slave_SQL_Running:NO。
sql_thread 发生异常的情况非常多，发生异常后，需要通过以下方法排查和解决：
a、对比主库和从库的二进制日志的情况：

b 、 通过 show slave status\G 查看错误信息：
show slave status\G
Last_SQL_Errno: 1062
Last_SQL_Error: Error ‘Duplicate entry ‘1’ for key ‘PRIMARY’’ on query. Default database:‘test’. Query: ‘insert into test values(1,2,3,4,5,6)’

c 、 通过错误日志查看错误信息：
140828 16:27:51 [ERROR] Slave SQL: Error ‘Duplicate entry ‘1’ for key ‘PRIMARY’’ on query.
Default database: ‘test’. Query: ‘insert into test values(1,2,3,4,5,6)’,
Error_code: 1062
140828 16:27:51 [Warning] Slave: Duplicate entry ‘1’ for key ‘PRIMARY’ Error_code: 1062 140828 16:27:51 [ERROR] Error running query, slave SQL
thread aborted. Fix the problem, and restart the slave SQL thread with “SLAVE START”. We stopped at log ‘mysql-bin.000303’
position 18711163
根据这些报错信息，往往就能够定位到发生异常的原因。

🚀 4.主键错误模拟及解决

–主库
use jemdb;
create table mytb2(id int primary key ,name varchar(30));
insert into mytb2 values(1,‘a’),(2,‘b’);
– 从库
insert into mytb2 values(3,‘c’),(4,‘d’);
– 主库
insert into mytb2 values(3,‘c0’),(4,‘d0’);
flush logs
– 从库
show slave status \G;
select * from performance_schema.replication_applier_status_by_worker
如果我们了解产生异常的具体事件，而且能够掌控，
可以通过设置 sql_slave_skip_counter 参数来跳过当前错误。
setglobalsql_slave_skip_counter=1; --如果是10，就是跳过接下来的10个错误
set global sql_slave_skip_counter=1;
start slave sql_thread;
或者使用 slave_skip_errors 参数（read only variable），指定跳过某种类型的错误：
参数文件中设置：
slave_skip_errors=1062 #跳过 1062 错误
遇到错误时，不要一通百度后，然后根据看起来很类似的操作直接来进行操作。
因为网上大部分解决 sql_thread 异常的方法是：
a、 直接 set global sql_slave_skip_counter=n;（n 设置很大的值，即：跳过所有错误），
b、 设置 slave_skip_errors=all;跳过所有类型的错误
c、 直接查看主库的 binlog，然后在从库上直接执行 change master to。
这些方法都会导致主从数据不一致。