從 MySQL 資料庫串流資料

這個部分包含以下資訊：

  • Datastream 處理從來源 MySQL 資料庫擷取資料的方式
  • Datastream 支援的 MySQL 資料庫版本
  • 使用 MySQL 資料庫做為來源時的已知限制
  • 簡介如何設定來源 MySQL 資料庫，以便將資料從該資料庫串流至目的地

行為

本節說明使用 Datastream 複製資料時，MySQL 來源的行為。從 MySQL 資料庫擷取資料時，您可以使用以 binlog 為基礎的複製功能，或以全域交易 ID (GTID) 為基礎的複製功能。您可以在建立串流時選取 CDC 方法。

以二進位記錄為基礎的複製

Datastream 可以使用二進位記錄檔檔案，記錄 MySQL 資料庫中的資料變更。這些記錄檔中的資訊隨後會複製到目的地，以重現來源所做的變更。

Datastream 中以二進位記錄檔為基礎的複製作業主要有以下特徵：

  • 您可以選取特定 MySQL 來源中的所有資料庫或特定資料庫，以及資料庫中的所有資料表或特定資料表。
  • 所有歷來資料都會複製。
  • 系統會複製所有資料操作語言 (DML) 變更，例如指定資料庫和資料表中的插入、更新和刪除作業。
  • 系統只會複製已提交的變更。

以全域交易 ID (GTID) 為基礎的複製功能

Datastream 也支援以全域 ID (GTID) 為基礎的複製功能。

全域交易 ID (GTID) 是指系統建立並與 MySQL 來源上提交的每筆交易建立關聯的專屬 ID。這個 ID 不僅在來源上是專屬的，在特定複製拓撲中的所有伺服器上也是專屬的。這與以二進位記錄為準的複製不同，在以二進位記錄為準的複製中，資料庫叢集中的每個節點都會維護自己的二進位記錄檔，並有自己的編號。如果發生故障或計畫性停機，維護個別二進位記錄檔和編號可能會造成問題，因為二進位記錄檔的連續性會中斷，導致以二進位記錄檔為基礎的複製失敗。

以 GTID 為基礎的複製模式支援容錯移轉和自行管理的資料庫叢集，且無論資料庫叢集發生任何變更，都能持續運作。

Datastream 中以 GTID 為基礎的複製模式主要有以下特點：

  • 您可以選取特定 MySQL 來源中的所有資料庫或特定資料庫，以及資料庫中的所有資料表或特定資料表。
  • 所有歷來資料都會複製。
  • 系統會複製所有資料操作語言 (DML) 變更，例如指定資料庫和資料表中的插入、更新和刪除作業。
  • 系統只會複製已提交的變更。
  • 順暢支援容錯移轉。

從以二進位記錄檔為基礎的複製模式切換至以 GTID 為基礎的複製模式

如要更新串流，並從以二進位記錄檔為準的複製作業切換為以 GTID 為準的複製作業，且不需要回填，請執行下列步驟：

  1. 確認符合以 GTID 為基礎的複製模式的所有需求。詳情請參閱「設定來源 MySQL 資料庫」。
  2. 您也可以建立並執行以 GTID 為基礎的測試串流。詳情請參閱「建立串流」。
  3. 建立以 GTID 為基礎的串流。請先不要啟動。
  4. 停止應用程式流量流向來源資料庫。
  5. 暫停現有的 binlog 串流。詳情請參閱「暫停串流」。
  6. 請稍候幾分鐘，確保 Datastream 已趕上資料庫的進度。您可以在串流的「串流詳細資料」頁面，透過「監控」分頁中的指標查看這項資訊。「資料更新間隔」和「輸送量」的值必須為 0。
  7. 啟動以 GTID 為基礎的串流。詳情請參閱「開始直播」。
  8. 恢復來源資料庫的流量。

如果執行回填作業沒有問題，您可以在 BigQuery 中截斷資料表、刪除舊串流，然後啟動新的串流並執行回填作業。如要進一步瞭解如何管理回填，請參閱「管理串流物件的回填」。

版本

Datastream 支援下列版本的 MySQL 資料庫：

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

  • MySQL 8.4 (僅支援以 GTID 為基礎的複製模式)

