• 首页
  • vue
  • TypeScript
  • JavaScript
  • scss
  • css3
  • html5
  • php
  • MySQL
  • redis
  • jQuery
  • 组复制要求

    您要用于组复制的服务器实例必须满足以下要求。

    基础设施

    • InnoDB存储引擎。数据必须存储在InnoDB事务存储引擎中。乐观地执行事务,然后在提交时检查冲突。如果存在冲突,为了保持整个组的一致性,将回滚某些事务。这意味着需要事务存储引擎。此外,InnoDB还提供了一些附加功能,可以在与组复制一起操作时更好地管理和处理冲突。使用其他存储引擎,包括临时MEMORY存储引擎,可能会导致组复制中的错误。您可以通过disabled_storage_engines在组成员上设置系统变量来阻止使用其他存储引擎,例如:

      disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
      
    • 主键。组要复制的每个表都必须具有定义的主键,或等效的主键,其中等效项是非null的唯一键。此类键是作为表中每一行的唯一标识符所必需的,从而使系统能够通过准确标识每笔交易已修改的行来确定哪些交易发生冲突。
    • 网络性能。 MySQL Group Replication旨在部署在服务器实例彼此非常靠近的集群环境中。网络延迟和网络带宽都会影响组的性能和稳定性。所有组成员之间必须始终保持双向通信。如果针对服务器实例阻止了入站或出站通信(例如,通过防火墙或由于连接问题),则该成员无法在该组中运行,并且该组成员(包括有问题的成员)可能无法报告受影响的服务器实例的正确成员状态。

      从MySQL 8.0.14开始,您可以使用IPv4或IPv6网络基础结构或两者的结合来进行远程组复制服务器之间的TCP通信。也没有什么可以阻止组复制通过虚拟专用网络(VPN)进行操作。

      同样,从MySQL 8.0.14(组复制服务器实例位于同一位置并共享本地组通信引擎(XCom)实例)开始,在可能的情况下,使用开销较小的专用输入通道代替TCP套接字进行通信。对于某些需要在远程XCom实例之间进行通信的组复制任务(例如加入组),仍然使用TCP网络,因此网络性能会影响组的性能。

    服务器实例配置

    必须按照作为组成员的服务器实例上所示配置以下选项。

    • 二进制日志处于活动状态。设置--log-bin[=log_file_name]。MySQL Group Replication复制二进制日志内容,因此二进制日志需要打开才能运行。默认情况下启用此选项。请参见“MySQL服务器二进制日志”。
    • 从动更新已记录。设置--log-slave-updates。默认情况下启用此选项。组成员需要记录加入时从其捐助者处收到并通过复制应用程序应用的事务,并记录他们从组中接收并应用的所有事务。这样,组复制就可以通过从现有组成员的二进制日志进行状态转移来执行分布式恢复。
    • 二进制日志行格式。设置--binlog-format=row。组复制依靠基于行的复制格式在组中的服务器之间一致地传播更改。它依靠基于行的基础结构来提取必要的信息,以检测在组中不同服务器中同时执行的事务之间的冲突。从MySQL 8.0.19起,该REQUIRE_ROW_FORMAT设置会自动添加到组复制的通道中,以在应用事务时强制使用基于行的复制。请参见“复制格式”和“复制特权检查”。
    • 二进制日志校验和关闭。设置--binlog-checksum=NONE。由于复制事件校验和的设计限制,组复制无法使用它们,必须将其禁用。
    • 全局事务标识符打开。设置gtid_mode=ON。组复制使用全局事务标识符来准确跟踪在每个服务器实例上已提交的事务,从而能够推断出哪些服务器已执行了可能与其他位置已提交的事务冲突的事务。换句话说,显式交易标识符是框架的基本部分,能够确定哪些交易可能发生冲突。请参见“使用全局事务标识符进行复制”。
    • 复制信息存储库。设置master_info_repository=TABLErelay_log_info_repository=TABLE。复制应用程序需要将主信息和中继日志元数据写入mysql.slave_master_infomysql.slave_relay_log_info表。这样可以确保组复制插件对复制元数据具有一致的可恢复性和事务管理。在MySQL 8.0.2中,TABLE默认情况下将这些选项设置为默认值,在MySQL 8.0.3中则不建议FILE使用该设置。请参见“从站状态日志”。
    • 事务写集提取。进行设置,--transaction-write-set-extraction=XXHASH64以便在收集行以将它们记录到二进制日志时,服务器也收集写集。写集基于每行的主键,并且是标签的简化且紧凑的视图,该标签唯一地标识已更改的行。然后,该标签用于检测冲突。默认情况下启用此选项。
    • 二进制日志依赖项跟踪。设置binlog_transaction_dependency_tracking=WRITESET_SESSION可以提高组成员的性能,具体取决于组的工作量。在应用中继日志中的事务时,组复制在认证后执行其自身的并行化,而与的设置值无关binlog_transaction_dependency_tracking。但是,binlog_transaction_dependency_tracking确实会影响将事务写入组复制成员上的二进制日志的方式。这些日志中的依赖项信息用于协助从捐助者的二进制日志进行状态转移的过程,以进行分布式恢复,只要成员加入或重新加入该组,就会发生这种情况。
    • 默认表加密。--default-table-encryption在所有组成员上设置相同的值。只要所有成员的设置都相同,就可以启用(ON)或禁用(OFF默认值)默认模式和表空间加密。
    • 小写表格名称。--lower-case-table-names在所有组成员上设置相同的值。设置1对于使用InnoDB存储引擎是正确的,这对于组复制是必需的。请注意,该设置并非在所有平台上都是默认设置。
    • 多线程应用程序。可以将组复制成员配置为多线程从属,从而使事务可以并行应用。一个非零值,用于slave_parallel_workers在成员上启用多线程应用程序,并且最多可以指定1024个并行应用程序线程。设置slave_preserve_commit_order=1可确保并行事务的最终提交与原始事务的顺序相同,这是组复制所需的,组复制依赖于围绕所有参与成员以相同顺序接收和应用已提交事务的保证而建立的一致性机制。最后,设置slave_parallel_type=LOGICAL_CLOCK需要使用,用于指定用于确定允许在从属服务器上并行执行哪些事务的策略slave_preserve_commit_order=1。设置slave_parallel_workers=0将禁用并行执行,并为从属提供一个单一的应用程序线程,而没有协调程序线程。使用该设置时,slave_parallel_typeslave_preserve_commit_order选项无效,将被忽略。