共计 1732 个字符，预计需要花费 5 分钟才能阅读完成。
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；
