Skip to main content
完成前置条件梳理▸的情况下，可以进行后续的迁移流程。本文详细介绍从 Apache Kafka 迁移到 AutoMQ 的方案以及实施流程。 开始生产迁移前，请先阅读 Kafka Linking 最佳实践，并将适用的接入点、客户端切流、消费位点、Topic 提升和回滚检查项纳入迁移手册。

​
迁移方案

使用 Kafka Linking 从 Apache Kafka 迁移到 AutoMQ，主要考虑如下工作：
  • 消息数据同步 ：Kafka 存储了历史已消费和未消费的消息数据，迁移集群需要保证消息数据按需复制到新集群，不能丢失消息。
  • 生产者切换： 迁移工作除去数据同步，还需要在合适的时机切换生产者应用，使生产者连接目标集群生产新的消息。
  • 消费者切换： 迁移工作除去数据同步，还需要在合适的时机切换消费者应用，使消费者连接目标集群接续之前的消费进度继续消费消息。
整体迁移方案参考下图的流程： 整体迁移方案流程图，包含消息数据同步、生产者切换和消费者切换三个步骤

​
操作步骤

​
步骤 1：创建 Kafka Link，开始同步数据

在完成前置条件梳理▸后，已经明确当前需要迁移的源集群、目标集群、Topic、ConsumerGroup 范围，接下来开始创建迁移任务。 创建Kafka Link ，前点击目标实例 >> Kafka Links ，按照指引填写相关参数。 控制台中的候选列表来自源集群 Kafka API。输入搜索关键词后，控制台按名称包含关系匹配资源，例如输入 order 可以匹配 prod-order-v1；每次最多展示 100 条匹配结果。候选资源还会按以下规则过滤：
  • Source Topic： 展示 Kafka Linking 源端身份有权限查看、且未被识别为内部 Topic 的 Topic。不展示 Kafka 元数据标记的内部 Topic，以及名称以 __ 或 . 开头、以 -internal 或 .internal 结尾的 Topic。
  • Source Consumer Group： 展示 Kafka Linking 源端身份有权限查看、protocolType 为 consumer 或空值，且 Group ID 未命中产品内部前缀的 Group。不展示其他协议类型的 Group，例如 Kafka Connect 使用的 connect、部分实现中显示为 connector 的 Group；也不展示 Group ID 以 sys-cmp 或 karapace-autogenerated 开头的产品内部 Group。
候选列表仅表示资源可被当前源端身份发现，不代表一定可以成功创建。目标实例同名 Topic、已经创建的 Mirror 资源等冲突不会在源端候选列表中预先过滤，创建时仍会执行校验。如果预期的 Topic 或 Consumer Group 未显示，请先缩短搜索关键词，再检查名称、Group 协议类型、Group ID 前缀以及源端 Kafka ACL。Kafka Connect 等组件的内部 Topic 和协调 Group 不属于 Kafka Linking 的业务 Topic/Consumer Group 迁移范围，应按对应组件的迁移流程单独处理。详细检查项请参考 Kafka Linking 最佳实践。
如果目标实例已经存在与所选 Source Topic 同名的 Topic，则无法创建对应的 Mirror Topic。请先处理同名 Topic 冲突，再将该 Source Topic 添加到 Kafka Link。
Kafka Link 创建表单，包含源集群、目标集群和同步配置字段 选择目标 topic 和 Consumer Group。 Kafka Link 同步 Topic 和 Consumer Group 选择界面
  1. 创建完成后，可以进入 Kafka Link 详情，查看指定的 Topic 和 Group 都已经进入同步中 状态。Kafka Link 创建完成后，同样支持添加新的 Topic、Consumer Group。可以按需添加待迁移的业务资源。
如果在 Kafka Link 中删除 Mirror Topic、Consumer Group ，会从目标集群（AutoMQ 实例）中删除对应的 Topic 和 Consumer Group。此操作无法撤销，后续只能重新创建。
Kafka Link 详情页，显示 Topic 和 Consumer Group 的同步状态

​
步骤 2：切换生产者和消费者，执行迁移流程

当 Kafka Link 创建完成后，用户需要修改 Topic 的 Producer、Consumer 配置，将 Producer 和 Consumer 从源集群切换到目标集群，其主要包含以下三类操作：
  • 生产者切流： 更新生产者的接入参数，使其指向目标集群。
  • 消费者切流： 更新消费者的接入参数，使其指向目标集群。
  • 提升 Mirror Topic 状态 ：在 AutoMQ 控制台选择 Mirror Topic 进行状态提升，提升操作本质上是控制 Kafka Linking 组件不再代理 Producer 写流量以及从源集群复制数据。
具体 Producer 和 Consumer 切流的操作步骤参考下方阶段：

​
阶段一：Producer 切换到目标集群

迁移过程，首先切换 Producer 的接入配置，使 Producer 连接到目标集群（ AutoMQ 实例）。切换过程的流量拓扑如下图所示： 阶段一流量拓扑图：生产者切换到目标 AutoMQ 实例 操作步骤：
  • Producer 分批次修改接入参数重启应用，使生产流量切换到目标的 AutoMQ 实例。
