使用自動容錯移轉群組可以啟用多個資料庫透明且協調的容錯移轉Use auto-failover groups to enable transparent and coordinated failover of multiple databases

自動容錯移轉群組是可讓您管理複寫和容錯移轉群組的 SQL Database 伺服器上的資料庫或的受管理的執行個體到另一個區域中的所有資料庫的 SQL Database 功能。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 uses the same underlying technology as active geo-replication. 您可以手動起始容錯移轉,也可以根據使用者定義的原則將其委派給 SQL Database 服務。You can initiate failover manually or you can delegate it to the SQL Database service based on a user-defined policy. 後項可讓您在導致主要區域中完全或部分喪失 SQL Database 服務可用性的嚴重失敗或其他非計劃事件之後,自動復原次要地區中的多個相關資料庫。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. 此外,您可以使用可讀取次要資料庫來卸載唯讀查詢工作負載。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. 在容錯移轉群組中,資料庫的主要和次要伺服器都必須位於相同的訂用帳戶。Both primary and secondary servers for the databases in the failover group must be in the same subscription. 自動容錯移轉群組支援將群組中的所有資料庫都只複寫到不同區域的一部次要伺服器。Auto-failover groups support replication of all databases in the group to only one secondary server in a different region.

注意

在 SQL Database 伺服器上使用單一或集區資料庫時,若您希望在相同或不同區域中有多個次要資料庫,請使用主動式異地複寫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. 此外,自動容錯移轉群組還提供在容錯移轉期間仍保持不變的讀寫和唯讀接聽程式端點。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 Database 伺服器或受控執行個體中資料庫的中斷,都會導致自動容錯移轉。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 安全性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

  • 容錯移轉群組 (霧)Failover group (FOG)

    容錯移轉群組是由單一 SQL Database 伺服器,或可以當做容錯移轉到另一個區域的單位以防所有或部分的主要資料庫變成無法使用,因為主要區域中斷的單一受控執行個體中的資料庫的具名的群組。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.

    重要

    容錯移轉群組的名稱必須是全域唯一內.database.windows.net網域。The name of the failover group must be globally unique within the .database.windows.net domain.

  • SQL Database 伺服器SQL Database servers

    使用 SQL Database 伺服器,可以將單一伺服器上的部分或所有使用者資料庫放在容錯移轉群組中。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 Database 伺服器在單一 SQL Database 伺服器上可支援多個容錯移轉群組。Also, a SQL Database server supports multiple failover groups on a single SQL Database server.

  • 主要Primary

    SQL Database 伺服器或裝載主要資料庫容錯移轉群組中的受控執行個體。The SQL Database server or managed instance that hosts the primary databases in the failover group.

  • 次要Secondary

    SQL Database 伺服器或裝載次要資料庫在容錯移轉群組中的受控執行個體。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 Database 伺服器上的單一資料庫放入相同的容錯移轉群組。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.

    重要

    在受管理的執行個體,會複寫所有使用者資料庫。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

    建立新的執行個體時自動產生的唯一識別碼。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.

    注意

    不需要容錯移轉群組為 SQL Database 伺服器建立 DNS 區域識別碼。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 formed that points to the current primary's URL. 它可讓讀寫 SQL 應用程式在容錯移轉之後,當主要資料庫變更時毫無障礙地重新連線至主要資料庫。It allows the read-write SQL applications to transparently reconnect to the primary database when the primary changes after failover. SQL Database 伺服器上建立容錯移轉群組時,且格式為的接聽程式 URL 的 DNS CNAME 記錄<fog-name>.database.windows.netWhen the failover group is created on a SQL Database server, the DNS CNAME record for the listener URL is formed as <fog-name>.database.windows.net. 接聽程式 URL 的 DNS CNAME 記錄的受管理的執行個體上建立容錯移轉群組時,且格式為<fog-name>.zone_id.database.windows.netWhen 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.windows.net.

  • 容錯移轉群組唯讀接聽程式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 allows the read-only SQL applications to transparently connect to the secondary using the specified load-balancing rules. SQL Database 伺服器上建立容錯移轉群組時,且格式為的接聽程式 URL 的 DNS CNAME 記錄<fog-name>.secondary.database.windows.netWhen 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.windows.net. 接聽程式 URL 的 DNS CNAME 記錄的受管理的執行個體上建立容錯移轉群組時,且格式為<fog-name>.zone_id.secondary.database.windows.netWhen 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.windows.net.

  • 自動容錯移轉原則Automatic failover policy

    容錯移轉群組預設是利用自動容錯移轉原則設定。By default, a failover group is configured with an automatic failover policy. SQL Database 服務在偵測到失敗且寬限期已過期之後,會觸發容錯移轉。The SQL Database service triggers failover after the failure is detected and the grace period has expired. 系統必須就影響級別,藉由 SQL Database 服務的內建高可用性基礎結構,來驗證中斷情況不會趨緩。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. 如果您無法容忍唯讀工作階段的停機時間,並且可以暫時將主要伺服器用於唯讀和讀寫流量,但代價是主要伺服器潛在的效能降低,則可以為唯讀接聽程式啟用容錯移轉。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. 在此情況下,將唯讀流量將會自動重新導向至主要如果次要資料庫無法使用。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.

    注意

    受控執行個體不支援多個容錯移轉群組。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 Database 伺服器上設定,並將其連接至不同 Azure 區域中的次要 SQL Database 伺服器。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.

