使用自动故障转移组可以实现多个数据库的透明、协调式故障转移Use auto-failover groups to enable transparent and coordinated failover of multiple databases

自动故障转移组是一项 SQL 数据库功能,可便于管理 SQL 数据库服务器中一组数据库或托管实例中所有数据库到另一区域的复制和故障转移。Auto-failover groups is a SQL Database feature that allows you to manage replication and failover of a group of databases on a SQL Database server or all databases in a managed instance to another region. 它是建立在现有活动异地复制功能基础之上的声明性抽象,旨在简化异地复制的数据库的大规模部署和管理。It is a declarative abstraction on top of the existing active geo-replication feature, designed to simplify deployment and management of geo-replicated databases at scale. 可以手动启动故障转移,也可以基于用户定义的策略委托 SQL 数据库服务进行故障转移。You can initiate failover manually or you can delegate it to the SQL Database service based on a user-defined policy. 使用后一种做法可在发生下述情况后自动恢复次要区域中的多个相关数据库:灾难性故障或其他导致主要区域中 SQL 数据库服务完全或部分丧失可用性的计划外事件。The latter option allows you to automatically recover multiple related databases in a secondary region after a catastrophic failure or other unplanned event that results in full or partial loss of the SQL Database service�s availability in the primary region. 一个故障转移组可以包含一个或多个数据库,通常由同一个应用程序使用。A failover group can include one or multiple databases, typically used by the same application. 此外,你还可以使用可读辅助数据库卸载只读查询工作负荷。Additionally, you can use the readable secondary databases to offload read-only query workloads. 由于自动故障转移组涉及多个数据库,因此这些数据库必须在主服务器上进行配置。Because auto-failover groups involve multiple databases, these databases must be configured on the primary server. 自动故障转移组支持将组中所有的数据库复制到另一个区域中唯一的辅助服务器。Auto-failover groups support replication of all databases in the group to only one secondary server in a different region.

Note

如果在 SQL 数据库服务器上使用单一数据库或共用数据库,并要在相同或不同的区域中使用多个辅助数据库,请使用活动异地复制When working with single or pooled databases on a SQL Database server and you want multiple secondaries in the same or different regions, use active geo-replication.

将自动故障转移组与自动故障转移策略配合使用时,任何影响组中一个或多个数据库的服务中断都会导致自动故障转移。When you are using auto-failover groups with automatic failover policy, any outage that impacts one or several of the databases in the group results in automatic failover. 通常,通过内置的自动高可用性操作无法自行缓解这些事件。Typically these are incidents that cannot be self-mitigated by the built-in automatic high availability operations. 故障转移触发器的示例包括:SQL 租户环或控制环由于多个计算节点上的 OS 内核内存泄漏而导致的事件,或者由于在日常硬件解除期间断开错误的网线而关闭一个或多个租户环,因此导致的事件。The examples of failover triggers include an incident caused by a SQL tenant ring or control ring being down due to an OS kernel memory leak on several compute nodes, or an incident caused by one or more tenant rings being down because a wrong network cable was cut during routine hardware decommissioning. 有关详细信息,请参阅 SQL 数据库高可用性For more information, see SQL Database High Availability.

此外,自动故障转移组提供在故障转移期间保持不变的读写和只读侦听器终结点。In addition, auto-failover groups provide read-write and read-only listener end-points that remain unchanged during failovers. 无论使用手动故障转移激活还是自动故障转移激活,故障转移都会将组中所有的辅助数据库切换到主数据库。Whether you use manual or automatic failover activation, failover switches all secondary databases in the group to primary. 数据库故障转移完成后,会自动更新 DNS 记录,以便将终结点重定向到新的区域。After the database failover is completed, the DNS record is automatically updated to redirect the endpoints to the new region. 有关具体的 RPO 和 RTO 数据,请参阅业务连续性概述For the specific RPO and RTO data, see Overview of Business Continuity.

将自动故障转移组与自动故障转移策略配合使用时,任何影响 SQL 数据库服务器或托管实例中数据库的服务中断都会导致自动故障转移。When you are using auto-failover groups with automatic failover policy, any outage that impacts databases in the SQL Database server or managed instance results in automatic failover. 可使用以下方式管理自动故障转移组:You can manage auto-failover group using:

故障转移后,请确保在新的主机上配置服务器和数据库的身份验证要求。After failover, ensure the authentication requirements for your server and database are configured on the new primary. 有关详细信息,请参阅 SQL Database security after disaster recovery(灾难恢复后的 Azure SQL 数据库安全性)。For details, see SQL Database security after disaster recovery.

若要真正实现业务连续性,只需添加数据中心之间的数据库冗余即可,这只是该解决方案的一部分功能。To achieve real business continuity, adding database redundancy between datacenters is only part of the solution. 在发生灾难性故障后,端对端地恢复应用程序(服务)需要恢复构成该服务的所有组件以及所有依赖服务。Recovering an application (service) end-to-end after a catastrophic failure requires recovery of all components that constitute the service and any dependent services. 这些组件的示例包括客户端软件(例如,使用自定义 JavaScript 的浏览器)、Web 前端、存储和 DNS。Examples of these components include the client software (for example, a browser with a custom JavaScript), web front ends, storage, and DNS. 所有组件必须能够弹性应对相同的故障,并在应用程序的恢复时间目标 (RTO) 值内变为可用,这一点非常关键。It is critical that all components are resilient to the same failures and become available within the recovery time objective (RTO) of your application. 因此,需要识别所有依赖服务,并了解它们提供的保证和功能。Therefore, you need to identify all dependent services and understand the guarantees and capabilities they provide. 然后,必须执行适当的步骤来确保对用户的服务所依赖的服务执行故障转移期间,用户的服务能够正常运行。Then, you must take adequate steps to ensure that your service functions during the failover of the services on which it depends. 有关设计灾难恢复解决方案的详细信息,请参阅设计使用活动异地复制的灾难恢复云解决方案For more information about designing solutions for disaster recovery, see Designing Cloud Solutions for Disaster Recovery Using active geo-replication.

