binlog复制模式
异步复制(Asynchronous replication)
MySQL默认的复制即是异步的,主库在执行完客户端提交的事务后会立即将结果返回给客户端,并不关心从库是否已经接收并处理。
这样就会有一个问题,如果主库crash掉了,此时主库上已经提交的事务可能并没有传到从库上,如果此时强行将从库提升为主库,可能导致新主库上的数据不完整。
全同步复制(Fully synchronous replication)
当主库执行完一个事务,所有的从库都执行了该事务才返回给客户端。
因为需要等待所有从库执行完该事务才能返回,所以全同步复制的性能必然会受到严重的影响。
半同步复制(Semisynchronous replication)
介于异步复制和全同步复制之间,主库在执行完客户端提交的事务后不是立刻返回给客户端,而是等待至少一个从库接收并且写到relay log中才返回给客户端。
相对于异步复制,半同步复制提高了数据的安全性,同时它也造成了一定程度的延迟,这个延迟最少是一个TCP/IP往返的时间。所以,半同步复制最好在低延时的网络中使用。
半同步复制
半同步复制有AFTER_COMMIT和AFTER_SYNC两种方式。
AFTER_COMMIT
同步过程:
- 用户向master提交事务;
- master节点处理事务,写binlog,commit该事务;
- master节点等待slave将binlog写入relay-log;
- master节点返回client事务执行结果;
AFTER_COMMIT的问题
若事务在master节点commit后,在等待slave节点的确认过程中,master节点宕机了,此时有两种情况:
1.事务还未发送到从库
此时client收到事务失败的结果,client会重新提交事务到新master上。
当宕机的老master重新启动后,以slave的角色加入后,该事务将从新master上同步过来,导致被再次提交一次。
2.事务已发送到从库
此时slave已经收到binlog并应用了该事务,当client由于事务失败而再次提交时,该事务被重新提交到新master上。
AFTER_SYNC
同步过程:
- 用户向master提交事务;
- master节点执行事务,写binlog;
- master节点等待slave将binlog写入relay-log;
- master节点commit该事务;
- master节点向client返回事务执行结果;
半同步复制参数
MariaDB [(none)]> show variables like '%semi%';
+---------------------------------------+--------------+
| Variable_name | Value |
+---------------------------------------+--------------+
| rpl_semi_sync_master_enabled | OFF |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_COMMIT |
| rpl_semi_sync_slave_delay_master | OFF |
| rpl_semi_sync_slave_enabled | OFF |
| rpl_semi_sync_slave_kill_conn_timeout | 5 |
| rpl_semi_sync_slave_trace_level | 32 |
+---------------------------------------+--------------+
rpl_semi_sync_master_enabled:master是否启用半同步
rpl_semi_sync_slave_enabled:slave是否启用半同步
rpl_semi_sync_master_timeout:master等待slave写入relay-log的超时时间,默认10s;
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。