自動容錯移轉

在商務持續性前提下設計服務時,請遵循這些一般指導方針: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.windows.net 作為伺服器 URL,連線會自動導向至主要伺服器。When performing OLTP operations, use <fog-name>.database.windows.net 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.windows.net 作為伺服器 URL,連線會自動導向至次要伺服器。For read-only sessions, use <fog-name>.secondary.database.windows.net 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.

  • 對效能降低做好心理準備Be prepared for perf degradation

    應用程式的其餘部分或所使用的其他服務並不會影響 SQL 的容錯移轉決策。SQL failover decision is independent from the rest of the application or other services used. 應用程式可能會「混用」某個區域的某些元件和另一個區域的某些元件。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.

    注意

    DR 區域中的應用程式不一定非得使用不同的連接字串。The application in the DR region does not have to use a different connection string.

  • 對資料遺失做好心理準備Prepare for data loss

    如果偵測到發生中斷,它會等候您透過 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.

    重要

    具有 800 個或更少 DTU 且使用異地複寫的資料庫超過 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.

自動容錯移轉

重要

受控執行個體的自動容錯移轉群組處於公開預覽狀態。Auto-failover groups for Managed Instance is in public preview.

如果您的應用程式會使用受管理的執行個體,做為資料層,業務續航力的設計時請遵循下列一般指導方針: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. 您可以藉由指定執行DNS Zone Partner使用 Azure 入口網站、 PowerShell 或 REST API 的選擇性參數。You can do it by specifying a DNS Zone Partner optional parameter using the Azure portal, PowerShell, or the REST API.

    在與主要執行個體相同的 DNS 區域中建立次要執行個體的詳細資訊,請參閱 < 管理容錯移轉群組與受管理的執行個體 (預覽)For more information about creating the secondary instance in the same DNS zone as the primary instance, see Managing failover groups with managed instances (preview).

  • 在兩個執行個體之間啟用複寫流量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

  • 設定容錯移轉群組來管理整個執行個體的容錯移轉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.

    重要

    如果從主要執行個體中移除資料庫,則它也將自動在異地次要執行個體上卸除。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.windows.net 作為伺服器 URL,連線會自動導向至主要伺服器。When performing OLTP operations, use <fog-name>.zone_id.database.windows.net 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.windows.net 作為伺服器 URL,並直接連接到異地複寫的次要執行個體。To connect directly to the geo-replicated secondary, use server.secondary.zone_id.database.windows.net as the server URL and the connection is made directly to the geo-replicated secondary.

    注意

    在特定的服務層級,Azure SQL Database 支援使用唯讀複本來使用一個唯讀複本的容量,並使用連接字串中的 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.windows.netTo connect to a read-only replica in the primary location, use <fog-name>.zone_id.database.windows.net.
    • 若要連線至唯讀複本在次要位置中,使用<fog-name>.secondary.zone_id.database.windows.netTo connect to a read-only replica in the secondary location, use <fog-name>.secondary.zone_id.database.windows.net.
  • 對效能降低做好心理準備Be prepared for perf degradation

    應用程式的其餘部分或所使用的其他服務並不會影響 SQL 的容錯移轉決策。SQL failover decision is independent from the rest of the application or other services used. 應用程式可能會「混用」某個區域的某些元件和另一個區域的某些元件。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 Resource Manager 的輪詢機制來監視完成情況。If it is initiated using the REST API, use standard Azure Resource Manager’s polling mechanism to monitor for completion.

    重要

    使用手動群組容錯移轉,將主要資料庫移回原始位置。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.

