Découverte des clusters

Vue d’ensemble

La fonctionnalité découverte des clusters de ClickHouse simplifie la configuration du cluster en permettant aux nœuds de se découvrir et de s’enregistrer automatiquement, sans nécessiter de définition explicite dans les fichiers de configuration. Cela est particulièrement utile lorsque la définition manuelle de chaque nœud devient fastidieuse.

La découverte des clusters nécessite que ClickHouse Keeper ou ZooKeeper soit configuré. Dans les versions antérieures, il s’agissait d’une fonctionnalité expérimentale qu’il fallait activer via le paramètre allow_experimental_cluster_discovery dans le fichier de configuration. Ce paramètre est désormais obsolète et n’a plus aucun effet.

Configuration des serveurs distants

Configuration manuelle traditionnelle

Traditionnellement, dans ClickHouse, chaque shard et chaque réplique du cluster devaient être spécifiés manuellement dans la configuration :

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

Utiliser découverte des clusters

Avec découverte des clusters, au lieu de définir explicitement chaque nœud, vous indiquez simplement un chemin dans ZooKeeper. Tous les nœuds qui s’enregistrent sous ce chemin dans ZooKeeper seront automatiquement détectés et ajoutés au cluster.

<remote_servers>
    <cluster_name>
        <discovery>
            <path>/clickhouse/discovery/cluster_name</path>

            <!-- # Optional configuration parameters: -->

            <!-- ## Authentication credentials to access all other nodes in cluster: -->
            <!-- <user>user1</user> -->
            <!-- <password>pass123</password> -->
            <!-- ### Alternatively to password, interserver secret may be used: -->
            <!-- <secret>secret123</secret> -->

            <!-- ## Shard for current node (see below): -->
            <!-- <shard>1</shard> -->

            <!-- ## Observer mode (see below): -->
            <!-- <observer/> -->
        </discovery>
    </cluster_name>
</remote_servers>

Si vous souhaitez spécifier un numéro de shard pour un nœud particulier, vous pouvez inclure la balise <shard> dans la section <discovery> : pour node1 et node2 :

<discovery>
    <path>/clickhouse/discovery/cluster_name</path>
    <shard>1</shard>
</discovery>

pour node3 et node4 :

<discovery>
    <path>/clickhouse/discovery/cluster_name</path>
    <shard>2</shard>
</discovery>

Mode observateur

Les nœuds configurés en mode observateur ne s’enregistreront pas en tant que répliques. Ils se contenteront d’observer et de détecter les autres répliques actives du cluster, sans y participer activement. Pour activer le mode observateur, incluez la balise <observer/> dans la section <discovery> :

<discovery>
    <path>/clickhouse/discovery/cluster_name</path>
    <observer/>
</discovery>

Il peut parfois être nécessaire d’ajouter et de supprimer non seulement des hôtes au sein des clusters, mais aussi les clusters eux-mêmes. Vous pouvez utiliser le nœud <multicluster_root_path> comme chemin racine pour plusieurs clusters :

<remote_servers>
    <some_unused_name>
        <discovery>
            <multicluster_root_path>/clickhouse/discovery</multicluster_root_path>
            <observer/>
        </discovery>
    </some_unused_name>
</remote_servers>

Dans ce cas, lorsqu’un autre hôte s’enregistre avec le chemin /clickhouse/discovery/some_new_cluster, un cluster nommé some_new_cluster sera ajouté. Vous pouvez utiliser ces deux fonctionnalités simultanément : l’hôte peut s’enregistrer dans le cluster my_cluster et découvrir d’autres clusters :

<remote_servers>
    <my_cluster>
        <discovery>
            <path>/clickhouse/discovery/my_cluster</path>
        </discovery>
    </my_cluster>
    <some_unused_name>
        <discovery>
            <multicluster_root_path>/clickhouse/discovery</multicluster_root_path>
            <observer/>
        </discovery>
    </some_unused_name>
</remote_servers>

Limites :

Vous ne pouvez pas utiliser à la fois <path> et <multicluster_root_path> dans le même sous-arbre remote_servers.
<multicluster_root_path> ne peut être utilisé qu’avec <observer/>.
Le dernier segment du chemin dans Keeper est utilisé comme nom du cluster, tandis que lors de l’enregistrement, le nom est tiré de la balise XML.

Cas d’utilisation et limites

À mesure que des nœuds sont ajoutés au chemin ZooKeeper spécifié ou en sont supprimés, ils sont automatiquement découverts ou retirés du cluster, sans qu’il soit nécessaire de modifier la configuration ni de redémarrer le serveur. Cependant, ces changements n’affectent que la configuration du cluster, et non les données ni les bases de données et tables existantes. Considérez l’exemple suivant avec un cluster de 3 nœuds :

<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 │      │      ᴺᵁᴸᴸ │
└─────────┴───────────┴──────────────┴─────────────┴──────────────┴──────────────┴──────┴──────────┴──────┴───────────┘

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

Ensuite, nous ajoutons un nouveau nœud au cluster en démarrant un nouveau nœud avec la même entrée dans la section remote_servers du fichier de configuration :

┌─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 │      │      ᴺᵁᴸᴸ │
└─────────┴───────────┴──────────────┴─────────────┴──────────────┴──────────────┴──────┴──────────┴──────┴───────────┘

Le quatrième nœud participe au cluster, mais la table event_table n’existe encore que sur les trois premiers nœuds :

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 │
└──────────────┴──────────┴─────────────┘

Si vous avez besoin que les tables soient répliquées sur tous les nœuds, vous pouvez utiliser le moteur de base de données Replicated à la place de la découverte de cluster.