Is it possible for dragonflydb to provide bi-directional replication capabilities？

[zmysysz]

Differing from redis, can the function of bi-directional replication be implemented to synchronize data between two data centers?

[romange]

Dragonfly does not provide Active-Active replication capabilities.

[chakaz]

I am not sure exactly what you mean by bi-directional replication.
When Dragonfly runs in a replica-mode it does not allow to directly run mutating commands (like SET) against the replica. Such commands are only allowed to run against the master.
So, at least presently, bi-directional doesn't make sense.
Do you wish to have 2 masters, each responsible for a subset of the data, and each replicating their data to the other master?
Why not have masters in a cluster owning data, and replicas ready to take over in case of a failure?

[zmysysz]

yes thx，

We mainly want two clusters or masters and slaves to be able to synchronize data bi-directionally in a multi-data center scenario. To avoid the application layer to read and write data across data centers, in fact, such a design will be used in two places, three centers, off-site multi-live and other scenarios. Due to the existence of loopback problems, redis itself does not have this capability
Drawing a crude schematic

[romange]

Thanks. yeah, it's called active-active. What's your API footprint, can you provide "redis-cli info all" output from your existing redis cluster? How you would expect the conflicts would be resolved in case multiple writes change concurrently the same key in both masters?

[zmysysz]

Yes, active-active so called more accurate, thanks for the correction, we currently do not have the relevant implementation, just explore the feasibility, according to my research, there are some solutions in the industry, mainly through the support of the instance id in the rdb and aof to avoid ring replication, you said that the same key written multiple times, in fact, asynchronous bi-directional synchronization scenarios do not require a high level of requirements (caching of data), the final consistency of the program through the vector clock and other programs to achieve is acceptable

[romange]

I understand. The reason I asked about the API is because it's simpler to achieve with idempotent operations like SET/MSET but tricky with commands like LPUSH. In any case, we currently do not support this feature.

[zmysysz]

I got it, thanks, it's true that non-idempotent data types or commands can be difficult to implement, and it's also true that some of the commands are not supported in existing solutions, regardless, thanks for the answer!