# 3.9. Replicator

## 3.9.1. Replicator Database Configuration

`[replicator]`
  `max_jobs`

    New in version 2.1.

    Number of actively running replications. This value represents the threshold to trigger the automatic replication scheduler. The system will check every `interval` milliseconds how many replication jobs are running, and if there are more than `max_jobs` active jobs, the scheduler will pause-and-restart up to `max_churn` jobs in the scheduler queue. Making this value too high could cause performance issues, while 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 the 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 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:

        [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. 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 if a remote database is too busy:

        [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. The default value for N is 5 (before version 2.1.1 it was 10). The requests are retried with a doubling exponential backoff starting at 0.25 seconds. So by default requests would be retried in 0.25, 0.5, 1, 2, 4 second intervals. When number of retires is exhausted, the whole replication job is stopped and will retry again later:

        [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:

        [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 key file 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

  `auth_plugins`

    New in version 2.2.

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

        [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.