At least one endpoint must be specified or ArangoDB will refuse to start.
It is recommended to specify at least two endpoints so ArangoDB has an
alternative endpoint if one of them becomes unavailable.

If no advertised endpoint is specified, no external endpoint will be advertised.

Examples

If an external interface is available to this server, it can be
specified to communicate with external software / drivers:

--cluster.my-advertised-endpoint tcp://some.public.place:8530

All specifications of endpoints apply.

My role

This server’s role:

--cluster.my-role <dbserver|coordinator>

The server’s role. Is this instance a DB-Server (backend data server)
or a Coordinator (frontend server for external and application access).

Require existing ID

Require an existing server id:

--cluster.require-persisted-id <bool>

If set to true, then the instance will only start if a UUID file is found
in the database on startup. Setting this option will make sure the instance
is started using an already existing database directory from a previous
start, and not a new one. For the first start, the UUID file must either be
created manually in the database directory, or the option must be set to
false for the initial startup and only turned on for restarts.

Upgrade

Introduced in: v3.6.0

Toggle cluster upgrade mode on a Coordinator:

--cluster.upgrade <string>

The following values can be used for the options:

auto: perform a cluster upgrade and shut down afterwards if the startup
option --database.auto-upgrade is set to true. Otherwise, do not perform
an upgrade.

disable: never perform a cluster upgrade, regardless of the value of
--database.auto-upgrade.

force: always perform a cluster upgrade and shut down, regardless of the
value of --database.auto-upgrade.

When set to true, forces the cluster into creating all future collections with
only a single shard and using the same DB-Server as these collections’
shards leader.
All collections created this way will be eligible for specific AQL query optimizations
that can improve query performance and provide advanced transactional guarantees.

The option only affects Coordinators. It does not have any affect on single servers,
Agents or DB-Servers.

Synchronous replication minimum timeout

Introduced in: v3.4.8, v3.5.1

--cluster.synchronous-replication-timeout-minimum <double>

This option should generally remain untouched and only changed with great care.

The minimum timeout in seconds for the internal synchronous replication
mechanism between DB-Servers. If replication requests are slow, but the servers
are otherwise healthy, timeouts can cause followers to be dropped
unnecessarily, resulting in costly resync operations. Increasing this value may
help avoid such resyncs. Conversely, decreasing it may cause more resyncs,
while lowering the latency of individual write operations. Default at 30.0
seconds.

Synchronous replication timeout scaling

--cluster.synchronous-replication-timeout-factor <double>

This option should generally remain untouched and only changed with great care.

Stretch or clinch timeouts for internal synchronous replication mechanism
between DB-Servers. All such timeouts are affected by this change.
Default at 1.0.

System replication factor

--cluster.system-replication-factor <integer>

Change default replication factor for system collections. Default at 2.

The option only affects Coordinators. It does not have any affect on single servers,
Agents or DB-Servers.

Minimum replication factor

--cluster.min-replication-factor <integer>

Introduced in: v3.5.1

Minimum replication factor that needs to be used when creating new collections.
The default value is 1.
When changing the value of this setting and restarting servers, no changes will be
applied to existing collections that would violate the new setting.

The option only affects Coordinators. It does not have any affect on single servers,
Agents or DB-Servers.

Maximum replication factor

Introduced in: v3.5.1

--cluster.max-replication-factor <integer>

Maximum replication factor that can be used when creating new collections.
The default value is 10.
When changing the value of this setting and restarting servers, no changes will be
applied to existing collections that would violate the new setting.

The option only affects Coordinators. It does not have any affect on single servers,
Agents or DB-Servers.

Default replication factor

--cluster.default-replication-factor <integer>

Default replication factor to be used implicit for new collections when no
replication factor is set.

If this value is not set, it will default to the value of the option
--cluster.min-replication-factor. If set, the value must be between the
values of --cluster.min-replication-factor and
--cluster.max-replication-factor. Note that the replication factor can still
be adjusted per collection. This value is only the default value used for new
collections when no replication factor is specified when creating a collection.

The option only affects Coordinators. It does not have any affect on single servers,
Agents or DB-Servers.

Write concern

Introduced in: v3.6.0

--cluster.write-concern <integer>

Sets the global default write concern. Used by databases as default, which in
turn is used by collections as default.