Replicación de datos

En este tutorial, utilizará Docker compose para configurar el clúster de ClickHouse. Esta configuración también puede adaptarse para funcionar en máquinas locales independientes, máquinas virtuales o instancias en la nube.

Ejecute los siguientes comandos para configurar la estructura de directorios de este ejemplo:

mkdir cluster_1S_2R
cd cluster_1S_2R

# Create clickhouse-keeper directories
for i in {01..03}; do
  mkdir -p fs/volumes/clickhouse-keeper-${i}/etc/clickhouse-keeper
done

# Create clickhouse-server directories
for i in {01..02}; do
  mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server
done

Añade el siguiente archivo docker-compose.yml al directorio cluster_1S_2R:

version: '3.8'
services:
  clickhouse-01:
    image: "clickhouse/clickhouse-server:latest"
    user: "101:101"
    container_name: clickhouse-01
    hostname: clickhouse-01
    volumes:
      - ${PWD}/fs/volumes/clickhouse-01/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
      - ${PWD}/fs/volumes/clickhouse-01/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
    ports:
      - "127.0.0.1:8123:8123"
      - "127.0.0.1:9000:9000"
    depends_on:
      - clickhouse-keeper-01
      - clickhouse-keeper-02
      - clickhouse-keeper-03
  clickhouse-02:
    image: "clickhouse/clickhouse-server:latest"
    user: "101:101"
    container_name: clickhouse-02
    hostname: clickhouse-02
    volumes:
      - ${PWD}/fs/volumes/clickhouse-02/etc/clickhouse-server/config.d/config.xml:/etc/clickhouse-server/config.d/config.xml
      - ${PWD}/fs/volumes/clickhouse-02/etc/clickhouse-server/users.d/users.xml:/etc/clickhouse-server/users.d/users.xml
    ports:
      - "127.0.0.1:8124:8123"
      - "127.0.0.1:9001:9000"
    depends_on:
      - clickhouse-keeper-01
      - clickhouse-keeper-02
      - clickhouse-keeper-03
  clickhouse-keeper-01:
    image: "clickhouse/clickhouse-keeper:latest-alpine"
    user: "101:101"
    container_name: clickhouse-keeper-01
    hostname: clickhouse-keeper-01
    volumes:
     - ${PWD}/fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml
    ports:
        - "127.0.0.1:9181:9181"
  clickhouse-keeper-02:
    image: "clickhouse/clickhouse-keeper:latest-alpine"
    user: "101:101"
    container_name: clickhouse-keeper-02
    hostname: clickhouse-keeper-02
    volumes:
     - ${PWD}/fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml
    ports:
        - "127.0.0.1:9182:9181"
  clickhouse-keeper-03:
    image: "clickhouse/clickhouse-keeper:latest-alpine"
    user: "101:101"
    container_name: clickhouse-keeper-03
    hostname: clickhouse-keeper-03
    volumes:
     - ${PWD}/fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper/keeper_config.xml:/etc/clickhouse-keeper/keeper_config.xml
    ports:
        - "127.0.0.1:9183:9181"

Cree los siguientes subdirectorios y archivos:

for i in {01..02}; do
  mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server/config.d
  mkdir -p fs/volumes/clickhouse-${i}/etc/clickhouse-server/users.d
  touch fs/volumes/clickhouse-${i}/etc/clickhouse-server/config.d/config.xml
  touch fs/volumes/clickhouse-${i}/etc/clickhouse-server/users.d/users.xml
done

• El directorio config.d contiene el archivo de configuración del servidor ClickHouse config.xml, en el que se define la configuración personalizada de cada nodo de ClickHouse. Esta configuración se combina con el archivo de configuración predeterminado config.xml de ClickHouse, incluido en cada instalación de ClickHouse.
• El directorio users.d contiene el archivo de configuración de usuarios users.xml, en el que se define la configuración personalizada para los usuarios. Esta configuración se combina con el archivo de configuración predeterminado users.xml de ClickHouse, incluido en cada instalación de ClickHouse.

Configuración del servidor