Datastream 支援下列類型的 MySQL 資料庫：

最佳做法

本節說明設定 MySQL 來源的最佳做法，建議您按照這些做法操作，以便搭配使用 Datastream。

使用 GTID 設定高可用性

如果生產環境的 MySQL 來源使用副本或任何其他高可用性設定，請使用以 GTID 為基礎的複製功能。

資料庫容錯移轉期間，二進位記錄檔和位置型複製作業可能會中斷，因為主要資料庫發生故障時，新的主要資料庫會有不同的二進位記錄檔記錄。在這種情況下，Datastream 會失去位置，且無法繼續。

GTID 會為整個複製拓撲 (主要和副本) 中的每筆交易指派專屬 ID。容錯移轉後，Datastream 可以從新主機上記錄的最後一個 GTID 繼續作業，不必知道二進位記錄檔或位置。

建議：對於任何具有副本或高可用性設定的正式版 MySQL 來源，都必須使用 GTID CDC 方法，才能確保資料複製作業的彈性和可靠性。

適當調整唯讀備用資源的大小

如果將 Datastream 設為從讀取副本複製資料，可能會遇到雙重延遲，也就是 MySQL 複製延遲 (從主要副本到副本) 和 Datastream 複製延遲 (從副本到目的地) 的組合。為了節省成本，讀取副本通常會配置比主副本更少的資源 (CPU、RAM、IOPS)，因此在寫入量較高的期間，讀取副本可能會落後主副本。

建議：使用唯讀副本做為 Datastream 的來源時，請為副本佈建與主要執行個體相當的資源，確保副本能跟上主要執行個體的寫入輸送量。

提高 binlog CDC 方法的處理量

如果您使用以二進位記錄檔為基礎的複寫功能，且來源寫入量過大，導致二進位記錄檔的產生速度快於單一工作處理速度，進而造成高延遲，請調整 maxConcurrentCdcTasks 參數來提高處理量。這項參數可控制串流平行執行的 CDC 工作數量。調高這項參數的值，Datastream 就能同時處理更多 binlog 檔案。

建議：如要判斷適當的資料更新間隔值，請在尖峰時段監控 MySQL 伺服器的 binlog 產生率。您可以觀察 MySQL 資料目錄中建立及輪替新二進位記錄檔的速率，或使用 MySQL 監控工具追蹤二進位記錄檔的成長情況，藉此判斷是否需要調整。舉例來說，如果來源在尖峰時段每分鐘產生 10 個 binlog 檔案，將 maxConcurrentCdcTasks 設為 10-15 等值，Datastream 就能平行處理這些檔案，避免積壓。

只要來源資料庫的負載量維持在可控範圍內，您最多可將 maxConcurrentCdcTasks 增加至支援上限 50。詳情請參閱「串流並行控制」。

正確設定 max_allowed_packet 參數的大小

MySQL 的預設 max_allowed_packet 設定 (例如 16 MB 至 64 MB) 可能太小。如果單一資料列含有大型 BLOB、JSON 或 TEXT 類型欄位，或是單一大型交易超過這個大小，MySQL 就會終止 Datastream 連線，導致串流失敗並顯示 Packet for query is too large 或 Got a packet bigger than 'max_allowed_packet' bytes 等錯誤。

建議：將 MySQL 伺服器上的 max_allowed_packet 參數設為允許的最大值 1G。這可確保伺服器能處理 Datastream 需要從二進位記錄檔讀取的任何大型資料列或交易。

已知限制

