ClickHouse Keeper (clickhouse-keeper)

Not supported in ClickHouse Cloud

note

This page is not applicable to ClickHouse Cloud. The procedure documented here is automated in ClickHouse Cloud services.

ClickHouse Keeper provides the coordination system for data replication and distributed DDL queries execution. ClickHouse Keeper is compatible with ZooKeeper.

Implementation details

ZooKeeper is one of the first well-known open-source coordination systems. It's implemented in Java, and has quite a simple and powerful data model. ZooKeeper's coordination algorithm, ZooKeeper Atomic Broadcast (ZAB), doesn't provide linearizability guarantees for reads, because each ZooKeeper node serves reads locally. Unlike ZooKeeper, ClickHouse Keeper is written in C++ and uses the RAFT algorithm implementation. This algorithm allows linearizability for reads and writes, and has several open-source implementations in different languages.

By default, ClickHouse Keeper provides the same guarantees as ZooKeeper: linearizable writes and non-linearizable reads. It has a compatible client-server protocol, so any standard ZooKeeper client can be used to interact with ClickHouse Keeper. Snapshots and logs have an incompatible format with ZooKeeper, but the clickhouse-keeper-converter tool enables the conversion of ZooKeeper data to ClickHouse Keeper snapshots. The interserver protocol in ClickHouse Keeper is also incompatible with ZooKeeper so a mixed ZooKeeper / ClickHouse Keeper cluster is impossible.

ClickHouse Keeper supports Access Control Lists (ACLs) the same way as ZooKeeper does. ClickHouse Keeper supports the same set of permissions and has the identical built-in schemes: world, auth and digest. The digest authentication scheme uses the pair username:password, the password is encoded in Base64.

note

External integrations are not supported.

Configuration

ClickHouse Keeper can be used as a standalone replacement for ZooKeeper or as an internal part of the ClickHouse server. In both cases the configuration is almost the same .xml file.

Keeper configuration settings

The main ClickHouse Keeper configuration tag is <keeper_server> and has the following parameters:

Parameter	Description	Default
tcp_port	Port for a client to connect.	2181
tcp_port_secure	Secure port for an SSL connection between client and keeper-server.	-
server_id	Unique server id, each participant of the ClickHouse Keeper cluster must have a unique number (1, 2, 3, and so on).	-
log_storage_path	Path to coordination logs, just like ZooKeeper it is best to store logs on non-busy nodes.	-
snapshot_storage_path	Path to coordination snapshots.	-
enable_reconfiguration	Enable dynamic cluster reconfiguration via reconfig.	False
max_memory_usage_soft_limit	Soft limit in bytes of keeper max memory usage.	max_memory_usage_soft_limit_ratio * physical_memory_amount
max_memory_usage_soft_limit_ratio	If max_memory_usage_soft_limit is not set or set to zero, we use this value to define the default soft limit.	0.9
cgroups_memory_observer_wait_time	If max_memory_usage_soft_limit is not set or is set to 0, we use this interval to observe the amount of physical memory. Once the memory amount changes, we will recalculate Keeper's memory soft limit by max_memory_usage_soft_limit_ratio.	15
http_control	Configuration of HTTP control interface.	-
digest_enabled	Enable real-time data consistency check	True
create_snapshot_on_exit	Create a snapshot during shutdown	-
hostname_checks_enabled	Enable sanity hostname checks for cluster configuration (e.g. if localhost is used with remote endpoints)	True
four_letter_word_white_list	White list of 4lw commands.	conf, cons, crst, envi, ruok, srst, srvr, stat, wchs, dirs, mntr, isro, rcvr, apiv, csnp, lgif, rqld, ydld
enable_ipv6	Enable IPv6	True

Other common parameters are inherited from the ClickHouse server config (listen_host, logger, and so on).

Internal coordination settings

Internal coordination settings are located in the <keeper_server>.<coordination_settings> section and have the following parameters:

Parameter	Description	Default
operation_timeout_ms	Timeout for a single client operation (ms)	10000
min_session_timeout_ms	Min timeout for client session (ms)	10000
session_timeout_ms	Max timeout for client session (ms)	100000
dead_session_check_period_ms	How often ClickHouse Keeper checks for dead sessions and removes them (ms)	500
heart_beat_interval_ms	How often a ClickHouse Keeper leader will send heartbeats to followers (ms)	500
election_timeout_lower_bound_ms	If the follower does not receive a heartbeat from the leader in this interval, then it can initiate leader election. Must be less than or equal to election_timeout_upper_bound_ms. Ideally they shouldn't be equal.	1000
election_timeout_upper_bound_ms	If the follower does not receive a heartbeat from the leader in this interval, then it must initiate leader election.	2000
rotate_log_storage_interval	How many log records to store in a single file.	100000
reserved_log_items	How many coordination log records to store before compaction.	100000
snapshot_distance	How often ClickHouse Keeper will create new snapshots (in the number of records in logs).	100000
snapshots_to_keep	How many snapshots to keep.	3
stale_log_gap	Threshold when leader considers follower as stale and sends the snapshot to it instead of logs.	10000
fresh_log_gap	When node became fresh.	200
max_requests_batch_size	Max size of batch in requests count before it will be sent to RAFT.	100
force_sync	Call fsync on each write to coordination log.	true
quorum_reads	Execute read requests as writes through whole RAFT consensus with similar speed.	false
raft_logs_level	Text logging level about coordination (trace, debug, and so on).	system default
auto_forwarding	Allow to forward write requests from followers to the leader.	true
shutdown_timeout	Wait to finish internal connections and shutdown (ms).	5000
startup_timeout	If the server doesn't connect to other quorum participants in the specified timeout it will terminate (ms).	30000
async_replication	Enable async replication. All write and read guarantees are preserved while better performance is achieved. Settings is disabled by default to not break backwards compatibility	false
latest_logs_cache_size_threshold	Maximum total size of in-memory cache of latest log entries	1GiB
commit_logs_cache_size_threshold	Maximum total size of in-memory cache of log entries needed next for commit	500MiB
disk_move_retries_wait_ms	How long to wait between retries after a failure which happened while a file was being moved between disks	1000
disk_move_retries_during_init	The amount of retries after a failure which happened while a file was being moved between disks during initialization	100
experimental_use_rocksdb	Use rocksdb as backend storage	0

Quorum configuration is located in the <keeper_server>.<raft_configuration> section and contain servers description.

The only parameter for the whole quorum is secure, which enables encrypted connection for communication between quorum participants. The parameter can be set true if SSL connection is required for internal communication between nodes, or left unspecified otherwise.

The main parameters for each <server> are:

• id — Server identifier in a quorum.
• hostname — Hostname where this server is placed.
• port — Port where this server listens for connections.
• can_become_leader — Set to false to set up the server as a learner. If omitted, the value is true.

note

In the case of a change in the topology of your ClickHouse Keeper cluster (e.g., replacing a server), please make sure to keep the mapping of server_id to hostname consistent and avoid shuffling or reusing an existing server_id for different servers (e.g., it can happen if your rely on automation scripts to deploy ClickHouse Keeper)

If the host of a Keeper instance can change, we recommend to define and use a hostname instead of raw IP addresses. Changing hostname is equal to removing and adding the server back which in some cases can be impossible to do (e.g. not enough Keeper instances for quorum).

note

async_replication is disabled by default to avoid breaking backwards compatibility. If you have all your Keeper instances in a cluster running a version supporting async_replication (v23.9+), we recommend enabling it because it can improve performance without any downsides.

Examples of configuration for quorum with three nodes can be found in integration tests with test_keeper_ prefix. Example configuration for server #1:

How to run

ClickHouse Keeper is bundled into the ClickHouse server package, just add configuration of <keeper_server> to your /etc/your_path_to_config/clickhouse-server/config.xml and start ClickHouse server as always. If you want to run standalone ClickHouse Keeper you can start it in a similar way with:

If you don't have the symlink (clickhouse-keeper) you can create it or specify keeper as an argument to clickhouse:

Four Letter Word Commands

