一次马虎大意造成的事故

最近生产环境服务器快到期了，就想着把一直使用docker-compose部署的canal和elasticsearch迁移到kubernetes集群。

由于在这之前开发、测试、预生产的canal我都已经迁移到了kubernetes集群，也已经跑了好几个月的时间了，没什么问题，所以这次迁移也是信心满满。

我们的业务场景基本上到晚上就使用的人就比较少了，为了不影响业务，因此我把迁移时间定在了晚上12点。

白天就把相关yaml编写好了，就等到晚上12点以后停掉相关服务，迁移elasticsearch数据到NAS，然后启动canal、elasticsearch和后端服务就一切OK。

晚上迁移也一切正常，迁移完也测试了同步功能一切都正常。

第二天到公司上班以后，运营反馈部分新增数据，无法搜索。

我马上去看了canal的日志，发现大量的报错日志：

canal日志如下：

ERROR com.alibaba.otter.canal.rocketmq.CanalRocketMQProducer - send flat message to fixed partition error

org.apache.rocketmq.client.exception.MQClientException: No route info for this topic, MQ_INST_xxxxxxxxx%TOPIC_ATANG-TEST

看到这个报错，让我想起了第一次用canal连接阿里云的rocketMQ的报错，当时我还分享了解决方法《canal无法连接阿里云rocketMQ解决办法》，但是都过去一年半的时间了，细节早就忘记了。我也去看了下我分享的文章，也对照了版本都是1.1.4，其他MQ参数我也配置了。

然后又去看了下MQ客户端的日志。

RocketmqClient日志如下：

WARN RocketmqClient - updateTopicRouteInfoFromNameServer Exception

org.apache.rocketmq.client.exception.MQClientException: CODE: 1  DESC: com.aliyun.openservices.ons.api.impl.authority.exception.AuthenticationException: com.alibaba.ons.open.exception.OnsException: __accessKey is blank., com.alibaba.ons.open.auth.resource.AccessResource.parseAccessResource(AccessResource.java:182)

提示accessKey为空。

我马上去看了canal官方文档，有介绍这个参数：

明明写的可以忽略该值，而且我使用的也1.1.4版本，而且都是使用的同一个镜像，不应该报这样的错误。

然后带着疑问去canal GitHub 的issues里面搜索了一下报错信息。

找到了两个相关的issues:

https://github.com/alibaba/canal/pull/3220

https://github.com/alibaba/canal/issues/3064

发现原来是有一个bug导致的，配置上canal.aliyun.accessKey和canal.aliyun.secretKey就可以了（最新的代码已经修复，应该是1.1.6已经修复了）。

于是我马上修改了canal的yaml文件，配置了这两个变量，然后启动测试，发现正常了。

此时我更纳闷了，为什么docker-compose没配置这两个参数就能正常，使用kubernetes部署的就有问题，镜像都是同一个。

然后又去看了canal的docker-compose.yaml文件，发现我配置了这两个参数（那一瞬间只想给自己一个巴掌）。

canal的yaml文件，我直接复制的测试环境的文件再修改的，因为测试环境使用的是自建RocketMQ，现在回想当时应该只关注mq相关的参数去了，没关注其他参数，导致了这个问题。

如果当时在修改yaml文件，仔细一点，对比一下canal的docker-compose.yaml文件里面的环境变量，也不会出现这个问题。

而且我的文章《canal无法连接阿里云rocketMQ解决办法》里面也提到了accessKey、secretKey这两个参数，我看的时候也没注意到（再给自己一个巴掌）。

至于当时迁移以后测试同步为什么正常，回想应该是测试的时候，原来的canal未停止的原因。

最后总结：做任何事情一定要仔细、仔细、再仔细。