使用 SQL Database 彈性集區之應用程式的災害復原策略Disaster recovery strategies for applications using SQL Database elastic pools

多年來,我們已了解雲端服務不是萬無一失的作法,災難性事件還是會發生。Over the years we have learned that cloud services are not foolproof and catastrophic incidents happen. SQL Database 提供許多功能,以在這些事件發生時提供應用程式的商務持續性。SQL Database provides several capabilities to provide for the business continuity of your application when these incidents occur. 彈性集區和單一資料庫支援相同類型的災害復原 (DR) 功能。Elastic pools and single databases support the same kind of disaster recovery (DR) capabilities. 本文說明利用這些 SQL Database 商務持續性功能之彈性集區的數種 DR 策略。This article describes several DR strategies for elastic pools that leverage these SQL Database business continuity features.

本文使用下列標準的 SaaS ISV 應用程式模式︰This article uses the following canonical SaaS ISV application pattern:

現代化雲端型 Web 應用程式會為每位使用者佈建一個 SQL Database。A modern cloud-based web application provisions one SQL database for each end user. ISV 有許多客戶,因此會使用多個資料庫 (稱為租用戶資料庫)。The ISV has many customers and therefore uses many databases, known as tenant databases. 因為租用戶資料庫通常會有無法預測的活動模式,所以 ISV 會使用彈性集區,在一段時間之後,讓資料庫成本預測性變高。Because the tenant databases typically have unpredictable activity patterns, the ISV uses an elastic pool to make the database cost very predictable over extended periods of time. 彈性集區也可在使用者活動尖峰時簡化效能管理。The elastic pool also simplifies the performance management when the user activity spikes. 除了租用戶資料庫之外,應用程式也會使用數個資料庫來管理使用者設定檔、安全性、收集使用模式等。個別租用戶的可用性不會影響整個應用程式的可用性。In addition to the tenant databases the application also uses several databases to manage user profiles, security, collect usage patterns etc. Availability of the individual tenants does not impact the application’s availability as whole. 不過,管理資料庫的可用性和效能對應用程式函數而言十分重要,而且,如果管理資料庫離線,整個應用程式也會離線。However, the availability and performance of management databases is critical for the application’s function and if the management databases are offline the entire application is offline.

本文會討論涵蓋各種案例 (從成本導向創業應用程式以至具有嚴格可用性需求的應用程式) 的 DR 策略。This article discusses DR strategies covering a range of scenarios from cost sensitive startup applications to ones with stringent availability requirements.

注意

如果您目前使用進階或業務關鍵資料庫和彈性集區,您可以將它們轉換成區域備援部署組態,使它們具備區域中斷復原能力。If you are using Premium or Business Critical databases and elastic pools, you can make them resilient to regional outages by converting them to zone redundant deployment configuration. 請參閱區域備援資料庫See Zone-redundant databases.

案例 1.Scenario 1. 成本導向創業Cost sensitive startup

我想要創業,而且成本極為有限。I am a startup business and am extremely cost sensitive. 我想要簡化應用程式的部署和管理,而且我可以為個別客戶提供受限的 SLA。I want to simplify deployment and management of the application and I can have a limited SLA for individual customers. 但是我想要確保整個應用程式絕不會離線。But I want to ensure the application as a whole is never offline.

若要滿足簡單性需求,請將所有租用戶資料庫部署到您所選擇 Azure 區域中的單一彈性集區,並將管理資料庫部署為異地複寫的單一資料庫。To satisfy the simplicity requirement, deploy all tenant databases into one elastic pool in the Azure region of your choice and deploy management databases as geo-replicated single databases. 對於租用戶的災害復原,請使用異地還原,這不需要額外成本。For the disaster recovery of tenants, use geo-restore, which comes at no additional cost. 若要確保管理資料庫的可用性,請使用自動容錯移轉群組將它們異地複寫到另一個區域 (步驟 1)。To ensure the availability of the management databases, geo-replicate them to another region using an auto-failover group (step 1). 此案例中災害復原組態的持續成本等於次要資料庫的總成本。The ongoing cost of the disaster recovery configuration in this scenario is equal to the total cost of the secondary databases. 下圖說明此組態。This configuration is illustrated on the next diagram.

