mysql 主从复制原理，概念，故障的检控/分析/处理
1. 主从复制的原理 (Classic Replication)
1.1 主从中涉及到的文件和线程
1.1.1 涉及的线程
主库:
DUMP THREAD
从库:
IO THREAD
SQL THREAD
1.1.2 涉及的文件
主库: mysql-bin.000001 =====》主库的二进制文件
从库: db01-relay.000001 ===》中继日志 master.info ===》主库信息记录日志 relay-log.info ===> 记录中继应用情况信息
1.2 主从复制原理
主从复制原理描述：
1.change master to 时，ip pot user password binlog position写入到master.info进行记录 2. start slave 时，从库会启动IO线程和SQL线程 3.IO_T，读取master.info信息，获取主库信息连接主库 4. 主库会生成一个准备binlog DUMP线程，来响应从库 5. IO_T根据master.info记录的binlog文件名和position号，请求主库DUMP最新日志 6. DUMP线程检查主库的binlog日志，如果有新的，TP(传送)给从从库的IO_T 7. IO_T将收到的日志存储到了TCP/IP 缓存，立即返回ACK给主库 ，主库工作完成 8.IO_T将缓存中的数据，存储到relay-log日志文件,更新master.info文件binlog 文件名和postion，IO_T工作完成 9.SQL_T读取relay-log.info文件，获取到上次执行到的relay-log的位置，作为起点，回放relay-log 10.SQL_T回放完成之后，会更新relay-log.info文件。 11. relay-log会有自动清理的功能。 细节： 1.主库一旦有新的日志生成，会发送“信号”给binlog dump ，IO线程再请求
2. 主从故障监控\分析\处理 *****
2.1 从库查看到的主从信息整理
mysql> show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event # 主库的相关信息(master.info中的信息) Master_Host: 192.168.0.104 Master_User: repl Master_Port: 3306 Connect_Retry: 10 Master_Log_File: mysql-bin.000011 # 获取到的最新的主库日志文件 Read_Master_Log_Pos: 779 # 当前主库最新的position位置 # 从库relay应用信息有关的(relay.info中的信息) Relay_Log_File: 192-relay-bin.000005 Relay_Log_Pos: 992 # 上下两个表示relay_log的文件名和position Relay_Master_Log_File: mysql-bin.000011 # 对应主库的文件名 # 从库线程运行状态 Slave_IO_Running: Yes Slave_SQL_Running: Yes Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: # 过滤复制有关的信息(有选择性的复制主库) Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: # 从库延时主库的时间(秒) Seconds_Behind_Master: 0 # 延时从库配置 SQL_Delay: 0 SQL_Remaining_Delay: NULL # gtid复制有关的状态信息 Retrieved_Gtid_Set: Executed_Gtid_Set: Auto_Position: 0
2.2 故障排查思路
主从复制的核心就是从库的两个线程（io和sql）加上主库的dump线程，而dump线程又是主库自动开启的，出问题的概率不大。
从库线程之io线程解析：
io线程的工作职责：
1. 连接主库
2. 请求主库的binlog
3. 存储请求到的binlog
从库线程之sql线程解析:
sql线程工作职责:
1. 读取并执行relaylog中的日志
2. 更新relay-info中的信息
2.2.1 排查连接异常思路
手动使用复制账户连接主库，核对账户，密码，ip，端口等配置信息是否正确，如果是这些信息异常导致的，则按照以下步骤到从库重新设置。
核对防火墙的影响。
stop slave
reset slave all
change master to xxxxxx
start slave
如果是因为数据库最大链接数满了引起的连接异常，可手动增大最大连接数限制 [root@db01 ~]# mysql -urepl -p123 -h 10.0.0.51 -P 3307 mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1040 (HY000): Too many connections 处理方法: db01 [(none)]>set global max_connections=300;
2.2.2 排查主库binlog请求不到异常
1. 确认主从binlog是否开启 2. 确认从库配置的二进制日志文件是否存在 3. 针对主库做过重置二进制文件序号的命令(即主库执行了：reset master)解决办法？
分析，之所以同步失败，是因为主库重置了二进制序号，而该操作不会被从库同步到，所以导致从库中储存的二进制文件和position号无效。 主库执行：show binlog events in 'xxxxx.000001';找到最开始的position号，从新配置从库的同步信息即可。 (reset master后刷出来的新二进制文件，开始的position号一定是154吗？)
2.2.3 排查sql线程异常:
1. relay-log文件找不到了. 重新构建主从 2. 报各种从库的对象存在,违反了约束等,虽然不大可能出现. 处理掉从库中异常提示中的问题. 3. 一切以主库为主.
不建议的操作如下:
方法一：
stop slave;
set global sql_slave_skip_counter = 1;
#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;
方法二：
从库配置文件中添加跳过配置,出现以下异常时自动跳过
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突
但是，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.
一劳永逸的方法:
(1) 可以设置从库只读. db01 [(none)]>show variables like '%read_only%'; 注意： 只会影响到普通用户，对管理员用户无效。
read_only # 用来控制普通用户只读
supper_read_only # 用来控制所有用户含root只读;
(2)加中间件 读写分离。
atlas
mycat
proxySQL
maxscale
