如何解决mysql主从复制带来的数据延迟问题

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

储方式的时候，Innodb的所有数据保存在一个单独的表空间里面，而这个表空间可以由很多个文件组成，一个表可以跨多个文件存在，所

以其大小限制不再是文件大小的限制，而是其自身的限制。从Innodb的官方文档中可以看到，其表空间的最大限制为64TB，也就是说，Innodb的单

表限制基本上也在64TB左右了，当然这个大小是包括这个表的所有索引等其他相关数据。

而当使用独享表空间来存放Innodb的表的时候，每个表的数据以一个单独的文件来存放，这个时候的单表限制，又变成文件系统的大小限制了。

mysql出现主从同步延迟有哪些原因

1.从库太多导致复制延迟

优化：建议从库数量3-5个为宜

2.从库硬件比主库硬件差

优化：提升硬件性能

3.慢SQL语句过多

优化：SQL语句执行时间太长，需要优化SQL语句

4.主从复制的设计问题

优化：主从复制单线程，可以通过多线程IO方案解决；另外MySQL5.6.3支持多线程IO复制。

5.主从库之间的网络延迟

优化：尽量链路短，提升端口带宽

6.主库读写压力大

优化：前端加buffer和缓存。主从延迟不同步：

不管有多延迟，只要不影响业务就没事

7、业务设计缺陷导致延迟影响业务

优化：从库没有数据改读主库

mysql主从配置成功，但是过段时间再操作master,发现slave没有同步更新

复制有延迟，slave想要尽可能及时跟上master的进度，可以尝试采用以下几种方法：

1、采用MariaDB发行版，它实现了相对真正意义上的并行复制，其效果远比ORACLE MySQL好的很多。在我的场景中，采用MariaDB作为slave的实例，几乎总是能及时跟上master。如果不想用这个版本的话，那就老实等待官方5.7大版本发布吧；

关于MariaDB的Parallel Replication具体请参考：Replication and Binary Log Server System Variables#slave_parallel_threads – MariaDB Knowledge Base

2、每个表都要显式指定主键，如果没有指定主键的话，会导致在row模式下，每次修改都要全表扫描，尤其是大表就非常可怕了，延迟会更严重，甚至导致整个slave库都被挂起，可参考案例：mysql主键的缺少导致备库hang；

3、应用程序端多做些事，让MySQL端少做事，尤其是和IO相关的活动，例如：前端通过内存CACHE或者本地写队列等，合并多次读写为一次，甚至消除一些写请求；

4、进行合适的分库、分表策略，减小单库单表复制压力，避免由于单库单表的的压力导致整个实例的复制延迟；

其他提高IOPS性能的几种方法，根据效果优劣，我做了个简单排序：

1、更换成SSD，或者PCIe SSD等IO设备，其IOPS能力的提升是普通15K SAS盘的数以百倍、万倍，甚至几十万倍计；

2、加大物理内存，相应提高InnoDB Buffer Pool大小，让更多热数据放在内存中，降低发生物理IO的频率；

3、调整文件系统为 XFS 或 ReiserFS，相比ext3可以极大程度提高IOPS能力。在高IOPS压力下，相比ext4有更稳健的IOPS表现(有人认为 XFS 在特别的场景下会有很大的问题，但我们除了剩余磁盘空间少于10%时引发丢数据外，其他的尚未遇到)；

4、调整RAID级别为raid 1+0，它相比raid1、raid5等更能提高IOPS性能。如果已经全部是SSD设备了，可以2块盘做成RAID 1，或者多快盘做成RAID 5(并且可以设置全局热备盘，提高阵列容错性)，甚至有些土豪用户直接将多块SSD盘组成RAID 50；

5、调整RAID的写cache策略为WB或FORCE WB，详情请参考：常用PC服务器阵列卡、硬盘健康监控 以及PC服务器阵列卡管理简易手册；

6、调整内核的io scheduler，优先使用deadline，如果是SSD，则可以使用noop策略，相比默认的cfq，个别情况下对IOPS的性能提升至少是数倍的。

其他更多方法，欢迎大家帮忙补充 ：)master中的position应该是高于read_master_log_pos的。我觉得这里需要注意

Seconds_Behind_Master: 0这个值就可以。1、同步一般都是实时的，可以及时同步，如果数据量大可能是插入速度上不去，mysql主从是通过写sql语句实现的，大数据的会延迟很严重

2、延迟的数据会同步过去

mysql主从同步延迟zabbix怎么监控

这个涉及到zabbix自定义监控项与MySQL主从同步两个技术，首先确保MySQL主从同步的前提下，在从库show slave status\G中找到“Seconds_Behind_Master”参数，改参数表示从库与主库同步的延迟间隔；

然后在被监控端的zabbix-agent配置文件中添加“UserParameter=db_status,mysql -uzabbix -pzabbixpass -e "show slave status\G" 2>/dev/null|egrep 'Seconds_Behind_Master'|awk '{print $2}'获取延迟；

重启zabbix客户端，并在zabbix-web上添加监控项，创建监控项图形；一.zabbix监控机导入模板 导入模板mysql_multiport_monitor.xml,导入后,模版默认名为percona mysql server multiport template。

二.被监控端

cat /usr/local/zabbix/etc/zabbix_agentd.conf | grep '^include'

include=/usr/local/zabbix/etc/zabbix_agentd.conf.d/利用在slave上运行show slave status获取Slave_IO_Running和Slave_SQL_Running的值

1.在mysql上新建监控用户

grant replication client on *.* to 'zabbix'@'localhost' identified by 'zabbix';

flush privileges;

2.在/data/zabbix/sbin下新建check_mysql_replication.sh脚本