大家关心的主从延时问题
原因:一般都会做读写分离,其实从库压力反而比主库大/从库读写压力大 非常容易导致延时。解决方案
首先定位延时瓶颈
如果是IO压力,可以通过升级硬件,比如替换SSD等
如果IO和CPU都不是瓶颈,非常有可能是SQL单线程问题,解决方案可以考虑刚才提到的并行复制方案
如果还有问题,可以考虑sharding拆分方案
提到延时不得不提到很坑人的Seconds_behind_master,使用过MySQL的应该很熟悉
这个值的源码里算法
long time_diff= ((long)(time(0) – mi->rli.last_master_timestamp) – mi->clock_diff_with_master);
Seconds_behind_master来判断延时不可靠,在网络抖动或者一些特殊参数配置情况下,会造成这个值是0但其实延时很大了。
通过heartbeat表插入时间戳这种机制判断延时是更靠谱的
复制注意点
Binlog格式,建议都采用row格式,数据一致性更好
Replication filter应用
主从数据一致性问题
row格式下的数据恢复问题
InnoDB优化
成熟开源事务存储引擎,支持ACID,支持事务四个隔离级别
更好的数据安全性,高性能高并发,MVCC,细粒度锁
支持O_DIRECT
主要优化参数
innodb_file_per_table =1
innodb_buffer_pool_size,根据数据量和内存合理设置
innodb_flush_log_at_trx_commit= 0 1 2
innodb_log_file_size,可以设置大一些
innodb_page_size
Innodb_flush_method = o_direct
innodb_undo_directory 放到高速设备(5.6+)
innodb_buffer_pool_dump_at_shutdown ,bufferpool dump (5.6+)
上图是5.5 4G的redo log和5.6 设置大于4G redo log文件性能对比,可以看到稳定性更好了。innodb_log_file_size设置还是很有意义的
InnoDB比较好的特性
Bufferpool预热和动态调整大小,动态调整大小需要5.7支持
Page size自定义调整,适应目前硬件
InnoDB 压缩,大大降低数据容量,一般可以压缩50%,节省存储空间和IO,用CPU换空间
Transportable tablespaces,迁移ibd文件,用于快速单表恢复
Memcached API,full text,GIS等
InnoDB在SSD上的优化
在5.5以上,提高innodb_write_io_threads和innodb_read_io_threads
innodb_io_capacity需要调大
日志文件和redo放到机械硬盘,undo放到SSD,建议这样,但必要性不大
atomic write,不需要Double Write Buffer
InnoDB压缩
单机多实例
也要搞清楚InnoDB哪些文件是顺序读写,哪些是随机读写
随机读写
datadir
innodb_data_file_path
innodb_undo_directory
顺序读写
innodb_log_group_home_dir
log-bin
InnoDB VS MyISAM
数据安全性至关重要,InnoDB完胜,曾经遇到过一次90G的MyISAM表repair,花了两天时间,如果在线上几乎不可忍受
并发度高
MySQL 5.5默认引擎改为InnoDB,标志着MyISAM时代的落幕