MySQL主从复制（1）基于Binlog搭建主从异步复制
一、MySQL主从复制介绍
1、主从复制原理
MySQL主从复制功能是对MySQL的一种横向扩展方案，主从复制依赖于MySQL自身的Binlog实现。主节点的Binlog记录了数据库所有DDL与DML操作（SELECT、SHOW等语句不对数据产生变化，不会有记录，另外临时表也不会有记录），从库将binlog日志复制到自己的中继日志Relaylog中，然后根据Relaylog做相同的操作，实现了数据的同步（对binlog日志的介绍与管理可以参考《【MySQL运维】binlog日志介绍、管理与数据恢复》）。主从结构通常可以分为一主一从、一主多从、级联复制等，如果是一主多从的架构需要注意从服务器的数量不能太多，否则会因为日志的传输给主库带来过多的带宽消耗（曾遇到过因为主库网卡异常导致从库延迟的情况发生）
2、主从复制的应用场景
· 读性能提升：所有数据变更在主节点进行，而读负载分摊到一个或者多个从节点，如果业务涉及OLAP也可以放在从节点完成，另外从节点的横向扩展也非常容易
· 数据安全性提升：每一个从节点都可以作为一个主节点的副本，通过半同步复制或者延迟复制确保数据的安全性。另外对于备份工作也可以放在从节点完成，减少主节点的性能损耗
· 远程数据分发：利用复制实现跨区域的数据同步，适合对数据实时性要求不高的场景，剩下对实时性有要求的请求放在主节点或者同区域节点完成
· 滚动升级：先升级从库进行测试，然后手动切换主从后升级其他从库，最终实现不停机的在线升级（并不是完全无感知，执行主从切换时应用需要重连数据库）
· 高可用切换：当主节点故障时可以通过数据库中间件或者手动切换的方式快速恢复服务
3、主从异步复制
异步复制是MySQL主从复制方式中性能最好的一种，异步复制中主库的性能不会受到从库复制性能的影响，不管是基于Binlog Position的传统主从复制还是GTID模式下的主从复制，都可以使用异步复制的方式进行。但是异步复制会存在一定的数据丢失风险，这个放在半同步复制中进行介绍，这里不考虑数据丢失问题
二、MySQL主从复制配置
在部署主从架构前先确保主从节点MySQL版本一致（从库版本可以高于主库但是不能低于主库）、时间一致，然后按照以下步骤操作即可
1、binlog主从相关配置选项（由于从库也随时有可能提升为主，所以建议都配成一样的）
配置文件内容可以参考——《【MySQL运维】MySQL配置文件示例与说明》
2、主库建立一个账号并给与数据复制权限
GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'slave'@'192.168.36.11' IDENTIFIED BY '123456789';
3、查看主库当前的position信息，position实际对应的是binlog的File Size，从库会从该位置进行复制
mysql > show master status \G
4、从库使用主库上配置好的复制用户，并且指定好主库的position信息
stop slave; CHANGE MASTER TO MASTER_HOST='192.168.145.85',MASTER_USER='repl',MASTER_PASSWORD='123456',MASTER_LOG_FILE='master-bin.000004',MASTER_LOG_POS=0; #MASTER_HOST：MASTER服务器的IP #MASTER_USER：有slave权限的用户，就是GRANT所授权的用户 #MASTER_PASSWORD：从库用户的密码 #MASTER_LOG_FILE：在主库上执行show master status语句可以查看日志名 #MASTER_LOG_POS=333：这个位置决定了从库从哪个位置开始复制，实测写0也可以，从头复制
5、启动从库复制线程，需要为两个yes
mysql > start slave; #启动从库 mysql > show slave status \G #查看从库状态
三、主从状态查看
1、查看主库Position信息与从库状态
show master status \G #查看主库binlog position信息 show slave status \G #查看从库状态
2、从库状态关键指标
· Read_Master_Log_Pos：从库读取到主库二进制日志到哪个位置
· Exec_Master_Log_Pos：从库执行到主库二进制日志到哪个位置。如果和Read_Master_Log_Pos一致代表数据是同步的
· Relay_Log_File：从库会将binlog记录到中继日志中，这里标识了当前中继日志是哪一个
· Relay_Master_Log_file：当前中继日志文件所对应的binlog日志文件
· Seconds_behind_master：从服务器比主服务器慢了多少秒，为0代表没有延迟。这里的计算方式为“从库当前系统时间 - 主从节点之间的系统时间差 - 从库SQL线程正在执行的事务时间戳”，这里主从节点之间的时间差会在从库IO线程执行启动的时候进行计算，所以主从时间不一致时也能计算出正确的延迟时间，但是要注意如果在复制过程中修改了系统时间就会导致主从延迟不可靠，除非重启IO线程。当SQL线程重放主库的大事务时，时间戳更新相当于被暂停了，此时无论主库是否还有事务写入，从库的延迟值都会越来越大，等大事务执行完毕后又突然变为0是正常现象。虽然该值可以用来判断主从同步情况，但是最准确的方式还是对比Read_Master_Log_Pos - Exec_Master_Master_Log_Pos的值以及Executed_Git_set - Retrieved_Gtid_Set的差值。如果GTID差值很小而Position差距很大的话，说明是有大事务的存在
· Slave_IO_Running、Slave_SQL_Running：如果有一项为No都表示主从异常。IO Thread的作用是从Master端请求二进制日志并存放到Slave端的中继日志中；SQL Thread的作用是将中继日志里的事件导入到SQL语句中，下图是启动slave之前的状态：
3、从库管理常用命令，需要注意的是无论使用何种复制方式，如果需要重启服务建议先stop slave再重启MySQL服务，避免复制出错
STOP SLAVE IO_THREAD; #停止从库IO进程 STOP SLAVE SQL_THREAD; #停止从库SQL进程 STOP SLAVE; #停止IO和SQL进程 START SLAVE IO_THREAD; #启动IO进程 START SLAVE SQL_THREAD; #启动SQL进程 START SLAVE; #启动IO和SQL进程 RESET SLAVE; #重置从库状态，该操作会删除所有中继日志并启动一个新的中继日志，通常重做从库的时候才会执行此命令 SHOW SLAVE STATUS; #查看MySQL同步状态
评论