Ahora modifique cada archivo de configuración vacío config.xml ubicado en fs/volumes/clickhouse-{}/etc/clickhouse-server/config.d. Las líneas que se muestran a continuación deben cambiarse para que sean específicas de cada nodo:

<clickhouse replace="true">
    <logger>
        <level>debug</level>
        <log>/var/log/clickhouse-server/clickhouse-server.log</log>
        <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
        <size>1000M</size>
        <count>3</count>
    </logger>
    <display_name>cluster_1S_2R node 1</display_name>
    <listen_host>0.0.0.0</listen_host>
    <http_port>8123</http_port>
    <tcp_port>9000</tcp_port>
    <user_directories>
        <users_xml>
            <path>users.xml</path>
        </users_xml>
        <local_directory>
            <path>/var/lib/clickhouse/access/</path>
        </local_directory>
    </user_directories>
    <distributed_ddl>
        <path>/clickhouse/task_queue/ddl</path>
    </distributed_ddl>
    <remote_servers>
        <cluster_1S_2R>
            <shard>
                <internal_replication>true</internal_replication>
                <replica>
                    <host>clickhouse-01</host>
                    <port>9000</port>
                </replica>
                <replica>
                    <host>clickhouse-02</host>
                    <port>9000</port>
                </replica>
            </shard>
        </cluster_1S_2R>
    </remote_servers>
    <zookeeper>
        <node>
            <host>clickhouse-keeper-01</host>
            <port>9181</port>
        </node>
        <node>
            <host>clickhouse-keeper-02</host>
            <port>9181</port>
        </node>
        <node>
            <host>clickhouse-keeper-03</host>
            <port>9181</port>
        </node>
    </zookeeper>
    <macros>
        <shard>01</shard>
        <replica>01</replica>
        <cluster>cluster_1S_2R</cluster>
    </macros>
</clickhouse>

Cada sección del archivo de configuración anterior se explica con más detalle a continuación.

Redes y registro

La comunicación externa a través de la interfaz de red se habilita al activar la configuración de listen host. Esto garantiza que el host del servidor ClickHouse sea accesible desde otros hosts:

<listen_host>0.0.0.0</listen_host>

El puerto de la API HTTP está configurado como 8123:

<http_port>8123</http_port>

El puerto TCP para la comunicación mediante el protocolo nativo de ClickHouse entre clickhouse-client y otras herramientas nativas de ClickHouse, y clickhouse-server y otros clickhouse-servers está configurado en 9000:

<tcp_port>9000</tcp_port>

El registro se define en el bloque <logger>. Esta configuración de ejemplo genera un log de depuración que rotará cada 1000 MB hasta tres veces:

<logger>
    <level>debug</level>
    <log>/var/log/clickhouse-server/clickhouse-server.log</log>
    <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
    <size>1000M</size>
    <count>3</count>
</logger>

Para obtener más información sobre la configuración de logging, consulte los comentarios incluidos en el archivo de configuración predeterminado de ClickHouse.

Configuración del clúster

La configuración del clúster se establece en el bloque <remote_servers>. Aquí se define el nombre del clúster cluster_1S_2R.

El bloque <cluster_1S_2R></cluster_1S_2R> define el layout del clúster mediante las configuraciones <shard></shard> y <replica></replica>, y actúa como plantilla para las consultas de DDL distribuido, es decir, consultas que se ejecutan en todo el clúster mediante la cláusula ON CLUSTER. De forma predeterminada, las consultas de DDL distribuido están permitidas, pero también pueden desactivarse con el parámetro allow_distributed_ddl_queries.

internal_replication está configurado en true para que los datos se escriban en una sola de las réplicas.

<remote_servers>
    <!-- cluster name (should not contain dots) -->
    <cluster_1S_2R>
        <!-- <allow_distributed_ddl_queries>false</allow_distributed_ddl_queries> -->
        <shard>
            <!-- Optional. Whether to write data to just one of the replicas. Default: false (write data to all replicas). -->
            <internal_replication>true</internal_replication>
            <replica>
                <host>clickhouse-01</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>clickhouse-02</host>
                <port>9000</port>
            </replica>
        </shard>
    </cluster_1S_2R>