自动故障转移组的术语和功能Auto-failover group terminology and capabilities

  • 故障转移组 (FOG)Failover group (FOG)

    故障转移组是由一个 SQL 数据库服务器管理或位于一个托管实例中的一组指定数据库,当主要区域的服务中断导致所有或部分主要数据库不可用时,这组数据库可作为单元故障转移到另一区域。A failover group is a named group of databases managed by a single SQL Database server or within a single managed instance that can fail over as a unit to another region in case all or some primary databases become unavailable due to an outage in the primary region. 为托管实例创建故障转移组后,该组将包含该实例中的所有用户数据库,因此,只能在一个实例上配置一个故障转移组。When created for managed instances, a failover group contains all user databases in the instance and therefore only one failover group can be configured on an instance.

    Important

    故障转移组的名称在 .database.chinacloudapi.cn 域中必须全局唯一。The name of the failover group must be globally unique within the .database.chinacloudapi.cn domain.

  • SQL 数据库服务器SQL Database servers

    使用 SQL 数据库服务器,可以将一个 SQL 数据库服务器上的部分或所有用户数据库放入故障转移组。With SQL Database servers, some or all of the user databases on a single SQL Database server can be placed in a failover group. 此外,SQL 数据库服务器支持一个 SQL 数据库服务器上有多个故障转移组。Also, a SQL Database server supports multiple failover groups on a single SQL Database server.

  • 主要节点Primary

    托管故障转移组中的主要数据库的 SQL 数据库服务器或托管实例。The SQL Database server or managed instance that hosts the primary databases in the failover group.

  • 辅助节点Secondary

    托管故障转移组中的辅助数据库的 SQL 数据库服务器或托管实例。The SQL Database server or managed instance that hosts the secondary databases in the failover group. 辅助节点不能与主要节点位于相同的区域。The secondary cannot be in the same region as the primary.

  • 将单一数据库添加到故障转移组Adding single databases to failover group

    可以将同一 SQL 数据库服务器上的多个单一数据库放入同一故障转移组。You can put several single databases on the same SQL Database server into the same failover group. 如果将单一数据库添加到故障转移组,则它会在辅助服务器上自动使用相同的版本和计算大小创建辅助数据库。If you add a single database to the failover group, it automatically creates a secondary database using the same edition and compute size on secondary server. 创建故障转移组时指定该服务器。You specified that server when the failover group was created. 如果在辅助服务器中添加已具有辅助数据库的数据库,则该异地复制链接由组继承。If you add a database that already has a secondary database in the secondary server, that geo-replication link is inherited by the group. 在不属于故障转移组的服务器中添加已有辅助数据库的数据库时,会在辅助服务器中创建新的辅助节点。When you add a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary server.

    Important

    在托管实例中,将复制所有用户数据库。In a managed instance, all user databases are replicated. 无法选择复制故障转移组中的一部分用户数据库。You cannot pick a subset of user databases for replication in the failover group.

  • 将弹性池中的数据库添加到故障转移组Adding databases in elastic pool to failover group

    可将一个弹性池内的所有或多个数据库放入同一故障转移组。You can put all or several databases within an elastic pool into the same failover group. 如果主数据库在弹性池中,将在具有相同名称的弹性池(辅助池)中自动创建辅助数据库。If the primary database is in an elastic pool, the secondary is automatically created in the elastic pool with the same name (secondary pool). 必须确保辅助服务器包含名称完全相同的弹性池,并有足够的可用容量来托管将由故障转移组创建的辅助数据库。You must ensure that the secondary server contains an elastic pool with the same exact name and enough free capacity to host the secondary databases that will be created by the failover group. 如果在辅助池中已有辅助数据库的池中添加数据库,则该异地复制链接由组继承。If you add a database in the pool that already has a secondary database in the secondary pool, that geo-replication link is inherited by the group. 在不属于故障转移组的服务器中添加已有辅助数据库的数据库时,会在辅助池中创建新的辅助数据库。When you add a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary pool.

  • DNS 区域DNS zone

    创建新实例时自动生成的唯一 ID。A unique ID that is automatically generated when a new instance is created. 将为此实例预配一个多域 (SAN) 证书,以便对与同一 DNS 区域中的任何实例建立的客户端连接进行身份验证。A multi-domain (SAN) certificate for this instance is provisioned to authenticate the client connections to any instance in the same DNS zone. 同一故障转移组中的两个托管实例必须共享 DNS 区域。The two managed instances in the same failover group must share the DNS zone.

    Note

    为 SQL 数据库服务器创建的故障转移组不需要 DNS 区域 ID。A DNS zone ID is not required for failover groups created for SQL Database servers.

  • 故障转移组读写侦听器Failover group read-write listener

    一个 DNS CNAME 记录,指向当前主要节点的 URL。A DNS CNAME record that points to the current primary's URL. 此记录是创建故障转移组时自动创建的,可让读写 SQL 工作负荷在故障转移发生后主节点发生更改时,以透明方式重新连接到主数据库。It is created automatically when the failover group is created and allows the read-write SQL workload to transparently reconnect to the primary database when the primary changes after failover. 在 SQL 数据库服务器上创建故障转移组时,侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.database.chinacloudapi.cnWhen the failover group is created on a SQL Database server, the DNS CNAME record for the listener URL is formed as <fog-name>.database.chinacloudapi.cn. 在托管实例上创建故障转移组时,侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.zone_id.database.chinacloudapi.cnWhen the failover group is created on a managed instance, the DNS CNAME record for the listener URL is formed as <fog-name>.zone_id.database.chinacloudapi.cn.

  • 故障转移组只读侦听器Failover group read-only listener

    构成的 DNS CNAME 记录,指向只读侦听器,后者指向辅助节点的 URL。A DNS CNAME record formed that points to the read-only listener that points to the secondary's URL. 此记录是创建故障转移组时自动创建的,可让只读 SQL 工作负荷使用指定的负载均衡规则以透明方式连接到辅助数据库。It is created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary using the specified load-balancing rules. 在 SQL 数据库服务器上创建故障转移组时,侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.secondary.database.chinacloudapi.cnWhen the failover group is created on a SQL Database server, the DNS CNAME record for the listener URL is formed as <fog-name>.secondary.database.chinacloudapi.cn. 在托管实例上创建故障转移组时,侦听器 URL 的 DNS CNAME 记录格式为 <fog-name>.zone_id.secondary.database.chinacloudapi.cnWhen the failover group is created on a managed instance, the DNS CNAME record for the listener URL is formed as <fog-name>.zone_id.secondary.database.chinacloudapi.cn.

  • 自动故障转移策略Automatic failover policy

    默认使用自动故障转移策略配置故障转移组。By default, a failover group is configured with an automatic failover policy. 检测到故障且宽限期过后,SQL 数据库服务会触发故障转移。The SQL Database service triggers failover after the failure is detected and the grace period has expired. 系统必须确保,因影响范围太大,SQL 数据库服务的内置高可用性基础结构无法缓解服务中断。The system must verify that the outage cannot be mitigated by the built-in high availability infrastructure of the SQL Database service due to the scale of the impact. 如果要从应用程序控制故障转移工作流,可以关闭自动故障转移。If you want to control the failover workflow from the application, you can turn off automatic failover.

  • 只读故障转移策略Read-only failover policy

    默认禁用只读侦听器的故障转移功能。By default, the failover of the read-only listener is disabled. 这可确保在辅助数据库脱机时,主数据库的性能不会受到影响。It ensures that the performance of the primary is not impacted when the secondary is offline. 但是,这也意味辅助数据库恢复前,只读会话将无法连接。However, it also means the read-only sessions will not be able to connect until the secondary is recovered. 如果不能容忍只读会话停机,但能容忍以主数据库的潜在性能降级为代价将主数据库临时用于只读和读写流量,则可以通过配置 AllowReadOnlyFailoverToPrimary 属性为只读侦听器启用故障转移。If you cannot tolerate downtime for the read-only sessions and are OK to temporarily use the primary for both read-only and read-write traffic at the expense of the potential performance degradation of the primary, you can enable failover for the read-only listener by configuring the AllowReadOnlyFailoverToPrimary property. 在这种情况下,如果辅助节点不可用,则会将只读流量自动重定向到主要节点。In that case, the read-only traffic will be automatically redirected to the primary if the secondary is not available.

  • 计划的故障转移Planned failover

    将辅助角色切换为主要角色之前,计划内故障转移在主要数据库与辅助数据库之间执行完全同步。Planned failover performs full synchronization between primary and secondary databases before the secondary switches to the primary role. 这可以保证数据不会丢失。This guarantees no data loss. 计划内故障转移用于以下场景:Planned failover is used in the following scenarios:

    • 不可接受数据丢失时在生产环境中执行灾难恢复 (DR) 演练Perform disaster recovery (DR) drills in production when the data loss is not acceptable
    • 将数据库重新定位到不同的区域Relocate the databases to a different region
    • 缓解服务中断(故障回复)后将数据库恢复到主要区域。Return the databases to the primary region after the outage has been mitigated (failback).
  • 未计划的故障转移Unplanned failover

    计划外故障转移或强制故障转移立即将辅助角色切换为主要角色,而不与主要节点进行任何同步。Unplanned or forced failover immediately switches the secondary to the primary role without any synchronization with the primary. 此操作会导致数据丢失。This operation will result in data loss. 在服务中断期间当主要节点不可访问时,计划外故障转移将用作恢复方法。Unplanned failover is used as a recovery method during outages when the primary is not accessible. 原始主要节点重新联机后,将在不进行同步的情况下自动重新连接,并成为新的辅助节点。When the original primary is back online, it will automatically reconnect without synchronization and become a new secondary.

  • 手动故障转移Manual failover

    可随时手动启动故障转移,而不考虑自动故障转移配置。You can initiate failover manually at any time regardless of the automatic failover configuration. 如果未配置自动故障转移策略,则需要执行手动故障转移才能将故障转移组中的数据库恢复到辅助节点。If automatic failover policy is not configured, manual failover is required to recover databases in the failover group to the secondary. 可通过完整数据同步启动强制或友好的故障转移。You can initiate forced or friendly failover (with full data synchronization). 后者可用于将主要节点重新定位到次要区域。The latter could be used to relocate the primary to the secondary region. 故障转移完成后,会自动更新 DNS 记录,以确保与新的主要节点建立连接When failover is completed, the DNS records are automatically updated to ensure connectivity to the new primary

  • 数据丢失宽限期Grace period with data loss

    由于主数据库和辅助数据库是使用异步复制进行同步的,因此故障转移可能会导致数据丢失。Because the primary and secondary databases are synchronized using asynchronous replication, the failover may result in data loss. 可以自定义自动故障转移策略,以便反映应用程序对数据丢失的容错。You can customize the automatic failover policy to reflect your application's tolerance to data loss. 通过配置 GracePeriodWithDataLossHours,可以控制系统启动可能导致数据丢失的故障转移之前的等待时间。By configuring GracePeriodWithDataLossHours, you can control how long the system waits before initiating the failover that is likely to result data loss.

  • 多个故障转移组Multiple failover groups

    可为同一对服务器配置多个故障转移组以控制故障转移规模。You can configure multiple failover groups for the same pair of servers to control the scale of failovers. 每个组均独立进行故障转移。Each group fails over independently. 如果多租户应用程序使用弹性池,则可使用此功能来混合每个池的主数据库和辅助数据库。If your multi-tenant application uses elastic pools, you can use this capability to mix primary and secondary databases in each pool. 采用这种方式可将服务中断的影响范围缩小到一半的租户中。This way you can reduce the impact of an outage to only half of the tenants.

    Note

    托管实例不支持多个故障转移组。Managed Instance does not support multiple failover groups.

