《丁奇-MySQL45讲-24/25/28》之归纳总结
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了《丁奇-MySQL45讲-24/25/28》之归纳总结，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2641字，纯文字阅读大概需要4分钟。
内容图文
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请求时间超过指定时间后就认为数据库异常。
内容总结
以上是互联网集市为您收集整理的《丁奇-MySQL45讲-24/25/28》之归纳总结全部内容，希望文章能够帮你解决《丁奇-MySQL45讲-24/25/28》之归纳总结所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。