本文整理自网络,侵删。
目录
- 1. 概述
- 2. 分布式恢复的连接
- 2.1分布式恢复端地址的查找
- 2.2分布式恢复压缩
- 2.3分布式恢复的用户
- 2.4分布式恢复和SSL认证
- 3. 利用克隆插件进行分布式恢复
- 3.1克隆的基本条件
- 3.2克隆的阈值
- 3.3克隆操作
- 3.4克隆的其他用处
1. 概述
每当一个MySQLserver新加入或者重新加入一个MGR集群时,它都必须追平集群内相差的事务,保证这个节点的数据和集群内最新的数据是同步的。这个新加入集群的节点在追平集群中的数据或者重新加入集群的节点追评它脱离集群后到现在这段时间内相差的事务数据的过程称为分布式恢复。
申请加入集群的节点首先检查groupreplicationapplier通道中的中继日志,检查该节点目前尚未从集群中同步过来的事务数据。如果是重新加入集群的节点,则该节点会找到在离开集群后到现在和集群最新数据中未回放的事务数据,在这种情况下,该节点首先会应用这些未同步的事务。对于新加入集群的节点,直接从一个引导节点上进行全量数据恢复即可。
此后,新加入的节点和集群中现有的online状态的节点(引导节点)建立连接进行状态转移。新加入的节点从集群中的引导节点中同步加入集群之前或者离开集群后到现在未同步过来的数据,这些相差的事务由集群中的引导节点提供。接下来,新加入的节点应用从集群中的引导节点同步过来的未进行应用的事务。此时申请加入集群的节点将应用在状态传输过程中集群内新事务写入的数据。(此时集群内新事物写入的数据暂时存放在缓存队列中,并未将数据写入磁盘中)完成此过程后,新加入的节点的数据和整个集群的数据相比,处于一个追平的状态,并且该节点设置为online状态。
注意:新加入集群的节点,不论是之前有没有在此集群中,都会先随机选一个online节点先同步该节点和集群相差的事务。
组复制在分布式恢复期间用下述方法实现状态传输:
使用克隆插件的功能进行远程克隆操作,该插件可从MySQL 8.0.17开始支持。要使用这种方法,必须在引导节点和新加入的节点上提前安装克隆插件。组复制会自动配置所需的克隆插件设置,并管理远程克隆操作。
从引导节点的二进制日志复制数据并在新加入的节点上应用这些事务。此方法需要在引导节点和加入节点之间建立的名为groupreplicationrecovery的标准异步复制通道。
在加入节点上执行STARTGROUP_REPLICATION后,组复制会自动选择上述方法的最佳组合进行状态转移。为此,组复制将会检查集群中哪些现有节点适合用作引导节点,加入节点需要引导节点传输多少事务,以及是否有事务不再存在于集群中任意节点的二进制日志文件中。如果加入节点与引导节点之间的事务差距很大,或者如果某些要求的事务不在引导节点的二进制日志文件中,则组复制将通过远程克隆操作开始分布式恢复。如果没有较大的事务间隙,或者未安装克隆插件,则组复制将直接从引导节点的二进制日志进行状态转移。
在远程克隆操作期间,将删除加入节点上的现有数据,并用引导节点数据的副本替换。当远程克隆操作完成并且新加入节点已重新启动时,将继续执行来自引导节点二进制日志来进行状态转移,以获取在进行远程克隆操作时集群所写入的增量数据。
在从引导节点的二进制日志进行状态转移期间,新加入节点从引导节点的二进制日志中复制并应用所需的事务,并在收到事务时应用事务,直到二进制日志记录新加入节点加入了集群。(当加入节点成功加入集群时,二进制日志中会记录对应的视图更改event)在此过程中,加入节点将缓冲该集群应用的新事务数据。从二进制日志的状态传输完成后,新加入节点将应用缓冲的事务。
当加入节点与该集群的所有事务保持最新时,该节点将在设置为online状态并可以作为普通节点加入集群,并且分布式恢复已完成。
ps:从二进制日志进行状态转移是组复制进行分布式恢复的基本机制,并且如果未将复制组中的引导节点和加入节点设置为支持克隆。由于从二进制日志进行状态转移是基于经典的异步复制,因此,如果加入该集群的MySQL server根本没有该集群的数据,或者从非常旧的备份中获取了数据,则可能要花费很长时间来恢复最新数据。因此,在这种情况下,建议在将MySQL server添加到集群之前,则应通过传输集群中已有节点的相当近期的快照来使用集群的数据对其进行设置。这可以最大程度地减少分布式恢复所需的时间,并减少对引导节点的影响,因为引导节点必须保留和传输较少的二进制日志文件。
2. 分布式恢复的连接
当加入节点连接到现有节点中的引导节点进行分布式恢复期间的状态转移时,加入节点充当客户端,而引导节点充当服务端。当通过此连接(使用异步复制通道groupreplicationrecovery)从引导节点的二进制日志进行状态转移时,加入节点充当副本,引导节点充当源端。通过此连接进行远程克隆操作时,新加入节点充当全量数据接收者,引导节点充当全量数据提供者。应用于组复制上下文之外的角色的配置设置也可以应用于组复制,除非它们被特定于组复制的配置设置或行为所覆盖。
现有节点提供给新加入节点以进行分布式恢复的连接与组复制用于集群内节点之间的通信的连接是不同的。
组通信引擎用于组复制(XCom,Paxos变体),用于远程XCom实例之间的TCP通信的连接由groupreplicationlocal_address系统变量指定。此连接用于集群内online节点之间的TCP / IP消息传递。与本地实例的通信是通过使用内存内共享的传输通道进行的。
对于分布式恢复,直到MySQL8.0.20为止,集群内的节点都将其标准SQL客户端连接提供给加入节点,这由MySQL Server的主机名和端口系统变量指定。如果report_port系统变量指定了备用端口号,则改用该端口号。
从MySQL 8.0.21开始,组成员可以将分布式恢复端点的替代列表作为加入成员的专用客户端连接,从而使得独立于成员的常规客户端用户的连接可以用来控制分布式恢复。可以使用groupreplicationadvertiserecoveryendpoints系统变量来指定此列表,并且成员在加入组时将其分布式恢复端点的列表传输到该组。默认值为成员继续提供与早期版本相同的标准SQL客户端连接。
PS:
如果加入节点无法使用MySQLServer的系统变量定义的主机名正确识别其他节点,则分布式恢复可能会失败。建议运行MySQL的操作系统使用DNS或本地设置具有正确配置的唯一主机名。可以在“performanceschema”库下的Replicationgroupmembers表的Memberhost列中验证server用于SQL客户端连接的主机名。如果多个组成员将操作系统设置的默认主机名外部化,则加入节点有可能无法将其解析为正确的地址,并且无法连接以进行分布式恢复。在这种情况下,可以使用MySQL Server的report_host系统变量来配置由每个server外部化的唯一主机名。
加入节点为分布式恢复建立连接的步骤如下:
当节点加入集群时,它会使用groupreplicationgroupseeds系统变量中列表中包含的一个种子节点进行连接,最初使用该列表中指定的groupreplicationlocaladdress连接。种子节点可能是集群数据的子集。
通过此连接,种子节点使用组复制的成员资格服务以视图的形式向加入的节点提供集群中所有online节点的列表。成员资格信息包括每个成员为分布式恢复提供的分布式恢复端点或标准SQL客户端连接的详细信息。
加入节点从此列表中选择合适的online节点作为其引导节点进行分布式恢复
加入节点尝试使用引导节点的分布式恢复端点来连接到引导节点,并按列表中指定的顺序依次尝试连接每个端点。如果引导节点没有提供端点,则加入节点将尝试使用引导节点的标准SQL客户端连接进行连接。连接的SSL要求由groupreplicationrecoveryssl *选项指定。
如果加入节点无法连接到指定的引导节点,则它将与其他合适的引导节点重试连接。如果加入节点在没有建立连接的情况下耗尽了端点的广播列表,则它不会回退到引导节点的标准SQL客户端连接,而是切换到另一个引导节点尝试重新建立连接。
加入节点与引导节点建立分布式恢复连接时,它将使用该连接进行状态转移,加入节点的日志中显示了所使用的连接的主机和端口。如果使用远程克隆操作,则在操作结束时重新启动加入节点时,它将与新的引导节点建立连接,从引导节点的二进制日志进行状态转移。这可能是与用于远程克隆操作的引导节点不同的连接,也可能是与引导节点建立相同的连接。无论如何,分布式恢复将以相同的方式与引导节点建立连接。
2.1分布式恢复端地址的查找
groupreplicationadvertiserecoveryendpoints系统变量作为分布式恢复端提供的IP地址,不必为MySQL Server配置(也就是说,不必由adminaddress系统变量或在bindaddress系统变量的列表中指定)。
为MySQL Server配置为分布式恢复端提供的端口,必须由port,reportport或adminport系统变量指定。必须在这些端口上侦听TCP / IP连接。如果指定adminport,则用于分布式恢复的复制用户需要SERVICECONNECTIONADMIN权限才能连接。选择adminport可使分布式恢复连接与常规MySQL客户端连接分开。
加入节点按列表中指定的顺序依次尝试每个端点。如果将groupreplicationadvertiserecoveryendpoints设置为DEFAULT而不是端点列表,则将提供标准SQL客户端连接。标准SQL客户端连接不会自动包含在分布式恢复端点列表中,并且如果引导节点的端点列表在没有连接的情况下被用尽,则不会将其作为备用。如果要提供标准SQL客户端连接作为多个分布式恢复端点之一,则必须将其显式包括在groupreplicationadvertiseadvertiserecovery_endpoints指定的列表中。可以将其放在最后,以便作为连接的最后手段。
无需将组成员的分布式恢复终点(或标准SQL客户端连接,如果未提供终点)添加到groupreplicationipallowlist(来自MySQL 8.0.22)或groupreplicationipwhitelist系统变量指定的组复制允许列表中。许可列表仅适用于由groupreplicationlocal_address为每个节点指定的地址。加入节点必须具有与允许列表允许的集群的初始连接,以便检索一个或多个地址进行分布式恢复。
设置系统变量和执行STARTGROUP_REPLICATION语句后,将验证列出的分布式恢复端点。如果无法正确解析列表,或者由于服务未在侦听列表而无法在主机上访问任何端点,则组复制将记录错误并且无法启动。
2.2分布式恢复压缩
在MySQL 8.0.18中,可以选择使用引导节点二进制日志中的状态转移方法为分布式恢复配置压缩。在网络带宽有限的情况下,压缩可以使分布式恢复受益,而引导节点必须将许多事务传输给加入节点。groupreplicationrecoverycompressionalgorithm和groupreplicationrecoveryzstdcompression_level系统变量配置允许的压缩算法以及zstd压缩级别,这些级别用于从引导节点的二进制日志执行状态转移时使用。
这些压缩设置不适用于远程克隆操作。当远程克隆操作用于分布式恢复时,将应用克隆插件的cloneenablecompression设置。
2.3分布式恢复的用户
分布式恢复需要具有正确权限的复制用户,以便组复制可以建立直接的节点到节点的复制通道。复制用户还必须具有正确的权限,如果该复制用户还同充当远程克隆操作中的克隆用户,则在引导节点中该复制用户还必须具有远程克隆相关的权限(BACKUP_ADMIN权限)才能充当引导节点上的克隆用户以进行远程克隆操作。除此之外,必须将同一复制用户用于集群内每个节点上的分布式恢复。
2.4分布式恢复和SSL认证
用于分布式恢复的SSL与用于普通组通信的SSL分开配置,这由server的SSL设置和groupreplicationssl_mode系统变量确定。对于分布式恢复连接,可以使用专用的组复制分布式恢复SSL系统变量来配置专门用于分布式恢复的证书和密钥的使用。
默认情况下,SSL不用于分布式恢复连接。设置groupreplicationrecoveryusessl= ON启用,然后配置组复制分布式恢复SSL系统变量,将复制用户设置为使用SSL。
将分布式恢复配置为使用SSL时,组复制会将此设置应用于远程克隆操作以及从引导节点的二进制日志进行状态转移。组复制会自动配置克隆SSL选项(clonesslca,clonesslcert和clonesslkey),以匹配相应组复制分布式恢复选项(groupreplicationrecoverysslca,groupreplicationrecoverysslcert和groupreplicationrecoverysslkey)的设置。
如果未使用SSL进行分布式恢复(groupreplicationrecoveryusessl设置为OFF),并且组复制的复制用户帐户使用cachingsha2password插件(MySQL 8.0中的默认设置)或sha256password插件进行身份验证,则RSA密钥对为用于密码交换。在这种情况下,使用groupreplicationrecoverypublickeypath系统变量指定RSA公共密钥文件,或者使用groupreplicationrecoverygetpublic_key系统变量请求公共密钥。否则整个分布式回复会因为报错导致恢复失败。
3. 利用克隆插件进行分布式恢复
MySQLServer的克隆插件可从MySQL8.0.17获得。如果要将远程克隆操作用于集群中的分布式恢复,则必须预先设置现有节点和加入节点才能支持此功能。如果不想在集群中使用此功能,请不要进行设置,在这种情况下,组复制仅使用二进制日志中的状态传输。
要使用克隆插件,必须预先设置至少一个现有的集群节点和加入节点支持远程克隆操作。至少,必须在引导节点和加入节点上安装克隆插件,将BACKUPADMIN权限授予复制用户以进行分布式恢复,并将groupreplicationclonethreshold系统变量设置为适当的级别。(默认情况下为GTID序列允许的最大值,表示正常情况下,始终优先使用基于二进制日志的状态传输,除非joiner节点所请求的事务在组中任意成员中都不存在,这个时候,如果设置好了克隆功能,则无论该系统变量的值设置为多少,都会触发通过克隆的方式进行分布式恢复,例如:全新初始化的Server申请加入组时。如果不希望使用克隆功能,则不要对其进行安装与配置)为了确保引导节点的最大可用性,建议设置所有当前和将来的集群节点支持远程克隆操作。以便后续有Server加入集群时能够使用远程克隆操作来快速追赶集群中的最新数据。
在从引导节点向加入节点传输数据之前,远程克隆操作会删除加入节点中用户创建的表空间和数据。如果在中途意外终止操作,则加入节点可能只剩下部分数据或没有数据。可以通过重新执行组复制自动执行的远程克隆操作来修复此问题。
这里主要针对远程克隆时使用DATADIRECTORY子选项指定了一个数据保存路径的情况,指定路径时,数据会保存在指定的目录下,即克隆之后的数据与操作克隆的实例没有关联,需要手动启动实例并指定datadir到保存克隆数据的目录进行启动,当然,MGR插件可以自动执行远程克隆的重试操作(需要保证克隆操作不指定DATA DIRECTORY子选项,在这种情况下,远程克隆数据会覆盖掉操作远程克隆的Server数据,完成远程克隆操之后,操作远程克隆的Server会基于克隆数据自动重新启动)。另外,克隆插件虽然与组复制配合使用对组复制的管理维护来说更加自动化,但是,克隆插件不要求必须在集群中运行(但MGR插件必须要安装)。
3.1克隆的基本条件
对于组复制,使用克隆插件进行分布式恢复需要注意以下要点和区别:
相关阅读 >>
更多相关阅读请进入《mysql》频道 >>
数据库系统概念 第6版
机械工业出版社
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
转载请注明出处:木庄网络博客 » MySQL分布式恢复进阶
相关推荐
评论
管理员已关闭评论功能...