权限Permissions

通过基于角色的访问控制 (RBAC) 管理故障转移组的权限。Permissions for a failover group are managed via role-based access control (RBAC). SQL Server 参与者角色拥有管理故障转移组所需的全部权限。The SQL Server Contributor role has all the necessary permissions to manage failover groups.

创建故障转移组Create failover group

若要创建某个故障转移组,需要对主服务器和辅助服务器,以及该故障转移组中的所有数据库拥有 RBAC 写入访问权限。To create a failover group, you need RBAC write access to both the primary and secondary servers, and to all databases in the failover group. 对于托管实例,需要对主要和辅助托管实例拥有 RBAC 写入访问权限,但对单个数据库的权限无关紧要,因为无法在故障转移组中添加或删除单个托管实例数据库。For a managed instance, you need RBAC write access to both the primary and secondary managed instance, but permissions on individual databases are not relevant since individual managed instance databases cannot be added to or removed from a failover group.

更新故障转移组Update a failover group

若要更新某个故障转移组,需要对该故障转移组,以及当前主服务器或托管实例上的所有数据库拥有 RBAC 写入访问权限。To update a failover group, you need RBAC write access to the failover group, and all databases on the current primary server or managed instance.

对故障转移组进行故障转移Failover a failover group

若要对某个故障转移组进行故障转移,需要对新的主服务器或托管实例上的故障转移组拥有 RBAC 写入访问权限。To fail over a failover group, you need RBAC write access to the failover group on the new primary server or managed instance.

有关将故障转移组与单一数据库和弹性池配合使用的最佳做法Best practices of using failover groups with single databases and elastic pools

