你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

配置故障转移组 - CLI

本文介绍如何使用 CLI 为 Azure Arc 启用的 SQL 托管实例配置灾难恢复。 在继续之前,请查看 Azure Arc 启用的 SQL 托管实例 - 灾难恢复中的信息和先决条件。

先决条件

在 Azure Arc 启用的 SQL 托管实例的两个实例之间设置故障转移组之前,必须满足以下先决条件:

  • Azure Arc 数据控制器和在主站点中预配的已启用 Arc 的 SQL 托管实例,其中 --license-typeBasePriceLicenseIncluded 之一。
  • Azure Arc 数据控制器和在辅助站点中预配的已启用 Arc 的 SQL 托管实例,其在以下方面与主站点的配置相同:
    • CPU
    • 内存
    • 存储
    • 服务层级
    • 排序规则
    • 其他实例设置
  • 辅助站点上的实例需要 --license-typeDisasterRecovery。 此实例需要是新的,无需任何用户对象。

注意

  • 请务必在创建托管实例的过程中指定 --license-type 这样,可从主数据中心的主实例对 DR 实例进行种子设定。 部署后更新此属性不会产生此效果。

部署过程

要在两个实例之间设置 Azure 故障转移组,请完成以下步骤:

  1. 为主站点上的分布式可用性组创建自定义资源
  2. 为辅助站点上的分布式可用性组创建自定义资源
  3. 从镜像证书复制二进制数据
  4. sync 模式或 async 模式下,在主站点和辅助站点之间设置分布式可用性组

下图为正确配置的分布式可用性组:

关系图显示了正确配置的分布式可用性组。

同步模式

Azure Arc 数据服务中的故障转移组支持两种同步模式- syncasync。 同步模式直接影响数据在实例之间同步的方式,还可能影响主要托管实例的性能。

如果主站点和辅助站点彼此相距离数英里,请使用 sync 模式。 否则,请使用 async 模式来避免对主站点的性能造成任何影响。

配置 Azure 故障转移组 - 直接模式

如果 Azure Arc 数据服务部署在 directly 连接模式下,请执行以下步骤。

满足先决条件后,运行以下命令,在两个实例之间设置 Azure 故障转移组:

az sql instance-failover-group-arc create --name <name of failover group> --mi <primary SQL MI> --partner-mi <Partner MI> --resource-group <name of RG> --partner-resource-group <name of partner MI RG>

示例:

az sql instance-failover-group-arc create --name sql-fog --mi sql1 --partner-mi sql2 --resource-group rg-name --partner-resource-group rg-name

上面的命令:

  • 在主站点和辅助站点上创建所需的自定义资源
  • 复制镜像证书,并在实例之间配置故障转移组

配置 Azure 故障转移组 - 间接模式

如果 Azure Arc 数据服务部署在 indirectly 连接模式下,请执行以下步骤。

  1. 在主站点中预配托管实例。

    az sql mi-arc create --name <primaryinstance> --tier bc --replicas 3 --k8s-namespace <namespace> --use-k8s
    
  2. 通过在将要成为灾难恢复实例的辅助站点中运行 kubectl config use-context <secondarycluster> 和预配托管实例,将上下文切换到辅助群集。 此时,系统数据库不属于包含的可用性组的一部分。

    注意

    请务必在托管实例的过程中指定 --license-type DisasterRecovery 这样,可从主数据中心的主实例对 DR 实例进行种子设定。 部署后更新此属性不会产生此效果。

    az sql mi-arc create --name <secondaryinstance> --tier bc --replicas 3 --license-type DisasterRecovery --k8s-namespace <namespace> --use-k8s
    
  3. 镜像证书 - 创建实例故障转移组 CR(自定义资源)需要托管实例的“镜像证书”属性内的二进制数据。

    可通过数种方式实现此目的:

    (a) 如果使用 az CLI,请先生成镜像证书文件,然后在配置实例故障转移组时指向该文件,以便从文件读取二进制数据并将其复制到 CR 中。 创建故障转移组后,不需要证书文件。

    (b) 如果使用 kubectl,请直接从托管实例 CR 复制二进制数据并将其粘贴到将用于创建实例故障转移组的 yaml 文件中。

    使用上面的 (a):

    为主实例创建镜像证书文件:

    az sql mi-arc get-mirroring-cert --name <primaryinstance> --cert-file </path/name>.pem​ --k8s-namespace <namespace> --use-k8s
    

    示例:

    az sql mi-arc get-mirroring-cert --name sqlprimary --cert-file $HOME/sqlcerts/sqlprimary.pem​ --k8s-namespace my-namespace --use-k8s
    

    连接到辅助群集并创建辅助实例的镜像证书文件:

    az sql mi-arc get-mirroring-cert --name <secondaryinstance> --cert-file </path/name>.pem --k8s-namespace <namespace> --use-k8s
    

    示例:

    az sql mi-arc get-mirroring-cert --name sqlsecondary --cert-file $HOME/sqlcerts/sqlsecondary.pem --k8s-namespace my-namespace --use-k8s
    

    创建镜像证书文件后,将证书从辅助实例复制到主实例群集上的共享/本地路径,反之亦然。

  4. 在两个站点上创建故障转移组资源。

    注意

    确保主站点和辅助站点的 SQL 实例具有不同的名称,并且两个站点上的 shared-name 值应相同。

    az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for primary failover group resource> --mi <local SQL managed instance name> --role primary --partner-mi <partner SQL managed instance name>  --partner-mirroring-url tcp://<secondary IP> --partner-mirroring-cert-file <secondary.pem> --k8s-namespace <namespace> --use-k8s
    

    示例:

    az sql instance-failover-group-arc create --shared-name myfog --name primarycr --mi sqlinstance1 --role primary --partner-mi sqlinstance2  --partner-mirroring-url tcp://10.20.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance2.pem --k8s-namespace my-namespace --use-k8s
    

    在辅助实例上,运行以下命令来设置故障转移组自定义资源。 在这种情况下,--partner-mirroring-cert-file 应指向一个路径,该路径包含从主实例生成的镜像证书文件,如上面的 3(a) 所述。

    az sql instance-failover-group-arc create --shared-name <name of failover group> --name <name for secondary failover group resource> --mi <local SQL managed instance name> --role secondary --partner-mi <partner SQL managed instance name>  --partner-mirroring-url tcp://<primary IP> --partner-mirroring-cert-file <primary.pem> --k8s-namespace <namespace> --use-k8s
    

    示例:

    az sql instance-failover-group-arc create --shared-name myfog --name secondarycr --mi sqlinstance2 --role secondary --partner-mi sqlinstance1  --partner-mirroring-url tcp://10.10.5.20:970 --partner-mirroring-cert-file $HOME/sqlcerts/sqlinstance1.pem --k8s-namespace my-namespace --use-k8s
    

