大型 kafka 集群平滑迁移

雨翔河

首页列表关于

大型 kafka 集群平滑迁移

2019-11-12 16:27

我们有一套kafka集群属于比较大的业务量在用的，里面的消息很重要且量大，因为历史原因，部署在虚拟机上，现在想在双十一高峰来临前完全迁移到物理机。

迁移之前还是很担心数据是否丢失或者对应用有影响，能否做到平滑迁移，所以挑选了业务量少的凌晨2点半开始操作。

### 以下是实现方案：

1. 配套的zk迁移就比较简单了，起新节点加入zk集群，稳定后关停旧节点。
2. 新增N个broker加入集群，将所有topic分区只分配给新broker，执行分配任务后，kafka将旧broker的分区数据复制到新broker，新broker成为各分区的leader，随后kafka删除旧broker上的分区数据；
3. 整个过程中客户端应用正常生产消费消息，执行结束后使用新的消费者组从头消费可以获取到全部历史消息。
4. 停止旧broker后，正在运行的客户端应用正常生产消费消息，新建客户端连接旧broker失败，连接新broker则正常。

### 真实的执行过程：

zk的迁移过程很快，但是会有少量的提交元数据失败（因为业务量少）。

凌晨2点多，这个时候的kafka的消费者的数据消费是稳定的，没有积压，修改下保留的kafka消息日志时间为3小时，这样起来的新节点数据同步就可以很快完成。

新节点起来后，利用 `kafka-reassign-partitions.sh` 来将所有topic的partition完全分配到新加入的节点，旧节点不分配topic。

这个迁移过程是很慢的，虽然是凌晨2点多（只保留了3个小时的日志消息数据），但是这个数据量也不少，耗时25分钟左右，迁移数据超过90G。

迁移过程中应用会有少量的提交到kafka失败的情况，报错有如下三种：

1.
```
at offset xxxxxxxx:  This is not the correct coordinator.
```

2.
```
Offset commit failed on partition xxxxxxQueue-5 at offset xxxxxxxx: The request timed out.
```

3.
```
Caused by: org.apache.kafka.common.errors.NotLeaderForPartitionException: This server is not the leader for that topic-partition.
```

这种提交失败有重试，所以问题不大，且此时业务量不多，即使出现数据丢失的情况也可以通过捞日志。

25分钟后，旧节点所有的topic的partition已经迁移到了所有新节点，所有旧节点已经是'空'的了。

因为我们应用配置的kafka集群连接的地址都是用的域名，所以此时在数据同步迁移完成确认后，就可以修改域名映射到kafka新节点的ip，这个时候DNS生效需要将近10分钟。

10分钟后，我们提前准备的脚本去几乎所有的应用ping域名，发现映射已经生效，这个时候可以开始关闭旧节点，关闭旧节点对业务已经没有任何影响。

旧节点关闭后，这个时候的kafka集群已经完全迁移到了物理机，原有的虚拟机可以考虑回收。

迁移过程应用几乎没有影响（当然，客观原因是因为凌晨业务量少），应用也不需要做任何变更，完成平滑迁移。

**注：在迁移完成之后，应用最好做一次无缝的重启操作，防止出现不同的线程消费到了同一个partition，或者有的partition没有分配到消费者线程。**

类型：工作标签：kafka,迁移