Replication Applier Commands

The applier commands allow to remotely start, stop, and query the state and configuration of an ArangoDB database's replication applier.

Return configuration of replication applier

fetch the current replication configuration

GET /_api/replication/applier-config

Returns the configuration of the replication applier.

The body of the response is a JSON object with the configuration. The following attributes may be present in the configuration:

  • endpoint: the logger server to connect to (e.g. "tcp://192.168.173.13:8529").

  • database: the name of the database to connect to (e.g. "_system").

  • username: an optional ArangoDB username to use when connecting to the endpoint.

  • password: the password to use when connecting to the endpoint.

  • maxConnectRetries: the maximum number of connection attempts the applier will make in a row. If the applier cannot establish a connection to the endpoint in this number of attempts, it will stop itself.

  • connectTimeout: the timeout (in seconds) when attempting to connect to the endpoint. This value is used for each connection attempt.

  • requestTimeout: the timeout (in seconds) for individual requests to the endpoint.

  • chunkSize: the requested maximum size for log transfer packets that is used when the endpoint is contacted.

  • autoStart: whether or not to auto-start the replication applier on (next and following) server starts

  • adaptivePolling: whether or not the replication applier will use adaptive polling.

  • includeSystem: whether or not system collection operations will be applied

  • autoResync: whether or not the slave should perform a full automatic resynchronization with the master in case the master cannot serve log data requested by the slave, or when the replication is started and no tick value can be found.

  • autoResyncRetries: number of resynchronization retries that will be performed in a row when automatic resynchronization is enabled and kicks in. Setting this to 0 will effectively disable autoResync. Setting it to some other value will limit the number of retries that are performed. This helps preventing endless retries in case resynchronizations always fail.

  • initialSyncMaxWaitTime: the maximum wait time (in seconds) that the initial synchronization will wait for a response from the master when fetching initial collection data. This wait time can be used to control after what time the initial synchronization will give up waiting for a response and fail. This value is relevant even for continuous replication when autoResync is set to true because this may re-start the initial synchronization when the master cannot provide log data the slave requires. This value will be ignored if set to 0.

  • connectionRetryWaitTime: the time (in seconds) that the applier will intentionally idle before it retries connecting to the master in case of connection problems. This value will be ignored if set to 0.

  • idleMinWaitTime: the minimum wait time (in seconds) that the applier will intentionally idle before fetching more log data from the master in case the master has already sent all its log data. This wait time can be used to control the frequency with which the replication applier sends HTTP log fetch requests to the master in case there is no write activity on the master. This value will be ignored if set to 0.

  • idleMaxWaitTime: the maximum wait time (in seconds) that the applier will intentionally idle before fetching more log data from the master in case the master has already sent all its log data and there have been previous log fetch attempts that resulted in no more log data. This wait time can be used to control the maximum frequency with which the replication applier sends HTTP log fetch requests to the master in case there is no write activity on the master for longer periods. This configuration value will only be used if the option adaptivePolling is set to true. This value will be ignored if set to 0.

  • requireFromPresent: if set to true, then the replication applier will check at start whether the start tick from which it starts or resumes replication is still present on the master. If not, then there would be data loss. If requireFromPresent is true, the replication applier will abort with an appropriate error message. If set to false, then the replication applier will still start, and ignore the data loss.

  • verbose: if set to true, then a log line will be emitted for all operations performed by the replication applier. This should be used for debugging replication problems only.

  • restrictType: the configuration for restrictCollections

  • restrictCollections: the optional array of collections to include or exclude, based on the setting of restrictType

Example:

shell> curl --dump - http://localhost:8529/_api/replication/applier-config

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff

{ 
  "requestTimeout" : 600, 
  "connectTimeout" : 10, 
  "ignoreErrors" : 0, 
  "maxConnectRetries" : 100, 
  "sslProtocol" : 0, 
  "chunkSize" : 0, 
  "autoStart" : false, 
  "adaptivePolling" : true, 
  "autoResync" : false, 
  "autoResyncRetries" : 2, 
  "includeSystem" : true, 
  "requireFromPresent" : false, 
  "verbose" : false, 
  "incremental" : false, 
  "useCollectionId" : true, 
  "restrictType" : "", 
  "restrictCollections" : [ ], 
  "connectionRetryWaitTime" : 15, 
  "initialSyncMaxWaitTime" : 300, 
  "idleMinWaitTime" : 1, 
  "idleMaxWaitTime" : 2.5 
}

