Hawkin
/
arangodb
mirror of https://gitee.com/bigwinds/arangodb
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Add synchronous replication

This commit is contained in:
Andreas Streichardt 2016-06-15 16:35:41 +02:00
parent 7c40d6d58d
commit 7c43bdddec
1 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
Documentation/Books/Manual/Administration/Replication/README.mdpp
View File

@ -1,9 +1,18 @@
!CHAPTER Introduction to Replication
!SUBSECTION How the replication works
Replication allows you to *replicate* data onto another machine. It forms the base of all disaster recovery and failover features ArangoDB offers.
Starting with ArangoDB 1.4, ArangoDB comes with optional asynchronous master-slave
replication. Replication is configured on a per-database level, meaning that
ArangoDB offers asynchronous and synchronous replication which both have their pros and cons. Both modes may and should be combined in a real world scenario and be applied in the usecase where the excel most. We will describe pros and cons of each of them in the following sections.
!SUBSECTION Synchronous replication
Synchronous replication only works in in a cluster and is typically used for mission critical data which must be accessible at all times. Synchronous replication generally stores a copy of the data on another host and keeps it in sync. Essentially when storing data after enabling synchronous replication the cluster will wait for all replicas to write all the data before greenlighting the write operation to the client. This makes writing naturally slower. However it will enabled the cluster to immediately fail over to a replica whenever an outage has been detected.
Synchronous replication is organized in a way that every shard has a leader and n followers. The number of followers can be controlled using the `replicationFactor` whenever you create a collection.
!SUBSECTION Asynchronous replication
Asynchronous replication does not necessarily need a cluster to operate and is configured on a per-database level, meaning that
different databases in the same ArangoDB instance can have different replication
settings. Replication must be turned on explicitly before it becomes active for a
database.
@ -29,10 +38,9 @@ of specific databases.
It is possible to connect multiple slave databases to the same master database. Slave
databases should be used as read-only instances, and no user-initiated write operations
should be carried out on them. Otherwise data conflicts may occur that cannot be solved
automatically, and that will make the replication stop. Master-master (or multi-master)
replication is not currently supported in ArangoDB.
automatically, and that will make the replication stop.
The replication in ArangoDB is asynchronous, meaning that slaves will *pull* changes
In an asynchronous replication scenario slaves will *pull* changes
from the master database. Slaves need to know to which master database they should
connect to, but a master database is not aware of the slaves that replicate from it.
When the network connection between the master database and a slave goes down, write
@ -41,7 +49,7 @@ can reconnect to the master database and transfer the remaining changes. This wi
happen automatically provided slaves are configured appropriately.
!SUBSECTION Replication lag
!SUBSUBSECTION Replication lag
In this setup, write operations are applied first in the master database, and applied
in the slave database(s) afterwards.
@ -64,17 +72,10 @@ on the slave(s). At point in time t1, the state of data on the master and slave(
is consistent again (provided no new data modifications happened on the master in
between). Thus, the replication will lead to an *eventually consistent* state of data.
!SUBSECTION Replication configuration
!SUBSUBSECTION Replication configuration
The replication is turned off by default. In order to create a master-slave setup,
the so-called *replication applier* needs to be enabled on the slave databases.
Since ArangoDB 2.2, the master database does not need any special configuration, as
it will automatically log all data modification operations into its write-ahead log.
The write-ahead log is then used in replication. Versions prior to ArangoDB 2.2
required the so-called *replication logger* to be activated on the master, too. This
requirement is gone since ArangoDB 2.2 and the replication logger does not have any
purpose in ArangoDB 2.2 and higher. The replication logger object is kept for compatibility
with previous versions only.
Replication is configured on a per-database level. If multiple database are to be
replicated, the replication must be set up individually per database.
@ -82,5 +83,4 @@ replicated, the replication must be set up individually per database.
The replication applier on the slave can be used to perform a one-time synchronization
with the master (and then stop), or to perform an ongoing replication of changes. To
resume replication on slave restart, the *autoStart* attribute of the replication
applier must be set to *true*.
applier must be set to *true*.