最近生產(chǎn)環(huán)境服務(wù)器快到期了，就想著把一直使用docker-compose部署的canal和elasticsearch遷移到kubernetes集群。

由于在這之前開發(fā)、測試、預(yù)生產(chǎn)的canal我都已經(jīng)遷移到了kubernetes集群，也已經(jīng)跑了好幾個月的時間了，沒什么問題，所以這次遷移也是信心滿滿。

我們的業(yè)務(wù)場景基本上到晚上就使用的人就比較少了，為了不影響業(yè)務(wù)，因此我把遷移時間定在了晚上12點。

白天就把相關(guān)yaml編寫好了，就等到晚上12點以后停掉相關(guān)服務(wù)，遷移elasticsearch數(shù)據(jù)到NAS，然后啟動canal、elasticsearch和后端服務(wù)就一切OK。

晚上遷移也一切正常，遷移完也測試了同步功能一切都正常。

第二天到公司上班以后，運營反饋部分新增數(shù)據(jù)，無法搜索。

我馬上去看了canal的日志，發(fā)現(xiàn)大量的報錯日志：

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的報錯，當(dāng)時我還分享了解決方法《canal無法連接阿里云rocketMQ解決辦法》，但是都過去一年半的時間了，細節(jié)早就忘記了。我也去看了下我分享的文章，也對照了版本都是1.1.4，其他MQ參數(shù)我也配置了。

然后又去看了下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官方文檔，有介紹這個參數(shù)：

明明寫的可以忽略該值，而且我使用的也1.1.4版本，而且都是使用的同一個鏡像，不應(yīng)該報這樣的錯誤。

然后帶著疑問去canal GitHub 的issues里面搜索了一下報錯信息。

找到了兩個相關(guān)的issues:

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

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

發(fā)現(xiàn)原來是有一個bug導(dǎo)致的，配置上canal.aliyun.accessKey和canal.aliyun.secretKey就可以了（最新的代碼已經(jīng)修復(fù)，應(yīng)該是1.1.6已經(jīng)修復(fù)了）。

于是我馬上修改了canal的yaml文件，配置了這兩個變量，然后啟動測試，發(fā)現(xiàn)正常了。

此時我更納悶了，為什么docker-compose沒配置這兩個參數(shù)就能正常，使用kubernetes部署的就有問題，鏡像都是同一個。

然后又去看了canal的docker-compose.yaml文件，發(fā)現(xiàn)我配置了這兩個參數(shù)（那一瞬間只想給自己一個巴掌）。

canal的yaml文件，我直接復(fù)制的測試環(huán)境的文件再修改的，因為測試環(huán)境使用的是自建RocketMQ，現(xiàn)在回想當(dāng)時應(yīng)該只關(guān)注mq相關(guān)的參數(shù)去了，沒關(guān)注其他參數(shù)，導(dǎo)致了這個問題。

如果當(dāng)時在修改yaml文件，仔細一點，對比一下canal的docker-compose.yaml文件里面的環(huán)境變量，也不會出現(xiàn)這個問題。

而且我的文章《canal無法連接阿里云rocketMQ解決辦法》里面也提到了accessKey、secretKey這兩個參數(shù)，我看的時候也沒注意到（再給自己一個巴掌）。

至于當(dāng)時遷移以后測試同步為什么正常，回想應(yīng)該是測試的時候，原來的canal未停止的原因。

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