mysql主从同步(5)

  • 时间:
  • 浏览:0
  • 来源:大发5分3DAPP下载_大发5分3DAPP官方

5

另另有几块多 遇到过的另有几块多 坑:

Mysql主从环境部署后,就让开始了了主从数据同步是没间题的,也是通过监控Seconds_Behind_Master的值来判断同步算是延迟。就让 运行一段时间后,无缘无故有一天发现,主库上写入新数据后,从库并那末 按时同步过来!!于是,立刻在从库上执行"show slave status \G;"发现Seconds_Behind_Master为0 ,就让 Slave_IO_Running和Slave_SQL_Running多线程 池情況有的是YES也却句子从库到主库的连接还在,那末 断开!就让 主库上的变更数据却说长时间无法同步到从库上。因为着那末 人为干预,直到另有几块多 小时就让 ,从库才会自动重新连接主库,进而才继续同步主库的变更

处于什儿 情況时,通过一般的正常监控依据是不用发现从库有数据延迟。由此可见,仅仅通过Seconds_Behind_Master=0来判断同步算是延迟显然是缺乏滴.........

+

重新执行qq克隆好友 后,要尽快修改slave_net_timeout什儿 参数

  slave-net-timeout 的默认值是3500 秒, master-connect-retry默认为50秒, master-retry-count默认为8650次。

  也却句子,因为着主库另有几块多 小时都那末 任何数据变更发送过来,备库才会尝试重连主库。

  这却说为哪此我遇到场景下,另有几块多 小时后,备库才会重连主库,继续同步数据变更的因为。

  另另有几块多 句子,因为着你的主库上变更比较频繁,还须要考虑将slave-net-timeout设置的小什儿 ,外理主库 Binlog dump 多线程 池 终止了,无法将最新的更新推送过来。

  当然 slave-net-timeout 设置的过小有的是间题,另另有几块多 会因为因为着主库的变更随便说说比较少的就让 ,备库频繁的重新连接主库,造成资源浪费。

当然,上述场景是非常特殊的,一般无缘无故出现的概率比较小,就让 作为运维人员,一群人非常有必要搞清楚该缘何应对什儿 情況。这就须要一群人要更加深入的吃透MySQL replication重试机制。

| Variable_name     | Value |

那末 MySQL具体是缘何“推”的列呢?

实际上备库在向主库申请数据变更记录的就让 ,须要指定从主库Binlog的哪个文件(MASTER_LOG_FILE)的具体有几块个字节偏移位置(MASTER_LOG_POS)。对应的,主库会启动另有几块多 Binlog dump的多线程 池,将变更的记录从什儿 位置刚开始了了一根绳子 一根绳子 的发给备库。备库无缘无故监听主库过来的变更,接收到一根绳子 ,才会在本地应用什儿 数据变更。

Query OK, 0 rows affected, 1 warning (0.00 sec)

   1--被动外理

   MySQL的延迟监控大次责直接分发show slave status中的Seconds_Behind_Master 。

   那末 像后面 说的什儿 情況下, Seconds_Behind_Master就无法用来真实的衡量主备之间的qq克隆好友 延迟了。

   推荐使用Percona提供的监控方案(参考:mysql主从同步(3)-percona-toolkit工具(数据一致性监测、延迟监控)使用梳理)

   2--主动预防

   除了手动在从库上stop slave和start slave重新执行qq克隆好友 后,还须要指定另有几块多 参数,用于qq克隆好友 多线程 池重连主库,分别是

   master-retry-count:连接重试的次数。

   master-connect-retry:连接失败后等待的秒数

   slave-net-timeout:后面 已介绍

   其中 master-connect-retry 和 master-retry-count 须要在 Change Master 搭建主备qq克隆好友 时指定,而 slave-net-timeout 是另有几块多 全局变量,还须要在 MySQL 运行时在线设置。

   不过要注意的是:master-connect-retry和master-retry-count参数在Mysql5.6版本里就被去除了,却说有Mysql5.6版本及更高版本就只设置slave-net-timeout参数即可。

3)间题外理

基于后面 的分析,还须要知道MySQL在什儿 情況下随便说说无法外理,那末 有哪此依据还须要避开:

   1--被动外理:修改延迟的监控依据,发现间题及时外理。

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

| slave_net_timeout | 3500  |

1 row in set (0.00 sec)

6

  具体的重试策略为:

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

9

1

4