自动故障转移组必须在主要 SQL 数据库服务器上进行配置,并会将它连接到不同 Azure 区域中的辅助 SQL 数据库服务器。The auto-failover group must be configured on the primary SQL Database server and will connect it to the secondary SQL Database server in a different Azure region. 组可以包含这些服务器中的所有或部分数据库。The groups can include all or some databases in these servers. 下图演示了使用多个数据库和自动故障转移组的异地冗余云应用程序的典型配置。The following diagram illustrates a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.

自动故障转移

Note

有关将单一数据库添加到故障转移组的详细分步教程,请参阅将单一数据库添加到故障转移组See Add single database to a failover group for a detailed step-by-step tutorial adding a single database to a failover group.

在设计具有业务连续性的服务时,请遵循以下一般准则:When designing a service with business continuity in mind, follow these general guidelines:

  • 使用一个或多个故障转移组来管理多个数据库的故障转移Use one or several failover groups to manage failover of multiple databases

    可在不同区域的两个服务器(主服务器和辅助服务器)之间创建一个或多个故障转移组。One or many failover groups can be created between two servers in different regions (primary and secondary servers). 每组可包含一个或多个数据库,这些数据库是在所有或某些主数据库因主要区域中的服务中断而变得不可用时,作为单元恢复的。Each group can include one or several databases that are recovered as a unit in case all or some primary databases become unavailable due to an outage in the primary region. 故障转移组使用服务目标作为主数据库创建异地辅助数据库。The failover group creates geo-secondary database with the same service objective as the primary. 如果将现有的异地复制关系添加到故障转移组,请确保使用与主数据库相同的服务层级和计算大小来配置异地辅助数据库。If you add an existing geo-replication relationship to the failover group, make sure the geo-secondary is configured with the same service tier and compute size as the primary.

  • 使用读写侦听器处理 OLTP 工作负荷Use read-write listener for OLTP workload

    执行 OLTP 操作时,请使用 <fog-name>.database.chinacloudapi.cn 作为服务器 URL,连接将自动定向到主要节点。When performing OLTP operations, use <fog-name>.database.chinacloudapi.cn as the server URL and the connections are automatically directed to the primary. 此 URL 在故障转移后不会更改。This URL does not change after the failover. 请注意,故障转移涉及更新 DNS 记录,以便仅在刷新客户端 DNS 缓存后,客户端连接才会重定向到新的主数据库。Note the failover involves updating the DNS record so the client connections are redirected to the new primary only after the client DNS cache is refreshed.

  • 使用只读侦听器处理只读工作负荷Use read-only listener for read-only workload

    如果你有一个在逻辑上隔离的只读工作负荷,且它允许存在一些过时数据,则可在应用程序中使用辅助数据库。If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. 对于只读的会话,请使用 <fog-name>.secondary.database.chinacloudapi.cn 作为服务器 URL,连接将自动定向到辅助节点。For read-only sessions, use <fog-name>.secondary.database.chinacloudapi.cn as the server URL and the connection is automatically directed to the secondary. 此外,还建议使用 ApplicationIntent=ReadOnly 在连接字符串中指示读取意向。It is also recommended that you indicate in connection string read intent by using ApplicationIntent=ReadOnly. 如果要确保只读工作负荷在故障转移后或辅助服务器脱机时可以重新连接,请确保配置故障转移策略的 AllowReadOnlyFailoverToPrimary 属性。If you want to ensure that the read-only workload can reconnect after failover or in case the secondary server goes offline, make sure to configure the AllowReadOnlyFailoverToPrimary property of the failover policy.

  • 可应对性能下降的问题Be prepared for perf degradation

    SQL 故障转移决策与应用程序的其余部分或所用的其他服务无关。SQL failover decision is independent from the rest of the application or other services used. 应用程序可能是“mixed”与在一个区域和一些在另一些组件。The application may be "mixed" with some components in one region and some in another. 为避免性能降低,请确保在 DR 区域中采用冗余的应用程序部署,并遵循这些网络安全性准则To avoid the degradation, ensure the redundant application deployment in the DR region and follow these network security guidelines.

    Note

    DR 区域中的应用程序不必使用不同的连接字符串。The application in the DR region does not have to use a different connection string.

  • 可应对数据丢失的问题Prepare for data loss

    如果检测到服务中断,SQL 会等待 GracePeriodWithDataLossHours 指定的期限。If an outage is detected, SQL waits for the period you specified by GracePeriodWithDataLossHours. 默认值为 1 小时。The default value is 1 hour. 如果不能承受丢失数据,请确保将 GracePeriodWithDataLossHours 设置为一个足够大的数字,如 24 小时。If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours. 使用手动组故障转移从辅助节点故障回复到主要节点。Use manual group failover to fail back from the secondary to the primary.

    Important

    DTU 少于或等于 800、使用异地复制的数据库超过 250 个的弹性数据库池可能会遇到更长的计划故障转移和性能下降等问题。Elastic pools with 800 or fewer DTUs and more than 250 databases using geo-replication may encounter issues including longer planned failovers and degraded performance. 这些问题更可能在写密集型工作负荷下发生,例如,异地复制终结点广泛分隔于各个地理位置,或者每个数据库使用多个辅助终结点。These issues are more likely to occur for write intensive workloads, when geo-replication endpoints are widely separated by geography, or when multiple secondary endpoints are used for each database. 当异地复制滞后随着时间推移增加时,这些问题的症状便会显现。Symptoms of these issues are indicated when the geo-replication lag increases over time. 这种滞后可以使用 sys.dm_geo_replication_link_status 进行监视。This lag can be monitored using sys.dm_geo_replication_link_status. 如果发生这些问题,缓解方法包括增加池 DTU 的数量或者减少同一池中异地复制数据库的数量。If these issues occur, then mitigations include increasing the number of pool DTUs, or reducing the number of geo-replicated databases in the same pool.

有关将故障转移组与托管实例配合使用的最佳做法Best practices of using failover groups with managed instances

自动故障转移组必须在主要实例上进行配置,需将其连接到不同 Azure 区域中的辅助实例。The auto-failover group must be configured on the primary instance and will connect it to the secondary instance in a different Azure region. 实例中的所有数据库将复制到辅助实例。All databases in the instance will be replicated to the secondary instance.

下图演示了使用托管实例和自动故障转移组的异地冗余云应用程序的典型配置。The following diagram illustrates a typical configuration of a geo-redundant cloud application using managed instance and auto-failover group.

自动故障转移

Note

有关添加托管实例以使用故障转移组的详细分步教程,请参阅将托管实例添加到故障转移组See Add managed instance to a failover group for a detailed step-by-step tutorial adding a managed instance to use failover group.

