本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon Neptune 資料庫叢集和執行個體
<a name="feature-overview-db-clusters"></a>

Amazon Neptune「資料庫叢集」**會透過查詢管理對資料的存取。一個叢集包含：
+ 一個「主要資料庫執行個體」**。
+ 最多 15 個「僅供讀取複本資料庫執行個體」**。

叢集中的所有執行個體共用相同的[基礎受管儲存磁碟區](feature-overview-storage.md)，這是專為可靠性和高可用性而設計的。

您可以透過 [Neptune 端點](feature-overview-endpoints.md)連線至資料庫叢集中的資料庫執行個體。

## Neptune 資料庫叢集中的主要資料庫執行個體
<a name="feature-overview-primary-instance"></a>

主要資料庫執行個體會協調對資料庫叢集的基礎儲存磁碟區的所有寫入操作。它也支援讀取操作。

Neptune 資料庫叢集中只能有一個主要資料庫執行個體。如果主要執行個體變得無法使用，Neptune 會自動容錯移轉至具有您所指定優先順序的其中一個僅供讀取複本執行個體。

## Neptune 資料庫叢集中的僅供讀取複本資料庫執行個體
<a name="feature-overview-read-replicas"></a>

在建立資料庫叢集的主要執行個體之後，您可以在資料庫叢集中最多建立 15 個僅供讀取複本執行個體，來支援唯讀查詢。

Aurora 僅供讀取複本很適用於擴展讀取容量，因為完全專用於叢集磁碟區上的讀取操作。所有寫入操作是由主要執行個體管理。每個僅供讀取複本資料庫執行個體都有自己的端點。

由於叢集儲存磁碟區是在叢集中的所有執行個體之間共用，因此所有僅供讀取複本執行個體都會針對查詢結果傳回相同的資料，複寫延遲非常短。在主要執行個體寫入更新之後，此延遲通常遠低於 100 毫秒，但在寫入操作的數量非常大時，此延遲通常會稍長一些。

在不同的可用區域中具有一或多個可用的僅供讀取複本執行個體可以提高可用性，因為僅供讀取複本會做為主要執行個體的容錯移轉目標。亦即，如果主要執行個體失敗，則 Neptune 會提升僅供讀取複本以成為主要執行個體。當發生此情況時，若重新啟動提升的執行個體，會發生短暫的中斷，在此期間對主要執行個體提出的讀取和寫入請求會由於例外狀況而失敗。

相反地，如果您的資料庫叢集不包含任何僅供讀取複本執行個體，則當主要執行個體失敗時，資料庫叢集仍無法使用，直到重新建立為止。重新建立主要執行個體所花費的時間比提升僅供讀取複本要長得多。

為了確保高可用性，建議您建立一或多個僅供讀取複本執行個體，這些執行個體具有與主要執行個體相同的資料庫執行個體類別，且位於與主要執行個體不同的可用區域。請參閱 [Neptune 資料庫叢集的容錯能力](backup-restore-overview-fault-tolerance.md)。

透過主控台，您只要在建立資料庫叢集時指定 Multi-AZ (異地同步備份)，即可輕鬆建立異地同步備份部署。如果資料庫叢集位於單一可用區域中，您可以在不同的可用區域新增 Neptune 複本，使其變成多重可用區資料庫叢集。

**注意**  
您無法為未加密的 Neptune 資料庫叢集建立加密的僅供讀取複本執行個體，也無法為加密的 Neptune 資料庫叢集建立未加密的僅供讀取複本執行個體。

如需如何建立 Neptune 僅供讀取複本資料庫執行個體的詳細資訊，請參閱 [使用主控台建立 Neptune 讀取器執行個體](manage-console-create-replica.md)。

## 調整 Neptune 資料庫叢集中資料庫執行個體的大小
<a name="feature-overview-sizing-instances"></a>

根據您的 CPU 和記憶體需求調整 Neptune 資料庫叢集中執行個體的大小。執行個體上的 vCPU 數目會決定處理傳入查詢的查詢執行緒數目。執行個體上的記憶體數量會決定緩衝區快取的大小，用於儲存從基礎儲存磁碟區擷取的資料頁面副本。

每個 Neptune 資料庫執行個體都具有相當於該執行個體上 vCPU 數目 2 倍的查詢執行緒數目。例如，具有 16 個 vCPU 的 `r5.4xlarge` 具有 32 個查詢執行緒，因此可以同時處理 32 個查詢。

在所有查詢執行緒都被佔用時到達的其他查詢會放入伺服器端佇列中，並在查詢執行緒變成可用時以 FIFO 的方式進行處理。此伺服器端佇列可保留約 8000 個待定請求。一旦裝滿，Neptune 會以 `ThrottlingException` 回應其他請求。您可以使用 `MainRequestQueuePendingRequests` CloudWatch 指標，或使用 [Gremlin 查詢狀態端點](gremlin-api-status.md)搭配 `includeWaiting` 參數，來監控待定的請求數目

從用戶端的角度來看，查詢執行時間除了實際執行查詢所花費的時間之外，還包括花費在佇列中的任何時間。

利用主要資料庫執行個體上所有查詢執行緒的持續並行寫入負載，理想情況下會顯示 90% 以上的 CPU 使用率，這指示伺服器上的所有查詢執行緒都在積極參與執行有用的工作。不過，即使在持續的並行寫入負載下，實際 CPU 使用率通常也會稍低一些。這通常是因為查詢執行緒正在等待基礎儲存磁碟區的 I/O 操作完成。Neptune 會使用仲裁寫入，跨三個可用區域製作六個資料副本，而這六個儲存節點中的四個必須確認寫入，才能將其視為持久性。當查詢執行緒從儲存磁碟區等待此仲裁時，它會停滯，從而降低 CPU 使用率。

如果您有一個序列寫入負載，您正在其中執行一個接一個的寫入，並等待第一個寫入完成後再開始下一個，您可以預期 CPU 使用率仍會降低。確切的數量將是 vCPU 和查詢執行緒數目的函數 (查詢執行緒越多，每個查詢的整體 CPU 就越少)，而等待 I/O 會導致減少一些。

如需有關如何最好地調整資料庫執行個體大小的詳細資訊，請參閱 [選擇 Amazon Neptune 的執行個體類型](instance-types.md)。如需每個執行個體類型的定價，請參閱 [Neptune 定價頁面](https://aws.amazon.com/neptune/pricing/)。

## 在 Neptune 中監控資料庫執行個體
<a name="feature-overview-monitoring-instances"></a>

您可以在 Neptune 中使用 CloudWatch 指標來監控資料庫執行個體的效能，並追蹤用戶端觀察到的查詢延遲。請參閱 [使用 CloudWatch 監控 Neptune 中的資料庫執行個體效能](cloudwatch-monitoring-instances.md)。