超大規模資料庫的次要複本
適用於： 
Azure SQL 資料庫
如分散式函式架構中所述，Azure SQL Database Hyperscale 有兩種不同類型的計算節點，也稱為複本：
次要複本一律是唯讀狀態，且可以有三種不同類型：
- 高可用性複本
- 異地複本
- 具名複本
每個類型具有不同的結構、功能集、用途和成本。 您可根據所需功能，只使用一種或甚至全部三種類型。 無伺服器和已佈建的計算層都支援次要複本。
如需有關設定和管理超大規模資料庫具名複本的教學課程，請參閱：
高可用性複本
高可用性 (HA) 複本會使用與主要複本相同的頁面伺服器，因此不需複製任何資料來新增 HA 複本。 HA 複本主要是用來提高資料庫可用性；其會作為熱待命複本以進行容錯移轉。 如果無法使用主要複本，則系統會自動且快速地容錯移轉至其中一個現有 HA 複本。 無須變更連接字串；在容錯移轉應用程式期間，可能會因使用中的連線中斷而發生最短停機時間。 針對此案例，建議您如往常般使用適當的重試邏輯。 數個驅動程式已為您提供某種程度的自動重試邏輯。 如果您使用的是 .NET，最新的 Microsoft.Data.SqlClient 程式庫會針對可設定的自動重試邏輯，提供原生完整支援。
HA 複本會使用與主要複本相同的伺服器和資料庫名稱。 其服務等級目標也一律與主要複本相同。 無法從入口網站或任何 API 中，看見或管理作為獨立資源的 HA 複本。
可以有零到四個 HA 複本。 您可以在建立資料庫期間，或在建立資料庫之後，透過一般管理端點和工具 (例如：PowerShell、AZ CLI、入口網站、REST API) 來變更其數目。 建立或移除 HA 複本不會影響主要複本上的使用中連線。
連線至 HA 複本
在超大規模資料庫中，用戶端在連接字串所用的 ApplicationIntent 引數，代表連線是否已路由至讀寫主要複本或唯讀 HA 複本。 如果 ApplicationIntent 設為 ReadOnly，且資料庫沒有次要複本，連線將會路由至主要複本，並預設為 ReadWrite 行為。
-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;
所有 HA 複本在其資源容量中皆相同。 如果有一個以上的 HA 複本，讀取意圖工作負載便會任意散發至所有可用的 HA 複本。 當有多個 HA 複本時，請留意，相對於主要複本的資料變更，每個複本可能具有不同的資料延遲。 針對同一組頁面伺服器上的主要複本，每個 HA 複本會使用與其相同的資料。 不過，每個 HA 複本上的本機資料快取，會反映透過交易記錄服務，所執行的主要複本變更，這會將記錄從主要複本轉送到 HA 複本。 如此一來，視 HA 複本所處理的工作負載而定，記錄的應用程式可能會以不同的速度執行，進而使不同複本可能具有不同的資料延遲 (相對於主要複本)。
具名複本
具名複本如同 HA 複本，會使用與主要複本相同的頁面伺服器。 類似於 HA 複本，您不需複製資料即可新增具名複本。
HA 複本與具名複本之間具有差異：
- 在入口網站和 API (AZ CLI、PowerShell、T-SQL) 呼叫中，具名複本會顯示為一般 (唯讀) Azure SQL 資料庫。
- 具名複本的資料庫名稱可以與主要複本不同，而且可以選擇性位於不同邏輯伺服器 (只要與主要複本位於相同區域即可)。
- 具名複本具有自己的服務等級目標，可獨立於主要複本來進行設定和變更。
- 具名複本最多支援 30 個具名複本 (針對每個主要複本)。
- 具名複本藉由在裝載具名複本的邏輯伺服器上建立不同的登入，以針對每個具名複本支援不同的驗證。
如此一來，具名複本可針對唯讀工作負載的考量，提供多個 HA 複本的優點：
- 如果擴大或縮小主要複本，則連線至具名複本的使用者將不會中斷連線；同時，連線至主要複本的使用者不會因具名複本擴大或縮小而受到影響。
- 在任何複本 (主要或具名) 上執行的工作負載不會因其他複本長時間執行查詢而受到影響。
具名複本的主要目標是啟用各種讀取縮放情節，並改善混合式交易和分析處理 (HTAP) 工作負載。 您可以在這裡找到如何建立這類解決方案的範例：
除了上述所列的主要案例，具名複本也提供彈性，可同時適用許多其他的使用案例：
- 存取隔離：您可以將存取權授與特定具名複本，但不能授與主要複本或其他具名複本。
- 工作負載相依的服務等級目標：當具名複本可具有本身的服務等級目標，便可針對不同的工作負載和使用案例，來使用不同的具名複本。 例如，一個具名複本可提供 Power BI 要求，而另一個則可為資料科學工作的 Apache Spark 提供資料。 每個複本都可具有獨立的服務等級目標，並可獨立調整規模。
- 工作負載相依路由：具有最多 30 個具名複本，可以使用群組中的具名複本，以便讓應用程式與另一個應用程式隔離。 例如，具有四個具名複本的群組，可提供來自行動應用程式的要求，而另一個具有兩個具名複本的群組，則可提供來自 Web 應用程式的要求。 此方法可讓您更精細地微調每個群組的效能和成本。
注意
如需超大規模資料庫具名複本的常見問題，請參閱Azure SQL Database Hyperscale 具名複本的常見問題。
超大規模資料庫具名複本的區域備援。
Azure SQL 資料庫超大規模資料庫具名複本的區域備援會使用 Azure 可用性區域，將具名複本計算節點分散到 Azure 區域內的不同實體位置。 藉由為具名複本選擇區域備援，您可以增強超大規模資料庫所有層級的復原能力，以取得更廣泛的失敗範圍，包括資料中心中斷，而不需要修改應用程式邏輯。 如需詳細資訊，請參閱＜超大規模資料庫區域備援可用性＞。
如需建立區域備援超大規模資料庫具名複本的教學課程，請參閱＜建立超大規模資料庫具名複本＞。
如需疑難排解和測試應用程式錯誤復原功能，請參閱＜測試應用程式錯誤復原＞。
異地複本
使用作用中異地複寫，您可以在相同或不同的 Azure 區域中，建立主要超大規模資料庫的可讀取次要複本。 您必須在不同的邏輯伺服器上建立異地複本。 異地複本的資料庫名稱，一律符合主要複本的資料庫名稱。
建立異地複本時，系統會將主要複本的所有資料，複製到另一組頁面伺服器。 即使異地複本和主要複本位於相同區域，仍不會共用頁面伺服器。 此結構提供異地容錯移轉所需的備援。
異地複本可透過非同步複寫，維護資料庫的交易一致性複本。 如果異地複本位於不同的 Azure 區域，則可在主要區域發生災害或中斷情形時，使用該複本來進行災害復原。 異地複本也可用於地理讀取縮放案例。 自 2022 年 10 月起，支援來自超大規模資料庫異地次要複本的資料庫複本。
超大規模資料庫的異地複寫具有下列目前限制：
- 只能建立一個異地複本 (在相同或不同區域中)。
- 不支援異地複本的還原時間點。
- 不支援建立異地複本的異地複本 (也稱為「異地複本鏈」)。
疑難排解
針對區域備援超大規模資料庫具名複本進行疑難排解
如需疑難排解和測試應用程式錯誤復原功能，請參閱＜測試應用程式錯誤復原＞。
在 PowerShell 和 CLI 中建立區域備援具名複本時，請確定至少有指定一個高可用性複本。 如需範例，請參閱＜建立超大規模資料庫命名複本＞。
- 在 Azure CLI 中，您必須同時指定參數 "ha-replicas" 和 "redundant"。
- 在 PowerShell 中，您必須指定參數 "HighAvailabilityReplicaCount" 和 "ZoneRedundant"。
- 如果省略，您可能會收到錯誤訊息：
(ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.
超大規模資料庫應已啟用區域備援，這是啟用具名複本功能的必要條件。
- 即使主要資料庫已啟用區域備援，還是可以選擇為具名複本啟用區域備援。
- 如果未啟用，您會接收到錯誤訊息：
(DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.
已知問題
從 sys.資料庫傳回部分不正確的資料
在 name 和 database_id 以外的資料行中針對具名複本從 sys.databases 所傳回的資料列值可能會不一致且不正確。 例如，即使已建立具名複本的主要資料庫設為 150，具名複本的 compatibility_level 資料行仍可能會回報為 140。 因應措施是使用 DATABASEPROPERTYEX() 函式，以取得相同且正確的資料 (若適用)。
相關內容
如需有關設定和管理超大規模資料庫具名複本的教學課程，請參閱：
如需詳細資訊，請參閱