因为着在部署mysql主从同步的就让 ,那末 在从库这边设置好slave_net_timeout什儿 参数,遇到后面 的情況,它就会按照默认的3500s(一小时)采取自动重新连接主库,就让 也能继续同步主库的变更。什儿 参数那末 设置很多,很多会造成数据库延迟因为着主备库直接的链接异常那末 及时发现就让 设置太小又会造成主库那末 数据更新时频繁重连。

至于slave_net_timeout什儿 参数究竟设置有几块,要根据当时人的mysql主库数据更新的频繁程度:主库数据更新频繁的,就将什儿 参数值设小点,更新不频繁就设大点。

一般什儿 参数设置5s、10s、15s、20s、50s等等。

3

+

1

并不一定要等1小时也能重新同步,因为着slave_net_timeout什儿 参数默认的却说3500s,它是设置在有几块秒没收到主库传来的Binary Logs events就让 ,从库认为网络超时,Slave IO多线程 池会重新连接主库。

就让 ,将什儿 参数设置恰当后,遇到后面 间题的就让 ,从库就会按照设定的时间去主动重新连接主库同步数据,就不须要人工干预。

2

+

一般情況下,一群人是通过"show slave status \G;"提供的Seconds_Behind_Master值来衡量mysql主从同步的延迟情況。具体说明见:mysql主从同步(4)-Slave延迟情況监控,什儿 依据在大多数情況下随便说说是可行的。就让 经验不知道,仅仅依靠Seconds_Behind_Master的值来监测主从同步数据算是延迟是绝对不可靠的!!!

mysql> set global slave_net_timeout = 5;

+

因为着在从库的myc.nf里加上:

[root@slave-server ~]# cat /usr/local/mysql/my.cnf

....

[mysqld]

.....

slave_net_timeout = 5

[root@slave-server ~]# /etc/init.d/mysql restart

6

+

7

1)Mysql主从qq克隆好友 的动作是“推”还是“拉”

MySQL的qq克隆好友 是“推”的,而有的是“拉”的。

“拉”是指MySQL的备库不断的循环询问主库算是有数据更新,什儿 依据资源消耗多,就让 效率低。

“推”是指MySQL的主库在当时人有数据更新的就让 推送什儿 变更给备库,什儿 依据那末 在数据有变更的就让 才会处于交互,资源消耗少。

显而易见,“推”的依据更加符合多线程 池池运行的节能原则。

8

| Variable_name     | Value |

5

2)因为解析

从后面 的分析,一群人还须要大致猜到为哪此 show slave status 显示一切正常,就让 实际上主库的变更都无法同步到备库上来:

无缘无故出现间题的就让 ,Binlog dump多线程 池池被kill掉了。而备库作为监听的一方,它无缘无故那末 收到任何变更,它会认为主库上长时间那末 任何变更,因为那末 变更数据推送过来。

备库是无法判断主库上对应的Binlog dump多线程 池到底是意外终止了,还是长时间那末 任何数据变更的。却说有,对这五种情況来说,备库都显示为正常。

接下来基于mysql主从qq克隆好友 原理来分析什儿 间题

MySQL的Replication是区别什儿 数据库很关键的地方,也是可扩展性和高可用的基础。它五种因为着非常智能化,只须要一群人调用Change Master指定Binlog 文件名和偏移位置就还须要搭建从主库到备库的qq克隆好友 关系。

MySQLqq克隆好友 多线程 池会自动将目前qq克隆好友 位置记录下来,在主备qq克隆好友 中断的就让 自动连上主库,并从上次中断的位置重新刚开始了了qq克隆好友 。哪此操作有的是全自动化的,不须要人为的干预。这给了一群人运维人员带来了却说有便利,一齐也隐藏了却说有细节。要真正的理解前面间题的真相以及缘何外理什儿 间题,一群人还是须要真正的理解MySQLqq克隆好友 的原理。

发现什儿 间题就让 ,一群人人工干预的操作却说须要在从库上执行下面两步重新qq克隆好友 就能外理此间题:

mysql> stop slave; mysql> start slave;

2

设置依据:

直接登陆从库的mysql在线修改:

| slave_net_timeout | 5     |

7

mysql> show variables like 'slave_net_timeout';

mysql> show variables like 'slave_net_timeout';

1 row in set (0.01 sec)

10

3

+

4

却说有该间题的关键在于:

主库Binlog dump多线程 池kill的消息因为着网络堵塞因为着什儿 因为无法发送到备库,而备库却认为主库上的数据给有变更,因为着双方数据产生了差异。

而备库那末 在默认的3500s后主动地重新去连接主库,届时它才会发现主库的数据有变动了,才会自动同步过来,这是须要等待很长时间。