Return Codes

  • 200: is returned if the request was executed successfully.
  • 405: is returned when an invalid HTTP method is used.
  • 500: is returned if an error occurred while assembling the response.

Examples

shell> curl --dump - http://localhost:8529/_api/replication/applier-config

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff
show response body

Adjust configuration of replication applier

set configuration values of an applier

PUT /_api/replication/applier-config

A JSON object with these properties is required:

  • username: an optional ArangoDB username to use when connecting to the endpoint.
  • includeSystem: whether or not system collection operations will be applied
  • endpoint: the logger server to connect to (e.g. "tcp://192.168.173.13:8529"). The endpoint must be specified.
  • verbose: if set to true, then a log line will be emitted for all operations performed by the replication applier. This should be used for debugging replication problems only.
  • connectTimeout: the timeout (in seconds) when attempting to connect to the endpoint. This value is used for each connection attempt.
  • autoResync: whether or not the slave should perform a full automatic resynchronization with the master in case the master cannot serve log data requested by the slave, or when the replication is started and no tick value can be found.
  • database: the name of the database on the endpoint. If not specified, defaults to the current local database name.
  • idleMinWaitTime: the minimum wait time (in seconds) that the applier will intentionally idle before fetching more log data from the master in case the master has already sent all its log data. This wait time can be used to control the frequency with which the replication applier sends HTTP log fetch requests to the master in case there is no write activity on the master. This value will be ignored if set to 0.
  • requestTimeout: the timeout (in seconds) for individual requests to the endpoint.
  • requireFromPresent: if set to true, then the replication applier will check at start whether the start tick from which it starts or resumes replication is still present on the master. If not, then there would be data loss. If requireFromPresent is true, the replication applier will abort with an appropriate error message. If set to false, then the replication applier will still start, and ignore the data loss.
  • idleMaxWaitTime: the maximum wait time (in seconds) that the applier will intentionally idle before fetching more log data from the master in case the master has already sent all its log data and there have been previous log fetch attempts that resulted in no more log data. This wait time can be used to control the maximum frequency with which the replication applier sends HTTP log fetch requests to the master in case there is no write activity on the master for longer periods. This configuration value will only be used if the option adaptivePolling is set to true. This value will be ignored if set to 0.
  • restrictCollections (string): the array of collections to include or exclude, based on the setting of restrictType
  • restrictType: the configuration for restrictCollections; Has to be either include or exclude
  • initialSyncMaxWaitTime: the maximum wait time (in seconds) that the initial synchronization will wait for a response from the master when fetching initial collection data. This wait time can be used to control after what time the initial synchronization will give up waiting for a response and fail. This value is relevant even for continuous replication when autoResync is set to true because this may re-start the initial synchronization when the master cannot provide log data the slave requires. This value will be ignored if set to 0.
  • maxConnectRetries: the maximum number of connection attempts the applier will make in a row. If the applier cannot establish a connection to the endpoint in this number of attempts, it will stop itself.
  • autoStart: whether or not to auto-start the replication applier on (next and following) server starts
  • adaptivePolling: if set to true, the replication applier will fall to sleep for an increasingly long period in case the logger server at the endpoint does not have any more replication events to apply. Using adaptive polling is thus useful to reduce the amount of work for both the applier and the logger server for cases when there are only infrequent changes. The downside is that when using adaptive polling, it might take longer for the replication applier to detect that there are new replication events on the logger server. Setting adaptivePolling to false will make the replication applier contact the logger server in a constant interval, regardless of whether the logger server provides updates frequently or seldom.
  • password: the password to use when connecting to the endpoint.
  • connectionRetryWaitTime: the time (in seconds) that the applier will intentionally idle before it retries connecting to the master in case of connection problems. This value will be ignored if set to 0.
  • autoResyncRetries: number of resynchronization retries that will be performed in a row when automatic resynchronization is enabled and kicks in. Setting this to 0 will effectively disable autoResync. Setting it to some other value will limit the number of retries that are performed. This helps preventing endless retries in case resynchronizations always fail.
  • chunkSize: the requested maximum size for log transfer packets that is used when the endpoint is contacted.

