企业级Mysql数据库集群--Mysql半同步复制

半同步复制

一般情况下，异步复制就已经足够应付了，但由于是异步复制，备库极有可能是落后于主库，特别是极端情况下，我们无法保证主备数据是严格一致的（即使我们观察到Seconds Behind Master这个值为0）

比如，当用户发起commit命令时，Master并不关心slave的执行状态，执行成功后，立即返回给用户。试想下，若一个事务提交后，master成功返回给用户后crash，这个事务的binlog还没来得及传递到slave，那么slave相对于master而言就少了一个事务，此时主备就不一致了。对于要求强一致的业务是不可以接受的，半同步复制就是为了解决数据一致性而产生的

为什么叫半同步复制？我们来先说说同步复制，所谓同步复制就是一个事务在master和slave都执行后，才返回给用户执行成功。这里核心是说master和slave要么都执行，要么都不执行，涉及到2pc（2 phrase commit)。而MySQL只实现了本地redo-log和binlog的2PC，但并没有实现master和slave的2PC，所以不是严格意义上的同步复制。而MySQL半同步复制不要求slave执行，而仅仅是接收到日志后，就通知master可以返回了

这里关键点是slave 接受日志后是否执行，若执行后才通知master则是同步复制，若仅仅是接受日志成功，则是半同步复制

半同步复制：一主多从模式下，有一个从节点返回成功，即成功，不必等待多个节点全部返回

master做完一步等一步，需要等待至少一个slave节点完成复制之后才开始进行下一个操作

master做大事件的时候，需要进行半同步，master节点等待一个节点即可

当半同步出现问题的时候会自动切换为异步同步

银行数据库全同步，master节点等待集群中的所有全部节点

数据库要避免慢查询问题，会造成延迟，占用数据库的IO

优点：提高了数据完整性，数据至少会存在两个节点（master节点和一个slave节点）

加了消息确认ACK，不会造成数据丢失

出现问题会自动降低为异步复制

master

ip:172.25.30.1/24

server1

mysql -uroot -p*

install plugin rpl_semi_sync_master SONAME 'semisync_master.so';

安装半同步模块master

set global rpl_semi_sync_master_enabled = 1

激活插件

slave

ip:172.25.30.2/24

server2

mysql -uroot -p*

install plugin rpl_semi_sync_slave SONAME 'semisync_slave.so';

安装半同步模块slave

set global rpl_semi_sync_slave_enabled = 1
激活插件
STOP SLAVE IO_THREAD;

关闭

START SLAVE IO_THREAD;

开启

从库重启io进程，激活插件之后必须要重启io进程，否则不会生效，如果重启不了的话就说明两端的数据不同步

STOP SLAVE IO_THREAD;

关闭从库进行测试

master

use westos;

insert into usertb values ('user4','123');

等待10s，没有接收到slave的ack请求，自动转换为异步复制

insert into usertb values ('user5','123');

再次插入数据，速度变快，异步复制生效

slave

use westos;

select * from usertab;

没有user4和user5数据

START SLAVE IO_THREAD;

开启slave

select * from usertab;

数据全部同步完成