关于提示replication性能

关于GTIDs的二进制日志：
gtid_next： 下一个事务的编号，是master传给slave的

如SET @@SESSION.GTID_NEXT= 'c09756b8-a7e7-11e5-9468-000c29df5442:4' 则下一个事务为4

1.正常情况,下一次收到的gtid是4，slave将同步，然后设置gtid为4。

2.收到重复的，网络问题：延迟，包重发等。mysql会忽略掉重复的，避免出错

3.收到大于gtid_next的GTID。有可能网络丢包等原因，mysql slave将等待新的事务传输，要么报错

因此：这个基于GTIDs的复制，数据的一致性好，易于管理。自动化

show variables like '%gtid%';

| gtid_mode | ON |
| gtid_next | AUTOMATIC |

还有一个优点：易于调整架构

只要改变master_host。就可以调整架构，如MS、MSS。而不需要知道二进制日志文件名和文件的位置。全都是基于gtid的

root@localhost: (none) 10:54 > change master to
-> master_host='192.168.88.123',
-> master_user='rep',
-> master_password='redhat',
-> master_auto_position=1;

如何提示复制的性能：

基本是就是延迟的问题，在没有发生故障的情况下，MS之间的数据不一致也是常用的

延迟分类：关键是克服经常性延迟的问题

*经常性延迟：高峰期，周期性

暂时性延迟：导入数据，计算大表。slave无法在短时间满足

原因：网络带宽、IO

如何减少延迟：

• 最好使用内网或者专线传输binlog。尽可能不要在互联网上传输。生产环境最好在千兆网以上，可以使用bond技术进行拓展，mysql也可以在bind在特定的网卡上（bind-address=ip,set global bind_address）。如果MS部署在不同的地方，距离较远，那最好是拉穿线，至少也得保证有单独网络传输专线，如VPN 。总之，避免在慢速上传输二进制日志。
• 将二进制日志保存在独立的存储介质上，改善IO（log-bin=/path/to/mysqlbinlog）
• 使用多核CPU，使用多线程方式传输二进制日志。在5.6之前二进制传输是单线程的，这就相当于把并行的变成串行的，因为master在执行任务时是并发操作的，而传输日志是单线程的。
• 如果二进制日志不是row格式的，则尽可能在insert或者update等DML操作的时候使用select。建议单独创建表或者视图
• 尽可能减少Master的写IO,因为Master所做的事很多，既要处理自身的操作，又要写自己的binlog，还要读自己的binlog传给slave。可以建立缓存系统如memcache，减缓数据库压力。只要周期性的将数据同步给数据库。

更新架构：

• 主从服务器可以使用不同的存储引擎。M使用Innodb，利用它能够支持事务、行锁和高并发性能好等特征。而slave上可以使用Myisam，因为Myisam读性更好，节省内存，易备份。可以在MS完成主从架构之后使用alter table engine改变存储引擎，还可以在MS使用不同的数据类型，因为使用了不同的存储引擎了嘛，所以对不同的数据类型，不同的存储引擎的处理也不一样。可以在master上使用varchar，在slave上使用char，利用Myisam表的静态表特征
• 使用M-S-Muti_Slave，中继slave可以考虑使用blackhole存储引擎。blackhole只记录日志，不写数据，就像/dev/null。利用这个特点可以让中继日志性能提示很多，但是，blackhole不支持GTIDs模式的复制，blockhole只支持传统的statement模式下的复制，row和mixed也不支持。但是平时建议使用row格式，使数据完整性能够保持很高的一致性
• 读写分离，使用M写，S来读。在这种情况下，Master可以只保留主键和唯一索引等保证数据关系的索引，因为在写数据的时候，同时也会写索引，索引很多情况下，将会是性能下降。但是在slave上只有读的操作，此时可以针对查询做索引优化
• 让更新频繁，且需要实时的数据查询放到Master上的场景下。可以通过持久化session，让发生修改的用户先看到结果，其他人等待同步后在查看slave。但是开发上就比较复杂。一般的情况，通过借助缓存如memcache来做到这一点，用户写的数据先存储在memcache上，然后每个一段时间，在同步到master上，而其他用户访问的使用可以先访问缓存memcache，访问没有的话才到slave或者master上读取。由于memcache是把数据存储在内存中因此，访问速度和性能上都会有改善。

replication容量
在master上不写新数据的情况下，将slave暂停一段时间（M），再重新开启，此时到slave的数据追到和Master的一致的这段时间（N），则replication容量可以表示为N：M，一般1:3甚至比这个值更小，replication性能才能说不错。比如M停60min，slave最好在20min之内就可以完成数据的一致性。

多线程方式传输二进制日志

（MySQL5.6之后，在之前可以使用mysql transfer 淘宝对mysql的多线程的patch http://csrd.aliapp.com/?p=1590）
一般在操作量（QPS）比较大的情况下,多线程的优势尤为明显
只能适用于GTIDs模式下
只有对不同的库执行的操作才使用多线程传输，同一库的不同的操作只能用单线程。所以在业务上，可以采用分库的方法，来提升replication的性能，默认多线程是不开启的。可以设定slave-parallel-workers=N(默认为0，表示不开启)，N可以根据cpu核心数和数据库的数量两方面来指定。