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；