圖 1

如果主要區域中斷,下圖說明讓您的應用程式上線的復原步驟。If an outage occurs in the primary region, the recovery steps to bring your application online are illustrated by the next diagram.

  • 容錯移轉群組開始將管理資料庫自動容錯移轉到 DR 區域。The failover group initiates automatic failover of the management database to the DR region. 應用程式會自動重新連線到新的主要區域,並且會在 DR 區域中建立所有新的帳戶和租用戶資料庫。The application is automatically reconnected to the new primary and all new accounts and tenant databases are created in the DR region. 現有的客戶會看到其資料暫時無法使用。The existing customers see their data temporarily unavailable.
  • 使用與原始集區 (2) 相同的組態來建立彈性集區。Create the elastic pool with the same configuration as the original pool (2).
  • 使用異地還原來建立租用戶資料庫 (3) 的複本。Use geo-restore to create copies of the tenant databases (3). 您可以考慮透過使用者連接來觸發個別還原,或使用某個其他應用程式特有的優先順序配置。You can consider triggering the individual restores by the end-user connections or use some other application-specific priority scheme.

您的應用程式目前在 DR 區域中已重新上線,但有些客戶在存取其資料時會經歷到延遲。At this point your application is back online in the DR region, but some customers experience delay when accessing their data.

圖 2

如果服務是暫時中斷,則在 DR 區域完成所有資料庫還原之前,Azure 可能已復原主要區域。If the outage was temporary, it is possible that the primary region is recovered by Azure before all the database restores are complete in the DR region. 在此情況下,請安排將應用程式移回主要區域。In this case, orchestrate moving the application back to the primary region. 此程序會採取下圖上所說明的步驟。The process takes the steps illustrated on the next diagram.

  • 取消所有未處理的異地還原要求。Cancel all outstanding geo-restore requests.
  • 將管理資料庫容錯移轉到主要區域 (5)。Fail over the management databases to the primary region (5). 復原區域之後,舊的主要已自動成為次要。After the region’s recovery, the old primaries have automatically become secondaries. 現在,它們會再次切換角色。Now they switch roles again.
  • 變更應用程式的連接字串,使其重新指向主要區域。Change the application's connection string to point back to the primary region. 現在,系統會在主要區域中建立所有新的帳戶和租用戶資料庫。Now all new accounts and tenant databases are created in the primary region. 部分現有客戶會發現其資料暫時無法使用。Some existing customers see their data temporarily unavailable.
  • 請將 DR 集區中的所有資料庫都設定為唯讀,確保在 DR 區域 (6) 中無法修改它們。Set all databases in the DR pool to read-only to ensure they cannot be modified in the DR region (6).
  • 對於已在復原後變更之 DR 集區中的每個資料庫,重新命名或刪除主要集區 (7) 中的對應資料庫。For each database in the DR pool that has changed since the recovery, rename or delete the corresponding databases in the primary pool (7).
  • 將更新的資料庫從 DR 集區複製到主要集區 (8)。Copy the updated databases from the DR pool to the primary pool (8).
  • 刪除 DR 集區 (9)Delete the DR pool (9)

您的應用程式目前在具有主要集區中所有可用租用戶資料庫的主要區域中已上線。At this point your application is online in the primary region with all tenant databases available in the primary pool.

圖 3

