調整叢集大小 - Amazon Redshift
彈性調整大小Elastic resize (傳統調整大小)

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

調整叢集大小

當您的資料倉儲容量和效能需要變更時，您可以調整叢集大小，以充分利用 Amazon Redshift 的運算和儲存選項。

調整大小操作有兩種類型：

  • 彈性調整大小 — 您可以在叢集中新增或移除節點。您也可以變更節點類型，例如從 DC2 節點變更為 RA3 節點。彈性調整大小通常會很快完成，平均需要十分鐘。因此，建議您將其作為第一個選項。當您執行彈性調整大小時，它會重新分散資料配量，這些資料配量是在每個節點中配置記憶體和磁碟空間的分割區。當您要進行下列操作時，就適合使用彈性調整大小：

    • 在現有叢集中新增或減少節點，但不變更節點類型 — 這通常稱為「就地」調整大小。當您執行此類型的調整大小時，某些執行中的查詢會成功完成，但其他查詢可能會在操作中遭到捨棄。

    • 變更叢集的節點類型 — 當您變更節點類型時，系統會建立快照，並將資料從來源叢集重新分散至包含新節點類型的叢集。完成後，執行中的查詢會遭到捨棄。和「就地」調整大小一樣，其也會快速完成。

  • 傳統調整大小 — 您可以透過類似於彈性調整大小的方式來變更節點類型和 (或) 節點數目。傳統調整大小需要更多時間來完成，但是如果節點計數的變化或要遷移到的節點類型不在彈性調整大小的範圍內，傳統調整大小可能會很有用。例如，當節點計數的變化非常大時，就適用這種方式。

彈性調整大小

當您新增或移除相同類型的節點時，彈性調整大小操作具有下列階段：

  1. 彈性調整大小會取得叢集快照。此快照一律會包含節點的不備份資料表 (如適用)。(RA3 等某些節點類型沒有不備份資料表。) 如果您的叢集因為您停用了自動快照而沒有最新的快照，備份操作會需要較長時間。(若要將調整大小操作開始之前的時間最小化，建議您啟用自動快照或在開始調整大小之前建立手動快照。) 當您啟動彈性調整大小且快照操作正在進行時，如果快照操作未在幾分鐘內完成，則調整大小可能會失敗。如需詳細資訊，請參閱 Amazon Redshift 快照和備份。

  2. 此操作會遷移叢集中繼資料。叢集會有幾分鐘的時間無法使用。大多數查詢會暫時暫停，且會保持連線。但是，某些查詢則可能遭到捨棄。這個階段很快就會結束。

  3. 工作階段連線會重新起始，並且查詢會繼續。

  4. 彈性調整大小會在背景中將資料重新分散給節點配量。叢集可供讀寫操作，但有些查詢可能需要較長時間來執行。

  5. 操作完成後，Amazon Redshift 會傳送事件通知。

當您使用彈性調整大小變更節點類型時，其運作方式與您新增或減少相同類型的節點時相似。首先，系統會建立快照。使用快照中的最新資料佈建新的目標叢集，並在背景中將資料傳輸到新的叢集。在此期間，資料是唯讀狀態。當調整大小操作接近完成時，Amazon Redshift 會更新端點以指向新的叢集，並中斷與來源叢集的所有連線。

彈性調整大小不太可能會失敗。但是，在發生故障的情況下，在大多數情況下都會自動進行復原，而無需任何手動介入。

如果您有保留節點 (例如 DC2 保留節點)，則可以在執行調整大小時升級至 RA3 保留節點。您可以在執行彈性調整大小或使用主控台從快照進行還原時進行升級。主控台會引導您完成此程序。如需升級至 RA3 節點的相關資訊，請參閱升級至 RA3 節點類型。

彈性調整大小不會排序資料表或回收磁碟空間，因此不是清空操作的替代方案。如需詳細資訊，請參閱清空資料表。

