從 MySQL 資料庫串流資料

本節包含下列資訊：

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

行為

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

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

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

Datastream 中以 binlog 為基礎的複寫功能主要有以下特點：

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

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

在高可用性設定中，使用以 GTID 為基礎的複製功能，支援無縫容錯移轉。

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

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

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

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

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

從以 binlog 為基礎的複製模式切換至以 GTID 為基礎的複製模式

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

注意： 這些步驟需要資料庫停機。如要升級 MySQL 來源的主要版本，也可以參考類似步驟。

1. 確認符合以 GTID 為基礎的複製模式的所有規定條件。詳情請參閱「設定來源 MySQL 資料庫」。
2. (選用) 建立並執行以 GTID 為基礎的測試串流。詳情請參閱「建立串流」一文。
3. 建立以 GTID 為基礎的串流。請先不要啟動。
4. 停止將應用程式流量傳送到來源資料庫。
5. 暫停現有的 binlog 串流。詳情請參閱「暫停串流」。
6. 請稍候幾分鐘，確保 Datastream 已趕上資料庫。如要查看這項資訊，請前往串流的「Stream details」(串流詳細資料) 頁面，然後查看「Monitoring」(監控) 分頁中的指標。「資料更新間隔」和「輸送量」的值必須為 0。
7. 啟動以 GTID 為基礎的串流。詳情請參閱「開始直播」一文。
8. 恢復來源資料庫的流量。

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

版本

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

• MySQL 5.6
• MySQL 5.7
• MySQL 8.0

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

  以全域交易 ID (GTID) 為基礎的複製功能僅支援 5.7 以上版本。

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

• 自行託管的 MySQL
• MySQL 適用的 Cloud SQL
  使用 GTID 型複製功能時，系統支援 MySQL 適用的 Cloud SQL Enterprise Plus 來源。
• MySQL 適用的 Amazon RDS
• Amazon Aurora MySQL
• MariaDB
• Alibaba Cloud PolarDB
• Percona Server for 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 資料目錄中建立及輪替新 binlog 檔案的速率，或使用 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 個資料表。
• 如果資料表的主鍵定義為 INVISIBLE，就無法進行回填。
• 如果資料表超過 5 億列，除非符合下列條件，否則無法回填：
  1. 資料表具有專屬索引。
  2. 索引的任何資料欄都不得為可為空值。
  3. 索引不是遞減。
  4. 串流中會包含索引的所有資料欄。
• Datastream 會在處理事件時，定期從來源擷取最新結構定義。如果結構定義有所變更，Datastream 會偵測到結構定義變更，並觸發結構定義擷取作業。不過，在擷取結構定義期間，部分事件可能會處理錯誤或遭到捨棄，導致資料不一致。
• 系統無法自動偵測來源結構定義的所有變更，因此可能會發生資料損毀。下列結構定義變更可能會導致資料損毀，或無法處理下游事件：
  • 捨棄資料欄
  • 在表格中間新增欄
  • 變更資料欄的資料類型
  • 重新排序資料欄
  • 捨棄資料表 (如果之後重新建立資料表並新增資料，這項操作就相當實用)
  • 截斷資料表
• Datastream 不支援複製檢視表。
• Datastream 不支援空間資料類型的資料欄。這些資料欄中的值會替換為 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 不支援來源 MySQL 連線設定檔中的 SSL 憑證鏈結。系統僅支援單一的 x509 PEM 編碼憑證。
• Datastream 不支援連鎖刪除作業。這類事件不會寫入二進位記錄檔，因此不會傳播至目的地。
• 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 資料庫」。

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

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

後續步驟

• 瞭解如何設定 MySQL 來源，以便搭配 Datastream 使用。