這項策略的重要 優點 是資料層備援的持續成本很低。The key benefit of this strategy is low ongoing cost for data tier redundancy. SQL Database 服務會自動執行備份,而且不需要進行任何應用程式重寫,也不需要額外的成本。Backups are taken automatically by the SQL Database service with no application rewrite and at no additional cost. 只有在還原彈性資料庫時,才會產生成本。The cost is incurred only when the elastic databases are restored. 取捨在於所有租用戶資料庫的完整復原需要很長的時間。The trade-off is that the complete recovery of all tenant databases takes significant time. 時間長短取決於您在 DR 區域中起始的總還原次數,和租用戶資料庫的整體大小。The length of time depends on the total number of restores you initiate in the DR region and overall size of the tenant databases. 即使您將某些租用戶還原的優先順序設地高於其他還原,還是會與在相同區域中起始的所有其他還原競爭,因為服務將會進行仲裁和節流,以將對現有客戶資料庫的整體影響降到最低。Even if you prioritize some tenants' restores over others, you are competing with all the other restores that are initiated in the same region as the service arbitrates and throttles to minimize the overall impact on the existing customers' databases. 此外,除非在 DR 區域中建立新的彈性集區,否則無法啟動租用戶資料庫的復原。In addition, the recovery of the tenant databases cannot start until the new elastic pool in the DR region is created.

案例 2.Scenario 2. 具有分層服務的成熟應用程式Mature application with tiered service

我已熟悉試用版客戶和付費客戶具有分層服務供應項目和不同 SLA 的 SaaS 應用程式。I am a mature SaaS application with tiered service offers and different SLAs for trial customers and for paying customers. 對於試用版客戶,我必須盡可能降低成本。For the trial customers, I have to reduce the cost as much as possible. 試用版客戶可能需要停機時間,但我想要減少其可能性。Trial customers can take downtime but I want to reduce its likelihood. 對於付費客戶,任何停機時間都是風險。For the paying customers, any downtime is a flight risk. 因此,我想要確定付費客戶一律可以存取其資料。So I want to make sure that paying customers are always able to access their data.

若要支援此案例,請將試用版租用戶與付費租用戶分開,方法是將它們放入個別的彈性集區中。To support this scenario, separate the trial tenants from paid tenants by putting them into separate elastic pools. 試用版客戶的每個租用戶的 eDTU 或虛擬核心較低,SLA 也因復原時間較長而較低。The trial customers have lower eDTU or vCores per tenant and lower SLA with a longer recovery time. 付費客戶所在集區中每個租用戶的 eDTU 或虛擬核心和 SLA 都較高。The paying customers are in a pool with higher eDTU or vCores per tenant and a higher SLA. 為了保證最低的復原時間,我們會對付費客戶的租用戶資料庫進行異地複寫。To guarantee the lowest recovery time, the paying customers' tenant databases are geo-replicated. 下圖說明此組態。This configuration is illustrated on the next diagram.

圖 4

與第一個案例相同,管理資料庫會相當活躍,因此針對它使用單一異地複寫的資料庫 (1)。As in the first scenario, the management databases are quite active so you use a single geo-replicated database for it (1). 這可確保新客戶訂用帳戶、設定檔更新和其他管理作業的可預測效能。This ensures the predictable performance for new customer subscriptions, profile updates, and other management operations. 主要管理資料庫複本所在區域是主要區域,而次要管理資料庫複本所在區域是 DR 區域。The region in which the primaries of the management databases reside is the primary region and the region in which the secondaries of the management databases reside is the DR region.

在主要區域中所佈建的「付費」集區中,付費客戶的租用戶資料庫會有使用中資料庫。The paying customers’ tenant databases have active databases in the “paid” pool provisioned in the primary region. 在 DR 區域中佈建同名的次要集區。Provision a secondary pool with the same name in the DR region. 每個租用戶都會異地複寫到次要集區 (2)。Each tenant is geo-replicated to the secondary pool (2). 這會使用容錯移轉來快速復原所有租用戶資料庫。This enables quick recovery of all tenant databases using failover.

如果主要區域中斷,下圖說明讓您的應用程式上線的復原步驟:If an outage occurs in the primary region, the recovery steps to bring your application online are illustrated in the next diagram:

圖 5

  • 將管理資料庫立即容錯移轉到 DR 區域 (3)。Immediately fail over the management databases to the DR region (3).
  • 變更應用程式的連接字串,使其指向 DR 區域。Change the application’s connection string to point to the DR region. 現在,系統會在 DR 區域中建立所有新的帳戶和租用戶資料庫。Now all new accounts and tenant databases are created in the DR region. 現有試用版客戶會發現其資料暫時無法使用。The existing trial customers see their data temporarily unavailable.
  • 將付費租用戶的資料庫容錯移轉到 DR 區域中的集區,以立即還原其可用性 (4)。Fail over the paid tenant's databases to the pool in the DR region to immediately restore their availability (4). 因為容錯移轉是快速中繼資料層級變更,請考慮透過使用者連接來依需要觸發個別容錯移轉的最佳化。Since the failover is a quick metadata level change, consider an optimization where the individual failovers are triggered on demand by the end-user connections.
  • 如果因為次要資料庫在仍是次要複本時只需要擁有處理變更記錄的容量,而造成次要集區 eDTU 或虛擬核心值大小低於主要集區,請立即增加集區容量來容納所有租用戶 (5) 的完整工作負載。If your secondary pool eDTU size or vCore value was lower than the primary because the secondary databases only required the capacity to process the change logs while they were secondaries, immediately increase the pool capacity now to accommodate the full workload of all tenants (5).
  • 使用試用版客戶資料庫 (6) 之 DR 區域中的相同名稱和組態,建立新的彈性集區。Create the new elastic pool with the same name and the same configuration in the DR region for the trial customers' databases (6).
  • 建立試用版客戶的集區之後,請使用異地還原,將個別試用版租用戶資料庫還原到新的集區 (7)。Once the trial customers’ pool is created, use geo-restore to restore the individual trial tenant databases into the new pool (7). 請考慮透過使用者連接來觸發個別還原,或使用某個其他應用程式特有的優先順序配置。Consider triggering the individual restores by the end-user connections or use some other application-specific priority scheme.

您的應用程式目前在 DR 區域中重新上線。At this point your application is back online in the DR region. 所有付費客戶都可以存取其資料,而試用版客戶在存取其資料時會經歷到延遲。All paying customers have access to their data while the trial customers experience delay when accessing their data.

當 Azure 在您於 DR 區域中還原應用程式「之後」 復原主要區域時,您可以繼續在該區域中執行應用程式,也可以決定容錯回復到主要區域。When the primary region is recovered by Azure after you have restored the application in the DR region you can continue running the application in that region or you can decide to fail back to the primary region. 如果在完成容錯移轉程序「之前」復原主要區域,請考慮立即容錯回復。If the primary region is recovered before the failover process is completed, consider failing back right away. 此容錯回復會採取下圖中所說明的步驟:The failback takes the steps illustrated in the next diagram:

圖 6

  • 取消所有未處理的異地還原要求。Cancel all outstanding geo-restore requests.
  • 容錯移轉管理資料庫 (8)。Fail over the management databases (8). 復原區域之後,舊的主要已自動成為次要。After the region’s recovery, the old primary automatically become the secondary. 現在,它再次變成主要。Now it becomes the primary again.
  • 容錯移轉付費租用戶資料庫 (9)。Fail over the paid tenant databases (9). 同樣地,復原區域之後,舊的主要會自動成為次要。Similarly, after the region’s recovery, the old primaries automatically become the secondaries. 現在,它們再次變成主要。Now they become the primaries again.
  • 將 DR 區域中變更的已還原試用版資料庫設定為唯讀 (10)。Set the restored trial databases that have changed in the DR region to read-only (10).
  • 對於已在復原後變更之試用版客戶 DR 集區中的每個資料庫,重新命名或刪除試用版客戶主要集區 (11) 中的對應資料庫。For each database in the trial customers DR pool that changed since the recovery, rename or delete the corresponding database in the trial customers primary pool (11).
  • 將更新的資料庫從 DR 集區複製到主要集區 (12)。Copy the updated databases from the DR pool to the primary pool (12).
  • 刪除 DR 集區 (13)。Delete the DR pool (13).