彈性調整大小有下列限制：

  • 彈性調整大小和資料共用叢集 — 當您在作為資料共用生產者的叢集上新增或減少節點時，您無法在 Amazon Redshift 遷移叢集中繼資料時從取用者連線至該叢集。同樣地，如果您執行彈性調整大小並選擇新的節點類型，則在連線中斷並傳輸到新的目標叢集時，便無法使用資料共用。在這兩種類型的彈性調整大小中，生產者都會有幾分鐘的時間無法使用。

  • 從共用快照傳輸資料 — 若要在從共用快照傳輸資料的叢集上執行彈性調整大小，必須至少有一個備份可供叢集使用。您可以在 Amazon Redshift 主控台快照清單、describe-cluster-snapshots CLI 命令或 DescribeClusterSnapshots API 操作上檢視備份。

  • 平台限制 — 彈性調整大小僅供使用 EC2-VPC 平台的叢集使用。如需詳細資訊，請參閱 在建立叢集時使用 EC2-VPC。

  • 儲存考量 — 請確定新節點的組態有足夠的儲存可儲存現有資料。您可能必須新增其他節點或變更組態。

  • 來源叢集與目標叢集的大小 — 彈性調整大小可以調整大小的節點數目和節點類型，取決於來源叢集中的節點數目和針對已調整大小的叢集所選擇的節點類型。若要判斷可用的組態，您可以使用主控台。或者，您可以將命describe-node-configuration-options AWS CLI 令與action-type resize-cluster選項搭配使用。如需使用 Amazon Redshift 主控台來調整大小的相關資訊，請參閱調整叢集大小。

    下列範例 CLI 命令會描述可用的組態選項。在此範例中，名為 mycluster 的叢集是一個 dc2.large 8 節點的叢集。

    aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster

    此命令會傳回一個具有所建議節點類型的選項清單、節點數，以及每個選項的磁碟使用率。傳回的組態會因為特定的輸入叢集而不同。當您指定 resize-cluster CLI 命令的選項時，您可以選擇其中一個所傳回的組態。

  • 其他節點的上限 — 彈性調整大小會限制您可以新增至叢集的節點數目。例如，dc2 叢集支援進行最多兩倍節點數目的彈性調整大小。為了說明，您可以在 4 節點的 dc2.8xlarge 叢集中新增一個節點，使其成為五節點的叢集，或新增更多節點，直到達到八個節點為止。

    注意

    增加和減少的限制取決於原始節點類型和原始叢集中的節點數目或其上次的傳統調整大小。如果彈性調整大小會超過增加或減少的限制，請使用傳統調整大小。

    對於某些 ra3 節點類型，您最多可以將節點數目增加到現有計數的四倍。具體來說，假設您的叢集由 ra3.4xlarge 或 ra3.16xlarge 節點組成。然後，您可以使用彈性調整大小，將 8 節點的叢集中的節點數目增加到 32 個。或者，您也可以選擇低於限制的值。(請記住，將叢集增加 4 倍的能力取決於來源叢集的大小。) 如果您的叢集具有 ra3.xlplus 節點，則限制為兩倍。

    所有 ra3 節點類型都支援將節點數目減少到現有計數的四分之一。例如，您可以將具有 ra3.4xlarge 節點的叢集大小從 12 個節點減少到 3 個，或減少到高於下限的數目。

    下表列出每個支援彈性調整大小之節點類型的增加和減少限制。

    原始節點類型 增加限制 減少限制

    ra3.16xlarge

    		 4 倍 (例如，從 4 個節點到 16 個節點)

    減少到四分之一的數目 (例如，從 16 個節點到 4 個節點)

    ra3.4xlarge

    4 倍

    		 減少到四分之一的數目

    ra3.xlplus

    2 倍 (例如，從 4 個節點到 8 個節點)

    減少到四分之一的數目

    dc2.8xlarge

    2 倍

    減少到二分之一的數目 (例如，從 16 個節點到 8 個節點)

    dc2.large

    2 倍

    減少到二分之一的數目
    注意

    在調整 RA3 叢集大小時選擇舊版節點類型 — 如果您嘗試從具有 RA3 節點的叢集調整為其他節點類型 (例如 DC2)，則主控台中會顯示驗證警告訊息，且調整大小作業將無法完成。發生這種情況是因為系統不支援調整大小為舊版節點類型。這是為了防止客戶調整大小為已棄用或即將棄用的節點類型。這同時適用於彈性調整大小和傳統調整大小。

Elastic resize (傳統調整大小)

傳統調整大小會處理彈性調整大小不支援的叢集大小變更或節點類型變更的使用案例。當您執行傳統調整大小時，Amazon Redshift 會建立目標叢集，並將資料和中繼資料從來源叢集遷移到目標叢集。

