Usage of managedTxns

Question for Badger team:

I am playing around with replication of badger db. I see there is some incremented timestamp attached to keys as version. I want to use that timestamp to replicate store over multiple nodes. I can get all records with stream.Backup API by providing initial timestamp/version from master node to slave node and match versions across all nodes.

  • What are those versions actually? And when are they increased?
  • How can I get my store’s latest version/timestamp?
  • Are the versions preserved in backup?
  • How would managedDB feature help me here?

Hey @rohanil,

Please find the answers inline:

  • Keys are always inserted with a version inside Badger. Normally this version is the commit timestamp of the transaction in which key is set. In non managed mode, Oracle(check file txn.go in Badger repo) is responsible for increasing timestamp(after every transaction commit).
  • You can get it from Oracle.
  • Yes.
  • I did not understand this question properly. In managed mode, user is responsible for providing commit timestamp of transaction. In Dgraph, it is done by Zero node(which maintains its own Oracle).

Hey @ashishgoswami,

thanks for the answers. I have few more questions:

  • oracle is not exposed to outside so how can I get last timestamp?

  • For replication purpose, what is the benefit of providing own timestamp of transaction?

My plan is to implement master-slave replication of badger store using stream.Backup API. I don’t understand benefit of using managed mode. Once there is a store commit in master node, I am planning to get last timestamp/version from slave node and send a store backup from master to slave starting from that timestamp. Do you see any issues in this logic? I am just figuring out why I would need to use transactions with own timestamps.