Sets the configuration of the replication applier. The configuration can only be changed while the applier is not running. The updated configuration will be saved immediately but only become active with the next start of the applier.

In case of success, the body of the response is a JSON object with the updated configuration.

Example:

shell> curl -X PUT --data-binary @- --dump - http://localhost:8529/_api/replication/applier-config <<EOF
{ 
  "endpoint" : "tcp://127.0.0.1:8529", 
  "username" : "replicationApplier", 
  "password" : "applier1234@foxx", 
  "chunkSize" : 4194304, 
  "autoStart" : false, 
  "adaptivePolling" : true 
}
EOF

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff

{ 
  "endpoint" : "tcp://127.0.0.1:8529", 
  "database" : "_system", 
  "username" : "replicationApplier", 
  "requestTimeout" : 600, 
  "connectTimeout" : 10, 
  "ignoreErrors" : 0, 
  "maxConnectRetries" : 100, 
  "sslProtocol" : 0, 
  "chunkSize" : 4194304, 
  "autoStart" : false, 
  "adaptivePolling" : true, 
  "autoResync" : false, 
  "autoResyncRetries" : 2, 
  "includeSystem" : true, 
  "requireFromPresent" : false, 
  "verbose" : false, 
  "incremental" : false, 
  "useCollectionId" : true, 
  "restrictType" : "", 
  "restrictCollections" : [ ], 
  "connectionRetryWaitTime" : 15, 
  "initialSyncMaxWaitTime" : 300, 
  "idleMinWaitTime" : 1, 
  "idleMaxWaitTime" : 2.5 
}

Return Codes

  • 200: is returned if the request was executed successfully.
  • 400: is returned if the configuration is incomplete or malformed, or if the replication applier is currently running.
  • 405: is returned when an invalid HTTP method is used.
  • 500: is returned if an error occurred while assembling the response.

Examples

shell> curl -X PUT --data-binary @- --dump - http://localhost:8529/_api/replication/applier-config <<EOF
{ 
  "endpoint" : "tcp://127.0.0.1:8529", 
  "username" : "replicationApplier", 
  "password" : "applier1234@foxx", 
  "chunkSize" : 4194304, 
  "autoStart" : false, 
  "adaptivePolling" : true 
}
EOF

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff
show response body

Start replication applier

start the replication applier

PUT /_api/replication/applier-start

Query Parameters

  • from (optional): The remote lastLogTick value from which to start applying. If not specified, the last saved tick from the previous applier run is used. If there is no previous applier state saved, the applier will start at the beginning of the logger server's log.

Starts the replication applier. This will return immediately if the replication applier is already running.

If the replication applier is not already running, the applier configuration will be checked, and if it is complete, the applier will be started in a background thread. This means that even if the applier will encounter any errors while running, they will not be reported in the response to this method.

To detect replication applier errors after the applier was started, use the /_api/replication/applier-state API instead.

Example:

shell> curl -X PUT --dump - http://localhost:8529/_api/replication/applier-start

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff

{ 
  "state" : { 
    "running" : true, 
    "lastAppliedContinuousTick" : null, 
    "lastProcessedContinuousTick" : null, 
    "lastAvailableContinuousTick" : null, 
    "safeResumeTick" : null, 
    "progress" : { 
      "time" : "2017-07-19T21:50:11Z", 
      "message" : "applier initially created", 
      "failedConnects" : 0 
    }, 
    "totalRequests" : 0, 
    "totalFailedConnects" : 0, 
    "totalEvents" : 0, 
    "totalOperationsExcluded" : 0, 
    "lastError" : { 
      "errorNum" : 0 
    }, 
    "time" : "2017-07-19T21:50:55Z" 
  }, 
  "server" : { 
    "version" : "3.2.0", 
    "serverId" : "250102568061957" 
  }, 
  "endpoint" : "tcp://127.0.0.1:8529", 
  "database" : "_system" 
}

Return Codes

  • 200: is returned if the request was executed successfully.
  • 400: is returned if the replication applier is not fully configured or the configuration is invalid.
  • 405: is returned when an invalid HTTP method is used.
  • 500: is returned if an error occurred while assembling the response.