注意

容錯移轉作業是非同步的。The failover operation is asynchronous. 若要將復原時間降到最低,請務必以至少 20 個資料庫的批次執行租用戶資料庫的容錯移轉命令。To minimize the recovery time it is important that you execute the tenant databases' failover command in batches of at least 20 databases.

這項策略的重要 優點 在於它可為付費客戶提供最高的 SLA。The key benefit of this strategy is that it provides the highest SLA for the paying customers. 它也保證會在建立試用版 DR 集區時,立即將新的試用版解除封鎖。It also guarantees that the new trials are unblocked as soon as the trial DR pool is created. 取捨在於因付費客戶的次要 DR 集區的成本,此設定會增加租用戶資料庫的總成本。The trade-off is that this setup increases the total cost of the tenant databases by the cost of the secondary DR pool for paid customers. 此外,如果次要集區的大小不同,則除非完成 DR 區域中的集區升級,否則付費客戶的效能在容錯移轉之後會較低。In addition, if the secondary pool has a different size, the paying customers experience lower performance after failover until the pool upgrade in the DR region is completed.

案例 3.Scenario 3. 具有分層服務的分散式應用程式Geographically distributed application with tiered service

我已有完善且提供分層服務的 SaaS 應用程式。I have a mature SaaS application with tiered service offers. 我想要將非常積極的 SLA 提供給付費客戶,並在中斷時將影響風險降到最低,因為即使是短暫中斷也可能造成客戶不滿。I want to offer a very aggressive SLA to my paid customers and minimize the risk of impact when outages occur because even brief interruption can cause customer dissatisfaction. 付費客戶務必一律可以存取其資料。It is critical that the paying customers can always access their data. 試用版是免費的,而且在試用期間未提供 SLA。The trials are free and an SLA is not offered during the trial period.

若要支援這種情況,請使用三個不同的彈性集區。To support this scenario, use three separate elastic pools. 將大小相同且每個資料庫都具有高 eDTU 或虛擬核心的兩個集區佈建到兩個不同的區域,以包含付費客戶的租用戶資料庫。Provision two equal size pools with high eDTUs or vCores per database in two different regions to contain the paid customers' tenant databases. 包含試用版租用戶的第三個集區可在每個資料庫具有較低 eDTU 或虛擬核心,並佈建到兩個區域中的其中一個。The third pool containing the trial tenants can have lower eDTUs or vCores per database and be provisioned in one of the two regions.

為了保證中斷期間的最低復原時間,我們會在這兩個區域使用 50% 的主要資料庫來異地複寫付費客戶的租用戶資料庫。To guarantee the lowest recovery time during outages, the paying customers' tenant databases are geo-replicated with 50% of the primary databases in each of the two regions. 同樣地,每個區域都有 50% 的次要資料庫。Similarly, each region has 50% of the secondary databases. 因此,如果區域離線,則只會影響 50% 的付費客戶資料庫,且只須對這個部分進行容錯移轉。This way, if a region is offline, only 50% of the paid customers' databases are impacted and have to fail over. 其他資料庫會保持不變。The other databases remain intact. 下圖說明此組態:This configuration is illustrated in the following diagram:

圖 4

與先前的案例相同,管理資料庫會相當活躍,因此請將它們設定為單一異地複寫的資料庫 (1)。As in the previous scenarios, the management databases are quite active so configure them as single geo-replicated databases (1). 這可確保新客戶訂用帳戶、設定檔更新和其他管理作業的可預測效能。This ensures the predictable performance of the new customer subscriptions, profile updates and other management operations. 區域 A 是管理資料庫的主要區域,而區域 B 會用於復原管理資料庫。Region A is the primary region for the management databases and the region B is used for recovery of the management databases.

