请不要用SECONDS

  • 时间:
  • 浏览:1
  • 来源:大发5分快乐8_极速5分11选5

沃趣科技的 Monitor 监控中对主备克隆的延迟监控,并需用通过 Seconds_Behind_Master 来监控主备的。它采用了累似 于 pt-heartbeat 的措施 对主备进行克隆延迟监控。

嘴笨 你这个 场景非常特殊,遇到的概率无须高,有后来 另一方嘴笨 有必要提醒一下使用 MySQL 的 DBA 们。通过对你这个 场景的分析,需用促使亲戚亲戚亲戚所有人 更加深入的理解 MySQL replication 重试机制。

其中 master-connect-retry 和 master-retry-count 需用在 Change Master 搭建主备克隆时指定,而 slave-net-timeout 是另一个全局变量,能否 在 MySQL 运行时在线设置。

slave-net-timeout 的默认值是 33000 秒, master-connect-retry 默认为 300 秒, master-retry-count 默认为 86300 次。也本来说,有后来 主库另一个小时都那末任何数据变更发送过来,备库才会尝试重连主库。这本来为哪十几个 在亲戚亲戚亲戚所有人 模拟的场景下,另一个小时后,备库才会重连主库,继续同步数据变更的意味。

l  被动处理

此时观察备库的克隆情况表, show slave status 中:

MySQL 克隆 进程 会自动将目前克隆位置记录下来,在主备克隆中断的后来自动连上主库,并从上次中断的位置重新刚开始了了克隆。哪十几个 操作需用全自动化的,不需用人为的干预。这给了 MySQL DBA 带来了本来便利,一起去却也隐藏了本来细节。

Seconds_Behind_Master: 0

那末 MySQL 具体是为啥“推”的列,实际上备库在向主库申请数据变更记录的后来,需用指定从主库Binlog 的哪个文件 MASTER_LOG_FILE 的具体十几个 个字节偏移位置 MASTER_LOG_POS )。对应的,主库会启动另一个 Binlog dump 的进程,将变更的记录从你这个 位置刚开始了了四根四根的发给备库。备库突然监听主库过来的变更,接收到四根,才会在本地应用你这个 数据变更。

突然出现疑问的后来, Binlog dump 进程被亲戚亲戚亲戚所有人  kill 掉了。作为监听的一方,备库突然那末收到任何变更,它会认为主库上长时间那末任何变更,意味那末变更数据推送过来。备库是无法判断主库上对应的Binlog dump 进程 到底是意外终止了,还是长时间那末任何数据变更的。本来,对这并需用情况表来说,备库都显示为正常。

搭建主备的克隆,临时断开主库的网络,并 kill 掉主库 MySQL 的 binlog dump 进程。

具体的重试策略为:备库过了 slave-net-timeout 秒还那末收到主库来的数据,它就会刚开始了了第一次重试。有后来 每过 master-connect-retry 秒,备库会再次尝试重连主库。直到重试了 master-retry-count 次,它才会放弃重试。有后来 重试的过程中,连上了主库,那末它认为当前主库是好的,又会刚开始了了 slave-net-timeout 秒的等候。

MySQL 能否 指定另一个参数,用于克隆进程重连主库: --master-retry-count ,  --master-connect-retry ,  --slave-net-timeout 

当然 slave-net-timeout 设置的过小需用疑问,原先会意味有后来 主库的变更嘴笨 比较少的后来,备库频繁的重新连接主库,造成资源浪费。

首先, MySQL 的克隆是“推”的,而需用“拉”的。“拉”是指 MySQL 的备库不断的循环询问主库是与非 有数据更新,你这个 措施 资源消耗多,有后来 速率单位低。“推”是指 MySQL 的主库在另一方有数据更新的后来推送你这个 变更给备库,你这个 措施 能否 了在数据有变更的后来才会地处交互,资源消耗少。有后来 你是进程员出身,你后来挑选 “推”的措施 。

一切正常,普通的监控软件需用会发现备库有数据延迟。

影响范围: MySQL , Percona , MariaDB 的所有版本。

Slave_IO_Running: Yes

基于顶端的分析,亲戚亲戚亲戚所有人 知道 MySQL 在你这个 情况表下嘴笨 无法处理,那末亲戚亲戚亲戚所有人 能否 有哪十几个 措施 能否 避开列:

l  备库有后来 长时间那末收到从主库过来的变更,它会每隔一段时间重连主库。

发现你这个 疑问后来,亲戚亲戚亲戚所有人 只需用 stop slave; start slave; 重启克隆就能处理你这个 疑问。

当然, MySQL 会尽量处理你这个 情况表。比如:

MySQL 的 Replication 是区别于其他数据库很关键的地方。也是可扩展性和高可用的基础。它并需用有后来 非常智能化,只需用亲戚亲戚亲戚所有人 调用 Change Master 指定 Binlog 文件名和偏移位置就能否 搭建从主库到备库的克隆关系。

2.  主动预防:正确设置 --master-retry-count ,  --master-connect-retry ,  --slave-net-timeout克隆重试参数。

Slave_SQL_Running: Yes

从顶端的分析,亲戚亲戚亲戚所有人 能否 大致猜到为哪十几个  show slave status 显示一切正常,有后来 实际上主库的变更都无法同步到备库上来:

原先励志的话 ,有后来 你的主库上变更比较频繁,能否 考虑将 slave-net-timeout 设置的小其他,处理主库Binlog dump 进程 终止了,无法将最新的更新推送过来。

MySQL 的延迟监控大每段直接派发 show slave status 中的 Seconds_Behind_Master 。你这个 情况表下,Seconds_Behind_Master 就无法用来真实的衡量主备之间的克隆延迟了。亲戚亲戚亲戚所有人 建议通过在主库轮询插入时间信息,并通过克隆到备库的时间差来获得主备延迟的方案。 Percona 提供了并需用累似 的方案 pt-heartbeat 

有后来 此时你把网络恢复后来,在主库做任何变更,备库都无法获得数据更新了。有后来 备库上的show slave status 显示: IO 进程 SQL 进程一切正常,克隆延迟突然是 

l  在 Binlog dump 被 kill 掉时通知备库 进程 被 kill 掉了。本来亲戚亲戚亲戚所有人 重现需用用保证你这个 通知发送能否 了备库,也本来说该疑问重现的关键在于 Binlog dump 被 kill 的消息有后来 网络堵塞有后来 其他意味无法发送到备库。

l  主动预防

MySQL 并需用通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的克隆延迟,有后来 今天碰到了另一个场景,发现 Seconds_Behind_Master 为 , 备库的 show slave status 显示 IO/SQL 进程需用正常的 , MySQL 的主库上的变更却长时间无法同步到备库上。有后来 那末人为干预,直到另一个小时后来, MySQL 才会自动重连主库,继续克隆主库的变更。

1.  被动处理:修改延迟的监控措施 ,发现疑问及时处理。

要真正的理解前面疑问的真相以及为啥处理你这个 疑问,亲戚亲戚亲戚所有人 还是需用真正的理解 MySQL  克隆的原理。