ClickHouse Keeper also provides 4lw commands which are almost the same with Zookeeper. Each command is composed of four letters such as mntr, stat etc. There are some more interesting commands: stat gives some general information about the server and connected clients, while srvr and cons give extended details on server and connections respectively.

The 4lw commands has a white list configuration four_letter_word_white_list which has default value conf,cons,crst,envi,ruok,srst,srvr,stat,wchs,dirs,mntr,isro,rcvr,apiv,csnp,lgif,rqld,ydld.

You can issue the commands to ClickHouse Keeper via telnet or nc, at the client port.

Bellow is the detailed 4lw commands:

• ruok: Tests if server is running in a non-error state. The server will respond with imok if it is running. Otherwise, it will not respond at all. A response of imok does not necessarily indicate that the server has joined the quorum, just that the server process is active and bound to the specified client port. Use "stat" for details on state with respect to quorum and client connection information.

• mntr: Outputs a list of variables that could be used for monitoring the health of the cluster.

• srvr: Lists full details for the server.

• stat: Lists brief details for the server and connected clients.

• srst: Reset server statistics. The command will affect the result of srvr, mntr and stat.

• conf: Print details about serving configuration.

• cons: List full connection/session details for all clients connected to this server. Includes information on numbers of packets received/sent, session id, operation latencies, last operation performed, etc...

• crst: Reset connection/session statistics for all connections.

• envi: Print details about serving environment

• dirs: Shows the total size of snapshot and log files in bytes

• isro: Tests if server is running in read-only mode. The server will respond with ro if in read-only mode or rw if not in read-only mode.

• wchs: Lists brief information on watches for the server.

• wchc: Lists detailed information on watches for the server, by session. This outputs a list of sessions (connections) with associated watches (paths). Note, depending on the number of watches this operation may be expensive (impact server performance), use it carefully.

• wchp: Lists detailed information on watches for the server, by path. This outputs a list of paths (znodes) with associated sessions. Note, depending on the number of watches this operation may be expensive (i.e., impact server performance), use it carefully.

• dump: Lists the outstanding sessions and ephemeral nodes. This only works on the leader.

• csnp: Schedule a snapshot creation task. Return the last committed log index of the scheduled snapshot if success or Failed to schedule snapshot creation task. if failed. Note that lgif command can help you determine whether the snapshot is done.

• lgif: Keeper log information. first_log_idx : my first log index in log store; first_log_term : my first log term; last_log_idx : my last log index in log store; last_log_term : my last log term; last_committed_log_idx : my last committed log index in state machine; leader_committed_log_idx : leader's committed log index from my perspective; target_committed_log_idx : target log index should be committed to; last_snapshot_idx : the largest committed log index in last snapshot.

• rqld: Request to become new leader. Return Sent leadership request to leader. if request sent or Failed to send leadership request to leader. if request not sent. Note that if node is already leader the outcome is same as the request is sent.

• ftfl: Lists all feature flags and whether they are enabled for the Keeper instance.

• ydld: Request to yield leadership and become follower. If the server receiving the request is leader, it will pause write operations first, wait until the successor (current leader can never be successor) finishes the catch-up of the latest log, and then resign. The successor will be chosen automatically. Return Sent yield leadership request to leader. if request sent or Failed to send yield leadership request to leader. if request not sent. Note that if node is already follower the outcome is same as the request is sent.

• pfev: Returns the values for all collected events. For each event it returns event name, event value, and event's description.

HTTP Control

ClickHouse Keeper provides an HTTP interface to check if a replica is ready to receive traffic. It may be used in cloud environments, such as Kubernetes.

Example of configuration that enables /ready endpoint:

Feature flags

Keeper is fully compatible with ZooKeeper and its clients, but it also introduces some unique features and request types that can be used by ClickHouse client. Because those features can introduce backward incompatible change, most of them are disabled by default and can be enabled using keeper_server.feature_flags config. All features can be disabled explicitly. If you want to enable a new feature for your Keeper cluster, we recommend you to first update all the Keeper instances in the cluster to a version that supports the feature and then enable the feature itself.

