從 MySQL 執行轉換作業

本指南說明如何使用 Datastream 和 Dataflow，將即時資料庫遷移作業從 MySQL 來源執行個體轉換至 Spanner 資料庫。

事前準備

執行轉換前，請確認您已完成下列工作，做為即時資料遷移作業的一部分：

  1. 結構定義遷移：將結構定義部署至 Spanner。詳情請參閱「從 MySQL 遷移結構定義」。
  2. 回填遷移：使用回填遷移 Dataflow 工作完成初始資料遷移。詳情請參閱「執行補充遷移」。
  3. 啟用 CDC 複製功能：確認持續變更資料擷取 (CDC) 複製功能已啟用且正常運作：
    • Datastream 串流會主動從來源 MySQL 資料庫讀取變更事件，並將這些事件寫入 Cloud Storage bucket。
    • Cloud Storage bucket 通知會將物件建立事件發布至 Pub/Sub 主題。
    • 串流 Dataflow 工作 (Cloud_Datastream_to_Spanner) 會使用 Pub/Sub 訂閱項目，並將變更寫入 Spanner，複製延遲時間不到一秒或可忽略不計。詳情請參閱「遷移 MySQL 資料」。
  4. 初始資料驗證：執行資料驗證檢查，確認來源 MySQL 執行個體和 Spanner 目標之間的資料一致性。詳情請參閱「驗證資料遷移作業」。
  5. 清除無效信件佇列 (DLQ) 狀態：確認 Cloud Storage 中的轉送複製嚴重 DLQ 目錄 (例如 gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) 完全空白。如果發生嚴重錯誤，請解決根本問題，並在開始轉換前，使用 retryDLQ 批次工作重播所有失敗的變更事件。詳情請參閱「監控及解決 CDC DLQ 錯誤」。
  6. 反向複製設定 (備用準備)：如果您需要應變備用路徑，請設定從 Spanner 回到來源 MySQL 資料庫的主動反向複製管道。詳情請參閱「設定備用 MySQL」。

必要的角色

執行轉換

以下各節說明如何排空寫入管道，並在切換應用程式寫入作業前，確認所有來源變更都已複製到 Spanner。

驗證管道健康狀態和 DLQ 狀態

暫停應用程式寫入流量或啟動停機時間前，請確認轉送複製管道的 DLQ 中沒有滯留的變更事件：

  1. 在 Google Cloud 控制台，前往 Dataflow 串流管道的「Job details」(工作詳細資料) 頁面。
  2. 在「Custom metrics」(自訂指標) 分頁中，檢查 Total permanent errors 自訂計數器。

  3. 如果這個計數器大於 0，請檢查 Cloud Storage 嚴重 DLQ 目錄 (例如 gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/)，並確認該目錄為空白。

暫停應用程式寫入作業

  1. 暫停應用程式的所有資料庫寫入流量。
  2. 允許來源 MySQL 主要執行個體上的有效交易完全提交並排空。

追蹤及暫停 Datastream

  1. 前往 Google Cloud 控制台的串流「Stream details」頁面。
  2. 在「Monitoring」(監控) 分頁中，查看「Data freshness」(資料更新間隔) 圖表 (Cloud Monitoring 指標類型：datastream.googleapis.com/stream/freshness)。等待指標值降至 0。這表示 Datastream 已擷取並處理所有來源資料庫變更，直到寫入作業暫停為止。詳情請參閱「監控串流」。

  3. 確認沒有任何複製事件通過串流。在「監控」分頁中，檢查「輸送量」圖表 (監控指標類型：datastream.googleapis.com/stream/event_count)，並確認事件率為 0。

    或者，如要使用 Metrics Explorer 以程式輔助方式驗證，請使用 Monitoring Query Language (MQL) 查詢事件計數：

    fetch datastream.googleapis.com/Stream
