MySQL半同步复制

1，三种复制方式比较

• 异步复制：源将事件写入其二进制日志，副本在准备好时请求它们。源不知道副本是否或何时已检索和处理事务，并且无法保证任何事件都会到达任何副本。使用异步复制，如果源崩溃，它已提交的事务可能不会传输到任何副本。在这种情况下，从源故障转移到副本可能会导致故障转移到缺少与源相关的事务的服务器。

• 完全同步复制：当源提交事务时，所有副本也必须在源返回到执行事务的会话之前提交事务。完全同步复制意味着可以随时从源故障转移到任何副本。完全同步复制的缺点是完成事务可能会有很多延迟。

• 半同步复制：半同步复制介于异步复制和完全同步复制之间。源等待直到至少一个副本接收并记录了事件（所需的副本数量是可配置的），然后提交事务。源不等待所有副本确认接收，它只需要来自副本的确认，而不是事件已在副本端完全执行并提交。因此，半同步复制保证如果源崩溃，它已提交的所有事务都已传输到至少一个副本。

1. 与异步复制相比，半同步复制提供了改进的数据完整性，因为当一次提交成功返回时，就知道数据至少存在于两个地方。在半同步源收到来自所需数量的副本的确认之前，事务处于暂停状态且未提交。
2. 与完全同步复制相比，半同步复制更快，因为它可以配置为平衡您对数据完整性的要求（确认收到事务的副本数）和提交速度，提交速度由于需要等待而较慢复制品。
3. 对于半同步复制，如果源崩溃并且执行到副本的故障转移，则故障源不应该被重用作为复制源服务器，而应该被丢弃。它可能有任何副本未确认的事务，因此在故障转移之前未提交。
4. 与异步复制相比，半同步复制的性能影响是提高数据完整性的权衡。减速量至少是发送提交到副本并等待副本确认接收的 TCP/IP 往返时间。这意味着半同步复制最适合通过快速网络通信的近距离服务器，而对于通过慢速网络通信的远程服务器最差。半同步复制还通过限制二进制日志事件从源发送到副本的速度来限制繁忙会话的速率。当一个用户太忙时，这会减慢它的速度，这在某些部署情况下很有用。

2，半同步复制安装配置

1. 半同步复制是使用插件实现的，因此必须将插件安装到服务器中以使其可用。首先需要验证MySQL 服务器是否支持动态加载的。have_dynamic_loading变量为YES表示支持。
   

2. 安装插件
   master上：

   INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
   

   在每个副本上：

   INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
   

   要查看安装了哪些插件，请使用 SHOW PLUGINS语句或查询INFORMATION_SCHEMA.PLUGINS 表。

3. 启动半同步复制插件，必须在master和slave都启用插件才能启用半同步复制。
   在master上开启插件：

   SET GLOBAL rpl_semi_sync_master_enabled = 1;
   

   在slave上开启插件

   SET GLOBAL rpl_semi_sync_slave_enabled = 1;
   

4. 如果在运行时在副本上启用半同步复制，则还必须启动复制 I/O 线程（如果它已经在运行，则首先停止它）以使副本连接到源并注册为半同步副本：

   STOP SLAVE IO_THREAD;
   START SLAVE IO_THREAD;
   

3，半同步复制相关变量

仅当安装了源端半同步复制插件时，以下变量才可用。

---

控制是否在源上启用半同步复制。要启用或禁用插件，请将此变量分别设置为ON或OFF （或 1 或 0）。默认值为 OFF.

---

一个以毫秒为单位的值，用于控制源在超时和恢复到异步复制之前等待来自副本的确认提交的时间。默认值为 10000（10 秒）。

---

1 = 一般级别（例如，时间函数故障）
16 = 详细级别（更详细的信息）
32 = 网络等待级别（有关网络等待的更多信息）
64 = 功能级别（有关功能进入和退出的信息）

---

在继续之前，源必须在每个事务中接收的副本确认数。默认情况下 rpl_semi_sync_master_wait_for_slave_count 是1，这意味着半同步复制在收到单个副本确认后继续进行。性能最适合此变量的小值。

---

此变量控制半同步源在向提交事务的客户端返回状态之前等待事务接收的副本确认的点。这些值是允许的：

AFTER_SYNC（默认）：源将每个事务写入其二进制日志和副本，并将二进制日志同步到磁盘。源在同步后等待交易接收的副本确认。收到确认后，源将事务提交给存储引擎并将结果返回给客户端，然后客户端可以继续。

AFTER_COMMIT：源将每个事务写入其二进制日志和副本，同步二进制日志，并将事务提交给存储引擎。提交后，源等待事务接收的副本确认。收到确认后，源将结果返回给客户端，然后客户端可以继续。

这些设置的复制特性不同如下：

使用AFTER_SYNC，所有客户端同时看到提交的事务：在它被副本确认并提交到源上的存储引擎之后。因此，所有客户端都在源上看到相同的数据。

如果源发生故障，源上提交的所有事务都已复制到副本（保存到其中继日志）。源意外退出和故障转移到副本是无损的，因为副本是最新的。但是请注意，在这种情况下，源无法重新启动并且必须被丢弃，因为它的二进制日志可能包含未提交的事务，在二进制日志恢复后外部化时会导致与副本冲突。

使用AFTER_COMMIT，发出事务的客户端只有在服务器提交到存储引擎并收到副本确认后才能获得返回状态。在提交之后和副本确认之前，其他客户端可以在提交客户端之前看到提交的事务。

如果出现问题导致副本无法处理事务，那么在意外的源退出和故障转移到副本的情况下，这些客户端可能会看到与他们在源上看到的数据相关的数据丢失。

4，参考

1. MySQL5.7手册