包拯断案 | 数据库从库复制延迟引发高可用风险 怎么破@还故障一个本相 ...

提问：作为DBA运维的你是否碰到过这些烦恼
1、数据库从库复制出现了延迟，是什么原因导致的？
2、延迟引发了高可用风险，应该怎样处置惩罚？
心中有章，遇事不慌

作为DBA的你，碰到问题无从动手，除了在问题面前倘佯，还能怎样选择？如果你一次或多次碰到该问题还是无法办理，又很懊恼，该怎样排忧呢？关注公众号，关注《包拯断案》专栏，让小编为你排忧解难~
包拯秘笈

一整套故障排错及应对策略送给你，让你像包拯一样断案如神：
#首先
碰到此类问题后，我们要做到心中有章（章程），遇事不慌。一定要冷静，仔细相识故障现象（与研发/用户仔细沟通其反馈的问题，相识故障现象、操纵流程、数据库架构等信息）
#其次
我们要根据故障现象进行初步分析。心中要想：是什么原因导致数据库从库复制出现延迟？例如：是大事务导致了从库延迟，还是参数设置不妥原因导致的？
#然后
针对上述思索，我们需要逐步验证并排除，确定问题排查方向。
#接着
确定了问题方向，进行具体分析。通过现象得出部分结论，通过部分结论继续排查并论证。
#最后
针对问题有了具体分析后，再进行线下复现，终极梳理故障陈诉。
真刀实战，我们能赢

说了这么多理论，想必实战更让你心动。那我们就拿一个真实案例进行分析——某国有大型贸易银行业务体系发生主从延迟告警，这种问题该怎样快速分析处置惩罚：
1、故障发生场景

在项目现场谨小慎微进行数据库情况部署的你，突然发现某个体系出现了主从延迟告警。虽然不影响生产主库利用，但导致从库复制延迟，存在数据库集群的高可用风险，DBA心中警铃大作，立马动手排查。
2、故障排查分析

1）根据告警短信查询主从同步状态，发现从库接收到的gtid为1-12481714，从库应用的gtid为1-12396346，主从延迟大概85w个事务。经太过析发现，生产主库正常运行，从库同步任务SQL线程与IO线程无报错，初步怀疑为大事务导致的从库延迟。
经过仔细排查分析，发现该故障是由于生产库中创建了一张无主键、无索引的“测试表”，同时该表存在较多text类型的大字段。然后在生产库实行了一条没有过滤条件的update语句，导致整个语句走了全表扫描，该“测试表”共计924384条数据，属于大事务。
事务语句如下图：

由于该update语句没有引用任何过滤条件，且表无主键、无索引，导致该语句走了全表扫码，更新92w行，通过binlog行模式将日志发送到备库后需要回放92w次。每次都需要进行一次全表扫描，备集群回放慢主备。
2）继续观察主从同步延迟情况，发现主从延迟并无缩小，判定备库日志回放夯住。由于主从库事务量相差较多，建议重做备库，该方案操纵风险最低，且能完全保证主从库间的数据同等性。
3、问题复现

1）测试创建无主键表

直接创建无主键表，显示失败，报错不支持创建无主键表。
2）创建测试表

通过create table xx select * from xxx方式将表进行复制，此时复制后的表是无主键表。
3）测试更新语句

当dbscale-safe-sql-mode参数为2时，无法实行无条件更新语句；当该参数为1时，可以实行无条件更新语句。
4）按照生产情况规模，构建更新后同步非常情况复现场景——

通过第4步复现出无主键大表，进行全表更新，出现主从卡住的现象。
5）通过以上测试步骤说明：
采用create table xxx as select * from xxx方式直接复制表，会丢掉原表一些信息，例如主键、索引等。
复盘总结

• 研发人员要严格按照参数开辟规范中的形貌进行开辟，禁止利用create table xxx as select * from xxx语句进行表复制。并将表复制操纵修改为2步：第一步复制元数据，create table xxx like xxxx；第二步复制数据，insert into xxx select * from xxxx。
  2.避免在生产情况中进行测试。
  3.大事务要进行拆分，避免出现全表更新或删除等操纵。
  4.通过参数sql_require_primary_key（创建新表或更改现有表布局的语句是否逼迫要求表具有主键），规避create table as select 举动。
  5.建议将dbscale-safe-sql-mode参数设置为2，禁止进行无条件更新语句实行。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。