Топологии кластера

Топология кластера — это количество шардов и количество реплик на каждом шарде. Выбор топологии определяет соотношение между надёжностью (HA), горизонтальным масштабированием ёмкости и стоимостью инфраструктуры. Нет универсальной топологии: выбор зависит от приоритетов конкретной системы.

1 шард x 3 реплики (1S_3R)

Один шард с тремя репликами. Все узлы содержат полную копию данных. Не масштабирует ёмкость хранения, но обеспечивает высокую читаемость и отказоустойчивость.

<!-- remote_servers: 1S_3R топология -->
<mycluster_1s3r>
    <shard>
        <internal_replication>true</internal_replication>
        <replica><host>clickhouse-01</host><port>9000</port></replica>
        <replica><host>clickhouse-02</host><port>9000</port></replica>
        <replica><host>clickhouse-03</host><port>9000</port></replica>
    </shard>
</mycluster_1s3r>

Применение: HA-кластер для чтения с parallel_replicas. Максимальная надёжность при фиксированном объёме данных.

2 шарда x 2 реплики (2S_2R)

Два шарда с двумя репликами каждый — стандартная production-топология. Масштабирует ёмкость (2x данных) и обеспечивает HA (каждый шард имеет резерв).

<!-- remote_servers: 2S_2R топология -->
<mycluster_2s2r>
    <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>
    <shard>
        <internal_replication>true</internal_replication>
        <replica><host>clickhouse-03</host><port>9000</port></replica>
        <replica><host>clickhouse-04</host><port>9000</port></replica>
    </shard>
</mycluster_2s2r>

4 узла хранят 2x объём данных (каждый узел хранит 50% с одним дублем). Потеря одного узла на любом шарде не приводит к недоступности данных.

3 шарда x 2 реплики (3S_2R)

Высокая ёмкость: 3x масштаб при сохранении HA. Требует 6 узлов. Используется когда 2S_2R перестаёт справляться с ingest-нагрузкой или объёмом.

<!-- remote_servers: 3S_2R топология -->
<mycluster_3s2r>
    <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>
    <shard>
        <internal_replication>true</internal_replication>
        <replica><host>clickhouse-03</host><port>9000</port></replica>
        <replica><host>clickhouse-04</host><port>9000</port></replica>
    </shard>
    <shard>
        <internal_replication>true</internal_replication>
        <replica><host>clickhouse-05</host><port>9000</port></replica>
        <replica><host>clickhouse-06</host><port>9000</port></replica>
    </shard>
</mycluster_3s2r>

Cross-DC топология

Cross-DC топология размещает реплики в разных датацентрах для защиты от катастрофического сбоя. Ключевые настройки: <priority> в конфиге реплик и read_from_closest_replica для маршрутизации чтения.

<!-- remote_servers: cross-DC 2S_2R с приоритетами реплик -->
<mycluster_crossdc>
    <shard>
        <internal_replication>true</internal_replication>
        <!-- DC-A: основная реплика (меньший priority = предпочтительнее) -->
        <replica>
            <host>clickhouse-01-dc-a</host>
            <port>9000</port>
            <priority>1</priority>
        </replica>
        <!-- DC-B: резервная реплика (higher priority = менее предпочтительна) -->
        <replica>
            <host>clickhouse-01-dc-b</host>
            <port>9000</port>
            <priority>2</priority>
        </replica>
    </shard>
</mycluster_crossdc>

-- Предпочитать ближайшую реплику при чтении (сессионная настройка)
SET load_balancing = 'nearest_hostname';
-- Или через конфиг: read_from_closest_replica = 1

Сравнение топологий

Ключевые выводы

1. 1S_3R — максимальная HA без масштабирования ёмкости: все узлы содержат полные данные, оптимально для parallel replicas и read scale-out.
2. 2S_2R — production standard: баланс HA и 2x масштабирования ёмкости за 4 узла.
3. 3S_2R — высокий ingest: 3x масштаб при сохранении HA, требует 6 узлов.
4. Cross-DC топология: <priority> определяет предпочтение реплик при чтении (меньше = предпочтительнее), load_balancing = 'nearest_hostname' маршрутизирует к ближайшей реплике.
5. Quorum inserts в cross-DC добавляют межсайтовую latency — учитывайте insert_quorum_timeout или используйте internal_replication=true без quorum.