付費客戶的租用戶資料庫會也會一併異地複寫,但在區域 A 與區域 B (2) 之間有分割的主要複本和次要複本。The paying customers’ tenant databases are also geo-replicated but with primaries and secondaries split between region A and region B (2). 因此,中斷所影響的租用戶主要資料庫可以容錯移轉到其他區域,並變成可用。This way, the tenant primary databases impacted by the outage can fail over to the other region and become available. 完全不會影響另一半的租用戶資料庫。The other half of the tenant databases are not be impacted at all.

下圖說明在區域 A 中斷時要採取的復原步驟。The next diagram illustrates the recovery steps to take if an outage occurs in region A.

圖 5

  • 將管理資料庫立即容錯移轉到區域 B (3)。Immediately fail over the management databases to region B (3).
  • 變更應用程式的連接字串以指向區域 B 中的管理資料庫。修改管理資料庫,確定系統是在區域 B 中建立新的帳戶和租用戶資料庫,而且在這裡也有發現現有的租用戶資料庫。Change the application’s connection string to point to the management databases in region B. Modify the management databases to make sure the new accounts and tenant databases are created in region B and the existing tenant databases are found there as well. 現有試用版客戶會發現其資料暫時無法使用。The existing trial customers see their data temporarily unavailable.
  • 將付費租用戶的資料庫容錯移轉到區域 B 中的集區 2,以立即還原其可用性 (4)。Fail over the paid tenant's databases to pool 2 in region B to immediately restore their availability (4). 因為容錯移轉是快速中繼資料層級變更,所以您可以考慮透過使用者連接來依需要觸發個別容錯移轉的最佳化。Since the failover is a quick metadata level change, you may consider an optimization where the individual failovers are triggered on demand by the end-user connections.
  • 現在,因為集區 2 只包含主要資料庫,所以集區中的總工作負載會增加,而且可以立即增加其 eDTU 大小 (5) 或虛擬核心數量。Since now pool 2 contains only primary databases, the total workload in the pool increases and can immediately increase its eDTU size (5) or number of vCores.
  • 使用試用版客戶資料庫 (6) 之區域 B 中的相同名稱和組態,建立新的彈性集區。Create the new elastic pool with the same name and the same configuration in the region B for the trial customers' databases (6).
  • 建立集區之後,請使用異地還原,將個別試用版租用戶資料庫還原到集區 (7)。Once the pool is created use geo-restore to restore the individual trial tenant database into the pool (7). 您可以考慮透過使用者連接來觸發個別還原,或使用某個其他應用程式特有的優先順序配置。You can consider triggering the individual restores by the end-user connections or use some other application-specific priority scheme.

注意

容錯移轉作業是非同步的。The failover operation is asynchronous. 若要將復原時間降到最低,請務必以至少 20 個資料庫的批次執行租用戶資料庫的容錯移轉命令。To minimize the recovery time, it is important that you execute the tenant databases' failover command in batches of at least 20 databases.

您的應用程式目前在區域 B 中已重新上線。所有付費客戶都可以存取其資料,而試用版客戶在存取其資料時會經歷到延遲。At this point your application is back online in region B. All paying customers have access to their data while the trial customers experience delay when accessing their data.

復原區域 A 時,您需要決定是否要將區域 B 用於試用版客戶或容錯回復到使用區域 A 中的試用版客戶集區。其中一個準則可能是在復原後修改多少百分比的試用版租用戶資料庫。When region A is recovered you need to decide if you want to use region B for trial customers or failback to using the trial customers pool in region A. One criteria could be the % of trial tenant databases modified since the recovery. 不論決策為何,您都必須重新平衡兩個集區之間的付費租用戶。Regardless of that decision, you need to re-balance the paid tenants between two pools. 下圖說明當試用版租用戶資料庫容錯回復至區域 A 時的程序。the next diagram illustrates the process when the trial tenant databases fail back to region A.

