主从延迟问题

一、主从延迟问题

1、原因与监控

首先需要了解为什么会存在延迟的问题

master 服务器和 slave 服务器连接时，创建 Binlog dump thread 以发送 bin log 数据：

1. 一个 Binlog dump thread 对应一个 slave 服务器；

2. Binlog dump thread 从 bin log 获取数据时会加锁，获取到数据后，立即释放锁。

当 slave 服务器收到 START_SLAVE 命令时，会创建 I/O thread 和 SQL thread：

1. I/O thread 以拉的方式，从 master 读取事件，并存储到 slave 服务器的 relay log 中；

2. SQL thread 从 relay log 中读取事件并执行；

3. slave 可以按照自己的节奏读取和更新数据，也可以随意操作复制进程(启动和停止)。

pt-heartbeat

在percona toolkit 产品中也提供了可以对于MySQL主从延时检查的工具pt-heartbeat, pt-heartbeat 的工作原理是通过使用时间戳方式在主库上更新特定表，然后 再从库上读取呗更新的时间戳然后与本地系统时间对比来得出其延迟。

具体流程：

1. 在住上创建一张hearteat表，按照一定的时间频率更新改表的子弹。监控操作运行后，heartbeat表能促使主从同步

2. 连接到从库上检查复制的时间记录，和从库的当前系统时间进行比较，得出时间的差异。 注意在使用的方式就是需要在主库中创建这个表；

use test; 

CREATE TABLE heartbeat (

   ts varchar(26) NOT NULL, 

   server_id int unsigned NOT NULL PRIMARY KEY,

   file varchar(255) DEFAULT NULL, -- SHOW MASTER STATUS 

   position bigint unsigned DEFAULT NULL, -- SHOW MASTER STATUS 

   relay_master_log_file varchar(255) DEFAULT NULL, -- SHOW SLAVE STATUS

   exec_master_log_pos bigint unsigned DEFAULT NULL -- SHOW SLAVE STATUS 
); 

通过pt-heartbeat可以对于mysql中的heartbeat表每隔多久更新一次（注意这个启动操作要在主库服务器上执行）

$ pt-heartbeat --user=root --ask-pass --create-table --database test --interval=1 --interval=1 --update --replace --daemonize 

$ ps -ef | grep pt-heartbeat 

在主库运行监测同步延迟

$ pt-heartbeat --database test --table=heartbeat --monitor --user=root --password=root --master-server-id=1 

0.02s [ 0.00s, 0.00s, 0.00s ] 

0.00s [ 0.00s, 0.00s, 0.00s ] 

这其中 0.02s 表示延迟了 ，没有延迟是为0 而 [ 0.00s, 0.00s, 0.00s ] 则表示1m,5m,15m的平均值， 而这期中需要注意的是

--master-server-id 为主服务器的服务id 就是在my.cnf中配置的 server_id的值

2、 处理延迟问题

对于从库的延时问题最为重要的就是主库与从库之间连接的网咯环境，从库的写入熟读 这两个点 - 其次就是对于主从的架构的优化；

注意：

一旦使用了主从必然是会有一定的延时问题，因此我们就需要考虑程序对于延迟的容忍度。 如果是0容忍的话建议还是不用主从了

MySQL从库产生配置

网络环境跳过，，，从库的写入主要是指insert，update，delete的语句的执行速度这些语句的执行速度我们就需要考虑MySQL的执行SQL语句的一个特点 -》 对 于每一个写的sql会默认开启事务并提交事务 ； 而事务是会影响到io的消耗的这和innodb_flush_log_at_trx_commit参数有关系。默认为1 我们可以尝试设置为0或 2可以提高效率， 另一个就是sync_binlog sync_binlog

配置说明：

sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对 于“sync_binlog”参数的各种设置的说明如下：

sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者 cache满了之后才同步到磁盘。

sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。 在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在 binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失 binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。

从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

innodb_flush_log_at_trx_commit 配置说明：

默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电 池供电缓存（Battery backed up cache）时。 设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超 过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。 硬件 升级电脑配置。。。

架构

1. 可以考虑对于一些库进行单独分离。

2. 服务的基础架构在业务和MySQL之间加入memcache或者redis的cache层。

3. 从库的配置要好。