Replication service for Influxdb 3.0

Hello,

I would like to update from influxdb 2.x to 3.x and the replication plugin is must have for our application. I have read many articles that mentioned the service is available as a plugin managed by the community and also a new version is being developed by the influx team itself. Here: Edge Data Replication: Contributions and Status Updates for InfluxDB 3 | InfluxData

Unfortunately, I can not find any available plugin for replication. The mentioned link is empty: GitHub - influxdata/influxdb3_plugins: Python plugins for InfluxDB 3 · GitHub

Can you help me:

  1. Where is the community maintained plugin located?
  2. Any scheduled due date for the official EDR release?

BTW: I am really satisfied with the replication service available in 2.x. Do you have any feedback with the new plugin-based solution?

Thank you so much!

Funnily enough, the Simple Data Replicator was contributed to the repository literally yesterday!

I believe that the preliminary version linked in the article was removed, so you’ll want to either use that new implementation, or, if you’re feeling adventurous, you could modify it to fit your needs, as the code is open source and any coding agent should be able to help you adjust for your use case.

Be a little cautious with this at massive scale, as the InfluxDB 3 processing engine is based in Python and won’t be performant with, say, PBs of data.

Thank you very much! That was really fast :smiley: One last question regarding the replication. The replication services shipped with 2.x was really awesome and works like charm. How does this plugin different from that? Has tha same sability and functionality?

Does this 3.x plugin use the durable message queue as 2.x does?

This is an entirely different implementation. The end result should be relatively the same, but this is via the InfluxDB 3 processing engine, which is a Python VM embedded within the database. Writes are somewhat durable because of the presence of a write-ahead log that can be read from after a reboot if something goes down, but I wouldn’t say this is identical to the idea of a durable message queue.