mirror of https://gitee.com/bigwinds/arangodb
0ba532b16a
Next steps after DC2DC and Cluster doc improvements: - We refactor replication sections and make more intuitive separation between Master/Slave and the new Active Failover in 3.3 - We create corresponding sections for Master/Slave and Active Failover in the Administration and Deployment chapters, as well as in the Scalability chapter, where these "modes" are introduced - We touch and improve the "Architecture" chapter as well, where some architecture info have to be placed - We reorg the TOC having in more "logical" order: -- Deployment -- Administration -- Security -- Monitoring -- Troubleshooting - We adds parts in the TOC - We add toc per pages, using page-toc plugin - We also put close together "Scalability" and "Architecture" chapters, preliminary steps of further improvements / aggregation - We improve swagger Internal Ref: - https://github.com/arangodb/planning/issues/1692 - https://github.com/arangodb/planning/issues/1655 - https://github.com/arangodb/planning/issues/1858 - https://github.com/arangodb/planning/issues/973 (partial fix) - https://github.com/arangodb/planning/issues/1498 (partial fix) |
||
|---|---|---|
| .. | ||
| OtherReplication.md | ||
| README.md | ||
| ReplicationApplier.md | ||
| ReplicationDump.md | ||
| ReplicationLogger.md | ||
README.md
HTTP Interface for Replication
Replication
This is an introduction to ArangoDB's HTTP replication interface. The replication architecture and components are described in more details in Replication.
The HTTP replication interface serves four main purposes:
- fetch initial data from a server (e.g. for a backup, or for the initial synchronization of data before starting the continuous replication applier)
- querying the state of a master
- fetch continuous changes from a master (used for incremental synchronization of changes)
- administer the replication applier (starting, stopping, configuring, querying state) on a slave
Please note that all replication operations work on a per-database level. If an ArangoDB server contains more than one database, the replication system must be configured individually per database, and replicating the data of multiple databases will require multiple operations.