MySql主从复制原理

一、概述

1、什么是主从复制?
概念 主从复制是用来建立一个和 主数据库完全一样的数据库环境称为从数据库；主数据库一般是准实时的业务数据库。
2、主从复制作用
我们来思考如果在企业网站中，后端MYSQL数据库只有一台时候，会有以下问题：
1、单点故障服务不可用
2、无法处理大量的并发数据请求
3、数据丢失
所以通过主从复制后，它的优点就很明显
1、如果主节点出现故障，那么我们就直接将服务切到从节点，来保证服务立马可用。
2、如果并发请求特别大的时候，我们可用进行读写分离操作，让主库负责写，从库负责读。
3、如果主库数据丢失，但从库还保存一份，减少数据丢失的风险。

二、主从复制原理

1、主从复制原理

上面主要分成了三步，下面会详细说明。
(1) Master的更新事件(update、insert、delete)会按照顺序写入bin-log中。当Slave连接到Master的后,Master机器会为Slave开启binlog dump线程,该线程会去读取bin-log日志
(2) Slave连接到Master后,Slave库有一个I/O线程 通过请求binlog dump thread读取bin-log日志,然后写入从库的relay log日志中。
(3) Slave还有一个 SQL线程,实时监控 relay-log日志内容是否有更新,解析文件中的SQL语句,在Slave数据库中去执行。

什么是binlog

1. binlog介绍

binlog 二进制日志文件，这个文件记录了MySQL所有的DML操作。通过binlog日志我们可以做数据恢复，增量备份，主主复制和主从复制等等。
binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。不会记录SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改，但可以通过查询通用日志来查看MySQL执行过的所有语句。
需要注意的一点是，即便update操作没有造成数据变化，也是会记入binlog。
binlog有两个常用的使用场景：

• 主从复制：mysql replication在master端开启binlog,master把它的二进制日志传递给slaves来达到master-slave数据一致的目的。
• 数据恢复：通过mysqlbinlog工具来恢复数据。

binlog 归档日志：（以后备份恢复用到）
（1）binlog 是 MySQL 的Server层实现的，所有引擎都可以使用。
（2）binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”.redo log 是物理日志，记录的是“在某个数据页上做了什么修改”
（3）binlog 是可以追加写入的。“追加写”是指binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。redo log 是物理日志，记录的是“在某个数据页上做了什么修改”。
3. 如何恢复到半个月任意一秒的状态
保存半个月的binlog，定期备份
依次提取当时的binlog，按照时间顺序重放的到需要的时刻
总结：binlog是做备份的，binlog 中记录的是sql语句，或行的内容。当想恢复到之前几小时，几天或者几个月的数据时，就需要依次提取当时的binlog，按照时间顺序重放的到需要的时刻。
redo log 和 binlog 都是顺序写,比磁盘的随机写要快;
通常我们说的 MySQL 的 “双1” 操作，指的是 sync_binlog = 1 AND innodb_flush_log_at_trx_commit = 1 。innodb_flush_log_at_trx_commit 设置成 1 表示 redo log 在 prepare 阶段就需要持久化一次，那么 “双1” 配置 每个事务提交的时候都会刷盘 2 次，一次是 binlog，一次是 redo log。
从上面可以看出，每个客户端线程都有自己独立的 binlog cache，但是会共享一份 binlog files。
上面的 write 是指把binlog cache 写到文件系统的 page cache，并没有写入到磁盘中，因此速度较快。
fsync 是实际的写盘操作，占用磁盘的 IOPS。
write 和 fsync 的写入时机，是由sync_binlog 控制的：
1、sync_binlog=0：每次事务提交都只 write，不 fsync；
2、sync_binlog=1：每次事务提交都会fsync；
3、sync_binlog=N（N>1）：每次提交事务都会 write，累计N 个后再执行 fsync。
在出现 IO 瓶颈的情况下，可以考虑将 sync_binlog 设置成一个大的值。比较常见的是将 N设置为 100~1000。但是存在的风险是，当主机异常重启时会丢失 N 个最近提交的事务 binlog。

2. ** binlog格式**

binlog有三种格式：Statement、Row以及Mixed。
–基于SQL语句的复制(statement-based replication,SBR)，
–基于行的复制(row-based replication,RBR)，
–混合模式复制(mixed-based replication,MBR)。
2.1 Statement
每一条会修改数据的sql都会记录在binlog中。
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能/触发器等，slave可与master上要保持一致会有很多相关问题。
ps：相比row能节约多少性能与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。
2.2 Row
5.1.5版本的MySQL才开始支持row level的复制,它不记录sql语句上下文相关信息，仅保存哪条记录被修改。
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题.
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。
ps:新版本的MySQL中对row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。
2.3 Mixed
从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。
在Mixed模式下，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。
3.1 查看是否开启binlog

show variables like 'log_bin'

如果binlog没有开启，可以通过set sql_log_bin=1命令来启用;如果想停用binlog,可以使用set sql_log_bin=0。
查看mysql数据存在了哪里

show global variables like "%datadir%";

查看binLog文件在哪里

show binary logs;
show binlog events in 'mysql-bin.000007';