Example of feature flag config that disables multi_read and enables check_not_exists:

The following features are available:

• multi_read - support for read multi request. Default: 1
• filtered_list - support for list request which filters results by the type of node (ephemeral or persistent). Default: 1
• check_not_exists - support for CheckNotExists request, which asserts that node doesn't exists. Default: 0
• create_if_not_exists - support for CreateIfNotExists request, which will try to create a node if it doesn't exist. If it exists, no changes are applied and ZOK is returned. Default: 0
• remove_recursive - support for RemoveRecursive request, which removes the node along with its subtree. Default: 0

Migration from ZooKeeper

Seamless migration from ZooKeeper to ClickHouse Keeper is not possible. You have to stop your ZooKeeper cluster, convert data, and start ClickHouse Keeper. clickhouse-keeper-converter tool allows converting ZooKeeper logs and snapshots to ClickHouse Keeper snapshot. It works only with ZooKeeper > 3.4. Steps for migration:

1. Stop all ZooKeeper nodes.

2. Optional, but recommended: find ZooKeeper leader node, start and stop it again. It will force ZooKeeper to create a consistent snapshot.

3. Run clickhouse-keeper-converter on a leader, for example:

4. Copy snapshot to ClickHouse server nodes with a configured keeper or start ClickHouse Keeper instead of ZooKeeper. The snapshot must persist on all nodes, otherwise, empty nodes can be faster and one of them can become a leader.

note

keeper-converter tool is not available from the Keeper standalone binary. If you have ClickHouse installed, you can use the binary directly:

Otherwise, you can download the binary and run the tool as described above without installing ClickHouse.

Recovering after losing quorum

Because ClickHouse Keeper uses Raft it can tolerate certain amount of node crashes depending on the cluster size.
E.g. for a 3-node cluster, it will continue working correctly if only 1 node crashes.

Cluster configuration can be dynamically configured, but there are some limitations. Reconfiguration relies on Raft also so to add/remove a node from the cluster you need to have a quorum. If you lose too many nodes in your cluster at the same time without any chance of starting them again, Raft will stop working and not allow you to reconfigure your cluster using the conventional way.

Nevertheless, ClickHouse Keeper has a recovery mode which allows you to forcefully reconfigure your cluster with only 1 node. This should be done only as your last resort if you cannot start your nodes again, or start a new instance on the same endpoint.

Important things to note before continuing:

• Make sure that the failed nodes cannot connect to the cluster again.
• Do not start any of the new nodes until it's specified in the steps.

After making sure that the above things are true, you need to do following:

1. Pick a single Keeper node to be your new leader. Be aware that the data of that node will be used for the entire cluster, so we recommend using a node with the most up-to-date state.
2. Before doing anything else, make a backup of the log_storage_path and snapshot_storage_path folders of the picked node.
3. Reconfigure the cluster on all of the nodes you want to use.
4. Send the four letter command rcvr to the node you picked which will move the node to the recovery mode OR stop Keeper instance on the picked node and start it again with the --force-recovery argument.
5. One by one, start Keeper instances on the new nodes making sure that mntr returns follower for the zk_server_state before starting the next one.
6. While in the recovery mode, the leader node will return error message for mntr command until it achieves quorum with the new nodes and refuse any requests from the client and the followers.
7. After quorum is achieved, the leader node will return to the normal mode of operation, accepting all the requests using Raft-verify with mntr which should return leader for the zk_server_state.

Using disks with Keeper

Keeper supports a subset of external disks for storing snapshots, log files, and the state file.

Supported types of disks are:

• s3_plain
• s3
• local

Following is an example of disk definitions contained inside a config.

To use a disk for logs keeper_server.log_storage_disk config should be set to the name of disk. To use a disk for snapshots keeper_server.snapshot_storage_disk config should be set to the name of disk. Additionally, different disks can be used for the latest logs or snapshots by using keeper_server.latest_log_storage_disk and keeper_server.latest_snapshot_storage_disk respectively. In that case, Keeper will automatically move files to correct disks when new logs or snapshots are created. To use a disk for state file, keeper_server.state_storage_disk config should be set to the name of disk.