| metric 'datastream.googleapis.com/stream/event_count'
| filter (resource.stream_id == 'STREAM_ID')
| align rate(1m)
| group_by [], [value_event_count_sum: sum(value.event_count)]
| every 1m
     將 STREAM_ID 替換為串流 ID。

    確認這項指標至少連續兩個匯總週期回報 0。

  4. 使用Google Cloud 控制台或 API 暫停 Datastream 串流，並等待串流狀態變更為 PAUSED。

等待處理中的變更資料排空

  1. 前往 Google Cloud 控制台的串流「Stream details」頁面。
  2. 在「監控」分頁中，檢查「系統延遲」圖表 (監控指標類型：datastream.googleapis.com/stream/system_latencies)。
  3. 請記下第 99 個百分位數 (P99) 延遲時間值，並在暫停串流後，等待至少兩倍的 P99 系統延遲時間加上 30 秒。這段等候期間可確保暫停前產生的所有變更資料檔案，都已安全寫入 Cloud Storage，且其物件建立事件已發布至 Pub/Sub。
  4. 確認串流 Dataflow 工作已處理所有待處理的變更事件。前往 Google Cloud 控制台的 Pub/Sub「Subscriptions」(訂閱項目) 頁面，然後選取在 CDC 遷移設定期間建立的訂閱項目。
  5. 在「Monitoring」(監控) 分頁中，檢查「Unacknowledged message count」(未確認訊息數量) 圖表 (監控指標類型：pubsub.googleapis.com/subscription/num_undelivered_messages)，確認數量為 0。

確認複製作業已完成

  1. 確認串流 Dataflow 管道已完成寫入所有複製的變更。在串流工作的「Job details」(工作詳細資料) 頁面中，選取「Custom metrics」(自訂指標) 分頁標籤，然後檢查 Replication lag total latency_MAX 使用者計數器。等待計數器值達到 0。

    或者，您也可以在 Metrics Explorer 中使用 MQL 查詢使用者計數器： 

    fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'Replication lag total latency_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
     將 JOB_ID 替換為 Dataflow 工作的 ID。

  2. 確認目標 Spanner 資料庫已停止寫入活動。在目標資料庫的「資料庫詳細資料」頁面，選取「監控」分頁標籤，然後檢查「寫入輸送量」圖表 (監控指標類型：spanner.googleapis.com/transaction_stat/total/bytes_written_count)。確認寫入輸送量在至少連續兩個 1 分鐘的匯總期間內為 0。

  3. 最後檢查轉送複製作業 DLQ。檢查 Cloud Storage 中的嚴重和重試 DLQ 目錄 (例如 gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ 和 gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/)，確認這些目錄仍為空白。

  4. 排空串流 Dataflow 工作：

    1. 前往 Google Cloud 控制台，查看串流工作的「Job details」(工作詳細資料) 頁面。
    2. 依序點選「停止工作」>「排空」>「停止工作」。
    3. 等待工作狀態變更為 Drained。詳情請參閱「停止執行中的管道」。

  5. 執行排空後 DLQ 驗證：工作狀態變更為 Drained 後，請最後一次檢查 Cloud Storage 中的嚴重和重試 DLQ 目錄。確認在傳輸中的資料耗盡時，沒有出現新的錯誤檔案。如果存在任何檔案，請解決並重新播放。詳情請參閱「監控及解決 CDC DLQ 錯誤」。

執行應用程式轉換

將應用程式資料庫連線切換至 Spanner，然後繼續即時讀取和寫入流量：

  1. 更新應用程式設定或資料庫連線字串，指定 Spanner 資料庫。
  2. 啟動應用程式服務，並確認即時讀寫流量能順利對 Spanner 執行。
  3. 監控反向複製管道，確認是否有錯誤。如果 Spanner 寫入作業無法複製回 MySQL，Dataflow 會將失敗的記錄儲存到 Cloud Storage 的 DLQ 目錄 (例如 gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/)。請定期檢查這個路徑，確認路徑仍為空白。如果出現失敗的記錄，請參閱「監控及解決反向複製錯誤」。

後續步驟