mysql主从延迟，主库挂掉如何恢复数据

在老版本的MySQL 3.22中，MySQL的单表限大小为4GB，当时的MySQL的存储引擎还是ISAM存储引擎。但是，当出现MyISAM存储引擎之后，也就是从MySQL 3.23开始，MySQL单表最大限制就已经扩大到了64PB了（官方文档显示）。也就是说，从目前的技术环境来看，MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定，而是由所在主机的OS上面的文件系统来决定了。 而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的，一种是共享表空间存储方式，还有一种是独享表空间存储方式。 当使用共享表空间存储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所 以其大小限制不再是文件大小的限制

很抱歉，您提供的信息不太清晰，我无法理解您的问题。请提供更多详细信息或背景，以便我能够更好地帮助您。很抱歉，您提供的信息不太清晰，我无法理解您的问题。请提供更多详细信息或背景，以便我能够更好地帮助您。

这样计算的问题：

1、 首先这样的计算方法本身是不对的，如果本地时间有问题会导致event时间戳不准，从而出现误差，所以计算公式中会记录一下主从库的当前时间差

公式如下：

注意：这个时间差只会在主从线程启动时计算一次，所以start slave后如果主从本地时间出现异常，Seconds_Behind_Master也是不准的，需要重启复制线程重新计算主从本地时间差异（如果最终计算结果是负数，会归零）

2、 如果IO线程出现延迟，此时这个值是有误差的，Seconds_Behind_Master可能显示为0，但实际和主库是有延迟的，容易出现误差

提示：所以只拿这个值来做复制延迟的监控是不准的，一般都会配合心跳表的时间戳来判断当前延迟

每次进行show slave status时都会进行一次计算

源码如下：

这里可以看到判断SQL线程是否应用所有的event

注意：此时如果IO线程有延迟则即使Seconds_Behind_Master=0但是还是有延迟

关键词解释

单线程复制和并行复制对于last_master_timestamp这个的计算也是不同的

ev->when.tv_sec表示事件的开始时间。exec_time指事件在主库的执行时间,GTID_EVENT和XID_EVENT才会统计exec_time

总结：事务执行中的event时间都是事务开始时begin的时间戳，GTID_EVENT和XID_EVENT则是事务提交的时间，所以如果存在事务长时间未提交就会出现延迟突然增大然后正常的情况

先了解一下并行复制的流程

这导致并行复制和单线程复制之间复制延迟会有差异，差异是slave_checkpoint_period + 事务在备库执行的时间，这就是有时单线程无延迟，换到并行复制反而有轻微延迟的原因

另外DDL的时间戳计算其实是事务执行时间+事务开始时间

本文主要讲述了seconds_behind_master在不同模式下的计算方式，很多情况会导致这个参数不准确，所以也建议大家还是结合心跳表配合监控延迟比较准确,如有理解偏差欢迎随时指正

本文参考：

---