一次马虎大意造成的事故

2021年11月12日16:26:39 2 219 ℃

最近生产环境服务器快到期了,就想着把一直使用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未停止的原因。

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

精选全网爆款产品,爆品销量榜单,全场低至0元起,还有更多云产品免费试用,带你0门槛上云

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

目前评论:2   其中:访客  0   博主  0

    • avatar 流量卡 0

      所有的灾难都是人祸

        • avatar 阿汤博客 Admin

          @流量卡 的确,大部分灾难都是人为造成的,这其中很大部分都是因为粗心大意。