容錯移轉群組和網路安全性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.

注意

如果您使用唯讀接聽程式對唯讀工作負載進行負載平衡,請確保此工作負載會在 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.

重要

若要保證區域性中斷時的商務持續性,您必須確定前端元件與資料庫的異地備援。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

當您設定兩個不同區域中的主要和次要受控執行個體之間的容錯移轉群組時,每個執行個體是隔離使用獨立的 VNet。When you set up a failover group between primary and secondary managed instances in two different regions, each instance is isolated using an independent VNet. 若要允許這些 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. 您的次要受控執行個體必須是空的 (沒有使用者資料庫)。Your secondary must be empty (no user databases).

  3. 主要和次要的 managed 執行個體必須位於相同的資源群組。The primary and secondary managed instances need to be in the same Resource Group.

  4. 受管理的執行個體屬於需要透過進行連線的 Vnet VPN 閘道The VNets that the managed instances are part of need to be connected through a VPN Gateway. 目前不支援轉移的全域 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

    重要

    設定錯誤的 NSG 安全性規則會導致資料庫複製作業停滯。Misconfigured NSG security rules leads to stuck database copy operations.

  7. 次要執行個體已使用正確的 DNS 區域識別碼。The secondary instance is configured with the correct DNS zone ID. DNS 區域是受管理的執行個體的屬性,其識別碼包含在主機名稱位址。DNS zone is a property of a managed instance and its ID is included in the host name address. 每個 VNet 中建立第一個受管理的執行個體,而且相同的識別碼指派給相同子網路中的所有執行個體時,會產生隨機字串形式區域識別碼。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. 包含在相同的容錯移轉群組中的 managed 執行個體必須共用 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.

升級或降級主要資料庫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.

注意

如果您已在容錯移轉群組設定中建立次要資料庫,則不建議降級次要資料庫。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.

注意

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 Resource Manager API,包括 Azure SQL Database 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 Database 容錯移轉群組Adds one or more databases to an Azure SQL Database failover group

PowerShell:使用受控執行個體管理容錯移轉叢集 (預覽)PowerShell: Managing failover groups with Managed Instances (preview)

安裝最新發行前版本的 PowerShellInstall the newest pre-release version of PowerShell

  1. 將 PowerShellGet 模組更新為 1.6.5 (或最新預覽版本)。Update the PowerShellGet module to 1.6.5 (or newest preview version). 請參閱 PowerShel Preview 網站See PowerShell preview site.

       install-module PowerShellGet -MinimumVersion 1.6.5 -force
    
  2. 在新的 PowerShell 視窗中,執行下列命令:In a new PowerShell window, execute the following commands:

       import-module PowerShellGet
       get-module PowerShellGet #verify version is 1.6.5 (or newer)
       install-module azurerm.sql -RequiredVersion 4.5.0-preview -AllowPrerelease –Force
       import-module azurerm.sql
    

若要建立執行個體容錯移轉群組的 PowerShell 指令程式PowerShell commandlets to create an instance failover group

APIAPI 描述Description
New-AzureRmSqlDatabaseInstanceFailoverGroupNew-AzureRmSqlDatabaseInstanceFailoverGroup 此命令會建立容錯移轉群組,並同時在主要和次要伺服器上註冊This command creates a failover group and registers it on both primary and secondary servers
Set-AzureRmSqlDatabaseInstanceFailoverGroupSet-AzureRmSqlDatabaseInstanceFailoverGroup 修改容錯移轉群組的設定Modifies the configuration of the failover group
Get-AzureRmSqlDatabaseInstanceFailoverGroupGet-AzureRmSqlDatabaseInstanceFailoverGroup 擷取容錯移轉群組設定Retrieves the failover group configuration
Switch-AzureRmSqlDatabaseInstanceFailoverGroupSwitch-AzureRmSqlDatabaseInstanceFailoverGroup 觸發容錯移轉群組的容錯移轉到次要伺服器Triggers failover of the failover group to the secondary server
Remove-AzureRmSqlDatabaseInstanceFailoverGroupRemove-AzureRmSqlDatabaseInstanceFailoverGroup 移除容錯移轉群組Removes a failover group

REST API:使用單一和集區資料庫管理 SQL Database 容錯移轉群組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 (preview)

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