Zero-copy Replication на S3
При стандартной репликации на S3 каждая реплика хранит собственную копию данных в S3-бакете. Если две реплики содержат идентичные данные, S3-хранилище используется вдвойне. Zero-copy replication пытается решить эту проблему, заставляя реплики ссылаться на одни и те же S3-объекты.
Концепция: общие объекты вместо копирования
Настройка: allow_remote_fs_zero_copy_replication
Параметр задаётся в конфигурационном файле ClickHouse-сервера:
<!-- /etc/clickhouse-server/config.d/storage.xml -->
<!-- РЕКОМЕНДУЕМАЯ PRODUCTION НАСТРОЙКА: -->
<clickhouse>
<allow_remote_fs_zero_copy_replication>false</allow_remote_fs_zero_copy_replication>
</clickhouse><!-- НЕ ИСПОЛЬЗУЙТЕ В PRODUCTION: -->
<clickhouse>
<allow_remote_fs_zero_copy_replication>true</allow_remote_fs_zero_copy_replication>
</clickhouse>allow_remote_fs_zero_copy_replication выключен по умолчанию (false) и должен оставаться выключенным в production. Feature была экспериментальной с 2021 года. Официальная документация ClickHouse явно рекомендует не включать в production-среде. Включение этого параметра может привести к data corruption при сбоях узлов или S3 операциях.
Кавеаты и риски
Data corruption при сбоях
Reference counting реализован через Keeper (ZooKeeper-совместимый сервис). При одновременном сбое нескольких реплик или Keeper-узлов возможны следующие сценарии:
- Неточный reference count: объект удаляется, когда на него ещё ссылается другая реплика
- Потеря данных: объект “собран мусорщиком” раньше времени; реплика теряет доступ к своим данным
- Несогласованность: Keeper видит объект удалённым, но S3 хранит его (или наоборот)
DR (Disaster Recovery) сценарии ненадёжны
При использовании zero-copy replication классические DR-сценарии (переключение на вторую реплику при отказе первой) ненадёжны: вторая реплика может не иметь полных данных, если reference objects были удалены или не были корректно переданы.
Операции на эфемерных узлах
Feature была разработана для read-heavy workloads с эфемерными узлами (Kubernetes pods), где дублирование данных особенно затратно. Однако именно такие окружения (kubernetes, spot instances) увеличивают вероятность сбоев, которые trigg’ерят описанные выше проблемы.
Когда zero-copy допустимо
| Сценарий | Рекомендация |
|---|---|
| Production кластер | Не использовать (официальная рекомендация ClickHouse) |
| Dev / staging среда | Допустимо, если потеря данных некритична |
| Read-heavy S3 с эфемерными узлами (non-production) | Допустимо с пониманием рисков |
| DR-critical workloads | Категорически нельзя |
| Kubernetes production | Нельзя (эфемерные поды + риск data corruption) |
Рекомендуемая альтернатива
Вместо zero-copy replication используйте стандартный подход:
- Каждая реплика хранит свою копию данных на S3 — надёжно, предсказуемо
- s3_cache на каждой реплике — ускоряет повторные чтения без data-sharing рисков
- JBOD + Standard replication — масштабирование ёмкости без zero-copy рисков
-- Безопасный паттерн: стандартная репликация + s3_cache для ускорения
CREATE TABLE events_replicated
(
event_time DateTime,
payload String
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/events', '{replica}')
ORDER BY event_time
SETTINGS storage_policy = 'tiered_with_cache'; -- s3_cache без zero-copyКлючевые выводы
- Zero-copy replication позволяет репликам разделять S3-объекты вместо хранения копий, экономя ~50% S3 при 2 репликах.
allow_remote_fs_zero_copy_replication=false— рекомендуемый production-дефолт; официальная документация явно рекомендует не включать в production.- Риски: data corruption при сбоях из-за неточного reference counting в Keeper, ненадёжные DR-сценарии.
- Допустимо только в dev/staging-средах, где потеря данных некритична.
- Безопасная альтернатива: стандартная репликация (каждая реплика хранит свою копию) + s3_cache для ускорения повторных чтений.