标签：24 25 执行 备库 丁奇 binlog 主备 主库 从库
24 | MySQL是怎么保证主备一致的？
- 主从同步流程：
-
在备库上执行change master命令，设置主库的IP、端口、用户、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量。
-
在备库上执行start slave命令，这个时候会启动两个线程，一个是IO_Thread、一个是SQL_Thread，其中IO_Thread负责与主库建立连接。
-
主库校验完用户密码后，按照备库指定的日志信息，从本地读取binlog，发送给备库。
-
备库拿到binlog后，写到本地文件，称为为中转日志（relay log）。
-
SQL_Thread读取中转日志，解析日志中的命令并执行。
-
文章中说的加-c参数保留注释是指：mysql -u root -p -c，这样子就可以使用了。
-
binlog_format=statement格式下会因为索引选择的不同而造成主从库不一致。
-
重放binlog的时候最好使用mysqlbinlog工具，或者是第三方工具，禁止自己拷贝SQL直接执行，执行完后的结果会出现问题。
25 | MySQL是怎么保证高可用的？
-
使用show slave status命令，seconds_behind_master表示备库落后主库的时间差，单位是秒。
-
造成主备延迟的最直接原因是：主库生产binlog的速度大于备库接收binlog的速度，那产生这些因素的原因有可能是：
-
备库所在的机器性能要比主库查。
-
备库压力大，比如运营后台的操作占用了备库上的大量CPU，造成了同步延迟。
-
主库上执行大事务，比如删除大量的数据或者是大表的DDL。
- MySQL高可用依赖于主备延迟的，延迟越小，在主库故障的时候，服务恢复需要的时间就越短，可用性就越高。
28 | 读写分离有哪里坑
- 处理过期读的方案：
-
强制走主库方案：按照业务需求进行分类，将需要立马查看最新数据的请求分发到主库，而不需要立马有效果的数据分发到从库。
-
sleep 方案，让执行语句先睡眠指定时间在开始执行，但仍然有可能拿到旧数据。
-
判断主备无延迟方案（仍然不够精确）：
-
查看seconds_behind_master参数值是否等于0。
-
通过show slave status命令可以看到主库的最新位点，也可以看到从库执行的最新位点，所以可以通过对比位点的方式判断是否达到主备一致。
-
同样通过show slave status可以看到从库的GTID集合。
-
-
配合 半同步复制（semi-sync）方案：主库将binlog发送给从库，从库收到后给主库发送一个ack，主库收到ack后才给客户端返回事务完成。半同步复制适合一主一从，对于一主多从来说只要有一个从库返回ack给主库就可以了，所以其他的从库有可能读到的仍然是旧数据，还有一个就是在更新频繁的主库上，从库来不及赶不上主库，就会导致响应过慢。
-
等主库位点方案，简单来说就是先判断从库是否包含刚刚执行的语句（最新的数据），如果没有或者说查询超过一定的时间后就到主库上查询，目的就是为了拿到最新数据，这种方案有可能导致主库压力增大。
-
等 GTID 方案，跟方案5类似，客户端执行完语句后会返回一个GTID，拿着这个GTID去从库查询，如果返回0表示可以在这个从库执行语句（binlog已经同步过来了），否则到主库执行。
29 | 如何判断一个数据库是不是出问题了？
-
严格来说select 1并没办法判断数据库是否有问题，这条命令只在执行器内执行后就干活了，压根没有到存储引擎。
-
如何判断数据库是不是有问题：定期执行更新语句，但仍然有可能出现IO慢问题，所以可以查询InnoDB引擎内部的统计信息来接着判断，当IO请求时间超过指定时间后就认为数据库异常。
标签：24,25,执行,备库,丁奇,binlog,主备,主库,从库 来源： https://www.cnblogs.com/zlia/p/14609004.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。