Examples

shell> curl -X PUT --dump - http://localhost:8529/_api/replication/applier-start

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff
show response body

Stop replication applier

stop the replication

PUT /_api/replication/applier-stop

Stops the replication applier. This will return immediately if the replication applier is not running.

Example:

shell> curl -X PUT --dump - http://localhost:8529/_api/replication/applier-stop

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff

{ 
  "state" : { 
    "running" : false, 
    "lastAppliedContinuousTick" : null, 
    "lastProcessedContinuousTick" : null, 
    "lastAvailableContinuousTick" : null, 
    "safeResumeTick" : null, 
    "progress" : { 
      "time" : "2017-07-19T21:50:56Z", 
      "message" : "applier shut down", 
      "failedConnects" : 1 
    }, 
    "totalRequests" : 3, 
    "totalFailedConnects" : 3, 
    "totalEvents" : 0, 
    "totalOperationsExcluded" : 0, 
    "lastError" : { 
      "errorNum" : 1412, 
      "time" : "2017-07-19T21:50:56Z", 
      "errorMessage" : "could not connect to master at tcp://127.0.0.1:8529: Could not connect to 'http+tcp://127.0.0.1:8529' 'connect() failed with #61 - Connection refused'" 
    }, 
    "time" : "2017-07-19T21:50:56Z" 
  }, 
  "server" : { 
    "version" : "3.2.0", 
    "serverId" : "250102568061957" 
  }, 
  "endpoint" : "tcp://127.0.0.1:8529", 
  "database" : "_system" 
}

Return Codes

  • 200: is returned if the request was executed successfully.
  • 405: is returned when an invalid HTTP method is used.
  • 500: is returned if an error occurred while assembling the response.

Examples

shell> curl -X PUT --dump - http://localhost:8529/_api/replication/applier-stop

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff
show response body

State of the replication applier

output the current status of the replication

GET /_api/replication/applier-state

Returns the state of the replication applier, regardless of whether the applier is currently running or not.

The response is a JSON object with the following attributes:

  • state: a JSON object with the following sub-attributes:

    • running: whether or not the applier is active and running

    • lastAppliedContinuousTick: the last tick value from the continuous replication log the applier has applied.

    • lastProcessedContinuousTick: the last tick value from the continuous replication log the applier has processed.

      Regularly, the last applied and last processed tick values should be identical. For transactional operations, the replication applier will first process incoming log events before applying them, so the processed tick value might be higher than the applied tick value. This will be the case until the applier encounters the transaction commit log event for the transaction.

    • lastAvailableContinuousTick: the last tick value the logger server can provide.

    • time: the time on the applier server.

    • totalRequests: the total number of requests the applier has made to the endpoint.

    • totalFailedConnects: the total number of failed connection attempts the applier has made.

    • totalEvents: the total number of log events the applier has processed.

    • totalOperationsExcluded: the total number of log events excluded because of restrictCollections.

    • progress: a JSON object with details about the replication applier progress. It contains the following sub-attributes if there is progress to report:

      • message: a textual description of the progress

      • time: the date and time the progress was logged

      • failedConnects: the current number of failed connection attempts

    • lastError: a JSON object with details about the last error that happened on the applier. It contains the following sub-attributes if there was an error:

      • errorNum: a numerical error code

      • errorMessage: a textual error description

      • time: the date and time the error occurred

      In case no error has occurred, lastError will be empty.

  • server: a JSON object with the following sub-attributes:

    • version: the applier server's version

    • serverId: the applier server's id

  • endpoint: the endpoint the applier is connected to (if applier is active) or will connect to (if applier is currently inactive)

  • database: the name of the database the applier is connected to (if applier is active) or will connect to (if applier is currently inactive)

Example:

Fetching the state of an inactive applier:

shell> curl --dump - http://localhost:8529/_api/replication/applier-state

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff

