最近生產環境服務器快到期了，就想著把一直使用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未停止的原因。

最后總結：做任何事情一定要仔細、仔細、再仔細。