4.9. Replicator

4.9.1. Replicator Database Configuration

[replicator]
maxjobs


New in version 2.1.


Number of actively running replications.This value represents the threshold to trigger the automatic replicationscheduler.The system will check every interval milliseconds how many replicationjobs are running, and if there are more than max_jobs active jobs,the scheduler will pause-and-restart up to max_churn jobs in thescheduler queue.Making this value too high could cause performance issues, while makingit too low could mean replications jobs might not have enough time to makeprogress before getting unscheduled again.This parameter can be adjusted at runtime and will take effect during nextrescheduling cycle:




  1. [replicator]
    max_jobs = 500



interval


New in version 2.1.


Scheduling interval in milliseconds.During each reschedule cycle the scheduler might start or stop up to max_churnnumber of jobs:




  1. [replicator]
    interval = 60000



max_churn


New in version 2.1.


Maximum number of replication jobs 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:




  1. [replicator]
    max_churn = 20



update_docs


New in version 2.1.


When set to true replicator will update replication document witherror and triggered states. This approximates pre-2.1 replicatorbehavior:




  1. [replicator]
    update_docs = false



worker_batch_size

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




  1. [replicator]
    worker_batch_size = 500



worker_processes

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




  1. [replicator]
    worker_processes = 4



http_connections

Maximum number of HTTP connections per replication:




  1. [replicator]
    http_connections = 20



connection_timeout

HTTP connection timeout per replication.This is divided by three (3) when the replicator makes changes feed requests.Even for very fast/reliable networks it might need to be increased ifa remote database is too busy:




  1. [replicator]
    connection_timeout = 30000



retries_per_request


Changed in version 2.1.1.


If a request fails, the replicator will retry it up to N times. Thedefault value for N is 5 (before version 2.1.1 it was 10). The requestsare retried with a doubling exponential backoff starting at 0.25seconds. So by default requests would be retried in 0.25, 0.5, 1, 2, 4second intervals. When number of retires is exhausted, the wholereplication job is stopped and will retry again later:




  1. [replicator]
    retries_per_request = 5



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:




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



checkpoint_interval


New in version 1.6.


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




  1. [replicator]
    checkpoint_interval = 5000




Lower intervals may be useful for frequently changing data, whilehigher values will lower bandwidth and make fewer requests forinfrequently updated databases.
use_checkpoints


New in version 1.6.


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




  1. [replicator]
    use_checkpoints = true





Note

Checkpoints are stored in local documentson both the source and target databases (which requires writeaccess).



Warning

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

cert_file

Path to a file containing the user’s certificate:




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



key_file

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




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



password

String containing the user’s password. Only used if the private key fileis password protected:




  1. [replicator]
    password = somepassword



verify_ssl_certificates

Set to true to validate peer certificates:




  1. [replicator]
    verify_ssl_certificates = false



ssl_trusted_certificates_file

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




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



ssl_certificate_max_depth

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




  1. [replicator]
    ssl_certificate_max_depth = 3



auth_plugins


New in version 2.2.


List of replicator client authentication plugins. Plugins willbe tried in order and the first to initialize successfully willbe used. By default there are two plugins available:_couch_replicator_auth_session implementing session (cookie)authentication, and couch_replicator_auth_noop implementing basicauthentication. For backwards compatibility, the no-op plugin should be used atthe end of the plugin list:




  1. [replicator]
    auth_plugins = couch_replicator_auth_session,couch_replicator_auth_noop





Note

In version 2.2, the session plugin is considered experimental and is not enabled by default.

原文: http://docs.couchdb.org/en/stable/config/replicator.html