从 MySQL 执行割接

本指南介绍了如何使用 Datastream 和 Dataflow 执行从 MySQL 源实例到 Spanner 数据库的实时数据库迁移的割接。

准备工作

在执行割接之前，请验证您是否已完成以下任务作为实时数据迁移的一部分：

  1. 架构迁移：将架构部署到 Spanner。如需了解详情，请参阅 从 MySQL 迁移架构。
  2. 回填迁移：使用回填迁移 Dataflow 作业完成初始数据迁移 。如需了解 详情，请参阅执行回填迁移。
  3. 活跃 CDC 复制：验证持续变更数据捕获 (CDC) 复制是否处于活跃且正常运行状态：
    • Datastream 流正在主动从 MySQL 源数据库读取更改事件，并将其写入 Cloud Storage 存储桶。
    • Cloud Storage 存储桶通知正在将对象创建事件发布到 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 流水线的 作业详情页面。
  2. 在自定义指标 标签页中，检查 Total permanent errors 自定义计数器。

  3. 如果此计数器大于 0，请检查 Cloud Storage 严重 DLQ 目录（例如 gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/），并验证该目录是否为空。

暂停应用写入

  1. 暂停应用上的所有数据库写入流量。
  2. 允许 MySQL 主实例上的活跃事务完全提交和排空。

跟踪和暂停 Datastream

  1. 在 Google Cloud 控制台中，前往流的流详情页面。
  2. 在监控 标签页中，检查数据新鲜度 图表（Cloud Monitoring 指标类型：datastream.googleapis.com/stream/freshness）。等待指标值减小到 0。这表示 Datastream 捕获并处理了所有源数据库更改，直到写入暂停的那一刻。如需了解详情，请参阅 监控流。

  3. 验证没有复制事件通过流。在监控 标签页中，检查吞吐量 图表（Monitoring 指标类型：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 控制台中，前往流的流详情页面。
  2. 在监控 标签页中，检查系统延迟时间 图表（Monitoring 指标类型：datastream.googleapis.com/stream/system_latencies）。
  3. 记下第 99 个百分位 (P99) 延迟时间值，并在暂停流后等待至少两倍的 P99 系统延迟时间加 30 秒。此等待时间有助于确保在暂停之前生成的所有更改数据文件都安全地写入 Cloud Storage，并且其对象创建事件发布到 Pub/Sub。
  4. 验证流式 Dataflow 作业是否使用了所有待处理的更改事件。在 Google Cloud 控制台中，前往 Pub/Sub 订阅 页面，然后选择 在 CDC 迁移设置期间创建的订阅。
  5. 在监控 标签页中，检查未确认的消息数 图表（Monitoring 指标类型：pubsub.googleapis.com/subscription/num_undelivered_messages），并验证计数是否为 0。

验证复制是否已完成

  1. 验证流式 Dataflow 流水线是否已完成写入所有复制的更改。在流式作业的作业详情 页面上，选择自定义指标 标签页，然后检查 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 数据库上的写入活动是否已停止。 在目标数据库的数据库详情 页面上，选择监控 标签页，然后检查写入吞吐量 图表（Monitoring 指标类型：spanner.googleapis.com/transaction_stat/total/bytes_written_count）。验证写入吞吐量是否至少连续两个 1 分钟的汇总周期为 0。

  3. 对正向复制 DLQ 执行最终检查。检查 Cloud Storage 中的严重 DLQ 目录和重试 DLQ 目录（例如 gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ 和 gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/），以验证它们是否保持为空。

  4. 排空流式 Dataflow 作业：

    1. 在 Google Cloud 控制台中，前往流式作业的作业详情 页面。
    2. 点击停止作业 ，选择排空 ，然后点击停止作业 。
    3. 等待作业状态更改为 Drained。如需了解详情，请参阅 停止正在运行的流水线。

  5. 执行排空后 DLQ 验证：作业状态更改为 Drained 后，最后一次检查 Cloud Storage 中的严重 DLQ 目录和重试 DLQ 目录。验证在传输中的数据排空时是否没有出现新的错误文件。如果存在任何文件，请解决并重放它们。如需了解详情，请参阅 监控和解决 CDC DLQ 错误。

执行应用割接

将应用数据库连接切换到 Spanner，并恢复实时读写流量：

  1. 更新应用配置或数据库连接字符串，以将 Spanner 数据库作为目标。
  2. 启动应用服务，并验证实时读写流量是否针对 Spanner 成功运行。
  3. 监控反向复制流水线是否存在错误。如果 Spanner 写入无法复制回 MySQL，Dataflow 会将失败的记录保存到 Cloud Storage 中的 DLQ 目录（例如 gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/）。定期检查此路径，以验证它是否保持为空。如果出现失败的记录 ，请参阅 监控和解决反向复制错误。

后续步骤