{ 
  "state" : { 
    "running" : false, 
    "lastAppliedContinuousTick" : null, 
    "lastProcessedContinuousTick" : null, 
    "lastAvailableContinuousTick" : null, 
    "safeResumeTick" : null, 
    "progress" : { 
      "time" : "2017-07-19T21:50:55Z", 
      "message" : "applier shut down", 
      "failedConnects" : 1 
    }, 
    "totalRequests" : 1, 
    "totalFailedConnects" : 1, 
    "totalEvents" : 0, 
    "totalOperationsExcluded" : 0, 
    "lastError" : { 
      "errorNum" : 1412, 
      "time" : "2017-07-19T21:50:55Z", 
      "errorMessage" : "could not connect to master at tcp://127.0.0.1:8529: Could not connect to 'http+tcp://127.0.0.1:8529' 'connect() failed with #61 - Connection refused'" 
    }, 
    "time" : "2017-07-19T21:50:55Z" 
  }, 
  "server" : { 
    "version" : "3.2.0", 
    "serverId" : "250102568061957" 
  }, 
  "endpoint" : "tcp://127.0.0.1:8529", 
  "database" : "_system" 
}

Example:

Fetching the state of an active applier:

shell> curl --dump - http://localhost:8529/_api/replication/applier-state

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff

{ 
  "state" : { 
    "running" : true, 
    "lastAppliedContinuousTick" : null, 
    "lastProcessedContinuousTick" : null, 
    "lastAvailableContinuousTick" : null, 
    "safeResumeTick" : null, 
    "progress" : { 
      "time" : "2017-07-19T21:50:55Z", 
      "message" : "fetching master state information", 
      "failedConnects" : 0 
    }, 
    "totalRequests" : 1, 
    "totalFailedConnects" : 1, 
    "totalEvents" : 0, 
    "totalOperationsExcluded" : 0, 
    "lastError" : { 
      "errorNum" : 0 
    }, 
    "time" : "2017-07-19T21:50:55Z" 
  }, 
  "server" : { 
    "version" : "3.2.0", 
    "serverId" : "250102568061957" 
  }, 
  "endpoint" : "tcp://127.0.0.1:8529", 
  "database" : "_system" 
}

Return Codes

  • 200: is returned if the request was executed successfully.
  • 405: is returned when an invalid HTTP method is used.
  • 500: is returned if an error occurred while assembling the response.

Examples

Fetching the state of an inactive applier:

shell> curl --dump - http://localhost:8529/_api/replication/applier-state

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff
show response body

Fetching the state of an active applier:

shell> curl --dump - http://localhost:8529/_api/replication/applier-state

HTTP/1.1 200 OK
content-type: application/json; charset=utf-8
x-content-type-options: nosniff
show response body

Turn the server into a slave of another

Changes role to slave

PUT /_api/replication/make-slave

A JSON object with these properties is required:

  • username: an optional ArangoDB username to use when connecting to the master.
  • includeSystem: whether or not system collection operations will be applied
  • endpoint: the master endpoint to connect to (e.g. "tcp://192.168.173.13:8529").
  • verbose: if set to true, then a log line will be emitted for all operations performed by the replication applier. This should be used for debugging replication problems only.
  • connectTimeout: the timeout (in seconds) when attempting to connect to the endpoint. This value is used for each connection attempt.
  • autoResync: whether or not the slave should perform an automatic resynchronization with the master in case the master cannot serve log data requested by the slave, or when the replication is started and no tick value can be found.
  • database: the database name on the master (if not specified, defaults to the name of the local current database).
  • idleMinWaitTime: the minimum wait time (in seconds) that the applier will intentionally idle before fetching more log data from the master in case the master has already sent all its log data. This wait time can be used to control the frequency with which the replication applier sends HTTP log fetch requests to the master in case there is no write activity on the master. This value will be ignored if set to 0.
  • requestTimeout: the timeout (in seconds) for individual requests to the endpoint.
  • restrictType: an optional string value for collection filtering. When specified, the allowed values are include or exclude.
  • idleMaxWaitTime: the maximum wait time (in seconds) that the applier will intentionally idle before fetching more log data from the master in case the master has already sent all its log data and there have been previous log fetch attempts that resulted in no more log data. This wait time can be used to control the maximum frequency with which the replication applier sends HTTP log fetch requests to the master in case there is no write activity on the master for longer periods. This configuration value will only be used if the option adaptivePolling is set to true. This value will be ignored if set to 0.
  • initialSyncMaxWaitTime: the maximum wait time (in seconds) that the initial synchronization will wait for a response from the master when fetching initial collection data. This wait time can be used to control after what time the initial synchronization will give up waiting for a response and fail. This value is relevant even for continuous replication when autoResync is set to true because this may re-start the initial synchronization when the master cannot provide log data the slave requires. This value will be ignored if set to 0.
  • restrictCollections (string): an optional array of collections for use with restrictType. If restrictType is include, only the specified collections will be sychronised. If restrictType is exclude, all but the specified collections will be synchronized.
  • requireFromPresent: if set to true, then the replication applier will check at start of its continuous replication if the start tick from the dump phase is still present on the master. If not, then there would be data loss. If requireFromPresent is true, the replication applier will abort with an appropriate error message. If set to false, then the replication applier will still start, and ignore the data loss.
  • adaptivePolling: whether or not the replication applier will use adaptive polling.
  • maxConnectRetries: the maximum number of connection attempts the applier will make in a row. If the applier cannot establish a connection to the endpoint in this number of attempts, it will stop itself.
  • password: the password to use when connecting to the master.
  • connectionRetryWaitTime: the time (in seconds) that the applier will intentionally idle before it retries connecting to the master in case of connection problems. This value will be ignored if set to 0.
  • autoResyncRetries: number of resynchronization retries that will be performed in a row when automatic resynchronization is enabled and kicks in. Setting this to 0 will effectively disable autoResync. Setting it to some other value will limit the number of retries that are performed. This helps preventing endless retries in case resynchronizations always fail.
  • chunkSize: the requested maximum size for log transfer packets that is used when the endpoint is contacted.