以 RA3 為目標的傳統調整大小可以提供更好的可用性

當目標節點類型為 RA3 時，傳統調整大小已獲得增強。其會在來源叢集與目標叢集之間使用備份和還原操作來做到這一點。調整大小開始進行時，來源叢集會重新啟動，並有幾分鐘的時間無法使用。之後，叢集便可用於讀取和寫入操作，同時調整大小會在背景中繼續進行。

檢查叢集

為了確保您在執行目標為 RA3 叢集的傳統調整大小時能獲得最佳效能和結果，請完成這份檢查清單。如果您不遵循這份檢查清單，可能就無法獲得使用 RA3 節點進行傳統調整大小的一些好處，例如執行讀取和寫入操作的能力。

  1. 資料的大小必須低於 2 PB。(PB 等於 1,000 TB)。若要驗證資料的大小，請建立快照並檢查其大小。您也可以執行以下查詢來檢查大小：

    SELECT
sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
sum(size) as total_blocks,
((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
FROM svv_table_info;

    只有超級使用者才能看到 svv_table_info 資料表。

  2. 在啟動傳統調整大小之前，請確定您已建立不超過 10 小時的手動快照。如果沒有，請建立快照。

  3. 用於執行傳統調整大小的快照不能用於還原資料表或其他目的。

  4. 叢集必須在 VPC 中。

目標為 RA3 的傳統調整大小所產生的排序和分散操作

在為 RA3 進行傳統調整大小期間，具 KEY 分佈 (移轉為 EVEN 分佈) 的資料表會轉換回其原始的分佈樣式。這種情況的持續時間取決於資料大小以及叢集的忙碌程度。查詢工作負載的執行優先順序高過資料遷移。如需詳細資訊，請參閱分散樣式。在此移轉過程中，對資料庫的讀取和寫入都會運作，但查詢可能需要更長的時間才能完成。不過，在這段期間，並行擴展可以透過為查詢工作負載新增資源來提升效能。您可以檢視來自 SYS_RESTORE_STATE 和 SYS_RESTORE_LOG 視觀表的結果，查看資料移轉的進度。後面有關於監控的詳細資訊。

叢集調整大小徹底完成後，會發生下列排序行為：

  • 如果調整大小導致叢集有更多的配量，KEY 分佈資料表會變成部分未排序的狀態，但平均分散資料表會保持排序狀態。此外，在調整大小剛完成時，有關已排序資料數量的資訊可能不是最新的。在復原索引鍵後，自動清空功能會隨著時間的推移對資料表進行排序。

  • 如果調整大小導致叢集有較少的配量，則 KEY 分佈資料表和平均分散資料表都會變成部分未排序的狀態。自動清空功能會隨著時間的推移對資料表進行排序。

如需自動清空資料的相關資訊，請參閱清空資料表。如需運算節點中配量的相關資訊，請參閱資料倉儲系統架構。

目標叢集為 RA3 時的傳統調整大小步驟

當目標叢集類型為 RA3 且您已符合上一節中詳述的先決條件時，傳統調整大小包含下列步驟。

  1. 啟動從來源叢集到目標叢集的遷移。佈建新的目標叢集時，Amazon Redshift 會傳送調整大小已開始的事件通知。它會重新啟動您現有的叢集，而這會關閉所有連線。如果您現有的叢集是資料共用生產者叢集，則與取用者叢集的連線也會關閉。重新啟動會進行幾分鐘的時間。

    請注意，在傳統調整大小進行期間，系統不會保留使用 BACKUP NO 所建立的任何資料庫關聯，例如資料表或具體化視觀表。如需詳細資訊，請參閱 CREATE MATERIALIZED VIEW。

  2. 重新啟動之後，資料庫便可進行讀取和寫入。此外，資料共用也會繼續進行，這另外需要幾分鐘的時間來完成。

  3. 資料會遷移至目標叢集。當目標節點類型為 RA3 時，系統可在資料遷移期間進行讀取和寫入。

  4. 當調整大小程序接近完成時，Amazon Redshift 會更新目標叢集的端點，而且與來源叢集的所有連線都會中斷。目標叢集會成為資料共用的生產者。

  5. 調整大小完成。Amazon Redshift 傳送事件通知。

您可以在 Amazon Redshift 主控台上檢視調整大小進度。調整叢集大小所需的時間取決於資料量。

注意

在調整 RA3 叢集大小時選擇舊版節點類型 — 如果您嘗試從具有 RA3 節點的叢集調整為其他節點類型 (例如 DC2)，則主控台中會顯示驗證警告訊息，且調整大小作業將無法完成。發生這種情況是因為系統不支援調整大小為舊版節點類型。這是為了防止客戶調整大小為已棄用或即將棄用的節點類型。這同時適用於彈性調整大小和傳統調整大小。

在目標叢集為 RA3 時監控傳統調整大小

若要監控正在進行傳統調整大小的佈建叢集 (包括 KEY 分佈)，請使用 SYS_RESTORE_STATE。其會顯示正在轉換的資料表的完成百分比。您必須是超級使用者才能存取該資料。

當您執行傳統調整大小時，請捨棄不需要的資料表。如果您這麼做，就可以更快速地分散現有資料表。

目標叢集不是 RA3 時的傳統調整大小步驟

例如，當目標節點類型是 RA3 以外的任何內容時，傳統調整大小由以下內容組成。

  1. 啟動從來源叢集到目標叢集的遷移。佈建新的目標叢集時，Amazon Redshift 會傳送調整大小已開始的事件通知。它會重新啟動您現有的叢集，而這會關閉所有連線。如果您現有的叢集是資料共用生產者叢集，則與取用者叢集的連線也會關閉。重新啟動會進行幾分鐘的時間。

    請注意，在傳統調整大小進行期間，系統不會保留使用 BACKUP NO 所建立的任何資料庫關聯，例如資料表或具體化視觀表。如需詳細資訊，請參閱 CREATE MATERIALIZED VIEW。

  2. 重新啟動之後，資料庫會是唯讀狀態。資料共用會繼續進行，這另外需要幾分鐘的時間來完成。

  3. 資料會遷移至目標叢集。資料庫會保持唯讀狀態。

  4. 當調整大小程序接近完成時，Amazon Redshift 會更新目標叢集的端點，而且與來源叢集的所有連線都會中斷。目標叢集會成為資料共用的生產者。

  5. 調整大小完成。Amazon Redshift 傳送事件通知。

您可以在 Amazon Redshift 主控台上檢視調整大小進度。調整叢集大小所需的時間取決於資料量。

注意

當目標叢集不是 RA3 時，或者其不符合上一節所述 RA3 目標叢集的先決條件時，可能需要數天甚至數週的時間，才能為包含大量資料的叢集調整大小。

另請注意，叢集所使用的儲存容量在進行傳統調整大小後可能會上升。當叢集因為傳統調整大小產生了額外的資料配量時，這是正常的系統行為。即使叢集中的節點數目保持不變，也可能會像這樣使用額外的容量。

彈性調整大小與傳統調整大小

下表會比較這兩種調整大小類型的行為。

彈性調整大小與傳統調整大小
Behavior (行為) 彈性調整大小 Elastic resize (傳統調整大小) 說明
系統資料保留 彈性調整大小會保留系統日誌資料。 傳統調整大小不會保留系統資料表和資料。 如果您已在來源叢集中啟用稽核記錄，則可以在調整大小後繼續存取 Amazon S3 或中 CloudWatch的日誌。您可以依照資料政策所指定的，來保留或刪除這些日誌。
變更節點類型

當節點類型未變更時的彈性調整大小：就地調整大小，並保留大多數查詢。

選取新節點類型時的彈性調整大小：建立新叢集。當調整大小程序完成時，查詢會遭到捨棄。

 傳統調整大小：建立新叢集。調整大小程序進行期間，查詢會遭到捨棄。
工作階段和查詢保留 當來源叢集和目標叢集中的節點類型相同時，彈性調整大小會保留工作階段和查詢。如果您選擇新的節點類型，查詢會遭到捨棄。 傳統調整大小不會保留工作階段和查詢。查詢會遭到捨棄。 當查詢遭到捨棄時，效能應該會降低。最好的辦法是在使用量不大時執行調整大小操作。
取消調整大小操作

您無法取消彈性調整大小。

您可以在 Amazon Redshift 主控台中，從叢集詳細資訊選擇取消調整大小，以在傳統調整大小操作完成前將其取消。

取消調整大小所需的時間量，取決於取消時調整大小操作的階段。如果您這麼做，則要等到取消操作完成後，叢集才可供使用。如果調整大小操作處於最終階段，即無法取消。

若為目標為 RA3 叢集的傳統調整大小，您無法加以取消。

排定調整大小

您可以為叢集排定調整大小操作，縱向擴展以應付預期的高使用量，或縮減規模以節省成本。排程同時適用於彈性調整大小和傳統調整大小。您可以在 Amazon Redshift 主控台上設定排程。如需詳細資訊，請參閱使用主控台管理叢集下的調整叢集大小。您也可以使用 AWS CLI 或 Amazon Redshift API 操作來安排調整大小。如需詳細資訊，請參閱AWS CLI 命令參考中的建立排程動作或 Amazon Redshift API 參考中的CreateScheduled動作。

快照、還原和調整大小

彈性調整大小是調整 Amazon Redshift 叢集大小最快的方法。如果彈性調整大小不是您的其中一個選擇，並且您需要對叢集進行近乎不變的寫入存取，則可以使用下節所述的快照和還原操作搭配傳統調整大小。此方法需要在擷取快照之後寫入至來源叢集的任何資料必須在切換之後手動複製到目標叢集。根據複製所需時間，您可能需要重複此動作數次，直到您在這兩個叢集中具有相同的資料。然後可以切換至目標叢集。此程序可能對現有查詢具有負面影響，直到可在目標叢集中提供完整資料集。但它的確會將您無法寫入至資料庫的時間量降至最低。

快照、還原和傳統調整大小方法使用下列程序：

  1. 擷取現有叢集的快照。現有叢集是來源叢集。

  2. 記下快照所花費的時間。這麼做表示稍後您可以識別將需要在哪個時間點重新執行擷取、交易和載入 (ETL) 程序，以將任何後置快照資料載入至目標資料庫。

  3. 將快照還原至新叢集。這個新叢集是目標叢集。驗證目標叢集中有範例資料。

  4. 調整目標叢集大小。為目標叢集選擇新的節點類型、節點數量和其他設定。

  5. 檢閱在您擷取來源叢集快照之後發生之 ETL 程序中的載入。務必依照相同順序將相同資料重新載入至目標叢集。如果您有資料持續載入，請重複此程序數次，直到來源叢集和目標叢集中的資料相同。

  6. 停止來源叢集上執行的所有佇列。若要這樣做，您可以重新啟動叢集，或以超級使用者身分登入，並使用 PG_CANCEL_BACKEND 和 PG_TERMINATE_BACKEND 命令。重新啟動叢集是確定叢集無法使用的最簡便方法。

  7. 重新命名來源叢集。例如，將它從 examplecluster 重新命名為 examplecluster-source。

  8. 重新命名目標叢集，以使用重新命名之前的來源叢集名稱。例如，將前述的目標叢集重新命名為 examplecluster。從此時起，使用包含 examplecluster 之端點的任何應用程式都會連接至目標叢集。

  9. 在切換至目標叢集之後刪除來源叢集，並驗證所有程序都如預期般運作。

或者，您可以在將資料重新載入目標叢集之前重新命名來源和目標叢集。如果您不需要任何相依系統和報告立即與目標叢集的系統和報告一樣最新，則可採用此方法。在此情況下，步驟 6 將移至上述程序尾端。

只在您想要應用程式繼續使用相同端點連接至叢集時，才需要重新命名程序。如果不需要這樣做，則您可以改為更新任何連接至叢集的應用程式，以使用目標叢集的端點，而無需重新命名叢集。

重複使用叢集名稱有一些優勢。首先，您不需要更新應用程式連線字串，因為端點不會變更，即使基礎叢集變更也一樣。其次，相關項目，例如 Amazon CloudWatch 警報和亞馬遜簡單通知服務 (Amazon SNS) 通知與叢集名稱繫結。這個連結表示您可以繼續使用您為叢集設定的相同警示和通知。這種持續使用主要是生產環境中的疑慮，而您想要在這個環境中能夠靈活地調整群集模範，而無需重新配置相關項目，例如警示和通知。