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;