Starts a full data synchronization from a remote endpoint into the local ArangoDB database and afterwards starts the continuous replication. The operation works on a per-database level.

All local database data will be removed prior to the synchronization.

In case of success, the body of the response is a JSON object with the following attributes:

  • state: a JSON object with the following sub-attributes:

    • running: whether or not the applier is active and running

    • lastAppliedContinuousTick: the last tick value from the continuous replication log the applier has applied.

    • lastProcessedContinuousTick: the last tick value from the continuous replication log the applier has processed.

      Regularly, the last applied and last processed tick values should be identical. For transactional operations, the replication applier will first process incoming log events before applying them, so the processed tick value might be higher than the applied tick value. This will be the case until the applier encounters the transaction commit log event for the transaction.

    • lastAvailableContinuousTick: the last tick value the logger server can provide.

    • time: the time on the applier server.

    • totalRequests: the total number of requests the applier has made to the endpoint.

    • totalFailedConnects: the total number of failed connection attempts the applier has made.

    • totalEvents: the total number of log events the applier has processed.

    • totalOperationsExcluded: the total number of log events excluded because of restrictCollections.

    • progress: a JSON object with details about the replication applier progress. It contains the following sub-attributes if there is progress to report:

      • message: a textual description of the progress

      • time: the date and time the progress was logged

      • failedConnects: the current number of failed connection attempts

    • lastError: a JSON object with details about the last error that happened on the applier. It contains the following sub-attributes if there was an error:

      • errorNum: a numerical error code

      • errorMessage: a textual error description

      • time: the date and time the error occurred

      In case no error has occurred, lastError will be empty.

  • server: a JSON object with the following sub-attributes:

    • version: the applier server's version

    • serverId: the applier server's id

  • endpoint: the endpoint the applier is connected to (if applier is active) or will connect to (if applier is currently inactive)

  • database: the name of the database the applier is connected to (if applier is active) or will connect to (if applier is currently inactive)

WARNING: calling this method will sychronize data from the collections found on the remote master to the local ArangoDB database. All data in the local collections will be purged and replaced with data from the master.

Use with caution!

Please also keep in mind that this command may take a long time to complete and return. This is because it will first do a full data synchronization with the master, which will take time roughly proportional to the amount of data.

Note: this method is not supported on a coordinator in a cluster.

Return Codes

  • 200: is returned if the request was executed successfully.
  • 400: is returned if the configuration is incomplete or malformed.
  • 405: is returned when an invalid HTTP method is used.
  • 500: is returned if an error occurred during sychronization or when starting the continuous replication.
  • 501: is returned when this operation is called on a coordinator in a cluster.

© ArangoDB - the native multi-model NoSQL database