如果应用程序使用托管实例作为数据层,进行业务连续性设计时,请遵循以下一般准则:If your application uses managed instance as the data tier, follow these general guidelines when designing for business continuity:

  • 在主要实例所在的同一 DNS 区域中创建辅助实例Create the secondary instance in the same DNS zone as the primary instance

    若要确保故障转移后与主要实例的连接不中断,主要实例和辅助实例必须位于同一 DNS 区域。To ensure non-interrupted connectivity to the primary instance after failover both the primary and secondary instances must be in the same DNS zone. 将会保证同一个多域 (SAN) 证书可用于对与故障转移组中的两个实例之一建立的客户端连接进行身份验证。It will guarantee that the same multi-domain (SAN) certificate can be used to authenticate the client connections to either of the two instances in the failover group. 准备好将应用程序部署到生产环境后,在不同的区域中创建一个辅助实例,并确保它与主要实例共享 DNS 区域。When your application is ready for production deployment, create a secondary instance in a different region and make sure it shares the DNS zone with the primary instance. 为此,可以使用 Azure 门户、PowerShell 或 REST API 指定 DNS Zone Partner 可选参数。You can do it by specifying a DNS Zone Partner optional parameter using the Azure portal, PowerShell, or the REST API.

Important

在子网中创建的第一个实例确定同一子网中所有后续实例的 DNS 区域。First instance created in the subnet determines DNS zone for all subsequent instances in the same subnet. 这意味着,同一子网中的两个实例不能属于不同的 DNS 区域。This means that two instances from the same subnet cannot belong to different DNS zones.

有关在主要实例所在的 DNS 区域中创建辅助实例的详细信息,请参阅创建辅助托管实例For more information about creating the secondary instance in the same DNS zone as the primary instance, see Create a secondary managed instance.

  • 在两个实例之间启用复制流量Enable replication traffic between two instances

    由于每个实例隔离在其自身的 VNet 中,因此,必须允许这些 VNet 之间的双向流量。Because each instance is isolated in its own VNet, two-directional traffic between these VNets must be allowed. 请参阅 Azure VPN 网关See Azure VPN gateway

  • 在不同订阅中的托管实例之间创建故障转移组Create a failover group between managed instances in different subscriptions

    可以在两个不同订阅中的托管实例之间创建故障转移组。You can create a failover group between managed instances in two different subscriptions. 使用 PowerShell API 时,可以通过为辅助实例指定 PartnerSubscriptionId 参数来执行此操作。When using PowerShell API you can do it by specifying the PartnerSubscriptionId parameter for the secondary instance. 使用 REST API 时,properties.managedInstancePairs 参数中包含的每个实例 ID 都可以有自己的订阅 ID。When using REST API, each instance ID included in the properties.managedInstancePairs parameter can have its own subscriptionID.

    Important

    Azure 门户不支持跨不同订阅的故障转移组。Azure Portal does not support failover groups across different subscriptions.

  • 将故障转移组配置为管理整个实例的故障转移Configure a failover group to manage failover of entire instance

    故障转移组将管理实例中所有数据库的故障转移。The failover group will manage the failover of all the databases in the instance. 创建某个组后,实例中的每个数据库将自动异地复制到辅助实例。When a group is created, each database in the instance will be automatically geo-replicated to the secondary instance. 无法使用故障转移组针对一部分数据库启动部分故障转移。You cannot use failover groups to initiate a partial failover of a subset of the databases.

    Important

    如果从主要实例中删除了某个数据库,该数据库也会在异地辅助实例上自动删除。If a database is removed from the primary instance, it will also be dropped automatically on the geo secondary instance.

  • 使用读写侦听器处理 OLTP 工作负荷Use read-write listener for OLTP workload

    执行 OLTP 操作时,请使用 <fog-name>.zone_id.database.chinacloudapi.cn 作为服务器 URL,连接将自动定向到主要节点。When performing OLTP operations, use <fog-name>.zone_id.database.chinacloudapi.cn as the server URL and the connections are automatically directed to the primary. 此 URL 在故障转移后不会更改。This URL does not change after the failover. 故障转移涉及更新 DNS 记录,以便仅在刷新客户端 DNS 缓存后,客户端连接才会重定向到新的主要节点。The failover involves updating the DNS record, so the client connections are redirected to the new primary only after the client DNS cache is refreshed. 由于辅助实例与主要实例共享 DNS 区域,客户端应用程序可以使用相同的 SAN 证书重新连接到辅助实例。Because the secondary instance shares the DNS zone with the primary, the client application will be able to reconnect to it using the same SAN certificate.

  • 直接连接到异地复制的辅助节点以进行只读查询Connect directly to geo-replicated secondary for read-only queries

    如果你有一个在逻辑上隔离的只读工作负荷,且它允许存在一些过时数据,则可在应用程序中使用辅助数据库。If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. 若要直接连接到异地复制的辅助节点,请使用 server.secondary.zone_id.database.chinacloudapi.cn 作为服务器 URL,这样可以直接连接到异地复制的辅助节点。To connect directly to the geo-replicated secondary, use server.secondary.zone_id.database.chinacloudapi.cn as the server URL and the connection is made directly to the geo-replicated secondary.

    Note

    在某些服务层级中,Azure SQL 数据库支持通过只读副本使用只读副本的容量和连接字符串中的 ApplicationIntent=ReadOnly 参数对只读查询工作负荷进行负载均衡。In certain service tiers, Azure SQL Database supports the use of read-only replicas to load balance read-only query workloads using the capacity of one read-only replica and using the ApplicationIntent=ReadOnly parameter in the connection string. 如果配置了异地复制的辅助节点,则可以使用此功能连接到主要位置或异地复制位置中的只读副本。When you have configured a geo-replicated secondary, you can use this capability to connect to either a read-only replica in the primary location or in the geo-replicated location.

    • 若要连接到主要位置中的只读副本,请使用 <fog-name>.zone_id.database.chinacloudapi.cnTo connect to a read-only replica in the primary location, use <fog-name>.zone_id.database.chinacloudapi.cn.
    • 若要连接到辅助位置中的只读副本,请使用 <fog-name>.secondary.zone_id.database.chinacloudapi.cnTo connect to a read-only replica in the secondary location, use <fog-name>.secondary.zone_id.database.chinacloudapi.cn.
  • 可应对性能下降的问题Be prepared for perf degradation

    SQL 故障转移决策与应用程序的其余部分或所用的其他服务无关。SQL failover decision is independent from the rest of the application or other services used. 应用程序可能是“mixed”与在一个区域和一些在另一些组件。The application may be �mixed� with some components in one region and some in another. 为避免性能降低,请确保在 DR 区域中采用冗余的应用程序部署,并遵循这些网络安全性准则To avoid the degradation, ensure the redundant application deployment in the DR region and follow these network security guidelines.

  • 可应对数据丢失的问题Prepare for data loss

    如果检测到服务中断,则 SQL 将自动触发读写故障转移是否我们的知识的最佳零数据丢失。If an outage is detected, SQL automatically triggers read-write failover if there is zero data loss to the best of our knowledge. 否则,它会等待 GracePeriodWithDataLossHours 指定的期限。Otherwise, it waits for the period you specified by GracePeriodWithDataLossHours. 如果指定了 GracePeriodWithDataLossHours,则可能会丢失数据。If you specified GracePeriodWithDataLossHours, be prepared for data loss. 一般情况下,在中断期间 Azure 倾向于可用性。In general, during outages, Azure favors availability. 如果不能承受丢失数据,请务必将 GracePeriodWithDataLossHours 设置为一个足够大的数字,例如 24 小时。If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours.

    启动故障转移后,读写侦听器的 DNS 更新会立即发生。The DNS update of the read-write listener will happen immediately after the failover is initiated. 此操作不会导致数据丢失。This operation will not result in data loss. 但是,在正常情况下,切换数据库角色的过程可能需要 5 分钟时间。However, the process of switching database roles can take up to 5 minutes under normal conditions. 在完成之前,新主要实例中的某些数据库仍是只读的。Until it is completed, some databases in the new primary instance will still be read-only. 如果使用 PowerShell 启动故障转移,则整个操作是同步的。If failover is initiated using PowerShell, the entire operation is synchronous. 如果使用 Azure 门户启动故障转移,UI 将指示完成状态。If it is initiated using the Azure portal, the UI will indicate completion status. 如果使用 REST API 启动故障转移,可以使用标准 Azure 资源管理器的轮询机制来监视完成状态。If it is initiated using the REST API, use standard Azure Resource Manager�s polling mechanism to monitor for completion.

    Important

    使用手动组故障转移可将主要数据库移回到原始位置。Use manual group failover to move primaries back to the original location. 缓解导致故障转移的服务中断问题后,可将主要数据库移到原始位置。When the outage that caused the failover is mitigated, you can move your primary databases to the original location. 为此,应该启动组的手动故障转移。To do that you should initiate the manual failover of the group.

  • 确认故障转移组的已知限制Acknowledge known limitations of failover groups

    故障转移组中的实例不支持数据库重命名和实例重设大小。Database rename and instance resize are not supported for instances in failover group. 需要临时删除故障转移组,才能执行这些操作。You will need to temporarily delete failover group to be able to preform these actions.

