在第一部分中，我们介绍了MySQL托管的高可用性（HA）框架，并讨论了各种组件及其功能。现在在第二部分中，我们将讨论MySQL半同步复制的细节以及相关的配置设置，这些设置有助于我们确保HA设置中数据的冗余和一致性。请务必重新检入第III部分，我们将审查可能出现的各种故障情况以及框架响应和恢复这些条件的方式。
什么是MySQL半同步复制？
简单地说，在MySQL MySQL semisynchronous replication配置中，主设备仅在收到来自至少一个从设备的确认后才将事务提交到存储引擎。只有在收到事件并将其复制到中继日志并刷新到磁盘后，从站才会提供确认。这保证了对于提交并返回到客户端的所有事务，数据至少存在于2个节点上。半同步（复制）中的术语“半”是由于主设备在接收到事件并将其刷新到中继日志后提交事务，但不一定提交给从设备上的数据文件。这与完全同步复制形成对比，完全同步复制在会话返回客户端之前，事务将在从服务器和主服务器上提交。
半导体复制（在MySQL中本机可用）可帮助HA框架确保已提交事务的数据一致性和冗余。如果主服务器出现故障，主服务器上提交的所有事务都将被复制到至少一个从服务器（保存到中继日志）。因此，故障转移到该从站将是无损的，因为从站是最新的（在从站的中继日志完全耗尽之后）。
复制和半同步相关设置
让我们讨论一些关键的MySQL设置，这些设置用于确保我们框架中的高可用性和数据一致性的最佳行为。
管理Slave的执行速度
第一个考虑因素是处理半同步复制的“半”行为，它只保证数据已被接收器的I / O线程接收并刷新到中继日志，但不一定由SQL线程提交。默认情况下，MySQL从属服务器中的SQL线程是单线程的，无法与多线程的主服务器保持同步。这样做的明显影响是，在主服务器发生故障时，从服务器将不会是最新的，因为它的SQL线程仍在处理中继日志中的事件。这将延迟故障转移过程，因为我们的框架期望从服务器在可以升级之前完全是最新的。这对于保持数据一致性是必要的。为解决此问题，我们使用slave_parallel_workers选项启用多线程从站，以设置处理中继日志中事件的并行SQL线程数。
此外，我们配置以下设置，以确保从站不会进入主站不在的任何状态：
- slave-parallel-type = LOGICAL_CLOCK
- slave_preserve_commit_order = 1
这为我们提供了更强的数据一致性。通过这些设置，我们将能够在从属设备上获得更好的并行化和速度，但是如果并行线程太多，则线程之间协调所涉及的开销也会增加，并且不幸地会抵消这些优势。
我们可以用来提高从站上并行执行效率的另一个配置是调整主站上的 binlog_group_commit_sync_delay 。通过在master上设置它，主服务器上的二进制日志条目以及从服务器上的中继日志条目将具有可由SQL线程并行处理的批量事务。这在 J-F Gagné’s blog 中有详细解释，他将这种行为称为“减慢主人加速奴隶的速度”。
如果您通过ScaleGrid控制台管理MySQL部署，则可以持续监视和接收有关从属服务器复制延迟的实时警报。它还允许您动态调整上述参数，以确保从站与主站一起工作，从而最大限度地减少故障转移过程中的时间。
重要的半同步复制选项
根据设计，MySQL半同步复制可以基于从确认超时设置或基于任何时间点可用的具有半同步能力的从设备的数量而回退到异步模式。根据定义，异步模式不能保证已提交的事务被复制到从属服务器，因此主服务器丢失会导致丢失尚未复制的数据。 ScaleGrid HA框架的默认设计是避免回退到异步模式。让我们来看看影响这种行为的配置。
rpl_semi_sync_master_wait_for_slave_count
此选项用于配置在半同步主服务器提交事务之前必须发送确认的从站数。在3节点主从配置中，我们将其设置为1，因此我们始终确保数据在至少一个从站中可用，同时避免在等待来自两个从站的确认时所涉及的任何性能影响。
此选项用于配置半同步主控器在切换回异步模式之前等待来自从器件的确认的时间。我们将其设置为相对较高的超时值，因此不会回退到异步模式。
由于我们使用2个从站运行并且rpl_semi_sync_master_wait_for_slave_count设置为1，因此我们注意到至少有一个从站确实在合理的时间内确认，并且主站在临时网络中断期间不会切换到异步模式。
rpl_semi_sync_master_wait_no_slave
这将控制主服务器是否等待rpl_semi_sync_master_timeout配置的超时时间到期，即使从服务器计数降至小于超时期间rpl_semi_sync_master_wait_for_slave_count配置的从服务器数。我们保留默认值ON，以便主服务器不会回退到异步复制。
失去所有半同步从属的影响
如上所述，如果所有从站都关闭或无法从主站访问，我们的框架会阻止主站切换到异步复制。这样做的直接影响是写入在主服务器上停滞不前影响服务的可用性。这基本上如CAP定理所述，关于任何分布式系统的局限性。该定理指出，在存在网络分区的情况下，我们必须选择可用性或一致性，但不能同时选择两者。在这种情况下，网络分区可以被视为与主服务器断开连接的MySQL从服务器，因为它们已关闭或无法访问。
我们的一致性目标是确保对于所有已提交的事务，数据至少在2个节点上可用。因此，在这种情况下，ScaleGrid HA框架有利于可用性的一致性。虽然MySQL主服务器仍将提供读取请求，但不会从客户端接受进一步的写入。这是我们作为默认行为的有意识的设计决策，当然，它可以根据应用程序要求进行配置。
请务必订阅ScaleGrid博客，这样您就不会错过第三部分，我们将讨论更多故障情景和MySQL HA框架的恢复能力。敬请关注！！
原文：https://scalegrid.io/blog/mysql-high-availability-framework-explained-part-2/
讨论：请加入知识星球或者小红圈【首席架构师圈】