• 首页
  • vue
  • TypeScript
  • JavaScript
  • scss
  • css3
  • html5
  • php
  • MySQL
  • redis
  • jQuery
  • 组复制在线升级

    如果有一个要升级的组正在运行,但是需要使该组保持联机状态以服务您的应用程序,则需要考虑升级方法。本节描述了在线升级中涉及的不同元素,以及如何升级组的各种方法。

    在线升级注意事项

    升级在线组时,应考虑以下几点:

    • 无论升级组的方式如何,重要的是禁止对组成员的任何写操作,直到他们准备重新加入组为止。
    • 当成员停止时,super_read_only变量将自动设置为on,但是此更改不会持久。
    • 当MySQL 5.7.22或MySQL 8.0.11尝试加入运行MySQL 5.7.21或更低版本的组时,由于MySQL 5.7.21不会发送其值,所以无法加入该组lower_case_table_names


    升级组复制成员

    本节说明了升级组成员所需的步骤。此过程是“组复制在线升级方法”中描述的方法的一部分。升级组成员的过程是所有方法共有的,并首先进行说明。加入升级成员的方式可能取决于您采用的方法以及其他因素,例如该组是以单主要模式还是多主要模式运行。使用就地或置备方法升级服务器实例的方式不会影响此处描述的方法。

    升级成员的过程包括按照所选的升级成员方法将其从组中删除,然后将升级后的成员重新加入到组中。推荐的升级单个主要组中成员的顺序是先升级所有辅助,然后再升级最后一个。如果在升级辅助数据库之前先升级了该数据库,则将选择使用旧版MySQL的新数据库,但是无需执行此步骤。

    升级组成员:

    • 将客户连接到组成员并发出STOP GROUP_REPLICATION。在继续之前,请OFFLINE通过监视replication_group_members表来确保成员的状态。
    • 禁止组复制自动启动,以便您可以在升级和配置后安全地连接到该成员,而无需通过设置重新加入该组group_replication_start_on_boot=0

      重要

      如果升级的成员拥有 group_replication_start_on_boot=1该成员,则可以在执行MySQL升级过程之前重新加入该组,并可能导致问题。例如,如果升级失败并且服务器再次重新启动,则可能损坏的服务器可以尝试加入该组。

    • 停止成员,例如使用mysqladmin shutdownSHUTDOWN语句。该组中的所有其他成员将继续运行。
    • 使用就地或置备方法升级成员。有关详细信息,请参见“升级MySQL”。重新启动升级的成员时,由于group_replication_start_on_boot设置为0,所以组复制不会在实例上启动,因此它不会重新加入组。
    • 在成员上执行MySQL升级过程后,group_replication_start_on_boot必须将其设置为1,以确保组复制在重新启动后正确启动。重新启动成员。
    • 连接到升级后的成员并发出START GROUP_REPLICATION。这会将成员重新加入该组。组复制元数据在已升级的服务器上就位,因此通常不需要重新配置组复制。服务器必须在服务器脱机时赶上该组处理的所有事务。一旦赶上该小组,它就会成为该小组的在线成员。

      注意

      升级服务器花费的时间越长,成员脱机的时间就越长,因此,当服务器重新添加到组中时,服务器追赶的时间就越多。

    当升级的成员加入具有任何成员运行早期MySQL Server版本的组的组时,升级的成员将加入super_read_only=on。这样可以确保在所有成员都运行较新版本之前,不对升级后的成员进行写操作。在多主要模式组中,当升级成功完成并且该组准备好处理事务时,必须将打算用作可写主要的成员设置为读写模式。从MySQL 8.0.17开始,当一个组的所有成员都升级到相同的发行版时,它们都会自动变回读写模式。对于早期版本,您必须手动将每个成员设置为读写模式。连接到每个成员并发出:

    SET GLOBAL super_read_only=OFF;
    

    组复制在线升级方法

    选择以下一种升级组复制组的方法:

    组内滚动升级

    如果运行新版本的服务器没有为组生成工作负载,而仍然有旧版本的服务器在其中,则支持此方法。换句话说,具有较新版本的服务器只能作为辅助服务器加入该组。在此方法中,只有一个组,并且每个服务器实例都从该组中删除,升级并重新加入该组。

    此方法非常适合单主要人群。当组在单主模式下运行时,如果您要求主数据库在整个过程中保持相同(除非它本身正在升级),则它应该是要升级的最后一个成员。除非它运行组中最低的MySQL Server版本,否则不能将其保留为主要数据库。主数据库升级后,您可以使用group_replication_set_as_primary() UDF再次将其指定为主。如果您不介意哪个成员是主要成员,则可以按任何顺序升级成员。该组会在必要时从运行最低MySQL Server版本的成员中选择一个新的主服务器,并遵循“单主模式”中所述的选举策略。

    对于以多主要模式运行的组,在滚动式小组内升级期间,主要数量会减少,从而导致写入可用性降低。这是因为,如果成员加入的组在运行的MySQL Server版本高于现有组成员运行的最低版本时,它将自动保持为只读模式(super_read_only=ON)。请注意,运行MySQL 8.0.17或更高版本的成员在进行检查时会考虑该发行版的修补程序版本,但是运行MySQL 8.0.16或更低版本或MySQL 5.7的成员仅会考虑主版本。当所有成员都已从MySQL 8.0.17升级到同一版本时,它们都会自动变回读写模式。对于早期版本,必须super_read_only=OFF在升级后手动设置为主要成员的每个成员上进行手动设置。

    有关组中版本兼容性及其在升级过程中如何影响组行为的完整信息,请参见“在组中组合不同的成员版本”。

    滚动迁移升级

    通过这种方法,您可以从组中删除成员,对其进行升级,然后使用升级后的成员创建另一个组。对于以多主要模式运行的组,在此过程中,主要数量会减少,从而导致写入可用性降低。这不会影响以单主要模式运行的组。

    因为在升级成员时运行旧版本的组处于联机状态,所以您需要运行新版本的组来赶上在升级成员时执行的所有事务。因此,新组中的服务器之一被配置为旧组中主服务器的复制从属服务器。这样可以确保新组赶上旧组。由于此方法依赖于异步复制通道,该通道用于将数据从一个组复制到另一个组,因此在主从复制的相同假设和要求下也支持该方法,请参见复制。。对于以单主数据库模式运行的组,与旧组的异步复制连接必须将数据发送到新组中的主数据库,对于多主数据库组,异步复制通道可以连接到任何主数据库。

    该过程是:

    • 从运行较旧服务器版本的原始组中逐个删除成员,请
    • 升级在成员上运行的服务器版本,请参见“升级MySQL”。您可以采用就地升级或预配置升级的方法。
    • 创建具有升级成员的新组,请参见组复制。在这种情况下,您需要在每个成员上配置一个新的组名(因为旧的组仍在运行并使用旧的名称),引导一个初始的升级成员,然后添加其余的升级成员。
    • 在旧组和新组之间设置异步复制通道,请参见“使用GTID设置复制”。将较旧的主服务器配置为充当异步复制主服务器,将新的组成员配置为基于GTID的复制从属服务器。

    在将应用程序重定向到新组之前,必须确保新组具有适当数量的成员,例如,以便该组可以处理成员的失败。发出SELECT * FROM performance_schema.replication_group_members并比较初始组大小和新组大小。等待直到来自旧组的所有数据传播到新组,然后删除异步复制连接并升级所有丢失的成员。

    滚动复制升级

    在这种方法中,您将创建第二个组,该组由正在运行较新版本的成员组成,较旧组中缺少的数据将复制到较新组中。假设您有足够的服务器来同时运行两个组。由于在此过程中主数据库的数量没有减少,因此对于以多主数据库模式运行的组,写入可用性不会降低。这使得滚动复制升级非常适合在多主要模式下运行的组。这不会影响以单主要模式运行的组。

    由于在配置新组中的成员时,运行较旧版本的组处于联机状态,因此需要运行较新版本的组来赶上在配置成员时执行的所有事务。因此,新组中的服务器之一被配置为旧组中主服务器的复制从属服务器。这样可以确保新组赶上旧组。由于此方法依赖于异步复制通道,该通道用于将数据从一个组复制到另一个组,因此在主从复制的相同假设和要求下也支持该方法,请参见复制。。对于以单主数据库模式运行的组,与旧组的异步复制连接必须将数据发送到新组中的主数据库,对于多主数据库组,异步复制通道可以连接到任何主数据库。

    该过程是:

    • 部署适当数量的成员,以便运行较新版本的组可以处理成员失败
    • 从该组成员中备份现有数据
    • 使用旧成员的备份来设置新组的成员。

      注意

      您必须将备份还原到与备份相同的MySQL版本,然后执行就地升级。有关说明,请参见“升级MySQL”。

    • 创建具有升级成员的新组,请参见组复制。在这种情况下,您需要在每个成员上配置一个新的组名(因为旧的组仍在运行并使用旧的名称),引导一个初始的升级成员,然后添加其余的升级成员。
    • 在旧组和新组之间设置异步复制通道,请参见“使用GTID设置复制”。将较旧的主服务器配置为充当异步复制主服务器,将新的组成员配置为基于GTID的复制从属服务器。

    一旦新组中缺少的正在进行的数据足够小而可以快速传输,则必须将写操作重定向到新组。等待直到旧组中的所有数据都传播到新组,然后断开异步复制连接。

    组复制升级与mysqlbackup

    作为置备方法的一部分,您可以使用MySQL Enterprise Backup将数据从组成员复制并还原到新成员。但是,您不能使用此技术直接将备份从运行旧版MySQL的成员还原到运行新版MySQL的成员。解决方案是将备份还原到新服务器实例,该实例运行与从中获取备份的成员相同版本的MySQL,然后升级实例。该过程包括:

    • 使用mysqlbackup从旧组的成员中进行备份。请参见“将MySQL Enterprise Backup与组复制一起使用”。
    • 部署一个新的服务器实例,该实例必须与执行备份的旧成员运行相同版本的MySQL。
    • 使用mysqlbackup将备份从较旧的成员还原到新实例。
    • 在新实例上升级MySQL,请参见“升级MySQL”。

    重复此过程,以创建适当数量的新实例,例如能够处理故障转移。然后加入实例基于A组第18.7.3.3,“组复制在线升级方法”