百木园1.场景描述
早上7：25 接到Report中心同学告警，昨天业务报表数据没有完整跑出来，缺少500位业务员的数据，并且很快定位到，缺少的是huabei_order库上的数据。Report中心的数据是BI每天5:15从huabei_order库的从库上抽取。查看监控告警，从库实例确实在4:50 --6:00 有延迟，但已恢复。报表数据不完整，直接原因就是主从延迟。
7:50 确认主从延迟已恢复，请求BI重新抽取数据，重新生成报表。
8：20 报表数据验证无误。
问题还没结束：
忽略监控告警的不及时、不完整。
还需要回答的问题是为什么在业务低峰期会出现延迟？是什么操作造成的？【问题1】
监控界面主从延迟指标
看到这样的走势图，又一个需要思考的问题:为什么延迟会瞬间飙升到24440s以上（实际可能已达25K以上），延迟不应该是逐渐累积的吗？【问题2】
确实是业务低峰期，和研发、产品、业务确认，23:30 之后没有大的操作、大的流量，也没有特别的活动、促销。从数据库Server业务压力上考虑，确实没有特殊的操作。
忽然想到，备份，完整备份。我们的灾备，数据库的完整备份实在从库上做的，cron 设置在每天的00:05 , 一般执行2个小时， 并且是周二、周五执行，当天正好是周二。
虽然自己也不太相信这个就是真正的原因，但毕竟是一个可考虑的因素。查看完整备份的log。
2.全量备份
失败
报错信息如下:
210831 04:49:46 >> log scanned up to (1168680308582)
210831 04:49:47 >> log scanned up to (1168680308668)
210831 04:49:48 >> log scanned up to (1168680308770)
210831 04:49:49 >> log scanned up to (1168680308856)
210831 04:49:50 >> log scanned up to (1168680308942)
210831 04:49:51 >> log scanned up to (1168680309028)
210831 04:49:52 >> log scanned up to (1168680309114)
InnoDB: Last flushed lsn: 1168515708469 load_index lsn 1168680309114
InnoDB: An optimized (without redo logging) DDLoperation has been performed. All modified pages may not have been flushed to the disk yet.
PXB will not be able take a consistent backup. Retry the backup operation
mysql: [Warning] Using a password on the command line interface can be insecure.
来源：https://www.cnblogs.com/xuliuzai/p/15216768.html
图文来源于网络，如有侵权请联系删除。