Moving files between disks is safe and there is no risk of losing data if Keeper stops in the middle of transfer. Until the file is completely moved to the new disk, it's not deleted from the old one.

Keeper with keeper_server.coordination_settings.force_sync set to true (true by default) cannot satisfy some guarantees for all types of disks. Right now, only disks of type local support persistent sync. If force_sync is used, log_storage_disk should be a local disk if latest_log_storage_disk is not used. If latest_log_storage_disk is used, it should always be a local disk. If force_sync is disabled, disks of all types can be used in any setup.

A possible storage setup for a Keeper instance could look like following:

This instance will store all but the latest logs on disk log_s3_plain, while the latest log will be on the log_local disk. Same logic applies for snapshots, all but the latest snapshots will be stored on snapshot_s3_plain, while the latest snapshot will be on the snapshot_local disk.

Changing disk setup

info

Before applying a new disk setup, manually back up all Keeper logs and snapshots.

If a tiered disk setup is defined (using separate disks for the latest files), Keeper will try to automatically move files to the correct disks on startup. The same guarantee is applied as before; until the file is completely moved to the new disk, it's not deleted from the old one, so multiple restarts can be safely done.

If it's necessary to move files to a completely new disk (or move from a 2-disk setup to a single disk setup), it's possible to use multiple definitions of keeper_server.old_snapshot_storage_disk and keeper_server.old_log_storage_disk.

The following config shows how we can move from the previous 2-disk setup to a completely new single-disk setup:

On startup, all the log files will be moved from log_local and log_s3_plain to the log_local2 disk. Also, all the snapshot files will be moved from snapshot_local and snapshot_s3_plain to the snapshot_local2 disk.

Configuring logs cache

To minimize the amount of data read from disk, Keeper caches log entries in memory. If requests are large, log entries will take too much memory so the amount of cached logs is capped. The limit is controlled with these two configs:

• latest_logs_cache_size_threshold - total size of latest logs stored in cache
• commit_logs_cache_size_threshold - total size of subsequent logs that need to be committed next

If the default values are too big, you can reduce the memory usage by reducing these two configs.

note

You can use pfev command to check amount of logs read from each cache and from a file. You can also use metrics from Prometheus endpoint to track the current size of both caches.

Prometheus

Keeper can expose metrics data for scraping from Prometheus.

Settings:

• endpoint – HTTP endpoint for scraping metrics by the Prometheus server. Start from '/'.
• port – Port for endpoint.
• metrics – Flag that sets to expose metrics from the system.metrics table.
• events – Flag that sets to expose metrics from the system.events table.
• asynchronous_metrics – Flag that sets to expose current metrics values from the system.asynchronous_metrics table.

Example

Check (replace 127.0.0.1 with the IP addr or hostname of your ClickHouse server):

Please also see the ClickHouse Cloud Prometheus integration.

ClickHouse Keeper User Guide

This guide provides simple and minimal settings to configure ClickHouse Keeper with an example on how to test distributed operations. This example is performed using 3 nodes on Linux.

1. Configure Nodes with Keeper settings

1. Install 3 ClickHouse instances on 3 hosts (chnode1, chnode2, chnode3). (View the Quick Start for details on installing ClickHouse.)

2. On each node, add the following entry to allow external communication through the network interface.

3. Add the following ClickHouse Keeper configuration to all three servers updating the <server_id> setting for each server; for chnode1 would be 1, chnode2 would be 2, etc.

   These are the basic settings used above:

   Parameter	Description	Example
   tcp_port	port to be used by clients of keeper	9181 default equivalent of 2181 as in zookeeper
   server_id	identifier for each ClickHouse Keeper server used in raft configuration	1
   coordination_settings	section to parameters such as timeouts	timeouts: 10000, log level: trace
   server	definition of server participating	list of each server definition
   raft_configuration	settings for each server in the keeper cluster	server and settings for each
   id	numeric id of the server for keeper services	1
   hostname	hostname, IP or FQDN of each server in the keeper cluster	chnode1.domain.com
   port	port to listen on for interserver keeper connections	9234