此滚动切流步骤仅适用于未使用 Kafka 事务的 Producer。配置了 transactional.id 或依赖 exactly-once 语义的应用，应先停止源端事务型 Producer，等待目标端追平并提升相关 Mirror Topic，再在目标端启动。详细步骤请参考 Kafka Linking 最佳实践。
预期效果：
  • 生产流量分批次 Rolling 目标实例，预期生产流量不停机、无影响。
  • 源集群的消费者继续消费所有的消息，无影响。
  • 源集群消息会通过 Replicate 任务同步到 AutoMQ。
回滚操作：
  • 生产者回滚配置，切换回源集群即可。

​
阶段二：Consumer 切换到目标集群

第二阶段执行切换 Consumer 的接入配置，使 Consumer 连接到目标集群（ AutoMQ 实例）。切换过程的流量拓扑如下图所示： 阶段二流量拓扑图：消费者切换到目标 AutoMQ 实例 操作步骤：
  • Consumer 分批次修改接入参数并滚动发布，使实例逐步连接到 AutoMQ 实例。
  • 对于使用 subscribe 和 group.id 参与 Group 管理的标准 Consumer，目标 Mirror Group 仍为 LINKING 时，已切换到目标端的实例无法获得分区分配，不会开始消费。随着源端实例逐批退出，剩余源端实例需要承担全部消费流量，请控制滚动批次并监控源端处理能力和积压。
  • 源端 Consumer 实例全部退出后，数据面检测到源 Group 已无活跃成员并自动提升 Consumer Group。数据面每 10 秒调度一次已登记的 Group；如果上一次检查时源 Group 仍有活跃成员，同一 Group 默认至少间隔 30 秒再次检查。
  • Consumer Group 提升、目标端 rebalance 和分区分配完成之前，会存在短暂消费暂停。必须等 Group 进入 PROMOTED，并确认目标 Consumer 已获得分区分配且消费进度持续推进。
切换 Consumer 之前，应满足以下条件对每个分区确认 Consumer 的实际启动位点处于 AutoMQ 实例当前 Topic 的可读范围内：
例如，Consumer 在 Partition X 的实际启动位点为 100：若目标端可读范围为 [80, 150]，则可以切换；若为 [120, 150]，说明位点 100 对应的历史消息已不可读；若为 [80, 90]，说明目标端尚未复制到位点 100，应继续等待目标端追平。实际启动位点可能来自 Kafka Consumer Group 已提交位点、Flink checkpoint/savepoint 或应用自管存储。详细判断方法请参考 Kafka Linking 最佳实践。
预期效果：
  • 生产流量仍然维持上一阶段的状态，继续代理回源集群并同步到目标集群。
  • Consumer Group 会继续源集群的消费位点，继续消费，不受影响。
回滚操作：
  • Consumer 回滚配置，切换回源集群即可。
因源集群的消费位点不会自动更新，回滚前建议先重置位点，否则可能会产生消费重复。

​
阶段三：提升 Mirror Topic 状态

在确保所有的 Producer 和 Consumer 都已经完成切换并且符合预期后，即可提升 Mirror Topic 的状态，停止写流量代理和同步。 AutoMQ 控制台中提升 Mirror Topic 状态的操作步骤 操作步骤：
  • 在 Consumer 切换完成后，建议观察一段时间，确保 Producer、Consumer 应用运行符合预期。
  • 确认符合预期后，在 AutoMQ 控制台，点击提升 Mirror Topic，停止流量代理和复制。
提升 Mirror Topic 之前务必确保以下条件：
  • 所有普通 Producer 实例已连接目标 AutoMQ，且没有业务 Producer 仍使用源集群接入点直接写入。Kafka Linking 在 LINKING 阶段仍会连接源集群，因此不能仅根据源集群存在连接判断业务 Producer 尚未切换。
  • 对事务型 Producer，源端实例已停止、事务已结束、目标端已追平，并且目标端事务型 Producer 尚未启动。
  • 所有 Consumer 实例已连接目标端，源 Consumer Group 已无活跃成员，Consumer Group 已完成提升且目标消费者运行稳定。
  • 复制延迟已收敛，没有持续的网络、认证或请求错误，并已明确提升后的回滚和数据对账方案。
完整门禁和验证方法请参考 Kafka Linking 最佳实践。
预期效果：
  • Mirror Topic 的读写全部集中在目标集群，不再代理回源集群。
回滚操作：
  • Mirror Topic 提升后目标集群的消息数据多于源集群，此时回滚需要注意消息数据不一致。
确认 Kafka Link 中全部 Mirror Topic 和 Consumer Group 均已完成提升，并且目标实例上的生产、消费和关键业务结果通过验收及观察窗口后，可以直接删除 Kafka Link。删除 Kafka Link 标志着本次迁移彻底结束。 迁移完成后删除 Kafka Link 的操作界面
完成迁移时只删除 Kafka Link 本身。不要删除 Kafka Link 中已经提升的 Mirror Topic 或 Consumer Group；该操作会真实删除目标 AutoMQ 实例中对应的 topic 或 Group。
删除 Kafka Link 后，建议停止源集群的新业务写入并将其静置一段观察时间，但暂时保留源端数据和必要的访问能力。确认目标端持续稳定且不再需要回滚或数据对账后，再回收源集群相关资源。详细退出条件和检查项请参考 Kafka Linking 最佳实践。