执行回退到 MySQL

本指南介绍了如何从 Spanner 执行回退和灾难恢复回滚到源 MySQL 实例。

如果您在切换到 Spanner 后遇到意外的性能下降、不可恢复的应用错误或严重的功能性阻碍，请按照以下部分中的步骤回滚到 MySQL 主实例：

准备工作

在启动回退程序之前，请验证以下前提条件：

  1. 活跃的反向复制：验证反向复制 Dataflow 流水线 (Spanner_to_SourceDb) 是否正在运行，并且是否以 forward_migration 过滤模式主动使用 Spanner 变更数据流。如需了解详情，请参阅 配置后备到 MySQL。
  2. 来源 MySQL 可用性：验证来源 MySQL 数据库是否 在线、可从 Dataflow 访问，并且能够接受写入 连接。
  3. 维护窗口：提醒利益相关方，在 Spanner 写入暂停且反向复制耗尽时，需要计划停机时间。

所需角色

暂停 Spanner 写入

  1. 暂停应用中所有对 Spanner 的数据库写入流量。
  2. 允许 Spanner 上的活跃事务完全提交并耗尽。

允许反向复制耗尽

以下部分介绍了如何验证在割接应用写入之前，写入 Spanner 的所有更改是否都复制回 MySQL。

监控复制延迟

跟踪复制延迟，以验证所有正在进行的更改是否都写入 MySQL：

  1. 在 Google Cloud 控制台中，前往反向 复制 Dataflow 作业的 作业详情 页面。
  2. 在自定义指标 标签页中，检查 replication_lag_in_seconds_LOGICAL_SHARD_NAME_MAX 用户计数器。如需了解详情，请参阅 配置回退到 MySQL。
  3. 等待计数器值达到 0。

或者，在 Metrics Explorer 中，使用 Monitoring Query Language (MQL) 查询用户计数器： 

fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'replication_lag_insecondsLOGICAL_SHARD_NAME_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
替换以下内容： * JOB_ID：反向复制 Dataflow 作业的 ID。 * LOGICAL_SHARD_NAME：逻辑分片名称 为来源数据库配置。

验证 MySQL 写入活动

验证反向复制写入操作是否已在来源数据库上完成：

  1. 在来源 MySQL 主数据库中，检查活跃查询和数据库连接指标。
  2. 验证反向复制流水线的写入流量是否已停止。

验证干净的 DLQ 状态

检查死信队列 (DLQ)，以验证在反向复制期间是否未发生任何未处理的错误：

  1. 在 Google Cloud 控制台中，前往反向 复制 Dataflow 作业的 作业详情 页面。在自定义指标 标签页中，检查 severe_error_count 用户计数器。

  2. 检查 Cloud Storage 中的严重错误和重试反向复制 DLQ 目录（例如 gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/ 和 gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/retry/）。

    您可以使用 gcloud CLI 列出严重错误 DLQ 目录的内容：

    gcloud storage ls gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/

    替换以下内容：

    • MIGRATION_BUCKET：Cloud Storage 存储桶的名称。
    • ENV：部署环境名称（例如 prod）。
    • SERVICE：应用或服务名称。
    • DB_SCHEMA：数据库架构名称。

  3. 验证 DLQ 目录是否完全为空。

  4. 如果存在错误文件，请先解决底层问题并重放失败的记录，然后再继续。如需了解详情，请参阅 监控和解决反向复制错误。

恢复正向 CDC 流式传输

如果您计划日后恢复到 Spanner 的正向迁移，请恢复正向 Datastream 流：

  1. 在 Google Cloud 控制台中，前往数据流的**数据流详情**页面。
  2. 点击恢复，然后等待数据流状态变为 RUNNING。如需了解详情，请参阅 迁移 MySQL 数据。

或者，如需使用 gcloud CLI 恢复数据流，请运行 gcloud datastream streams resume 命令：

gcloud datastream streams resume STREAM_ID \
    --location=LOCATION

替换以下内容：

  • STREAM_ID：Datastream 流的 ID。
  • LOCATION：数据流所在的 Google Cloud 区域。

将写入重新路由到 MySQL

  1. 更新应用配置和数据库连接字符串，以将来源 MySQL 主数据库实例作为目标。
  2. 启动应用服务，并恢复针对 MySQL 的实时读取和写入流量。
  3. 验证应用读取和写入操作是否针对 MySQL 数据库成功运行。

后续步骤