name: Node Types about: Introduce heterogeneous node types to CouchDB 4 title: ‘Node Types’ labels: rfc, discussion assignees: ''
This RFC proposes the ability to have different node types in CouchDB 4+. This would improve performance and allow for a more efficient use of resources.
Previously, in CouchDB 2 and 3, cluster functionality was uniformly distributed amongst the nodes. Any node could accept HTTP requests, run replication jobs and build secondary indices. With the FDB-based topology, CRUD operations have lower resource needs and so it could be useful to have a heterogeneous topology, where for example, CRUD operations run on lower capacity nodes, and a few higher capacity nodes handle replication or indexing jobs.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
node type : A label used to designate a subset of CouchDB functionality.
A node type is a description of a some internal CouchDB functionality. These are the initially defined node types:
api_frontend
: Indicates this node can accept HTTP API requests.view_indexing
: Indicates this node can build map/reduce view indices.search_indexing
: Indicates this node can build search indices.replication
: Indicates this node can run replication jobs.Users can configure CouchDB nodes with any combination of those types.
Configuration MAY be specified in the Erlang application or OS environment variables. OS environment variables have a higher precedence. By default, if the type is not configured in either one of those places, it defaults to true
.
Configuration MUST be specified for the fabric
application, under the node_types
key. The value MUST be proplist which looks like [{$type, true | false}, ...]
. For example, the va.args
file MAY be used like such:
-fabric node_types '[{api_frontend, false}, {replication, true}]'
Node types MAY be set via environment variables using the COUCHDB_NODE_TYPE_
prefix. The prefix SHOULD be followed by the type label. If the value of the variable is false
the functionality indicated will be disabled on that node. Any other value, indicates true
.
Example:
COUCHDB_NODE_TYPE_API_FRONTEND=false COUCHDB_NODE_TYPE_VIEW_INDEXING=true ...
Implementation should be minimally invasive, at least for the node types listed above.
api_frontend
would enable the chttpd
application, or its top level supervisor.
All background tasks in FDB are executed via the couch_jobs
framework. The top level application supervisors typically have a separate gen_server
in charge of accepting jobs and executing them. The implementation then would be as simple as having a case
statement around the worker's start_link()
function.
N/A
N/A
N/A
[1] https://github.com/apache/couchdb/issues/1338
[2] https://github.com/apache/couchdb/blob/main/src/docs/rfcs/007-background-jobs.md
@kocolosk @mikerhodes