摘要：
一、项目背景由于当前生产环境RocketMQ机器使用年限较长，已经过保，并且其中一台曾经发生过异常宕机事件。
一、项目背景
由于当前生产环境RocketMQ机器使用年限较长，已经过保，并且其中一台曾经发生过异常宕机事件。并且早期网络规划较乱，生产、开发、测试等网络没有分开，公司决定对当前网络进行规划，区分各个环境网段、机柜，涉及到MQ集群需要迁移，由于物理机比较老旧，使用决定使用新机器替换老机器，并且之前的MQ集群为多master模式，当master宕机是会导致部分消息不可消费，决定将模式同时修改为多master多slave同步双写同步刷盘模式(本公司生产MQ压力较小，如果MQ压力大可以使用异步刷盘模式)
二、多master多slave集群功能性测试及集群测试结果如下
三、迁移步骤及遇到问题和解决方案
1.更新当前topic路由负载到所有broker上
执行该操作的原因：由于公司RocketMQ早期上线是没有深入研究，很多特性都不很了解，够用就行，很多地方没有考虑到。经过测试环境测试并查看生产MQ路由现象，发现如果topic首次发送的消息30秒内少于(N-1)*4+1个(N表示master个数)，那么该topic路由只会存在部分broker上，这样会存在两个问题：1.topic无法达到负载均衡的效果 2.如果topic所在的broker宕机，会导致该topic无法生产及消费
topic路由更新方案(二选一，具体看你心情选择)
1.1.通过rocketmq控制台修改(生产验证通过)
1.2.使用其他broker上的Topics.json文件替换本地，该文件在storePathRootDir配置项指定的的目录下config目录内，替换后重启服务生效(生产验证通过)
注意事项：通常Topics.json文件会从当前MQ集群的第一台机器上拷贝。例，我们当前生产MQ集群分别为158.7 158.8 158.9 ，集群中第一台broker为158.7，默认情况下如果不人为指定topic路由信息，其他两台可能不会存在所以的topic路由，但是，第一台(158.7)通常会都拥有所以topic的路由信息
2.依次修改当前生产MQ集群模式，由多master修改为多master多slave模式，并设置同步双写同步刷盘(后续模式看具体情况定)，步骤忽略，会主从部署添加slave应该不在话下，此步操作无风险
3.关闭一台master，并等待slave消息消费完毕，注意下面的操作步骤：
1.首先先通知nameserver，我这台broker马上要下线啦，不要再给我发消息啦，阿里提供的命令如下 sh mqadmin wipeWritePerm -b brokerName -n namesrvAddr 实际执行的命令为 sh mqadmin wipeWritePerm -b broker-a -n 172.16.158.7:9876 sh mqadmin wipeWritePerm -b broker-a -n 172.16.158.8:9876 sh mqadmin wipeWritePerm -b broker-a -n 172.16.158.9:9876 有几台nameserver就执行几次，虽然帮助问题提示可以以;符号为分隔符，一次写入多个，但是执行报错 2.等待1~2分钟后关闭当前broker(因为延迟类消息slave无法消费，所以略微多等一下) sh mqshutdown broker #关闭broker
4.修改master的IP地址或者关机，修改slaveIP地址为master地址并修改配置文件为master模式，重启生效
碰到的问题： slave升级为master时，查看日志，日志文件有大量"WARN ScheduleMessageTimerThread - findMapedFileByOffset offset not ..." 日志，并且消息无法写入
解决方法：
删掉当前服务器storePathRootDir配置项指定的的目录下所有，在启动服务，拷贝其他服务器Topics.json到本地，在重启(生产验证通过，也许有更简单的方法，暂时没想到)