4. Enable the Zookeeper component. It will use the ClickHouse Keeper engine:

   These are the basic settings used above:

   Parameter	Description	Example
   node	list of nodes for ClickHouse Keeper connections	settings entry for each server
   host	hostname, IP or FQDN of each ClickHouse keeper node	chnode1.domain.com
   port	ClickHouse Keeper client port	9181

5. Restart ClickHouse and verify that each Keeper instance is running. Execute the following command on each server. The ruok command returns imok if Keeper is running and healthy:

6. The system database has a table named zookeeper that contains the details of your ClickHouse Keeper instances. Let's view the table:

   The table looks like:

2. Configure a cluster in ClickHouse

1. Let's configure a simple cluster with 2 shards and only one replica on 2 of the nodes. The third node will be used to achieve a quorum for the requirement in ClickHouse Keeper. Update the configuration on chnode1 and chnode2. The following cluster defines 1 shard on each node for a total of 2 shards with no replication. In this example, some of the data will be on node and some will be on the other node:

   Parameter	Description	Example
   shard	list of replicas on the cluster definition	list of replicas for each shard
   replica	list of settings for each replica	settings entries for each replica
   host	hostname, IP or FQDN of server that will host a replica shard	chnode1.domain.com
   port	port used to communicate using the native tcp protocol	9000
   user	username that will be used to authenticate to the cluster instances	default
   password	password for the user define to allow connections to cluster instances	ClickHouse123!

2. Restart ClickHouse and verify the cluster was created:

   You should see your cluster:

3. Create and test distributed table

1. Create a new database on the new cluster using ClickHouse client on chnode1. The ON CLUSTER clause automatically creates the database on both nodes.

2. Create a new table on the db1 database. Once again, ON CLUSTER creates the table on both nodes.

3. On the chnode1 node, add a couple of rows:

4. Add a couple of rows on the chnode2 node:

5. Notice that running a SELECT statement on each node only shows the data on that node. For example, on chnode1:

   On chnode2:

7. You can create a Distributed table to represent the data on the two shards. Tables with the Distributed table engine do not store any data of their own, but allow distributed query processing on multiple servers. Reads hit all the shards, and writes can be distributed across the shards. Run the following query on chnode1:

8. Notice querying dist_table returns all four rows of data from the two shards:

Summary

This guide demonstrated how to set up a cluster using ClickHouse Keeper. With ClickHouse Keeper, you can configure clusters and define distributed tables that can be replicated across shards.

Configuring ClickHouse Keeper with unique paths

Not supported in ClickHouse Cloud

note

This page is not applicable to ClickHouse Cloud. The procedure documented here is automated in ClickHouse Cloud services.

Description

This article describes how to use the built-in {uuid} macro setting to create unique entries in ClickHouse Keeper or ZooKeeper. Unique paths help when creating and dropping tables frequently because this avoids having to wait several minutes for Keeper garbage collection to remove path entries as each time a path is created a new uuid is used in that path; paths are never reused.

Example Environment

A three node cluster that will be configured to have ClickHouse Keeper on all three nodes, and ClickHouse on two of the nodes. This provides ClickHouse Keeper with three nodes (including a tiebreaker node), and a single ClickHouse shard made up of two replicas.

node	description
chnode1.marsnet.local	data node - cluster cluster_1S_2R
chnode2.marsnet.local	data node - cluster cluster_1S_2R
chnode3.marsnet.local	ClickHouse Keeper tie breaker node

Example config for cluster:

Procedures to set up tables to use {uuid}

1. Configure Macros on each server example for server 1:

note

Notice that we define macros for shard and replica, but that {uuid} is not defined here, it is built-in and there is no need to define.

2. Create a Database

3. Create a table on the cluster using the macros and {uuid}

4. Create a distributed table

Testing

1. Insert data into first node (e.g chnode1)

2. Insert data into second node (e.g., chnode2)

3. View records using distributed table

Alternatives

The default replication path can be defined beforehand by macros and using also {uuid}

1. Set default for tables on each node