</remote_servers>

Para cada servidor, se especifican los siguientes parámetros:

Configuración de Keeper

La sección <ZooKeeper> indica a ClickHouse dónde se está ejecutando ClickHouse Keeper (o ZooKeeper). Como estamos utilizando un cluster de ClickHouse Keeper, es necesario especificar cada <node> del cluster, junto con su hostname y número de puerto mediante las etiquetas <host> y <port> respectivamente.

La configuración de ClickHouse Keeper se explica en el siguiente paso del tutorial.

<zookeeper>
    <node>
        <host>clickhouse-keeper-01</host>
        <port>9181</port>
    </node>
    <node>
        <host>clickhouse-keeper-02</host>
        <port>9181</port>
    </node>
    <node>
        <host>clickhouse-keeper-03</host>
        <port>9181</port>
    </node>
</zookeeper>

Configuración de macros

Además, la sección <macros> se utiliza para definir sustituciones de parámetros para tablas replicadas. Estas se listan en system.macros y permiten usar sustituciones como {shard} y {replica} en las consultas.

<macros>
    <shard>01</shard>
    <replica>01</replica>
    <cluster>cluster_1S_2R</cluster>
</macros>

Configuración de usuario

Ahora modifique cada archivo de configuración vacío users.xml ubicado en fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d con lo siguiente:

<?xml version="1.0"?>
<clickhouse replace="true">
    <profiles>
        <default>
            <max_memory_usage>10000000000</max_memory_usage>
            <use_uncompressed_cache>0</use_uncompressed_cache>
            <load_balancing>in_order</load_balancing>
            <log_queries>1</log_queries>
        </default>
    </profiles>
    <users>
        <default>
            <access_management>1</access_management>
            <profile>default</profile>
            <networks>
                <ip>::/0</ip>
            </networks>
            <quota>default</quota>
            <access_management>1</access_management>
            <named_collection_control>1</named_collection_control>
            <show_named_collections>1</show_named_collections>
            <show_named_collections_secrets>1</show_named_collections_secrets>
        </default>
    </users>
    <quotas>
        <default>
            <interval>
                <duration>3600</duration>
                <queries>0</queries>
                <errors>0</errors>
                <result_rows>0</result_rows>
                <read_rows>0</read_rows>
                <execution_time>0</execution_time>
            </interval>
        </default>
    </quotas>
</clickhouse>

En este ejemplo, el usuario default se configura sin contraseña para simplificar. En la práctica, esto no es recomendable.

Configuración de ClickHouse Keeper

Para que la replicación funcione, es necesario configurar un clúster de ClickHouse Keeper. ClickHouse Keeper proporciona el sistema de coordinación para la replicación de datos y actúa como reemplazo directo de ZooKeeper, que también podría utilizarse. No obstante, se recomienda ClickHouse Keeper, ya que ofrece mejores garantías y fiabilidad, además de utilizar menos recursos que ZooKeeper. Para lograr alta disponibilidad y mantener el quorum, se recomienda ejecutar al menos tres nodos de ClickHouse Keeper.

Cree los archivos keeper_config.xml para cada nodo de ClickHouse Keeper con el siguiente comando desde la raíz de la carpeta de ejemplo:

for i in {01..03}; do
  touch fs/volumes/clickhouse-keeper-${i}/etc/clickhouse-keeper/keeper_config.xml
done

Modifique los archivos de configuración vacíos que se crearon en el directorio de cada nodo fs/volumes/clickhouse-keeper-{}/etc/clickhouse-keeper. Las líneas resaltadas a continuación deben modificarse para que sean específicas de cada nodo:

<clickhouse replace="true">
    <logger>
        <level>information</level>
        <log>/var/log/clickhouse-keeper/clickhouse-keeper.log</log>
        <errorlog>/var/log/clickhouse-keeper/clickhouse-keeper.err.log</errorlog>
        <size>1000M</size>
        <count>3</count>
    </logger>
    <listen_host>0.0.0.0</listen_host>
    <keeper_server>
        <tcp_port>9181</tcp_port>
        <server_id>1</server_id>
        <log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path>
        <snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>
        <coordination_settings>
            <operation_timeout_ms>10000</operation_timeout_ms>
            <session_timeout_ms>30000</session_timeout_ms>
            <raft_logs_level>information</raft_logs_level>
        </coordination_settings>
        <raft_configuration>
            <server>
                <id>1</id>
                <hostname>clickhouse-keeper-01</hostname>
                <port>9234</port>
            </server>
            <server>
                <id>2</id>
                <hostname>clickhouse-keeper-02</hostname>
                <port>9234</port>
            </server>
            <server>
                <id>3</id>
                <hostname>clickhouse-keeper-03</hostname>
                <port>9234</port>
            </server>
        </raft_configuration>
    </keeper_server>
</clickhouse>

Cada archivo de configuración contendrá la siguiente configuración única (que se muestra a continuación). El server_id utilizado debe ser único para ese nodo específico de ClickHouse Keeper en el clúster y coincidir con el <id> del servidor definido en la sección <raft_configuration>. tcp_port es el puerto que utilizan los clientes de ClickHouse Keeper.

<tcp_port>9181</tcp_port>
<server_id>{id}</server_id>

La siguiente sección se utiliza para configurar los servidores que participan en el quórum del algoritmo de consenso Raft:

<raft_configuration>
    <server>
        <id>1</id>
        <hostname>clickhouse-keeper-01</hostname>
        <!-- Puerto TCP utilizado para la comunicación entre nodos de ClickHouse Keeper -->
        <port>9234</port>
    </server>
    <server>
        <id>2</id>
        <hostname>clickhouse-keeper-02</hostname>
        <port>9234</port>
    </server>
    <server>
        <id>3</id>
        <hostname>clickhouse-keeper-03</hostname>
        <port>9234</port>
    </server>
</raft_configuration>

Asegúrate de que Docker se esté ejecutando en tu equipo. Inicia el clúster con el comando docker-compose up desde la raíz del directorio cluster_1S_2R:

docker-compose up -d

Deberías ver que Docker empieza a descargar las imágenes de ClickHouse y Keeper, y luego inicia los contenedores:

[+] Running 6/6
 ✔ Network cluster_1s_2r_default   Created
 ✔ Container clickhouse-keeper-03  Started
 ✔ Container clickhouse-keeper-02  Started
 ✔ Container clickhouse-keeper-01  Started
 ✔ Container clickhouse-01         Started
 ✔ Container clickhouse-02         Started

Para verificar que el cluster esté en funcionamiento, conéctese a clickhouse-01 o clickhouse-02 y ejecute la siguiente consulta. A continuación se muestra el comando para conectarse al primer nodo:

# Connect to any node
docker exec -it clickhouse-01 clickhouse-client

Si todo ha ido bien, verá el prompt del cliente de ClickHouse:

cluster_1S_2R node 1 :)

Ejecute la siguiente consulta para comprobar qué topologías de clúster están definidas para cada host:

SELECT 
    cluster,
    shard_num,
    replica_num,
    host_name,
    port
FROM system.clusters;

   ┌─cluster───────┬─shard_num─┬─replica_num─┬─host_name─────┬─port─┐
1. │ cluster_1S_2R │         1 │           1 │ clickhouse-01 │ 9000 │
2. │ cluster_1S_2R │         1 │           2 │ clickhouse-02 │ 9000 │
3. │ default       │         1 │           1 │ localhost     │ 9000 │
   └───────────────┴───────────┴─────────────┴───────────────┴──────┘

Ejecute la siguiente consulta para verificar el estado del cluster de ClickHouse Keeper:

SELECT *
FROM system.zookeeper
WHERE path IN ('/', '/clickhouse')

   ┌─name───────┬─value─┬─path────────┐
1. │ sessions   │       │ /clickhouse │
2. │ task_queue │       │ /clickhouse │
3. │ keeper     │       │ /           │
4. │ clickhouse │       │ /           │
   └────────────┴───────┴─────────────┘

