《丁奇-MySQL45讲-24/25/28》之归纳总结

24 | MySQL是怎么保证主备一致的？

• 主从同步流程：

1. 在备库上执行change master命令，设置主库的IP、端口、用户、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量。

2. 在备库上执行start slave命令，这个时候会启动两个线程，一个是IO_Thread、一个是SQL_Thread，其中IO_Thread负责与主库建立连接。

3. 主库校验完用户密码后，按照备库指定的日志信息，从本地读取binlog，发送给备库。

4. 备库拿到binlog后，写到本地文件，称为为中转日志（relay log）。

5. SQL_Thread读取中转日志，解析日志中的命令并执行。

• 文章中说的加-c参数保留注释是指：mysql -u root -p -c，这样子就可以使用了。

• binlog_format=statement格式下会因为索引选择的不同而造成主从库不一致。

• 重放binlog的时候最好使用mysqlbinlog工具，或者是第三方工具，禁止自己拷贝SQL直接执行，执行完后的结果会出现问题。

25 | MySQL是怎么保证高可用的？

• 使用show slave status命令，seconds_behind_master表示备库落后主库的时间差，单位是秒。

• 造成主备延迟的最直接原因是：主库生产binlog的速度大于备库接收binlog的速度，那产生这些因素的原因有可能是：

1. 备库所在的机器性能要比主库查。

2. 备库压力大，比如运营后台的操作占用了备库上的大量CPU，造成了同步延迟。

3. 主库上执行大事务，比如删除大量的数据或者是大表的DDL。

• MySQL高可用依赖于主备延迟的，延迟越小，在主库故障的时候，服务恢复需要的时间就越短，可用性就越高。

28 | 读写分离有哪里坑

• 处理过期读的方案：

1. 强制走主库方案：按照业务需求进行分类，将需要立马查看最新数据的请求分发到主库，而不需要立马有效果的数据分发到从库。

2. sleep 方案，让执行语句先睡眠指定时间在开始执行，但仍然有可能拿到旧数据。

3. 判断主备无延迟方案（仍然不够精确）：

   • 查看seconds_behind_master参数值是否等于0。

   • 通过show slave status命令可以看到主库的最新位点，也可以看到从库执行的最新位点，所以可以通过对比位点的方式判断是否达到主备一致。

   • 同样通过show slave status可以看到从库的GTID集合。

4. 配合 半同步复制（semi-sync）方案：主库将binlog发送给从库，从库收到后给主库发送一个ack，主库收到ack后才给客户端返回事务完成。半同步复制适合一主一从，对于一主多从来说只要有一个从库返回ack给主库就可以了，所以其他的从库有可能读到的仍然是旧数据，还有一个就是在更新频繁的主库上，从库来不及赶不上主库，就会导致响应过慢。

5. 等主库位点方案，简单来说就是先判断从库是否包含刚刚执行的语句（最新的数据），如果没有或者说查询超过一定的时间后就到主库上查询，目的就是为了拿到最新数据，这种方案有可能导致主库压力增大。

6. 等 GTID 方案，跟方案5类似，客户端执行完语句后会返回一个GTID，拿着这个GTID去从库查询，如果返回0表示可以在这个从库执行语句（binlog已经同步过来了），否则到主库执行。

29 | 如何判断一个数据库是不是出问题了？

• 严格来说select 1并没办法判断数据库是否有问题，这条命令只在执行器内执行后就干活了，压根没有到存储引擎。

• 如何判断数据库是不是有问题：定期执行更新语句，但仍然有可能出现IO慢问题，所以可以查询InnoDB引擎内部的统计信息来接着判断，当IO请求时间超过指定时间后就认为数据库异常。

标签：24,25,执行,备库,丁奇,binlog,主备,主库,从库
来源： https://www.cnblogs.com/zlia/p/14609004.html