本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Amazon DocumentDB 高可用性和複寫 您可以使用複本執行個體，在 Amazon DocumentDB 中實現高可用性和讀取擴展 （與 MongoDB 相容）。單一 Amazon DocumentDB 叢集支援單一主要執行個體和最多 15 個複本執行個體。這些執行個體可以分佈在叢集區域內的可用區域之中。主要執行個體接受讀取和寫入流量，而複寫執行個體僅接受讀取請求。 叢集磁碟區是由叢集的多個資料複本組成。不過，叢集磁碟區中的資料會以單一邏輯磁碟區表示，以做為主要執行個體和叢集中的 Amazon DocumentDB 複本。複本執行個體是最終一致性 它們會透過最低複寫延遲 (通常在主要執行個體寫入更新後短於 100 毫秒) 來傳回查詢結果。複本延遲會根據資料庫變更率而有所不同。也就是，在資料庫發生大量寫入操作期間，您可能會發現複本延遲增加。 ## 讀取擴展 Amazon DocumentDB 複本非常適合用於讀取擴展，因為它們完全專用於叢集磁碟區上的讀取操作。寫入操作由主要執行個體管理。叢集中的所有執行個體將共用叢集磁碟區。因此，您不需要複寫和維護每個 Amazon DocumentDB 複本的資料副本。 ## 高可用性 當您建立 Amazon DocumentDB 叢集時，取決於子網路群組中的可用區域數量 （必須至少有兩個），Amazon DocumentDB 會在可用區域中佈建執行個體。當您在叢集中建立執行個體時，Amazon DocumentDB 會自動將執行個體分散到子網路群組中的可用區域，以平衡叢集。這個動作還可防止所有執行個體位於相同的可用區域。 **範例** 為說明要點，假設我們建立含有一個子網路群組，且該子網路群組有三個可用區域 (*AZ1*、*AZ2* 和 *AZ3*) 的叢集。 當叢集的第一個執行個體建立完成後，其為主執行個體，且位於其中一個可用區域。在此範例中，其位於 *AZ1*。建立的第二個執行個體為複本執行個體，其位於另外兩個可用區域其中之一，假設為 *AZ2*。建立的第三個執行個體為複本執行個體，其位於剩餘的可用區域，即 *AZ3*。如果您建立多個執行個體，它們會分佈在可用區域之中，讓您可在叢集中達到平衡。 如果故障發生在主執行個體 (AZ1)，將觸發容錯移轉，且其中一個現有的複本會提升至主要執行個體。當舊的主要執行個體恢復時，它會在佈建 (AZ1) 的相同可用區域中成為複本。當您佈建三執行個體叢集時，Amazon DocumentDB 會繼續保留該三執行個體叢集。Amazon DocumentDB 會自動處理執行個體故障的偵測、容錯移轉和復原，無需任何手動介入。 當 Amazon DocumentDB 執行容錯移轉並復原執行個體時，復原的執行個體會保留在原始佈建的可用區域中。不過，執行個體角色可能從主要變更為複本。這樣做可防止一連串的容錯移轉導致所有執行個體出現在同一個可用區域內。 您可以指定 Amazon DocumentDB 複本做為容錯移轉目標。也就是說，如果主要執行個體失敗，則從層指定的 Amazon DocumentDB 複本或複本會提升為主要執行個體。在對主要執行個體提出的讀取和寫入請求由於例外狀況而失敗的期間，會發生短暫的中斷。如果您的 Amazon DocumentDB 叢集不包含任何 Amazon DocumentDB 複本，當主要執行個體失敗時，會重新建立。提升 Amazon DocumentDB 複本比重新建立主要執行個體快得多。 對於高可用性案例，我們建議您建立一或多個 Amazon DocumentDB 複本。這些複本應與主要執行個體相同，且位於 Amazon DocumentDB 叢集的不同可用區域中。 如需詳細資訊，請參閱下列內容： + [了解 Amazon DocumentDB 叢集容錯能力](db-cluster-fault-tolerance.md) + [Amazon DocumentDB 容錯移轉](failover.md) + [控制容錯移轉目標](failover.md#failover-target_control) ### 全球叢集的高可用性 若要在多個叢集之間實現高可用性 AWS 區域，您可以設定 [Amazon DocumentDB 全域叢集](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html)。每個全域叢集橫跨多個區域，可實現低延遲的全域讀取，並從 中斷中復原災難 AWS 區域。Amazon DocumentDB 會自動處理從主要區域複寫所有資料和更新到每個次要區域。 ## 新增 複本 叢集中新增的第一個執行個體即為主要執行個體。在第一個執行個體後新增的每個執行個體即為複寫執行個體。除了主要執行個體之外，叢集最多可以有 15 個複本執行個體。 當您使用 建立叢集時 AWS 管理主控台，會自動同時建立主要執行個體。若要在您建立叢集和主要執行個體的同時建立複本，請選擇 **Create replica in different zone (在不同區域中建立複本)**。如需詳細資訊，請參閱 [建立 Amazon DocumentDB 叢集](db-cluster-create.md) 中的步驟 4.d。若要將更多複本新增至 Amazon DocumentDB 叢集，請參閱 [將 Amazon DocumentDB 執行個體新增至叢集](db-instance-add.md)。 使用 AWS CLI 建立叢集時，您必須明確建立主要執行個體和複本執行個體。如需詳細資訊，請參閱下列主題中的「使用 AWS CLI」一節： + [建立 Amazon DocumentDB 叢集](db-cluster-create.md) + [將 Amazon DocumentDB 執行個體新增至叢集](db-instance-add.md) # Amazon DocumentDB 容錯移轉 在某些情況下，例如特定類型的計劃維護，或在不太可能發生主節點或可用區域故障的情況下，Amazon DocumentDB （具有 MongoDB 相容性） 會偵測故障並取代主節點。容錯移轉期間，寫入時間會降至最低。這是因為主要節點的角色會容錯移轉至其中一個僅供讀取複本，而非必須建立並佈建新的主要節點。此故障偵測及複本提升可確保您能在提升完成時立即繼續寫入新的主要節點。 若要容錯移轉至 運作，您的叢集必須至少有兩個執行個體：主要執行個體和至少一個複本執行個體。 **注意** 本主題僅適用於原始 Amazon DocumentDB 執行個體型叢集。它不適用於彈性或全域叢集。 ## 控制容錯移轉目標 Amazon DocumentDB 為您提供容錯移轉層，作為控制發生容錯移轉時，哪些複本執行個體會提升為主要執行個體的方法。 **容錯移轉方案** 每個複本執行個體都與容錯移轉層 (0–15) 相關聯。當由於維護或不太可能的硬體故障而發生容錯移轉時，主要執行個體會容錯移轉至具有最高優先順序 （最低編號層） 的複本。如果多個複本具有相同的優先順序層，則主要 會容錯移轉到該層的複本，該複本的大小最接近先前的主要複本。 選擇一組複本，並將其容錯移轉方案設定為 `0` (最高優先順序)，就可以確保容錯移轉會提升到該群組的其中一個複本。為複本指派低優先順序方案 (數字較大)，就可以有效防止容錯移轉發生時，將特定複本提升成主要執行個體。這在特定複本接收來自應用程式的繁重使用情形時非常有用，容錯移轉至這些複本的其中一個將會對關鍵應用程式造成負面影響。 您可以在建立執行個體時設定容錯移轉方案，或在稍後進行修改。藉由修改執行個體來設定執行個體容錯移轉方案，並不會觸發容錯移轉。如需詳細資訊，請參閱下列主題： + [將 Amazon DocumentDB 執行個體新增至叢集](db-instance-add.md) + [修改 Amazon DocumentDB 執行個體](db-instance-modify.md) 手動啟動容錯移轉時，您有兩種方式來控制要將哪個執行個體複本提升為主要執行個體：透過前面所述的容錯移轉方案和 `--target-db-instance-identifier` 參數。 **--`target-db-instance-identifier`** 若要進行測試，您可以使用 `failover-db-cluster` 操作強制容錯移轉事件發生。您可以使用 `--target-db-instance-identifier` 參數來指定將哪些複本提升成主要執行個體。使用 `--target-db-instance-identifier` 參數會取代容錯移轉優先順序方案。如果您未指定 `--target-db-instance-identifier` 參數，主要容錯移轉會根據容錯移轉優先順序方案。 ## 容錯移轉期間會發生什麼情況 Amazon DocumentDB 會自動處理容錯移轉，讓您的應用程式可以盡快恢復資料庫操作，而無需管理介入。 + 如果容錯移轉時，在相同或不同的可用區域中有 Amazon DocumentDB 複本執行個體：Amazon DocumentDB 會翻轉執行個體的正式名稱記錄 (CNAME)，以指向運作狀態良好的複本，進而提升為新的主要複本。容錯移轉從開始到結束通常可在 30 秒內完成。 + 如果您沒有 Amazon DocumentDB 複本執行個體 （例如單一執行個體叢集）：Amazon DocumentDB 會嘗試在與原始執行個體相同的可用區域中建立新的執行個體。已盡力進行這種原始執行個體的取代操作，但可能不成功，例如，在出現會廣泛影響可用區域的問題時。 您的應用程式應該會在發生連線中斷時重試資料庫連線。 ## 測試容錯移轉 叢集的容錯移轉會將叢集中的其中一個 Amazon DocumentDB 複本 （唯讀執行個體） 提升為主要執行個體 （叢集寫入器）。 當主要執行個體失敗時，如果存在 Amazon DocumentDB 複本，Amazon DocumentDB 會自動容錯移轉至 Amazon DocumentDB 複本。當您想要模擬主要執行個體故障以進行測試時，可以強制容錯移轉。叢集中的每個執行個體都有自己的端點地址。因此，當容錯移轉完成時，您需要清除和重新建立任何使用這些端點地址的現有連線。 若要強制容錯移轉，請搭配這些參數使用 `failover-db-cluster` 操作。 + `--db-cluster-identifier` - 必要項目。要容錯移轉之叢集的名稱。 + `--target-db-instance-identifier`- 選用。要提升為主要執行個體之執行個體的名稱。 **Example** 以下操作會強制容錯移轉 `sample-cluster` 叢集。它不會指定要讓哪個執行個體成為新的主要執行個體，因此 Amazon DocumentDB 會根據容錯移轉層優先順序選擇執行個體。 若為 Linux、macOS 或 Unix： ``` aws docdb failover-db-cluster \ --db-cluster-identifier sample-cluster ``` 針對 Windows： ``` aws docdb failover-db-cluster ^ --db-cluster-identifier sample-cluster ``` 以下操作會強制容錯移轉 `sample-cluster` 叢集，指定 `sample-cluster-instance` 為要提升的主要角色。(請注意輸出中的 `"IsClusterWriter": true`。) 若為 Linux、macOS 或 Unix： ``` aws docdb failover-db-cluster \ --db-cluster-identifier sample-cluster \ --target-db-instance-identifier sample-cluster-instance ``` 針對 Windows： ``` aws docdb failover-db-cluster ^ --db-cluster-identifier sample-cluster ^ --target-db-instance-identifier sample-cluster-instance ``` 此操作的輸出將會如下所示 (JSON 格式)。 ``` { "DBCluster": { "HostedZoneId": "Z2SUY0A1719RZT", "Port": 27017, "EngineVersion": "3.6.0", "PreferredMaintenanceWindow": "thu:04:05-thu:04:35", "BackupRetentionPeriod": 1, "ClusterCreateTime": "2018-06-28T18:53:29.455Z", "AssociatedRoles": [], "DBSubnetGroup": "default", "MasterUsername": "master-user", "Engine": "docdb", "ReadReplicaIdentifiers": [], "EarliestRestorableTime": "2018-08-21T00:04:10.546Z", "DBClusterIdentifier": "sample-cluster", "ReaderEndpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com", "DBClusterMembers": [ { "DBInstanceIdentifier": "sample-cluster-instance", "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1, "IsClusterWriter": true }, { "DBInstanceIdentifier": "sample-cluster-instance-00", "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1, "IsClusterWriter": false }, { "DBInstanceIdentifier": "sample-cluster-instance-01", "DBClusterParameterGroupStatus": "in-sync", "PromotionTier": 1, "IsClusterWriter": false } ], "AvailabilityZones": [ "us-east-1b", "us-east-1c", "us-east-1a" ], "DBClusterParameterGroup": "default.docdb3.6", "Endpoint": "sample-cluster.node.us-east-1.docdb.amazonaws.com", "IAMDatabaseAuthenticationEnabled": false, "AllocatedStorage": 1, "LatestRestorableTime": "2018-08-22T21:57:33.904Z", "PreferredBackupWindow": "00:00-00:30", "StorageEncrypted": false, "MultiAZ": true, "Status": "available", "DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:sample-cluster", "VpcSecurityGroups": [ { "Status": "active", "VpcSecurityGroupId": "sg-12345678" } ], "DbClusterResourceId": "cluster-ABCDEFGHIJKLMNOPQRSTUVWXYZ" } } ``` ## 複寫延遲 複寫延遲通常為 50 毫秒或更短。複本延遲增加的最常見原因是： + 主要 上的高寫入速率，會導致僅供讀取複本落後主要複本。 + 長時間執行查詢 （例如，大型循序掃描、彙總查詢） 和傳入寫入複寫之間的僅供讀取複本上的爭用。 + 僅供讀取複本上非常大量的並行查詢。 若要將複寫延遲降至最低，請嘗試下列疑難排解技巧： + 如果您有高寫入率或高 CPU 使用率，建議您擴展叢集中的執行個體。 + 如果您的僅供讀取複本上有長時間執行的查詢，而且非常頻繁地更新正在查詢的文件，請考慮變更長時間執行的查詢，或針對主要/寫入複本執行查詢，以避免僅供讀取複本發生爭用。 + 如果僅供讀取複本上有非常大量的並行查詢或高 CPU 使用率，則另一個選項是擴展讀取複本數量以分散工作負載。 + 由於複寫延遲是高寫入輸送量和長時間執行查詢的結果，我們建議您使用 DBClusterReplicaLagMaximum CW 指標搭配慢查詢記錄器和 `WriteThroughput`/`WriteIOPS` 指標來疑難排解複寫延遲。 一般而言，我們建議所有複本都是相同的執行個體類型，因此叢集容錯移轉不會導致效能降低。 如果您選擇向上擴展和向外擴展 （例如，6 個較小的執行個體與三個較大的執行個體），通常建議您先嘗試向上擴展 （較大的執行個體），然後再向外擴展，因為每個資料庫執行個體都會獲得較大的緩衝快取。 主動設定複寫延遲警示，並將其閾值設定為您認為在複本執行個體上資料開始影響應用程式功能之前落後 （或過時） 多長時間的上限值。一般而言，由於暫時性工作負載，我們建議在發出警示之前超過數個資料點的複寫延遲閾值。 **注意** 此外，我們建議您為超過 10 秒的複寫延遲設定另一個警示。如果您針對多個資料點超過此閾值，我們建議您擴展執行個體或降低主要執行個體的寫入輸送量。