El comando mntr también se usa habitualmente para verificar que ClickHouse Keeper está en ejecución y para obtener información sobre el estado de la relación entre los tres nodos de Keeper. En la configuración utilizada en este ejemplo, hay tres nodos que trabajan juntos. Los nodos elegirán un líder y los nodos restantes serán followers.

El comando mntr proporciona información relacionada con el rendimiento y con si un nodo determinado es follower o leader.

Ejecute el siguiente comando desde un shell en clickhouse-keeper-01, clickhouse-keeper-02 y clickhouse-keeper-03 para comprobar el estado de cada nodo de Keeper. El comando para clickhouse-keeper-01 se muestra a continuación:

docker exec -it clickhouse-keeper-01  /bin/sh -c 'echo mntr | nc 127.0.0.1 9181'

A continuación se muestra un ejemplo de respuesta de un nodo seguidor:

zk_version      v23.3.1.2823-testing-46e85357ce2da2a99f56ee83a079e892d7ec3726
zk_avg_latency  0
zk_max_latency  0
zk_min_latency  0
zk_packets_received     0
zk_packets_sent 0
zk_num_alive_connections        0
zk_outstanding_requests 0
zk_server_state follower
zk_znode_count  6
zk_watch_count  0
zk_ephemerals_count     0
zk_approximate_data_size        1271
zk_key_arena_size       4096
zk_latest_snapshot_size 0
zk_open_file_descriptor_count   46
zk_max_file_descriptor_count    18446744073709551615

A continuación se muestra un ejemplo de respuesta de un nodo líder:

zk_version      v23.3.1.2823-testing-46e85357ce2da2a99f56ee83a079e892d7ec3726
zk_avg_latency  0
zk_max_latency  0
zk_min_latency  0
zk_packets_received     0
zk_packets_sent 0
zk_num_alive_connections        0
zk_outstanding_requests 0
zk_server_state leader
zk_znode_count  6
zk_watch_count  0
zk_ephemerals_count     0
zk_approximate_data_size        1271
zk_key_arena_size       4096
zk_latest_snapshot_size 0
zk_open_file_descriptor_count   48
zk_max_file_descriptor_count    18446744073709551615
zk_followers    2
zk_synced_followers     2

Con esto, ha configurado correctamente un clúster de ClickHouse con un solo segmento y dos réplicas. En el siguiente paso, creará una tabla en el clúster.

Ahora que ha verificado que el clúster está correctamente configurado y en funcionamiento, va a recrear la misma tabla que se usa en el tutorial del conjunto de datos de ejemplo de precios de propiedades en el Reino Unido. Contiene alrededor de 30 millones de filas con precios pagados por propiedades inmobiliarias en Inglaterra y Gales desde 1995.

Conéctese al cliente de cada host ejecutando los siguientes comandos en pestañas o ventanas de terminal independientes:

docker exec -it clickhouse-01 clickhouse-client
docker exec -it clickhouse-02 clickhouse-client

Puedes ejecutar la consulta siguiente desde clickhouse-client en cada host para confirmar que todavía no se ha creado ninguna base de datos, aparte de las predeterminadas:

SHOW DATABASES;

   ┌─name───────────────┐
1. │ INFORMATION_SCHEMA │
2. │ default            │
3. │ information_schema │
4. │ system             │
   └────────────────────┘

Desde el cliente clickhouse-01, ejecute la siguiente consulta DDL distribuida mediante la cláusula ON CLUSTER para crear una nueva base de datos llamada uk:

CREATE DATABASE IF NOT EXISTS uk 
ON CLUSTER cluster_1S_2R;

Puedes volver a ejecutar la misma consulta que antes desde el cliente de cada host para confirmar que la base de datos se ha creado en todo el clúster, aunque la consulta se haya ejecutado solo en clickhouse-01:

SHOW DATABASES;

   ┌─name───────────────┐
1. │ INFORMATION_SCHEMA │
2. │ default            │
3. │ information_schema │
4. │ system             │
5. │ uk                 │
   └────────────────────┘