tip

You can also define a macro {database} on each node if nodes are used for certain databases.

2. Create table without explicit parameters:

3. Verify it used the settings used in default config

Troubleshooting

Example command to get table information and UUID:

Example command to get information about the table in zookeeper with UUID for the table above

note

Database must be Atomic, if upgrading from a previous version, the default database is likely of Ordinary type.

To check:

For example,

ClickHouse Keeper dynamic reconfiguration

Not supported in ClickHouse Cloud

note

This page is not applicable to ClickHouse Cloud. The procedure documented here is automated in ClickHouse Cloud services.

Description

ClickHouse Keeper partially supports ZooKeeper reconfig command for dynamic cluster reconfiguration if keeper_server.enable_reconfiguration is turned on.

note

If this setting is turned off, you may reconfigure the cluster by altering the replica's raft_configuration section manually. Make sure you the edit files on all replicas as only the leader will apply changes. Alternatively, you can send a reconfig query through any ZooKeeper-compatible client.

A virtual node /keeper/config contains last committed cluster configuration in the following format:

• Each server entry is delimited by a newline.
• server_type is either participant or learner (learner does not participate in leader elections).
• server_priority is a non-negative integer telling which nodes should be prioritised on leader elections. Priority of 0 means server will never be a leader.

Example:

You can use reconfig command to add new servers, remove existing ones, and change existing servers' priorities, here are examples (using clickhouse-keeper-client):

And here are examples for kazoo:

Servers in joining should be in server format described above. Server entries should be delimited by commas. While adding new servers, you can omit server_priority (default value is 1) and server_type (default value is participant).

If you want to change existing server priority, add it to joining with target priority. Server host, port, and type must be equal to existing server configuration.

Servers are added and removed in order of appearance in joining and leaving. All updates from joining are processed before updates from leaving.

There are some caveats in Keeper reconfiguration implementation:

• Only incremental reconfiguration is supported. Requests with non-empty new_members are declined.

  ClickHouse Keeper implementation relies on NuRaft API to change membership dynamically. NuRaft has a way to add a single server or remove a single server, one at a time. This means each change to configuration (each part of joining, each part of leaving) must be decided on separately. Thus there is no bulk reconfiguration available as it would be misleading for end users.

  Changing server type (participant/learner) isn't possible either as it's not supported by NuRaft, and the only way would be to remove and add server, which again would be misleading.

• You cannot use the returned znodestat value.

• The from_version field is not used. All requests with set from_version are declined. This is due to the fact /keeper/config is a virtual node, which means it is not stored in persistent storage, but rather generated on-the-fly with the specified node config for every request. This decision was made as to not duplicate data as NuRaft already stores this config.

• Unlike ZooKeeper, there is no way to wait on cluster reconfiguration by submitting a sync command. New config will be eventually applied but with no time guarantees.

• reconfig command may fail for various reasons. You can check cluster's state and see whether the update was applied.

Converting a single-node keeper into a cluster

Sometimes it's necessary to extend experimental keeper node into a cluster. Here's a scheme of how to do it step-by-step for 3 nodes cluster:

• IMPORTANT: new nodes must be added in batches less than the current quorum, otherwise they will elect a leader among them. In this example one by one.
• The existing keeper node must have keeper_server.enable_reconfiguration configuration parameter turned on.
• Start a second node with the full new configuration of keeper cluster.
• After it's started, add it to the node 1 using reconfig.
• Now, start a third node and add it using reconfig.
• Update the clickhouse-server configuration by adding new keeper node there and restart it to apply the changes.
• Update the raft configuration of the node 1 and, optionally, restart it.

To get confident with the process, here's a sandbox repository.

Unsupported Features

While ClickHouse Keeper aims to be fully compatible with ZooKeeper, there are some features that are currently not implemented (although development is ongoing):

• create does not support returning Stat object
• create does not support TTL
• addWatch does not work with PERSISTENT watches
• removeWatch and removeAllWatches are not supported
• setWatches is not supported
• Creating CONTAINER type znodes is not supported
• SASL authentication is not supported