Chronos节点down机，RocksDB中的延迟消息数据怎么处理？ about ddmq

[joycgj]

一组Chronos里有主备两台机器，如果主down掉了，备则会接管。
down掉的机器如果短时间内恢复，broker上的消息还没有删除，则可以直接运行。
down掉的机器如果长时间无法恢复，borker上的消息可能已经删除或者硬盘有问题，则需要从主上进行数据的同步，然后再开始运行。

[reallax]

@joycgj 我对RocksDB不是很熟悉，但看文档RocksBD是一个嵌入式数据库引擎，它并未提供远程访问的功能。1）两台Chronos节点是如何共用一个RocksDB实例数据的呢？

broker上的消息还没有删除

2）这里的Broker是指Chronos，还是指inner_delay_topic的Broker？

需要从主上进行数据的同步，然后再开始运行

3）这里的同步，是手动的还是自动的？

谢谢您回答。

[lybuestc]

@joycgj 我对RocksDB不是很熟悉，但看文档RocksBD是一个嵌入式数据库引擎，它并未提供远程访问的功能。1）两台Chronos节点是如何共用一个RocksDB实例数据的呢？

broker上的消息还没有删除

2）这里的Broker是指Chronos，还是指inner_delay_topic的Broker？

需要从主上进行数据的同步，然后再开始运行

3）这里的同步，是手动的还是自动的？

谢谢您回答。

1. 不共用，每台机器本地的RocksDB，使用不同的group从同一个队列消费的全量数据，两边数据一样。
2. 是指inner_delay_topic的Broker，比如broker上保存消息配置的是2天，那么2天内只要能够重新起来就不需要做数据同步，启动后会消费到这些数据。如果是磁盘坏了或者超过了2天都没有再次启动，那么就需要从主上同步一份数据过来，这个过程是手动的。
3. 见2

[susonglin]

一组的Chronos里有主备两台机器，如果主降掉了，备则会接管。
向下掉的机器如果短时间内恢复，经纪人上的消息还没有删除，则可以直接运行。
向下掉的机器如果长时间无法恢复，借款人上的消息可能已经删除或硬盘有问题，则需要从主上进行数据同步，然后再开始运行。

我理解您的回复是指master和salve数据不一致的处理方式。

我的疑问是：如果master宕机后，这时slave接管，由于主从之间不共用同一个rocksdb实例，那么slave怎么知道master已经消费到哪里了呢

期望您的回复

[Jason918]

我的疑问是：如果master宕机后，这时slave接管，由于主从之间不共用同一个rocksdb实例，那么slave怎么知道master已经消费到哪里了呢

主的消费位点会定时上报至zk，slave 最多只会消费到主已经上报的位点。

[susonglin]

我的疑问是：如果master宕机后，这时slave接管，由于主从之间不共用同一个rocksdb实例，那么slave怎么知道master已经消费到哪里了呢

主的消费位点会定时上报至zk，slave 最多只会消费到主已经上报的位点。

感谢您的回复，我明白了

[cserwen]

@Jason918 您好，新的主节点该从哪里开始投递消息到目标的Topic中，是主节点会定时将投递位点同步到zk吗？如果是，这样会不会导致重复投递

[Jason918]

@Jason918 您好，新的主节点该从哪里开始投递消息到目标的Topic中，是主节点会定时将投递位点同步到zk吗？如果是，这样会不会导致重复投递

@cserwen
是。同步的频率是一秒。同一秒内的消息会重复。

整体上是保证消息必达，下游需要在异常情况下去重。