Aurora零 ETL 整合

協助您從多個資料來源衍生整體洞見。

無需建置和維護執行擷取、轉換和載入 (ETL) 操作的複雜資料管道。Zero-ETL 整合會透過為您佈建和管理管道，免除建置和管理這些管道所帶來的挑戰。

減少操作負擔和成本，讓您專注於改善應用程式。

讓您利用目標目的地的分析和 ML 功能，從交易和其他資料衍生洞見，以有效地回應關鍵、時間敏感的事件。

來源資料庫叢集必須與目標位於相同的區域。

您無法重新命名資料庫叢集或其任何執行個體，如果它具有現有整合的話。

您無法在相同的來源和目標資料庫之間建立多個整合。

您無法刪除具有現有整合的資料庫叢集。您必須先刪除所有相關聯的整合。

如果停止來源資料庫叢集，則最後幾個交易可能不會複寫到目標，直到您恢復叢集為止。

如果您的叢集是藍/綠部署的來源，則藍色和綠色環境在轉換期間無法具有現有的零 ETL 整合。您必須先刪除整合再進行轉換，然後重新建立該整合。

資料庫叢集必須至少包含一個資料庫執行個體，才能成為整合的來源。

您無法為跨帳戶複製的來源資料庫叢集建立整合，例如使用 AWS Resource Access Manager () 共用的資料庫叢集AWS RAM。

如果來源叢集是 Aurora 全域資料庫中的主要資料庫叢集，且容錯移轉到其中一個次要叢集，則整合會變成非作用中。您必須刪除並重新建立整合。

您無法為正在主動建立另一個整合的來源資料庫建立整合。

當您一開始建立整合時或當資料表重新同步時，從來源植入目標的資料可能需要 20 到 25 分鐘或更長時間，取決於來源資料庫的大小。此延遲可能會導致複本延遲增加。

不支援某些資料類型。如需詳細資訊，請參閱Aurora 與 Amazon Redshift 資料庫之間的資料類型差異。

系統資料表、暫存資料表和檢視不會複寫到目標倉儲。

在來源資料表上執行 DDL 命令 (例如 ALTER TABLE) 可以觸發資料表重新同步，使得資料表無法在重新同步時進行查詢。如需詳細資訊，請參閱我的一個或多個 Amazon Redshift 資料表需要重新同步。

您的來源資料庫叢集必須執行支援的 Aurora MySQL 版本。如需支援的版本的清單，請參閱零 ETL 整合的支援區域和 Aurora 資料庫引擎。

零 ETL 整合依賴 MySQL 二進位記錄 (binlog)，來擷取持續的資料變更。不要使用 Binlog 型資料篩選，因為其可能會在來源資料庫與目標資料庫之間導致資料不一致。

僅針對設定為使用 InnoDB 儲存體引擎的資料庫支援零 ETL 整合。

不支援具有預先定義之資料表更新的外部索引鍵參考。具體而言，不支援 ON DELETE 和 ON UPDATE 規則搭配 CASCADE、SET NULL 和 SET DEFAULT 動作。嘗試建立或更新對另一個資料表具有這類參考的資料表，會將該資料表置於失敗狀態。

在來源資料庫叢集上執行的 XA 交易會導致整合進入 Syncing 狀態。

您的來源資料庫叢集必須執行支援的 Aurora PostgreSQL 版本。如需支援的版本的清單，請參閱零 ETL 整合的支援區域和 Aurora 資料庫引擎。

如果您選取 Aurora PostgreSQL 來源資料庫叢集，則必須至少指定一個資料篩選條件模式。模式至少必須包含單一資料庫 (database-name.*.*)，才能複寫至目標倉儲。如需詳細資訊，請參閱Aurora 零 ETL 整合的資料篩選。

在來源 Aurora PostgreSQL 資料庫叢集內建立的所有資料庫都必須使用 UTF-8 編碼。

使用宣告式分割時，資料表分割區會複寫至 Amazon Redshift。不過，分割的資料表本身不會複寫到 Amazon Redshift。

不支援兩階段交易。

如果您從整合來源的資料庫叢集刪除所有資料庫執行個體，然後重新新增資料庫執行個體，則來源與目標叢集之間的複寫會中斷。

來源資料庫叢集無法使用 Aurora Limitless Database。

資料篩選條件中存在的所有資料表都需要主索引鍵。任何沒有主索引鍵的資料表都會進入失敗狀態。

目錄名稱的長度限制為 19 個字元。