Master/Slave Limitations

• there is no feedback from the slaves to the master. If a slave cannot apply an eventit got from the master, the master will have a different state of data. In this case, the replication applier on the slave will stop and report an error. Administratorscan then either “fix” the problem or re-sync the data from the master to the slaveand start the applier again.
• at the moment it is assumed that only the replication applier executes write operations on a slave. ArangoDB currently does not prevent users from carrying outtheir own write operations on slaves, though this might lead to undefined behaviorand the replication applier stopping.
• Foxx applications consist of database entries and application scripts in the file system.The file system parts of Foxx applications are not tracked anywhere and thus not replicated in current versions of ArangoDB. To replicate a Foxx application, it isrequired to copy the application to the remote server and install it there using thefoxx-manager utility.
• master servers do not know which slaves are or will be connected to them. All serversin a replication setup are currently only loosely coupled. There currently is no way for a client to query which servers are present in a replication.
• the replication applier is single-threaded, but write operations on the master maybe executed in parallel if they affect different collections. Thus the replicationapplier might not be able to catch up with a very powerful and loaded master.
• replication is only supported between the two ArangoDB servers running the sameArangoDB version. It is currently not possible to replicate between different ArangoDB versions.