10bet官方网站文档之家
MySQL 8.0参考手册
相关的文档10bet官方网站 本手册下载 本手册摘录

17.4.10 Semisynchronous复制

除了内置的异步复制,MySQL 8.0还支持通过插件实现的半同步复制接口。本节讨论什么是半异步复制以及它是如何工作的。以下部分将介绍半同步复制的管理界面以及如何安装、配置和监视它。

MySQL复制默认是异步的。源程序将事件写入二进制日志,副本在准备好时请求它们。源不知道副本是否或何时检索并处理了事务,并且不能保证任何事件都到达任何副本。使用异步复制,如果源崩溃,则它所提交的事务可能没有传输到任何副本。在这种情况下,从源到副本的故障转移可能导致到缺少相对于源的事务的服务器的故障转移。

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

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

与异步复制相比,半异步复制提供了更好的数据完整性,因为当提交成功返回时,可以知道数据至少存在于两个地方。在半同步源接收到所需副本数量的确认之前,事务将被暂停而不提交。

与完全同步复制相比,半同步复制更快,因为它可以配置为与提交的速度相比,通过提交的速度平衡数据完整性的要求(确认交易的收到的副本的数量),因为需要等待复制品。

重要的

使用半同步复制,如果执行源崩溃并执行故障转移,则失败的源不应重用为复制源,并且应该被丢弃。它可能具有任何复制品未承认的交易,因此在故障转移之前未犯下。

如果您的目标是实现容错复制拓扑,所有服务器都以相同的顺序接收相同的交易,并且崩溃的服务器可以重新加入该组并自动达到约会,您可以使用组复制来实现这一目标。有关信息,请参阅第18章,组复制

半同步复制与异步复制相比的性能影响是增加数据完整性的权衡。减速量至少是TCP / IP往返时间,以将提交发送到副本并等待副本的收据确认。这意味着半同步复制最佳适用于通过快速网络通信的关闭服务器,以及用于通过慢速网络通信的遥控服务器最差。半同步复制还通过约束可以从源发送二进制日志事件到副本的速度来置于忙会话的速率限制。当一个用户太忙时,这会减慢它,这可以在某些部署情况下很有用。

源和其副本之间的半同步复制如下:

  • 一个副本表明当它连接到源时是否具有半异步能力。

  • 如果启用了semisynchronous复制源端和至少有一个semisynchronous副本,一个线程执行一个事务提交源块和等待,直到至少有一个semisynchronous副本承认已收到所有事件的事务,或者直到超时。

  • 只有在将事件写入其中继日志并刷新到磁盘之后,副本才会确认事务事件的接收。

  • 如果在没有任何已确认事务的副本的情况下发生超时,则源将恢复异步复制。当至少一个半同词副本捕获时,源返回半同步复制。

  • 必须在源和副本侧面上启用半同步复制。如果在源上禁用了半同步复制,或在源上启用但在没有副本上启用,则源使用异步复制。

当源处于阻塞状态(等待来自副本的确认)时,它不会返回到执行事务的会话。当块结束时,源返回到会话,然后会话可以继续执行其他语句。此时,事务已经在源端提交,并且至少有一个副本已经确认其事件的接收。在返回到会话之前,源必须接收每个事务的复制确认的数量可以使用rpl_semi_sync_master_wait_for_slave_count系统变量,默认值为1。

在写入二进制日志之后也发生阻塞,这在修改未致讲台的事务时发生后发生。回滚事务是记录的,即使它没有对事务表表的影响,因为对非致讲台的修改不能回滚并且必须发送到副本。

用于不在事务上下文中出现的语句(即没有启动事务时)开始事务设置autocommit = 0),启用自动提交,每个语句都隐式提交。对于半同步复制,每个此类语句的源块,就像它对显式事务提交所做的那样。

rpl_semi_sync_master_wait_point.系统变量控制半同步源服务器在将状态返回给提交事务的客户端之前等待事务收据的副本确认的时间点。这些值是允许的:

  • AFTER_SYNC(默认):源将每个事务写入二进制日志和副本,并将二进制日志同步到磁盘。同步后,源等待事务收据的副本确认。在收到确认后,源将事务提交给存储引擎,并将结果返回给客户端,然后客户端可以继续处理。

  • After_commit.:源将每个事务写入二进制日志和副本,同步二进制日志,并将事务提交给存储引擎。提交后,源等待事务收据的副本确认。在收到确认后,源返回一个结果给客户端,然后客户端可以继续。

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

  • AFTER_SYNC,所有客户端同时都会看到已提交的事务,这是副本已确认并致电源上的存储引擎。因此,所有客户端都会在源上看到相同的数据。

    在源失败的情况下,在源上提交的所有事务都被复制到副本(保存到其中继日志中)。源的意外退出和故障转移到副本是无损的,因为副本是最新的。如上所述,故障转移后不应该重用源。

  • After_commit.,只有当服务器提交给存储引擎并收到副本确认后,发出事务的客户端才会获得返回状态。在提交之后和副本确认之前,其他客户端可以在提交客户端之前看到已提交的事务。

    如果出现错误,使副本不能处理事务,那么在意外源退出和故障转移到副本的情况下,这样的客户机可能会看到相对于它们在源上看到的数据的丢失。