浅析 MySQL Replication（本文转自网络，非本人所写）

slave：

log_slave_updates=1 
server-id = 328 
relay_log_recover = 1 
relay_log_info_repository = TABLE 
master_info_repository = TABLE
read_only = 1

如何提高复制效率？

MySQL 5.6提供了并行复制,但是这种并行只是基于database的。如果是基于单database的依然无法做到真正的并行回放，这个阶段很多DBA将数据库进行垂直拆分，将一个database拆分成几个database，通过设置slave_parallel_workers=n，可以进行database级别的并行复制，但对于热点业务复制延迟依然无法解决。

MySQL 5.6版本中还引入了GTID，不但降低了主从failover时，寻找filename，position的难度，更是加入到了组提交中，这也造就了MySQL 5.7版本中的Multi-Threaded Slave的出现。如下图，一组中的事务，可以并行回放。

在下图的测试中，MySQL 5.7的多线程复制极大的提升了延迟效率，在30个线程并发操作的时候还能保证平均延迟5.9秒左右，而单线程复制的延迟率基本一直在上升。

Multi-Threaded Slave 相关参数

slave-parallel-type= DATABASE /LOGICAL_CLOCK
-- DATABASE -- 基于库级别的并行复制 与5.6相同
-- LOGICAL_CLOCK -- 逻辑时钟，主上怎么并行执行，从上怎么回放。

slave-parallel-workers=16  
-- 并行复制的线程数

slave_preserve_commit_order=1 
--commit的顺序保持一致

半同步

我们都知道，默认的 MySQL Replication 复制为异步模式，异步也就说明会有丢失数据的可能性，MySQL在5.5版本中提供了 semi-sync replication，也就是半同步，但半同步只能说减少数据丢失的风险，所以在 MySQL 5.7版本中，MySQL 提供了 lossless semi-sync replication，也就是无损复制，可最低限度的减少数据丢失（无损复制会和半同步一样在出问题时会切换为异步复制）。

在半同步中，至少有一个Slave节点收到binlog后再返回，不能完全避免数据丢失，超时后，切回异步复制。在事物提交的过程中，在InnoDB层的 commit log 阶段后，Master 节点需要收到至少一个Slave节点回复的ACK后，才能继续下一个事物。

无损复制

在无损复制中，master把binlog发送给slave，只有在slave把binlog写到本地的relay-log里，master才会将事务提交到存储引擎层，然后把请求返回给客户端，客户端才可以看见刚才提交的事务。在一个事物提交的过程中，在MySQL Server 层的 binlog阶段后，Master节点需要收到至少一个Slave节点回复的ACK后，才能继续下一个事物。

半同步复制与无损复制的对比

ACK的时间点不同

• 半同步复制在InnoDB层的Commit Log后，等待ACK。

• 无损复制在MySQL Server层的Write binlog后，等待ACK。

主从数据一致性

• 半同步复制意味着在Master节点上，这个刚刚提交的事物对数据库的修改，对其他事物是可见的。

• 无损复制在write binlog完成后，就传输binlog，但还没有去写commit log，意味着当前这个事物对数据库的修改，其他事物也是不可见的。

半同步相关参数

rpl_semi_sync_master_enabled=1
rpl_semi_sync_slave_enabled=1
rpl_semi_sync_master_timeout=1000
rpl_semi_sync_master_wait_for_slave_count=1
rpl_semi_sync_master_wait_point=AFTER_SYNC
rpl_semi_sync_master_wait_for_slave_count=1

半同步相关事件统计

Rpl_semi_sync_master_tx_avg_wait_time
--开启Semi_sync，平均需要额外等待的时间
Rpl_semi_sync_master_net_avg_wait_time
--事务进入等待队列后，到网络平均等待时间Semi-sync的网络消耗有多大。
Rpl_semi_sync_master_status
-- 则表示当前Semi-sync是否正常工作
Rpl_semi_sync_master_no_times
--可以知道一段时间内，Semi-sync是否有超时失败过，记录了失败次数。

multi-source

然而在MySQL 5.7版本中，提供了多源复制，多源复制的出现对于分库分表的业务提供了极大的便利，目前我们已经部署了多套多源复制供统计使用。

如上图，多源复制采用多通道的模式，和普通的复制相比，就是使用FOR CHANNEL进行了分离。

CHANGE MASTER TO .... FOR CHANNEL ‘m1‘;
CHANGE MASTER TO .... FOR CHANNEL ‘m2‘;

上面我们也说到，为了提高复制效率，很多DBA会根据业务进行DB拆分，但拆分后又面临一个新的问题，就是join，join绝对是关系型数据库中最常用一个特性，然而在分布式的环境中，join是最难解决的一个问题，使用多源复制就能很好的解决这个问题。

如果数据库，表名一致如何使用多源复制？，其实只要解决了数据冲突的问题就可以使用。

如上图的分库分表架构，可以使用以下参数实现奇偶插入的方式去解决。

auto_increment_offset=1…n
auto_increment_increment=n

但这种方式需要提前考虑扩展性。

浅析 MySQL Replication（本文转自网络，非本人所写）

标签：mysq   内容   删除   多个   img   扩展性   涵盖   1.2   主从复制