Ahora que se ha creado la base de datos, cree una tabla en el clúster. Ejecute la siguiente consulta desde cualquiera de los clientes host:

CREATE TABLE IF NOT EXISTS uk.uk_price_paid_local
ON CLUSTER cluster_1S_2R
(
    price UInt32,
    date Date,
    postcode1 LowCardinality(String),
    postcode2 LowCardinality(String),
    type Enum8('terraced' = 1, 'semi-detached' = 2, 'detached' = 3, 'flat' = 4, 'other' = 0),
    is_new UInt8,
    duration Enum8('freehold' = 1, 'leasehold' = 2, 'unknown' = 0),
    addr1 String,
    addr2 String,
    street LowCardinality(String),
    locality LowCardinality(String),
    town LowCardinality(String),
    district LowCardinality(String),
    county LowCardinality(String)
)
ENGINE = ReplicatedMergeTree
ORDER BY (postcode1, postcode2, addr1, addr2);

Observa que es idéntica a la consulta utilizada en la sentencia CREATE original del tutorial del conjunto de datos de ejemplo precios de viviendas del Reino Unido, salvo por la cláusula ON CLUSTER y el uso del motor ReplicatedMergeTree.

La cláusula ON CLUSTER está diseñada para la ejecución distribuida de consultas DDL (Data Definition Language) como CREATE, DROP, ALTER y RENAME, lo que garantiza que estos cambios de esquema se apliquen en todos los nodos de un clúster.

El motor ReplicatedMergeTree funciona igual que el motor de tabla MergeTree normal, pero también replica los datos.

Puedes ejecutar la consulta siguiente desde el cliente clickhouse-01 o clickhouse-02 para confirmar que la tabla se ha creado en todo el clúster:

SHOW TABLES IN uk;

   ┌─name────────────────┐
1. │ uk_price_paid.      │
   └─────────────────────┘

Dado que el conjunto de datos es grande y tarda varios minutos en ingestarse por completo, comenzaremos insertando solo un pequeño subconjunto.

Inserte un subconjunto más pequeño de los datos mediante la siguiente consulta desde clickhouse-01:

INSERT INTO uk.uk_price_paid_local
SELECT
    toUInt32(price_string) AS price,
    parseDateTimeBestEffortUS(time) AS date,
    splitByChar(' ', postcode)[1] AS postcode1,
    splitByChar(' ', postcode)[2] AS postcode2,
    transform(a, ['T', 'S', 'D', 'F', 'O'], ['terraced', 'semi-detached', 'detached', 'flat', 'other']) AS type,
    b = 'Y' AS is_new,
    transform(c, ['F', 'L', 'U'], ['freehold', 'leasehold', 'unknown']) AS duration,
    addr1,
    addr2,
    street,
    locality,
    town,
    district,
    county
FROM url(
    'http://prod1.publicdata.landregistry.gov.uk.s3-website-eu-west-1.amazonaws.com/pp-complete.csv',
    'CSV',
    'uuid_string String,
    price_string String,
    time String,
    postcode String,
    a String,
    b String,
    c String,
    addr1 String,
    addr2 String,
    street String,
    locality String,
    town String,
    district String,
    county String,
    d String,
    e String'
) LIMIT 10000
SETTINGS max_http_get_redirects=10;

Observe que los datos están completamente replicados en cada host:

-- clickhouse-01
SELECT count(*)
FROM uk.uk_price_paid_local

--   ┌─count()─┐
-- 1.│   10000 │
--   └─────────┘

-- clickhouse-02
SELECT count(*)
FROM uk.uk_price_paid_local

--   ┌─count()─┐
-- 1.│   10000 │
--   └─────────┘

Para demostrar qué ocurre cuando uno de los hosts falla, cree una base de datos de prueba sencilla y una tabla de prueba desde cualquiera de los hosts:

CREATE DATABASE IF NOT EXISTS test ON CLUSTER cluster_1S_2R;
CREATE TABLE test.test_table ON CLUSTER cluster_1S_2R
(
    `id` UInt64,
    `name` String
)
ENGINE = ReplicatedMergeTree
ORDER BY id;