故障转移组和网络安全Failover groups and network security

对于某些应用程序,安全规则要求只允许特定组件(如 VM、Web 服务等)通过网络访问数据层。此要求对业务连续性设计和故障转移组的使用提出了一些挑战。For some applications the security rules require that the network access to the data tier is restricted to a specific component or components such as a VM, web service etc. This requirement presents some challenges for business continuity design and the use of the failover groups. 在实施此类受限访问时,请考虑以下选项。Consider the following options when implementing such restricted access.

使用故障转移组和虚拟网络规则Using failover groups and virtual network rules

如果使用虚拟网络服务终结点和规则来限制对 SQL 数据库的访问,请注意每个虚拟网络服务终结点仅适用于一个 Azure 区域。If you are using Virtual Network service endpoints and rules to restrict access to your SQL database, be aware that Each Virtual Network service endpoint applies to only one Azure region. 终结点不允许其他区域接受来自该子网的通信。The endpoint does not enable other regions to accept communication from the subnet. 因此,只有部署在同一区域中的客户端应用程序才能连接到主数据库。Therefore, only the client applications deployed in the same region can connect to the primary database. 因为故障转移会导致 SQL 客户端会话重新路由到不同(次要)区域中的服务器,所以源自该区域之外的客户端的这些会话将失败。Since the failover results in the SQL client sessions being rerouted to a server in a different (secondary) region, these sessions will fail if originated from a client outside of that region. 因此,如果参与的服务器包含在虚拟网络规则中,则无法启用自动故障转移策略。For that reason, the automatic failover policy cannot be enabled if the participating servers are included in the Virtual Network rules. 若要支持手动故障转移,请执行以下步骤:To support manual failover, follow these steps:

  1. 在次要区域中预配应用程序前端组件(Web 服务、虚拟机等)的冗余副本Provision the redundant copies of the front-end components of your application (web service, virtual machines etc.) in the secondary region
  2. 为主服务器和辅助服务器分别配置虚拟网络规则Configure the virtual network rules individually for primary and secondary server
  3. 使用流量管理器配置启用前端故障转移Enable the front-end failover using a Traffic manager configuration
  4. 检测到服务中断时启动手动故障转移。Initiate manual failover when the outage is detected. 此选项针对需要在前端和数据层之间保持一致延迟的应用程序进行了优化,并支持在前端和/或数据层受到服务中断的影响时进行恢复。This option is optimized for the applications that require consistent latency between the front-end and the data tier and supports recovery when either front end, data tier or both are impacted by the outage.

Note

如果使用只读侦听器对只读工作负荷进行负载均衡,请确保在次要区域中的 VM 或其他资源上执行此工作负荷,以便它可以连接到辅助数据库。If you are using the read-only listener to load-balance a read-only workload, make sure that this workload is executed in a VM or other resource in the secondary region so it can connect to the secondary database.

使用故障转移组和 SQL 数据库防火墙规则Using failover groups and SQL database firewall rules

如果业务连续性计划要求使用自动故障转移组进行故障转移,则可以使用传统防火墙规则限制对 SQL 数据库的访问。If your business continuity plan requires failover using groups with automatic failover, you can restrict access to your SQL database using the traditional firewall rules. 若要支持自动故障转移,请执行以下步骤:To support automatic failover, follow these steps:

  1. 创建公共 IPCreate a public IP
  2. 创建公共负载均衡器并为其分配公共 IP。Create a public load balancer and assign the public IP to it.
  3. 为前端组件创建虚拟网络和虚拟机Create a virtual network and the virtual machines for your front-end components
  4. 创建网络安全组并配置入站连接。Create network security group and configure inbound connections.
  5. 使用“Sql”服务标记确保出站连接向 Azure SQL 数据库开放。Ensure that the outbound connections are open to Azure SQL database by using 'Sql' service tag.
  6. 创建 SQL 数据库防火墙规则,以允许来自步骤 1 中创建的公共 IP 地址的入站流量。Create a SQL database firewall rule to allow inbound traffic from the public IP address you create in step 1.