圖 6

  • 取消試用版 DR 集區的所有未處理異地還原要求。Cancel all outstanding geo-restore requests to trial DR pool.
  • 容錯移轉管理資料庫 (8)。Fail over the management database (8). 復原區域之後,舊的主要已自動成為次要。After the region’s recovery, the old primary automatically became the secondary. 現在,它再次變成主要。Now it becomes the primary again.
  • 選取哪些付費租用戶資料庫要容錯回復到集區 1,以及起始容錯移轉到其次要 (9)。Select which paid tenant databases fail back to pool 1 and initiate failover to their secondaries (9). 復原區域之後,集區 1 中的所有資料庫都已自動成為次要。After the region’s recovery, all databases in pool 1 automatically became secondaries. 現在,其中的 50% 會再次變成主要。Now 50% of them become primaries again.
  • 將集區 2 的大小減少為原始 eDTU (10) 或虛擬核心數量。Reduce the size of pool 2 to the original eDTU (10) or number of vCores.
  • 將區域 B 中的所有已還原試用版資料庫設定為唯讀 (11)。Set all restored trial databases in the region B to read-only (11).
  • 對於已在復原後變更之試用版 DR 集區中的每個資料庫,重新命名或刪除試用版主要集區 (12) 中的對應資料庫。For each database in the trial DR pool that has changed since the recovery, rename or delete the corresponding database in the trial primary pool (12).
  • 將更新的資料庫從 DR 集區複製到主要集區 (13)。Copy the updated databases from the DR pool to the primary pool (13).
  • 刪除 DR 集區 (14)。Delete the DR pool (14).

這項策略的重要 優點 如下:The key benefits of this strategy are:

  • 它支援付費客戶的最積極 SLA,因為這樣可確保中斷不會影響 50% 以上的租用戶資料庫。It supports the most aggressive SLA for the paying customers because it ensures that an outage cannot impact more than 50% of the tenant databases.
  • 它保證在復原期間建立試用版 DR 集區時,立即將新的試用版解除封鎖。It guarantees that the new trials are unblocked as soon as the trail DR pool is created during the recovery.
  • 它允許更有效率地使用集區容量,因為集區 1 和集區 2 中 50% 的次要資料庫比主要資料庫還不活躍。It allows more efficient use of the pool capacity as 50% of secondary databases in pool 1 and pool 2 are guaranteed to be less active than the primary databases.

主要 取捨 如下:The main trade-offs are:

  • 對於連接到區域 A 的使用者,其管理資料庫的 CRUD 作業的延遲低於連接到區域 B 的使用者,因為它們是針對管理資料庫的主要來執行。The CRUD operations against the management databases have lower latency for the end users connected to region A than for the end users connected to region B as they are executed against the primary of the management databases.
  • 需要更複雜的管理資料庫設計。It requires more complex design of the management database. 例如,每個租用戶記錄都具有必須在容錯移轉和容錯回復期間變更的位置標記。For example, each tenant record has a location tag that needs to be changed during failover and failback.
  • 除非完成區域 B 中的集區升級,否則付費客戶的效能可能會低於正常情況。The paying customers may experience lower performance than usual until the pool upgrade in region B is completed.

總結Summary

本文著重於SaaS ISV 多租用戶應用程式所使用之資料庫層的災害復原策略。This article focuses on the disaster recovery strategies for the database tier used by a SaaS ISV multi-tenant application. 要選擇哪個策略請根據應用程式的需求 (例如商務模型、您想提供給客戶的 SLA、預算限制等等)。每個所述的策略都會概述優缺點,因此您可以做出明智的決定。The strategy you choose is based on the needs of the application, such as the business model, the SLA you want to offer to your customers, budget constraint etc. Each described strategy outlines the benefits and trade-off so you could make an informed decision. 此外,特定應用程式可能包含其他 Azure 元件。Also, your specific application likely includes other Azure components. 所以您必須檢閱其商務持續性指引,並安排使用元件來復原資料庫層。So you review their business continuity guidance and orchestrate the recovery of the database tier with them. 若要深入了解如何管理 Azure 中資料庫應用程式的復原,請參閱設計災害復原的雲端解決方案To learn more about managing recovery of database applications in Azure, refer to Designing cloud solutions for disaster recovery.

後續步驟Next steps