检索 Azure 故障转移组运行状况状态

可以在主站点或辅助站点上的自定义资源上查看故障转移组的相关信息,例如主要角色、辅助角色和当前运行状况。

在主站点和/或辅助站点上运行以下命令,列出故障转移组自定义资源:

kubectl get fog -n <namespace>

描述用于检索故障转移组状态的自定义资源,如下所示:

kubectl describe fog <failover group cr name> -n <namespace>

故障转移组操作

在托管实例之间设置故障转移组后,可以根据情况执行不同的故障转移操作。

可能的故障转移方案包括:

  • 两个站点上的实例处于正常运行状态,需要执行故障转移:

    • 通过在主要 SQL MI 上设置 role=secondary,执行从主站点到辅助站点的手动故障转移,而不会丢失数据。
  • 主站点运行不正常/无法访问,需要执行故障转移:

    • Azure Arc 启用的主要 SQL 托管实例已关闭/运行不正常/无法访问
    • 需要将 Azure Arc 启用的辅助 SQL 托管实例强制提升为主实例,但可能丢失数据
    • 当 Azure Arc 启用的原始主要 SQL 托管实例重新联机时,它将报告为 Primary 角色和运行不正常状态,并且需要强制进入 secondary 角色,这样它才能联接故障转移组,并且可以同步数据。

手动故障转移(无数据丢失)

使用 az sql instance-failover-group-arc update ... 命令组启动从主实例到辅助实例的故障转移。 在故障转移之前,会将异地主实例上的任何挂起的事务复制到异地辅助实例。

直接连接模式

运行以下命令,使用 ARM API 在 direct 连接模式下启动手动故障转移:

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <primary instance> --role secondary --resource-group <resource group>

示例:

az sql instance-failover-group-arc update --name myfog --mi sqlmi1 --role secondary --resource-group myresourcegroup

间接连接模式

运行以下命令,使用 kubernetes API 在 indirect 连接模式下启动手动故障转移:

az sql instance-failover-group-arc update --name <name of failover group resource> --role secondary --k8s-namespace <namespace> --use-k8s 

示例:

az sql instance-failover-group-arc update --name myfog --role secondary --k8s-namespace my-namespace --use-k8s 

强制故障转移(会丢失数据)

异地主实例不可用时,可以在异地辅助灾难恢复实例上运行以下命令,通过强制故障转移将其提升为主实例,这可能导致数据丢失。

在异地辅助灾难恢复实例上运行以下命令,将其提升为主要角色,但这会造成数据丢失。

注意

如果将 --partner-sync-mode 配置为 sync,则当辅助实例提升为主实例时,需要将其重置为 async

直接连接模式

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <instance> --role force-primary-allow-data-loss --resource-group <resource group> --partner-sync-mode async

示例:

az sql instance-failover-group-arc update --name myfog --mi sqlmi2 --role force-primary-allow-data-loss --resource-group myresourcegroup --partner-sync-mode async

间接连接模式

az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-primary-allow-data-loss --partner-sync-mode async

当异地主实例变为可用时,请运行以下命令,来将其引入故障转移组并同步数据:

直接连接模式

az sql instance-failover-group-arc update --name <shared name of failover group> --mi <old primary instance> --role force-secondary --resource-group <resource group>

间接连接模式

az sql instance-failover-group-arc update --k8s-namespace my-namespace --name secondarycr --use-k8s --role force-secondary

(可选)如果需要,可以将 --partner-sync-mode 配置回为 sync 模式。

故障转移后的操作

执行从主站点到辅助站点的故障转移后,无论是否丢失数据,都可能需要执行以下操作:

  • 更新应用程序的连接字符串,以连接到新提升的主要 Arc SQL 托管实例
  • 如果计划继续在辅助站点上运行生产工作负载,请将 --license-type 更新为 BasePriceLicenseIncluded,以启动所使用的 vCore 的计费。