mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-09-20 08:40:50 +00:00
Add cluster discovery documentation
This commit is contained in:
vdimir
parent
77dd2a556a
commit
10bcc028df
@ -37,6 +37,8 @@ When creating a new replica of the database, this replica creates tables by itse
|
||||
|
||||
[`ALTER TABLE FREEZE|ATTACH|FETCH|DROP|DROP DETACHED|DETACH PARTITION|PART`](../../sql-reference/statements/alter/partition.md) queries are allowed but not replicated. The database engine will only add/fetch/remove the partition/part to the current replica. However, if the table itself uses a Replicated table engine, then the data will be replicated after using `ATTACH`.
|
||||
|
||||
In case you need only configure a cluster without maintaining table replication, refer to [Cluster Discovery](../../operations/cluster-discovery.md) feature.
|
||||
|
||||
## Usage Example {#usage-example}
|
||||
|
||||
Creating a cluster with three hosts:
|
||||
|
||||
171
docs/en/operations/cluster-discovery.md
Normal file
171
docs/en/operations/cluster-discovery.md
Normal file
@ -0,0 +1,171 @@
|
||||
---
|
||||
slug: /en/operations/cluster-discovery
|
||||
sidebar_label: Cluster Discovery
|
||||
---
|
||||
# Cluster Discovery
|
||||
|
||||
## Overview
|
||||
|
||||
ClickHouse's Cluster Discovery feature simplifies cluster configuration by allowing nodes to automatically discover and register themselves without the need for explicit definition in the configuration files. This is especially beneficial in cases where the manual definition of each node becomes cumbersome.
|
||||
|
||||
:::note
|
||||
|
||||
Cluster Discovery is an experimental feature and can be changed or removed in future versions.
|
||||
To enable it include the `allow_experimental_cluster_discovery` setting in your configuration file:
|
||||
|
||||
```xml
|
||||
<clickhouse>
|
||||
<!-- ... -->
|
||||
<allow_experimental_cluster_discovery>1</allow_experimental_cluster_discovery>
|
||||
<!-- ... -->
|
||||
</clickhouse>
|
||||
```
|
||||
:::
|
||||
|
||||
## Remote Servers Configuration
|
||||
|
||||
### Traditional Manual Configuration
|
||||
|
||||
Traditionally, in ClickHouse, each shard and replica in the cluster needed to be manually specified in the configuration:
|
||||
|
||||
```xml
|
||||
<remote_servers>
|
||||
<cluster_name>
|
||||
<shard>
|
||||
<replica>
|
||||
<host>node1</host>
|
||||
<port>9000</port>
|
||||
</replica>
|
||||
<replica>
|
||||
<host>node2</host>
|
||||
<port>9000</port>
|
||||
</replica>
|
||||
</shard>
|
||||
<shard>
|
||||
<replica>
|
||||
<host>node3</host>
|
||||
<port>9000</port>
|
||||
</replica>
|
||||
<replica>
|
||||
<host>node4</host>
|
||||
<port>9000</port>
|
||||
</replica>
|
||||
</shard>
|
||||
</cluster_name>
|
||||
</remote_servers>
|
||||
|
||||
```
|
||||
|
||||
### Using Cluster Discovery
|
||||
|
||||
With Cluster Discovery, rather than defining each node explicitly, you simply specify a path in ZooKeeper. All nodes that register under this path in ZooKeeper will be automatically discovered and added to the cluster.
|
||||
|
||||
```xml
|
||||
<remote_servers>
|
||||
<cluster_name>
|
||||
<discovery>
|
||||
<path>/clickhouse/discovery/cluster_name</path>
|
||||
</discovery>
|
||||
</cluster_name>
|
||||
</remote_servers>
|
||||
```
|
||||
|
||||
If you want to specify a shard number for a particular node, you can include the `<shard>` tag within the `<discovery>` section:
|
||||
|
||||
for `node1` and `node2`:
|
||||
|
||||
```xml
|
||||
<discovery>
|
||||
<path>/clickhouse/discovery/cluster_name</path>
|
||||
<shard>1</shard>
|
||||
</discovery>
|
||||
```
|
||||
|
||||
for `node3` and `node4`:
|
||||
|
||||
```xml
|
||||
<discovery>
|
||||
<path>/clickhouse/discovery/cluster_name</path>
|
||||
<shard>2</shard>
|
||||
</discovery>
|
||||
```
|
||||
|
||||
### Observer mode
|
||||
|
||||
|
||||
Nodes configured in observer mode will not register themselves as replicas.
|
||||
They will solely observe and discover other active replicas in the cluster without actively participating.
|
||||
To enable observer mode, include the `<observer/>` tag within the `<discovery>` section:
|
||||
|
||||
```xml
|
||||
<discovery>
|
||||
<path>/clickhouse/discovery/cluster_name</path>
|
||||
<observer/>
|
||||
</discovery>
|
||||
```
|
||||
|
||||
|
||||
## Use-Cases and Limitations
|
||||
|
||||
As nodes are added or removed from the specified ZooKeeper path, they are automatically discovered or removed from the cluster without the need for configuration changes or server restarts.
|
||||
|
||||
However, changes affect only cluster configuration, not the data or existing databases and tables.
|
||||
|
||||
Consider the following example with a cluster of 3 nodes:
|
||||
|
||||
|
||||
```xml
|
||||
<remote_servers>
|
||||
<default>
|
||||
<discovery>
|
||||
<path>/clickhouse/discovery/default_cluster</path>
|
||||
</discovery>
|
||||
</default>
|
||||
</remote_servers>
|
||||
```
|
||||
|
||||
```
|
||||
SELECT * EXCEPT (default_database, errors_count, slowdowns_count, estimated_recovery_time, database_shard_name, database_replica_name)
|
||||
FROM system.clusters WHERE cluster = 'default';
|
||||
|
||||
┌─cluster─┬─shard_num─┬─shard_weight─┬─replica_num─┬─host_name────┬─host_address─┬─port─┬─is_local─┬─user─┬─is_active─┐
|
||||
│ default │ 1 │ 1 │ 1 │ 92d3c04025e8 │ 172.26.0.5 │ 9000 │ 0 │ │ ᴺᵁᴸᴸ │
|
||||
│ default │ 1 │ 1 │ 2 │ a6a68731c21b │ 172.26.0.4 │ 9000 │ 1 │ │ ᴺᵁᴸᴸ │
|
||||
│ default │ 1 │ 1 │ 3 │ 8e62b9cb17a1 │ 172.26.0.2 │ 9000 │ 0 │ │ ᴺᵁᴸᴸ │
|
||||
└─────────┴───────────┴──────────────┴─────────────┴──────────────┴──────────────┴──────┴──────────┴──────┴───────────┘
|
||||
```
|
||||
|
||||
```sql
|
||||
CREATE TABLE event_table ON CLUSTER default (event_time DateTime, value String)
|
||||
ENGINE = ReplicatedMergeTree('/clickhouse/tables/event_table', '{replica}')
|
||||
ORDER BY event_time PARTITION BY toYYYYMM(event_time);
|
||||
|
||||
INSERT INTO event_table ...
|
||||
```
|
||||
|
||||
Then, we add a new node to the cluster, starting a new node with the same entry in the `remote_servers` section in a configuration file:
|
||||
|
||||
```
|
||||
┌─cluster─┬─shard_num─┬─shard_weight─┬─replica_num─┬─host_name────┬─host_address─┬─port─┬─is_local─┬─user─┬─is_active─┐
|
||||
│ default │ 1 │ 1 │ 1 │ 92d3c04025e8 │ 172.26.0.5 │ 9000 │ 0 │ │ ᴺᵁᴸᴸ │
|
||||
│ default │ 1 │ 1 │ 2 │ a6a68731c21b │ 172.26.0.4 │ 9000 │ 1 │ │ ᴺᵁᴸᴸ │
|
||||
│ default │ 1 │ 1 │ 3 │ 8e62b9cb17a1 │ 172.26.0.2 │ 9000 │ 0 │ │ ᴺᵁᴸᴸ │
|
||||
│ default │ 1 │ 1 │ 4 │ b0df3669b81f │ 172.26.0.6 │ 9000 │ 0 │ │ ᴺᵁᴸᴸ │
|
||||
└─────────┴───────────┴──────────────┴─────────────┴──────────────┴──────────────┴──────┴──────────┴──────┴───────────┘
|
||||
```
|
||||
|
||||
The fourth node is participating in the cluster, but table `event_table` still exists only on the first three nodes:
|
||||
|
||||
|
||||
```sql
|
||||
SELECT hostname(), database, table FROM clusterAllReplicas(default, system.tables) WHERE table = 'event_table' FORMAT PrettyCompactMonoBlock
|
||||
|
||||
┌─hostname()───┬─database─┬─table───────┐
|
||||
│ a6a68731c21b │ default │ event_table │
|
||||
│ 92d3c04025e8 │ default │ event_table │
|
||||
│ 8e62b9cb17a1 │ default │ event_table │
|
||||
└──────────────┴──────────┴─────────────┘
|
||||
```
|
||||
|
||||
If you need to have tables replicated on all the nodes, you may use the [Replicated](../engines/database-engines/replicated.md) database engine in alternative to cluster discovery.
|
||||
|
||||
@ -88,7 +88,7 @@ Default: 2
|
||||
|
||||
## background_merges_mutations_scheduling_policy
|
||||
|
||||
The policy on how to perform a scheduling for background merges and mutations. Possible values are: `round_robin` and `shortest_task_first`.
|
||||
The policy on how to perform a scheduling for background merges and mutations. Possible values are: `round_robin` and `shortest_task_first`.
|
||||
|
||||
## background_merges_mutations_scheduling_policy
|
||||
|
||||
@ -583,7 +583,7 @@ Both the cache for `local_disk`, and temporary data will be stored in `/tiny_loc
|
||||
|
||||
Type: String
|
||||
|
||||
Default:
|
||||
Default:
|
||||
|
||||
## thread_pool_queue_size
|
||||
|
||||
@ -640,7 +640,7 @@ When `/disk1` is full, temporary data will be stored on `/disk2`.
|
||||
```
|
||||
Type: String
|
||||
|
||||
Default:
|
||||
Default:
|
||||
|
||||
## uncompressed_cache_policy
|
||||
|
||||
@ -1948,7 +1948,7 @@ If the table does not exist, ClickHouse will create it. If the structure of the
|
||||
<flush_interval_milliseconds>7500</flush_interval_milliseconds>
|
||||
<max_size_rows>1048576</max_size_rows>
|
||||
<reserved_size_rows>8192</reserved_size_rows>
|
||||
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
|
||||
<buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
|
||||
<flush_on_crash>false</flush_on_crash>
|
||||
</query_thread_log>
|
||||
```
|
||||
@ -2236,6 +2236,8 @@ For the value of the `incl` attribute, see the section “[Configuration files](
|
||||
**See Also**
|
||||
|
||||
- [skip_unavailable_shards](../../operations/settings/settings.md#settings-skip_unavailable_shards)
|
||||
- [Cluster Discovery](../../operations/cluster-discovery.md)
|
||||
- [Replicated database engine](../../engines/database-engines/replicated.md)
|
||||
|
||||
## timezone {#server_configuration_parameters-timezone}
|
||||
|
||||
@ -2404,7 +2406,7 @@ This section contains the following parameters:
|
||||
* nearest_hostname - selects a ZooKeeper node with a hostname that is most similar to the server’s hostname.
|
||||
* first_or_random - selects the first ZooKeeper node, if it's not available then randomly selects one of remaining ZooKeeper nodes.
|
||||
* round_robin - selects the first ZooKeeper node, if reconnection happens selects the next.
|
||||
|
||||
|
||||
**Example configuration**
|
||||
|
||||
``` xml
|
||||
|
||||
Loading…
Reference in New Issue
Block a user