岚山网站建设报价,wordpress滑块,分销管理系统软件,7星彩网站开发MySQL高可用
Hi#xff0c;我是阿昌#xff0c;今天学习记录的是关于MySQL高可用的内容。
正常情况下#xff0c;只要主库执行更新生成的所有 binlog#xff0c;都可以传到备库并被正确地执行#xff0c;备库就能达到跟主库一致的状态#xff0c;这就是最终一致性。但是…MySQL高可用
Hi我是阿昌今天学习记录的是关于MySQL高可用的内容。
正常情况下只要主库执行更新生成的所有 binlog都可以传到备库并被正确地执行备库就能达到跟主库一致的状态这就是最终一致性。但是MySQL 要提供高可用能力只有最终一致性是不够的。为什么这么说呢 一、主备延迟
主备切换 可能是一个主动运维动作比如软件升级、主库所在机器按计划下线等也可能是被动操作比如主库所在机器掉电。
一个概念即“同步延迟”。与数据同步有关的时间点主要包括以下三个
主库 A 执行完成一个事务写入 binlog把这个时刻记为 T1;之后传给备库 B把备库 B 接收完这个 binlog 的时刻记为 T2;备库 B 执行完成这个事务把这个时刻记为 T3。
所谓主备延迟就是同一个事务在备库执行完成的时间和主库执行完成的时间之间的差值也就是 T3-T1。
可以在备库上执行 show slave status 命令它的返回结果里面会显示 seconds_behind_master用于表示当前备库延迟了多少秒。
seconds_behind_master 的计算方法是这样的
每个事务的 binlog 里面都有一个时间字段用于记录主库上写入的时间备库取出当前正在执行的事务的时间字段的值计算它与当前系统时间的差值得到 seconds_behind_master。
可以看到其实 seconds_behind_master 这个参数计算的就是 T3-T1。
所以可以用 seconds_behind_master 来作为主备延迟的值这个值的时间精度是秒。
如果主备库机器的系统时间设置不一致会不会导致主备延迟的值不准其实不会的。
因为备库连接到主库的时候会通过执行 SELECT UNIX_TIMESTAMP() 函数来获得当前主库的系统时间。
如果这时候发现主库的系统时间与自己不一致备库在执行 seconds_behind_master 计算的时候会自动扣掉这个差值。
需要说明的是在网络正常的时候日志从主库传给备库所需的时间是很短的即 T2-T1 的值是非常小的。
也就是说网络正常情况下主备延迟的主要来源是备库接收完 binlog 和执行完这个事务之间的时间差。
所以说主备延迟最直接的表现是备库消费中转日志relay log的速度比主库生产 binlog 的速度要慢。 二、主备延迟的来源
首先有些部署条件下备库所在机器的性能要比主库所在的机器性能差。
一般情况下有人这么部署时的想法是反正备库没有请求所以可以用差一点儿的机器。
或者他们会把 20 个主库放在 4 台机器上而把备库集中在一台机器上。
其实都知道更新请求对 IOPS 的压力在主库和备库上是无差别的。
所以做这种部署时一般都会将备库设置为“非双 1”的模式。但实际上更新过程中也会触发大量的读操作。
所以当备库主机上的多个备库都在争抢资源的时候就可能会导致主备延迟了。当然这种部署现在比较少了。
因为主备可能发生切换备库随时可能变成主库所以主备库选用相同规格的机器并且做对称部署是现在比较常见的情况。 追问 1但是做了对称部署以后还可能会有延迟。这是为什么呢
这就是第二种常见的可能了即备库的压力大。
一般的想法是主库既然提供了写能力那么备库可以提供一些读能力。
或者一些运营后台需要的分析语句不能影响正常业务所以只能在备库上跑。
真就见过不少这样的情况。由于主库直接影响业务大家使用起来会比较克制反而忽视了备库的压力控制。
结果就是备库上的查询耗费了大量的 CPU 资源影响了同步速度造成主备延迟。
这种情况一般可以这么处理
一主多从。除了备库外可以多接几个从库让这些从库来分担读的压力。通过 binlog 输出到外部系统比如 Hadoop 这类系统让外部系统提供统计类查询的能力。
其中一主多从的方式大都会被采用。因为作为数据库系统还必须保证有定期全量备份的能力。而从库就很适合用来做备份。 追问 2采用了一主多从保证备库的压力不会超过主库还有什么情况可能导致主备延迟吗
这就是第三种可能了即大事务。大事务这种情况很好理解。因为主库上必须等事务执行完成才会写入 binlog再传给备库。
所以如果一个主库上的语句执行 10 分钟那这个事务很可能就会导致从库延迟 10 分钟 不知道所在公司的 DBA 有没有跟你这么说过不要一次性地用 delete 语句删除太多数据。
其实这就是一个典型的大事务场景。比如一些归档类的数据平时没有注意删除历史数据等到空间快满了业务开发人员要一次性地删掉大量历史数据。
同时又因为要避免在高峰期操作会影响业务至少有这个意识还是很不错的所以会在晚上执行这些大量数据的删除操作。
结果负责的 DBA 同学半夜就会收到延迟报警。然后DBA 团队就要求你后续再删除数据的时候要控制每个事务删除的数据量分成多次删除。
另一种典型的大事务场景就是大表 DDL。 追问 3如果主库上也不做大事务了还有什么原因会导致主备延迟吗
造成主备延迟还有一个大方向的原因就是备库的并行复制能力。 三、可靠性优先策略
在图 1 的双 M 结构下从状态 1 到状态 2 切换的详细过程是这样的
判断备库 B 现在的 seconds_behind_master如果小于某个值比如 5 秒继续下一步否则持续重试这一步把主库 A 改成只读状态即把 readonly 设置为 true判断备库 B 的 seconds_behind_master 的值直到这个值变成 0 为止把备库 B 改成可读写状态也就是把 readonly 设置为 false把业务请求切到备库 B。
这个切换流程一般是由专门的 HA 系统来完成的暂时称之为可靠性优先流程。 备注图中的 SBM是 seconds_behind_master 参数的简写。可以看到这个切换流程中是有不可用时间的。
因为在步骤 2 之后主库 A 和备库 B 都处于 readonly 状态也就是说这时系统处于不可写状态直到步骤 5 完成后才能恢复。
在这个不可用状态中比较耗费时间的是步骤 3可能需要耗费好几秒的时间。
这也是为什么需要在步骤 1 先做判断确保 seconds_behind_master 的值足够小。
试想如果一开始主备延迟就长达 30 分钟而不先做判断直接切换的话系统的不可用时间就会长达 30 分钟这种情况一般业务都是不可接受的。
当然系统的不可用时间是由这个数据可靠性优先的策略决定的。
也可以选择可用性优先的策略来把这个不可用时间几乎降为 0。 四、可用性优先策略
如果强行把步骤 4、5 调整到最开始执行也就是说不等主备数据同步直接把连接切到备库 B并且让备库 B 可以读写那么系统几乎就没有不可用时间了。把这个切换流程暂时称作可用性优先流程。
这个切换流程的代价就是可能出现数据不一致的情况。
分享一个可用性优先流程产生数据不一致的例子。
假设有一个表 t
mysql CREATE TABLE t (id int(11) unsigned NOT NULL AUTO_INCREMENT,c int(11) unsigned DEFAULT NULL,PRIMARY KEY (id)
) ENGINEInnoDB;insert into t(c) values(1),(2),(3);这个表定义了一个自增主键 id初始化数据后主库和备库上都是 3 行数据。
接下来要继续在表 t 上执行两条插入语句的命令依次是
insert into t(c) values(4);
insert into t(c) values(5);假设现在主库上其他的数据表有大量的更新导致主备延迟达到 5 秒。
在插入一条 c4 的语句后发起了主备切换。
图 3 是可用性优先策略且 binlog_formatmixed 时的切换流程和数据结果。 现在一起分析下这个切换流程
步骤 2 中主库 A 执行完 insert 语句插入了一行数据4,4之后开始进行主备切换。步骤 3 中由于主备之间有 5 秒的延迟所以备库 B 还没来得及应用“插入 c4”这个中转日志就开始接收客户端“插入 c5”的命令。步骤 4 中备库 B 插入了一行数据4,5并且把这个 binlog 发给主库 A。步骤 5 中备库 B 执行“插入 c4”这个中转日志插入了一行数据5,4。而直接在备库 B 执行的“插入 c5”这个语句传到主库 A就插入了一行新数据5,5。
最后的结果就是主库 A 和备库 B 上出现了两行不一致的数据。可以看到这个数据不一致是由可用性优先流程导致的。那么如果我还是用可用性优先策略但设置 binlog_formatrow情况又会怎样呢
因为 row 格式在记录 binlog 的时候会记录新插入的行的所有字段值所以最后只会有一行不一致。而且两边的主备同步的应用线程会报错 duplicate key error 并停止。
也就是说这种情况下备库 B 的 (5,4) 和主库 A 的 (5,5) 这两行数据都不会被对方执行。
图 4 中画出了详细过程分析一下。 从上面的分析中可以看到一些结论
使用 row 格式的 binlog 时数据不一致的问题更容易被发现。而使用 mixed 或者 statement 格式的 binlog 时数据很可能悄悄地就不一致了。如果过了很久才发现数据不一致的问题很可能这时的数据不一致已经不可查或者连带造成了更多的数据逻辑不一致。主备切换的可用性优先策略会导致数据不一致。
因此大多数情况下都建议使用可靠性优先策略。毕竟对数据服务来说的话数据的可靠性一般还是要优于可用性的。 但事无绝对有没有哪种情况数据的可用性优先级更高呢答案是有的。曾经一个场景
有一个库的作用是记录操作日志。这时候如果数据不一致可以通过 binlog 来修补而这个短暂的不一致也不会引发业务问题。同时业务系统依赖于这个日志写入逻辑如果这个库不可写会导致线上的业务操作无法执行。
这时候你可能就需要选择先强行切换事后再补数据的策略。
当然事后复盘的时候想到了一个改进措施就是让业务逻辑不要依赖于这类日志的写入。
也就是说日志写入这个逻辑模块应该可以降级比如写到本地文件或者写到另外一个临时库里面。
这样的话这种场景就又可以使用可靠性优先策略了。 按照可靠性优先的思路异常切换会是什么效果
假设主库 A 和备库 B 间的主备延迟是 30 分钟这时候主库 A 掉电了HA 系统要切换 B 作为主库。
在主动切换的时候可以等到主备延迟小于 5 秒的时候再启动切换但这时候已经别无选择了。 采用可靠性优先策略的话就必须得等到备库 B 的 seconds_behind_master0 之后才能切换。
但现在的情况比刚刚更严重并不是系统只读、不可写的问题了而是系统处于完全不可用的状态。因为主库 A 掉电后连接还没有切到备库 B。
那能不能直接切换到备库 B但是保持 B 只读呢这样也不行。
因为这段时间内中转日志还没有应用完成如果直接发起主备切换客户端查询看不到之前执行完成的事务会认为有“数据丢失”。
虽然随着中转日志的继续应用这些数据会恢复回来但是对于一些业务来说查询到“暂时丢失数据的状态”也是不能被接受的。
在满足数据可靠性的前提下MySQL 高可用系统的可用性是依赖于主备延迟的。延迟的时间越小在主库故障的时候服务恢复需要的时间就越短可用性就越高。 五、问题
一般现在的数据库运维系统都有备库延迟监控其实就是在备库上执行 show slave status采集 seconds_behind_master 的值。假设现在你看到你维护的一个备库它的延迟监控的图像类似图 6是一个 45°斜向上的线段觉得可能是什么原因导致呢又会怎么去确认这个原因呢 现象描述 主备延迟最直接的表现是备库消费中转日志relay log的速度比主库生产binlog日志的速度要慢。 导致上述现象的可能原因有如下几种
有些部署条件下备库所在机器的性能要比主库所在机器性能要差 备库压力大 大事务一次性delete删除大量数据和大表DDL 备库的并行复制能力
针对性确认思路
观察主备库所在机器的是否一致。 观察备库所在机器的CPU资源占用情况。 通过从库的show slave status来查看主从同步延迟情况如果时间太长则可以认为有大事务反之则没有。 待确认。
文章转载自： http://www.morning.bsbcp.cn.gov.cn.bsbcp.cn http://www.morning.llfwg.cn.gov.cn.llfwg.cn http://www.morning.cxtbh.cn.gov.cn.cxtbh.cn http://www.morning.tqrjj.cn.gov.cn.tqrjj.cn http://www.morning.qyhcm.cn.gov.cn.qyhcm.cn http://www.morning.mcwrg.cn.gov.cn.mcwrg.cn http://www.morning.wkgyz.cn.gov.cn.wkgyz.cn http://www.morning.bxnrx.cn.gov.cn.bxnrx.cn http://www.morning.yllym.cn.gov.cn.yllym.cn http://www.morning.klzt.cn.gov.cn.klzt.cn http://www.morning.clxpp.cn.gov.cn.clxpp.cn http://www.morning.skdhm.cn.gov.cn.skdhm.cn http://www.morning.rfxg.cn.gov.cn.rfxg.cn http://www.morning.ggtkk.cn.gov.cn.ggtkk.cn http://www.morning.gywfp.cn.gov.cn.gywfp.cn http://www.morning.dpjtn.cn.gov.cn.dpjtn.cn http://www.morning.fxxmj.cn.gov.cn.fxxmj.cn http://www.morning.skscy.cn.gov.cn.skscy.cn http://www.morning.jfxdy.cn.gov.cn.jfxdy.cn http://www.morning.qhjkz.cn.gov.cn.qhjkz.cn http://www.morning.pqqhl.cn.gov.cn.pqqhl.cn http://www.morning.webpapua.com.gov.cn.webpapua.com http://www.morning.llgpk.cn.gov.cn.llgpk.cn http://www.morning.rdlxh.cn.gov.cn.rdlxh.cn http://www.morning.lxngn.cn.gov.cn.lxngn.cn http://www.morning.mrlls.cn.gov.cn.mrlls.cn http://www.morning.lnyds.cn.gov.cn.lnyds.cn http://www.morning.jpmcb.cn.gov.cn.jpmcb.cn http://www.morning.bbgn.cn.gov.cn.bbgn.cn http://www.morning.tmjhy.cn.gov.cn.tmjhy.cn http://www.morning.qysnd.cn.gov.cn.qysnd.cn http://www.morning.zdxinxi.com.gov.cn.zdxinxi.com http://www.morning.wbqt.cn.gov.cn.wbqt.cn http://www.morning.jopebe.cn.gov.cn.jopebe.cn http://www.morning.ysbrz.cn.gov.cn.ysbrz.cn http://www.morning.zkgpg.cn.gov.cn.zkgpg.cn http://www.morning.sfcfy.cn.gov.cn.sfcfy.cn http://www.morning.htqrh.cn.gov.cn.htqrh.cn http://www.morning.fzqfb.cn.gov.cn.fzqfb.cn http://www.morning.qbfqb.cn.gov.cn.qbfqb.cn http://www.morning.zpyxl.cn.gov.cn.zpyxl.cn http://www.morning.rszt.cn.gov.cn.rszt.cn http://www.morning.wqwbj.cn.gov.cn.wqwbj.cn http://www.morning.xwbld.cn.gov.cn.xwbld.cn http://www.morning.nhgkm.cn.gov.cn.nhgkm.cn http://www.morning.hhqjf.cn.gov.cn.hhqjf.cn http://www.morning.lrjtx.cn.gov.cn.lrjtx.cn http://www.morning.xrtsx.cn.gov.cn.xrtsx.cn http://www.morning.mxnrl.cn.gov.cn.mxnrl.cn http://www.morning.bpmth.cn.gov.cn.bpmth.cn http://www.morning.pqjpw.cn.gov.cn.pqjpw.cn http://www.morning.gjqnn.cn.gov.cn.gjqnn.cn http://www.morning.gbcxb.cn.gov.cn.gbcxb.cn http://www.morning.nzhzt.cn.gov.cn.nzhzt.cn http://www.morning.mqss.cn.gov.cn.mqss.cn http://www.morning.zcsyz.cn.gov.cn.zcsyz.cn http://www.morning.rbrd.cn.gov.cn.rbrd.cn http://www.morning.tmcmj.cn.gov.cn.tmcmj.cn http://www.morning.zrdqz.cn.gov.cn.zrdqz.cn http://www.morning.thrtt.cn.gov.cn.thrtt.cn http://www.morning.yrhd.cn.gov.cn.yrhd.cn http://www.morning.xinxianzhi005.com.gov.cn.xinxianzhi005.com http://www.morning.zknjy.cn.gov.cn.zknjy.cn http://www.morning.pzcjq.cn.gov.cn.pzcjq.cn http://www.morning.gbqgr.cn.gov.cn.gbqgr.cn http://www.morning.mwwnz.cn.gov.cn.mwwnz.cn http://www.morning.ldzss.cn.gov.cn.ldzss.cn http://www.morning.pznqt.cn.gov.cn.pznqt.cn http://www.morning.yxplz.cn.gov.cn.yxplz.cn http://www.morning.lsgsn.cn.gov.cn.lsgsn.cn http://www.morning.jcxzq.cn.gov.cn.jcxzq.cn http://www.morning.jkwwm.cn.gov.cn.jkwwm.cn http://www.morning.bnylg.cn.gov.cn.bnylg.cn http://www.morning.wjtxt.cn.gov.cn.wjtxt.cn http://www.morning.jcbmm.cn.gov.cn.jcbmm.cn http://www.morning.fynkt.cn.gov.cn.fynkt.cn http://www.morning.dnvhfh.cn.gov.cn.dnvhfh.cn http://www.morning.xfxlr.cn.gov.cn.xfxlr.cn http://www.morning.jbhhj.cn.gov.cn.jbhhj.cn http://www.morning.wdply.cn.gov.cn.wdply.cn