Al igual que con la tabla uk_price_paid, podemos insertar datos desde cualquiera de los dos hosts:

INSERT INTO test.test_table (id, name) VALUES (1, 'Clicky McClickface');

¿Pero qué pasará si uno de los hosts está caído? Para simularlo, detenga clickhouse-01 ejecutando:

docker stop clickhouse-01

Verifique que el host esté apagado ejecutando:

docker-compose ps

NAME                   IMAGE                                        COMMAND            SERVICE                CREATED          STATUS          PORTS
clickhouse-02          clickhouse/clickhouse-server:latest          "/entrypoint.sh"   clickhouse-02          X minutes ago    Up X minutes    127.0.0.1:8124->8123/tcp, 127.0.0.1:9001->9000/tcp
clickhouse-keeper-01   clickhouse/clickhouse-keeper:latest-alpine   "/entrypoint.sh"   clickhouse-keeper-01   X minutes ago    Up X minutes    127.0.0.1:9181->9181/tcp
clickhouse-keeper-02   clickhouse/clickhouse-keeper:latest-alpine   "/entrypoint.sh"   clickhouse-keeper-02   X minutes ago    Up X minutes    127.0.0.1:9182->9181/tcp
clickhouse-keeper-03   clickhouse/clickhouse-keeper:latest-alpine   "/entrypoint.sh"   clickhouse-keeper-03   X minutes ago    Up X minutes    127.0.0.1:9183->9181/tcp

Con clickhouse-01 ahora inactivo, inserta otra fila de datos en la tabla de prueba y consulta la tabla:

INSERT INTO test.test_table (id, name) VALUES (2, 'Alexey Milovidov');
SELECT * FROM test.test_table;

   ┌─id─┬─name───────────────┐
1. │  1 │ Clicky McClickface │
2. │  2 │ Alexey Milovidov   │
   └────┴────────────────────┘

Ahora reinicie clickhouse-01 con el siguiente comando (puede volver a ejecutar docker-compose ps para confirmarlo):

docker start clickhouse-01

Vuelva a consultar la tabla de prueba desde clickhouse-01 tras ejecutar docker exec -it clickhouse-01 clickhouse-client:

SELECT * FROM test.test_table

   ┌─id─┬─name───────────────┐
1. │  1 │ Clicky McClickface │
2. │  2 │ Alexey Milovidov   │
   └────┴────────────────────┘

Si en este punto desea ingestar el conjunto de datos completo de precios de propiedades del Reino Unido para experimentar con él, puede ejecutar las siguientes consultas:

TRUNCATE TABLE uk.uk_price_paid_local ON CLUSTER cluster_1S_2R;
INSERT INTO uk.uk_price_paid_local
SELECT
    toUInt32(price_string) AS price,
    parseDateTimeBestEffortUS(time) AS date,
    splitByChar(' ', postcode)[1] AS postcode1,
    splitByChar(' ', postcode)[2] AS postcode2,
    transform(a, ['T', 'S', 'D', 'F', 'O'], ['terraced', 'semi-detached', 'detached', 'flat', 'other']) AS type,
    b = 'Y' AS is_new,
    transform(c, ['F', 'L', 'U'], ['freehold', 'leasehold', 'unknown']) AS duration,
    addr1,
    addr2,
    street,
    locality,
    town,
    district,
    county
FROM url(
    'http://prod1.publicdata.landregistry.gov.uk.s3-website-eu-west-1.amazonaws.com/pp-complete.csv',
    'CSV',
    'uuid_string String,
    price_string String,
    time String,
    postcode String,
    a String,
    b String,
    c String,
    addr1 String,
    addr2 String,
    street String,
    locality String,
    town String,
    district String,
    county String,
    d String,
    e String'
    ) SETTINGS max_http_get_redirects=10;

Consulta la tabla desde clickhouse-02 o clickhouse-01:

SELECT count(*) FROM uk.uk_price_paid_local;

   ┌──count()─┐
1. │ 30212555 │ -- 30.21 million
   └──────────┘