使用 MySQL 資料庫做為來源時，您必須遵守下列已知限制：

  • 串流最多只能有 10,000 個資料表。
  • 複製的資料表必須使用 InnoDB 儲存空間引擎。系統不支援使用 MyISAM 儲存空間引擎的資料表，且會導致串流驗證失敗。
  • 主鍵定義為 INVISIBLE 的資料表無法回填。
  • 如果資料表超過 5 億列，除非符合下列條件，否則無法回填資料：
    1. 資料表有專屬索引。
    2. 索引的任何資料欄都不得為可為空值。
    3. 索引不是遞減。
    4. 串流中會包含索引的所有資料欄。
  • Datastream 會在處理事件時，定期從來源擷取最新結構定義。如果結構定義有所變更，Datastream 會偵測到結構定義變更，並觸發結構定義擷取作業。不過，部分事件可能會在擷取結構定義時處理錯誤或遭到捨棄，導致資料差異。
  • 系統無法自動偵測來源結構定義的所有變更，因此可能會發生資料損毀。下列結構定義變更可能會導致資料損毀，或無法處理下游事件：
    • 捨棄資料欄
    • 在表格中間新增資料欄
    • 變更資料欄的資料類型
    • 重新排序資料欄
    • 捨棄資料表 (如果之後重新建立資料表並新增資料，這項操作就相當實用)
    • 截斷資料表
  • Datastream 不支援複製檢視區塊。
  • Datastream 不支援空間資料類型的資料欄，例如 GEOMETRY、POINT、LINESTRING、POLYGON。這些資料欄中的值會替換為 NULL 值。
  • Datastream 不支援 DATETIME、DATE 或 TIMESTAMP 資料類型資料欄中的零值 (0000-00-00 00:00:00)。零值會替換為 NULL 值。
  • 如果資料列的 JSON 資料欄包含下列值，Datastream 就不支援複製該資料列：DECIMAL、NEWDECIMAL、TIME、TIME2、DATETIME、DATETIME2、DATE、TIMESTAMP 或 TIMESTAMP2。系統會捨棄含有這類值的事件。
  • Datastream 不支援二進位記錄檔交易壓縮。
  • Datastream 不支援超過 4 GiB 的二進位記錄檔。 由於 MySQL 會將每筆交易寫入單一二進位記錄檔，請將個別交易大小控制在 4 GiB 以下，以免二進位記錄檔超過這個限制。
  • Datastream 不支援來源 MySQL 連線設定檔中的 SSL 憑證鏈結。系統僅支援單一的 x509 PEM 編碼憑證。
  • Datastream 不支援連鎖作業：ON UPDATE CASCADE 和 ON DELETE CASCADE。這類事件不會寫入二進位記錄檔，因此不會傳播至目的地。如要解決這個問題，可以將連鎖作業替換為資料庫觸發程序。
  • Datastream 不支援 DROP PARTITION 作業。這類作業僅限於中繼資料，不會複製。其他事件不受影響，串流也會順利執行。
  • 複製 FEDERATED 資料表時，可能會發生連線問題。如果發生這種情況，請從來源資料庫設定中移除所有 FEDERATED 資料表，並增加 connect_timeout、net_read_timeout 和 max_allowed_packet 參數的值，以減輕回填期間的逾時問題。
  • Cloud SQL Enterprise Plus 執行個體必須使用以 GTID 為依據的複製作業，因為這類執行個體會進行幾乎無須停機的維護作業。以二進位記錄檔為基礎的複製模式會在容錯移轉時中斷，因此建議您針對高可用性用途使用以 GTID 為基礎的複製模式。
  • 如果是 MySQL 8.0 以上版本，binlog_row_value_options 變數必須設為空值。大多數版本預設會使用這個值，但如果是 Oracle Cloud Infrastructure (OCI) 上的 MySQL 來源等，則必須明確設定。詳情請參閱「設定自行管理的 MySQL 資料庫」。
  • MariaDB 限制：
    • MariaDB 不支援以 GTID 為基礎的複製模式。您必須設定 MariaDB 串流，才能使用以二進位記錄檔為基礎的複製功能。
    • 如為 MariaDB 11.4 至 12.2 版，請務必在來源資料庫中啟用 binlog_legacy_event_pos 系統變數，確保與 Datastream 相容。
    • Datastream 不支援 UUID 資料類型 (MariaDB 10.7 中導入)。您必須從串流設定中排除 UUID 資料類型的資料欄。

以 GTID 為基礎的複製作業的其他限制

  • 只有在使用 Datastream API 時，才能復原以 GTID 為依據的複製作業所用的串流。
  • 系統不支援使用 CREATE TABLE ... SELECT 陳述式從其他資料表建立資料表。
  • Datastream 不支援已加上標記的 GTID。
  • 如要瞭解以 GTID 為基礎的複製功能適用的 MySQL 限制，請參閱 MySQL 說明文件。

後續步驟