3.8. Replicator

3.8.1. Replicator Database Configuration

[replicator]
max_jobs

New in version 2.1.

Number of actively running replications. Making this too high could cause performance issues. Making it too low could mean replications jobs might not have enough time to make progress before getting unscheduled again. This parameter can be adjusted at runtime and will take effect during next rescheduling cycle:

[replicator]
max_jobs = 500
interval

New in version 2.1.

Scheduling interval in milliseconds. During each reschedule cycle scheduler might start or stop up to “max_churn” number of jobs:

[replicator]
interval = 60000
max_churn

New in version 2.1.

Maximum number of replications to start and stop during rescheduling. This parameter along with interval defines the rate of job replacement. During startup, however a much larger number of jobs could be started (up to max_jobs) in a short period of time:

[replicator]
max_churn = 20
update_docs

New in version 2.1.

When set to true replicator will update replication document with error and triggered states. This approximates pre 2.1 replicator behavior:

[replicator]
update_docs = false
worker_batch_size

With lower batch sizes checkpoints are done more frequently. Lower batch sizes also reduce the total amount of used RAM memory:

[replicator]
worker_batch_size = 500
worker_processes

More worker processes can give higher network throughput but can also imply more disk and network IO:

[replicator]
worker_processes = 4
http_connections

Maximum number of HTTP connections per replication:

[replicator]
http_connections = 20
connection_timeout

HTTP connection timeout per replication. Even for very fast/reliable networks it might need to be increased if a remote database is too busy:

[replicator]
connection_timeout = 30000
retries_per_request

If a request fails, the replicator will retry it up to N times:

[replicator]
retries_per_request = 10
socket_options

Some socket options that might boost performance in some scenarios:

  • {nodelay, boolean()}
  • {sndbuf, integer()}
  • {recbuf, integer()}
  • {priority, integer()}

See the inet Erlang module’s man page for the full list of options:

[replicator]
socket_options = [{keepalive, true}, {nodelay, false}]
checkpoint_interval

New in version 1.6.

Defines replication checkpoint interval in milliseconds. Replicator will requests from the Source database at the specified interval:

[replicator]
checkpoint_interval = 5000

Lower intervals may be useful for frequently changing data, while higher values will lower bandwidth and make fewer requests for infrequently updated databases.

use_checkpoints

New in version 1.6.

If use_checkpoints is set to true, CouchDB will make checkpoints during replication and at the completion of replication. CouchDB can efficiently resume replication from any of these checkpoints:

[replicator]
use_checkpoints = true

Note

Checkpoints are stored in local documents on both the source and target databases (which requires write access).

Warning

Disabling checkpoints is not recommended as CouchDB will scan the Source database’s changes feed from the beginning.

cert_file

Path to a file containing the user’s certificate:

[replicator]
cert_file = /full/path/to/server_cert.pem
key_file

Path to file containing user’s private PEM encoded key:

[replicator]
key_file = /full/path/to/server_key.pem
password

String containing the user’s password. Only used if the private keyfile is password protected:

[replicator]
password = somepassword
verify_ssl_certificates

Set to true to validate peer certificates:

[replicator]
verify_ssl_certificates = false
ssl_trusted_certificates_file

File containing a list of peer trusted certificates (in the PEM format):

[replicator]
ssl_trusted_certificates_file = /etc/ssl/certs/ca-certificates.crt
ssl_certificate_max_depth

Maximum peer certificate depth (must be set even if certificate validation is off):

[replicator]
ssl_certificate_max_depth = 3