mysql 高可用7

大家关心的主从延时问题

原因：一般都会做读写分离，其实从库压力反而比主库大／从库读写压力大 非常容易导致延时。
解决方案
首先定位延时瓶颈 
如果是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时代的落幕