有关如何配置出站访问以及在防火墙规则中使用哪个 IP 的详细信息,请参阅负载均衡器出站连接For more information about on how to configure outbound access and what IP to use in the firewall rules, see Load balancer outbound connections.

上述配置将确保自动故障转移不会阻止来自前端组件的连接,并假定应用程序可以容忍前端与数据层之间的较长延迟。The above configuration will ensure that the automatic failover will not block connections from the front-end components and assumes that the application can tolerate the longer latency between the front end and the data tier.

Important

若要保证区域服务中断的业务连续性,则必须确保前端组件和数据库的地理冗余。To guarantee business continuity for regional outages you must ensure geographic redundancy for both front-end components and the databases.

在托管实例及其 VNet 之间启用异地复制Enabling geo-replication between managed instances and their VNets

在两个不同区域中的主要和辅助托管实例之间设置故障转移组时,将使用独立的虚拟网络来隔离每个实例。When you set up a failover group between primary and secondary managed instances in two different regions, each instance is isolated using an independent virtual network. 若要允许这些 VNet 之间的复制流量,请确保满足以下先决条件:To allow replication traffic between these VNets ensure these prerequisites are met:

  1. 两个托管实例需位于不同的 Azure 区域中。The two managed instances need to be in different Azure regions.

  2. 这两个托管实例需位于相同的服务层级,并且具有相同的存储大小。The two managed instances need to be the same service tier, and have the same storage size.

  3. 辅助托管实例必须是空的(不包含任何用户数据库)。Your secondary managed instance must be empty (no user databases).

  4. 需要通过 VPN 网关或 Express Route 来连接托管实例使用的虚拟网络。The virtual networks used by the managed instances need to be connected through a VPN Gateway or Express Route. 当两个虚拟网络通过本地网络连接时,请确保没有任何防火墙规则阻止端口 5022 和 11000-11999。When two virtual networks connect through an on-premises network, ensure there is no firewall rule blocking ports 5022, and 11000-11999. 不支持全局 VNet 对等互连。Global VNet Peering is not supported.

  5. 两个托管实例 VNet 的 IP 地址不能重叠。The two managed instance VNets cannot have overlapping IP addresses.

  6. 需要设置网络安全组 (NSG),使端口 5022 和端口范围 11000~12000 保持打开,以便能够从其他托管实例子网建立入站和出站连接。You need to set up your Network Security Groups (NSG) such that ports 5022 and the range 11000~12000 are open inbound and outbound for connections from the other managed instanced subnet. 目的是允许实例之间的复制流量This is to allow replication traffic between the instances

    Important

    NSG 安全规则配置不当会导致数据库复制操作停滞。Misconfigured NSG security rules leads to stuck database copy operations.

  7. 辅助实例上已配置正确的 DNS 区域 ID。The secondary instance is configured with the correct DNS zone ID. DNS 区域是托管实例的属性,其 ID 包含在主机名地址中。DNS zone is a property of a managed instance and its ID is included in the host name address. 在每个 VNet 中创建第一个托管实例时,将生成随机字符串形式的区域 ID。同一个 ID 将分配到同一子网中的所有其他实例。The zone ID is generated as a random string when the first managed instance is created in each VNet and the same ID is assigned to all other instances in the same subnet. 分配后,无法修改 DNS 区域。Once assigned, the DNS zone cannot be modified. 同一故障转移组中包含的托管实例必须共享 DNS 区域。Managed instances included in the same failover group must share the DNS zone. 为此,在创建辅助实例时,可以传递主要实例的区域 ID 作为 DnsZonePartner 参数的值。You accomplish this by passing the primary instance's zone ID as the value of DnsZonePartner parameter when creating the secondary instance.

    Note

    有关使用托管实例配置故障转移组的详细教程,请参阅将托管实例添加到故障转移组For a detailed tutorial on configuring failover groups with managed instance, see add a managed instance to a failover group.

升级或降级主数据库Upgrading or downgrading a primary database

无需断开连接任何辅助数据库,即可将主数据库升级或降级到不同的计算大小(在相同的服务层级中,但不在“常规用途”与“业务关键”类型之间)。You can upgrade or downgrade a primary database to a different compute size (within the same service tier, not between General Purpose and Business Critical) without disconnecting any secondary databases. 升级时,建议先升级所有辅助数据库,再升级主数据库。When upgrading, we recommend that you upgrade all of the secondary databases first, and then upgrade the primary. 降级时,请反转顺序:先降级主数据库,再降级所有辅助数据库。When downgrading, reverse the order: downgrade the primary first, and then downgrade all of the secondary databases. 将数据库升级或降级到不同服务层级时,将强制执行此建议操作。When you upgrade or downgrade the database to a different service tier, this recommendation is enforced.

具体而言,建议采用此顺序的目的是避免较低 SKU 上的辅助数据库在过载时出现问题,并且必须在升级或降级过程中重新设定种子。This sequence is recommended specifically to avoid the problem where the secondary at a lower SKU gets overloaded and must be reseeded during an upgrade or downgrade process. 此外,可以通过将主数据库设为只读来避免问题,代价是针对主数据库的所有读写工作负荷会受到影响。You could also avoid the problem by making the primary read-only, at the expense of impacting all read-write workloads against the primary.

Note

如果辅助数据库是作为故障转移组配置的一个部分创建的,则我们不建议对辅助数据库进行降级。If you created secondary database as part of the failover group configuration it is not recommended to downgrade the secondary database. 这是为了确保激活故障转移后,数据层有足够的容量来处理常规工作负荷。This is to ensure your data tier has sufficient capacity to process your regular workload after failover is activated.

防止丢失关键数据Preventing the loss of critical data

由于广域网的延迟时间较长,连续复制使用了异步复制机制。Due to the high latency of wide area networks, continuous copy uses an asynchronous replication mechanism. 在发生故障时,异步复制会不可避免地丢失某些数据。Asynchronous replication makes some data loss unavoidable if a failure occurs. 但是,某些应用程序可能要求不能有数据丢失。However, some applications may require no data loss. 为了保护这些关键更新,应用程序开发人员可以在提交事务后立即调用 sp_wait_for_database_copy_sync 系统过程。To protect these critical updates, an application developer can call the sp_wait_for_database_copy_sync system procedure immediately after committing the transaction. 调用 sp_wait_for_database_copy_sync 会阻止调用线程,直到将上次提交的事务传输到辅助数据库。Calling sp_wait_for_database_copy_sync blocks the calling thread until the last committed transaction has been transmitted to the secondary database. 但是,它不会等待传输的事务提交到辅助数据库进行重播。However, it does not wait for the transmitted transactions to be replayed and committed on the secondary. sp_wait_for_database_copy_sync 的范围限定为特定的连续复制链接。sp_wait_for_database_copy_sync is scoped to a specific continuous copy link. 对主数据库具有连接权限的任何用户都可以调用此过程。Any user with the connection rights to the primary database can call this procedure.