命令

 mysqlbinlog --no-defaults --database=test1 --start-datetime="2021-09-17 07:21:09" --stop-datetime="2021-09-23 07:59:50" mysql-bin.000007 | more

** binlog的扩展**
当停止或重启服务器时，服务器会把日志文件记入下一个日志文件，Mysql会在重启时生成一个新的日志文件，文件序号递增；此外，如果日志文件超过max_binlog_size（默认值1G）系统变量配置的上限时，也会生成新的日志文件（在这里需要注意的是，如果你正使用大的事务，二进制日志还会超过max_binlog_size，不会生成新的日志文件，事务全写入一个二进制日志中,这种情况主要是为了保证事务的完整性）；日志被刷新时，新生成一个日志文件。
binlog偏移量
恢复数据有两种方式
根据时间恢复

 mysqlbinlog --no-defaults --database=test1 --start-datetime="2021-09-17 07:21:09" --stop-datetime="2021-09-23 07:59:50" mysql-bin.000007 | more

根据position恢复,那么什么是position

show binlog events in 'mysql-bin.000007';

可以知道在日志的偏移量位置后的发生了什么事件
或者通过mysqlbinlog工具进行分析

执行复原

mysqlbinlog --stop-position=1919 binlog.000002 | mysql -h 192.168.159.100 -P 3306 -u root -p

总结

(1) 既然是要把事件记录到bin-log日志，那么对于Master就必须开启bin-log功能。
(2) 整个Mysql主从复制一共开启了3个线程。Master开启 IO线程，Slave开启 IO线程 和 SQL线程。
(3) 这点也很重要那就是Master和Slave交互的时候，记住这里是Slave去请求Master,而不是Master主动推给Slave。Slave通过IO线程连接Master后发起请求,Master服务器收到Slave IO线程发来的日志请求信息，io线程去将bin-log内容返回给slave IO线程。
2、MySQL主从复制同步方式
(1)异步复制
MySQL主从同步 默认是异步复制的。就是上面三步中,只有第一步是同步的(也就是Mater写入bin log日志),就是主库写入binlog日志后即可成功返回客户端，无须等待binlog
日志传递给从库的过程。Master 不关心 Slave 的数据有没有写入成功。因此如果Master和Slave之间有网络延迟，就会造成暂时的数据不一致的现象；如果Master出故障，而数据
还没有复制过去，则会造成数据丢失；但也有好处，效率较其他两种复制方式最高。
（2)同步复制
对于同步复制而言，Master主机将事件发送给Slave主机后会触发一个等待，直到所有Slave节点（如果有多个Slave）返回数据复制成功的信息给Master。这种复制方式最安
全，但是同时，效率也是最差的。
（3)半同步复制
对于半同步复制而言，Master主机将事件发送给Slave主机后会触发一个等待，直到其中一个Slave节点（如果有多个Slave）返回数据复制成功的信息给Master。由此增强了数据的一致性，但是因为Master主机的确认开销，会损耗一部分的性能；另外，半同步复制除了不需要等待所有Slave主机确认事件的接收外，半同步数据复制并不要求那些事件完全地执行，因此，仍有可能看到在Slave主机上数据复制延迟的发生，如果因为网络延迟等原因造成Slave迟迟没有返回复制成功的信息，超过了Master设置的超时时长，半同步复制就降级为异步复制方式，而后继续数据复制。

三、Mysql主从同步延时

上面也说了，Mysql默认采用的异步操作，因为它的效率明显是最高的。因为只要写入bin log后事物就结束返回成功了。但由于从库从主库异步拷贝日志 以及串行执行 SQL 的特点，所以从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。这就是主从同步延时问题。
1、如何查看主从延迟时间
通过监控 show slave status 命令输出的Seconds_Behind_Master参数的值来判断：
Seconds_Behind_Master=0: 表示主从复制良好；
Seconds_Behind_Master=NULL: 表示io_thread或是sql_thread有任何一个发生故障；
Seconds_Behind_Master=79: 数字越大表示从库延迟越严重。
2、影响延迟因素
这里整理了影响主从复制延迟大致有以下几个原因：
1）主节点如果执行一个很大的事务，那么就会对主从延迟产生较大的影响
2）网络延迟，日志较大，slave数量过多
3）主上多线程写入，从节点只有单线程同步
4）机器性能问题，从节点是否使用了“烂机器”
5）锁冲突问题也可能导致从机的SQL线程执行慢
3、优化主从复制延迟
这个没有说去完全解决，要想解决那么就只能采用同步复制策略。不过，一般不建议使用这种同步模式。显而易见，如果写操作必须等待更新同步完成，肯定会极大地影响性能，除非你不在乎性能。
1）大事务：将大事务分为小事务，分批更新数据
2）减少Slave的数量，不要超过5个，减少单次事务的大小
3）MySQL 5.7之后，可以使用多线程复制，使用MGR复制架构
4）在磁盘、raid卡、调度策略有问题的情况下可能会出现单个IO延迟很高的情况，可用iostat命令查看DB数据盘的IO情况，再进一步判断
5）针对锁问题可以通过抓去processlist以及查看information_schema下面和锁以及事务相关的表来查看

总结

主机与从机之间的物理延迟是无法避免的，既然无法避免就可以考虑尝试通过缓存等方式，降低新修改数据被立即读取的概率。