Note

sp_wait_for_database_copy_sync 可防止故障转移后的数据丢失,但不能保证读取访问完全同步。sp_wait_for_database_copy_sync prevents data loss after failover, but does not guarantee full synchronization for read access. sp_wait_for_database_copy_sync 过程调用导致的延迟可能会很明显,具体取决于调用时的事务日志大小。The delay caused by a sp_wait_for_database_copy_sync procedure call can be significant and depends on the size of the transaction log at the time of the call.

故障转移组和时间点还原Failover groups and point-in-time restore

有关将时间点还原与故障转移组配合使用的信息,请参阅时间点恢复 (PITR)For information about using point-in-time restore with failover groups, see Point in Time Recovery (PITR).

以编程方式管理故障转移组Programmatically managing failover groups

如上所述,也可以使用 Azure PowerShell 和 REST API 以编程方式管理自动故障转移组和活动异地复制。As discussed previously, auto-failover groups and active geo-replication can also be managed programmatically using Azure PowerShell and the REST API. 下表描述了可用的命令集。The following tables describe the set of commands available. 活动异地复制包括一组用于管理的 Azure 资源管理器 API,其中包括 Azure SQL 数据库 REST APIAzure PowerShell cmdletActive geo-replication includes a set of Azure Resource Manager APIs for management, including the Azure SQL Database REST API and Azure PowerShell cmdlets. 这些 API 需要使用资源组,并支持基于角色的安全性 (RBAC)。These APIs require the use of resource groups and support role-based security (RBAC). 有关如何实现访问角色的详细信息,请参阅 Azure 基于角色的访问控制For more information on how to implement access roles, see Azure Role-Based Access Control.

PowerShell:使用单一数据库和弹性池管理 SQL 数据库故障转移PowerShell: Manage SQL database failover with single databases and elastic pools

CmdletCmdlet 说明Description
New-AzSqlDatabaseFailoverGroupNew-AzSqlDatabaseFailoverGroup 此命令会创建故障转移组,并将其同时注册到主服务器和辅助服务器This command creates a failover group and registers it on both primary and secondary servers
Remove-AzSqlDatabaseFailoverGroupRemove-AzSqlDatabaseFailoverGroup 从服务器中移除故障转移组,并删除组中包含的所有辅助数据库Removes the failover group from the server and deletes all secondary databases included the group
Get-AzSqlDatabaseFailoverGroupGet-AzSqlDatabaseFailoverGroup 检索故障转移组配置Retrieves the failover group configuration
Set-AzSqlDatabaseFailoverGroupSet-AzSqlDatabaseFailoverGroup 修改故障转移组的配置Modifies the configuration of the failover group
Switch-AzSqlDatabaseFailoverGroupSwitch-AzSqlDatabaseFailoverGroup 触发故障转移组到辅助服务器的故障转移Triggers failover of the failover group to the secondary server
Add-AzSqlDatabaseToFailoverGroupAdd-AzSqlDatabaseToFailoverGroup 将一个或多个数据库添加到 Azure SQL 数据库故障转移组Adds one or more databases to an Azure SQL Database failover group

PowerShell:使用托管实例管理 SQL 数据库故障转移组PowerShell: Managing SQL database failover groups with managed instances

CmdletCmdlet 说明Description
New-AzSqlDatabaseInstanceFailoverGroupNew-AzSqlDatabaseInstanceFailoverGroup 此命令会创建故障转移组,并将其同时注册到主服务器和辅助服务器This command creates a failover group and registers it on both primary and secondary servers
Set-AzSqlDatabaseInstanceFailoverGroupSet-AzSqlDatabaseInstanceFailoverGroup 修改故障转移组的配置Modifies the configuration of the failover group
Get-AzSqlDatabaseInstanceFailoverGroupGet-AzSqlDatabaseInstanceFailoverGroup 检索故障转移组配置Retrieves the failover group configuration
Switch-AzSqlDatabaseInstanceFailoverGroupSwitch-AzSqlDatabaseInstanceFailoverGroup 触发故障转移组到辅助服务器的故障转移Triggers failover of the failover group to the secondary server
Remove-AzSqlDatabaseInstanceFailoverGroupRemove-AzSqlDatabaseInstanceFailoverGroup 删除故障转移组Removes a failover group

REST API:使用单一数据库和共用数据库管理 SQL 数据库故障转移组REST API: Manage SQL database failover groups with single and pooled databases

APIAPI 说明Description
创建或更新故障转移组Create or Update Failover Group 创建或更新故障转移组Creates or updates a failover group
删除故障转移组Delete Failover Group 从服务器中删除故障转移组Removes the failover group from the server
故障转移(计划内)Failover (Planned) 从当前主服务器故障转移到此服务器。Fails over from the current primary server to this server.
强制故障转移允许数据丢失Force Failover Allow Data Loss 从当前主服务器故障转移到此服务器。ails over from the current primary server to this server. 此操作可能导致数据丢失。This operation might result in data loss.
获取故障转移组Get Failover Group 获取某个故障转移组。Gets a failover group.
按服务器列出故障转移组List Failover Groups By Server 列出某个服务器中的故障转移组。Lists the failover groups in a server.
更新故障转移组Update Failover Group 更新某个故障转移组。Updates a failover group.

REST API:使用托管实例管理故障转移组REST API: Manage failover groups with Managed Instances

APIAPI 说明Description
创建或更新故障转移组Create or Update Failover Group 创建或更新故障转移组Creates or updates a failover group
删除故障转移组Delete Failover Group 从服务器中删除故障转移组Removes the failover group from the server
故障转移(计划内)Failover (Planned) 从当前主服务器故障转移到此服务器。Fails over from the current primary server to this server.
强制故障转移允许数据丢失Force Failover Allow Data Loss 从当前主服务器故障转移到此服务器。ails over from the current primary server to this server. 此操作可能导致数据丢失。This operation might result in data loss.
获取故障转移组Get Failover Group 获取某个故障转移组。Gets a failover group.
列出故障转移组 - 按位置列出List Failover Groups - List By Location 列出某个位置中的故障转移组。Lists the failover groups in a location.

后续步骤Next steps