Подскажите, неужели нельзя сделать аналог master-slave с clickhouse? Просто без

zookeeper'a... кластер не нужен, просто суть slave'a для того что бы некие люди, без прав на запись, могли читать данные (ну грубо говоря это регулятор, которому доступ в прод точно не стоит давать).

Сейчас стоит вопрос (от безысходности) всё таки поднять cluster с zookeeper'ом...

Думали использовать clickhouse-copier, но он вроде как дропает таблички, не умеет инкрементить (ну как в случае с Mysql бин логами), и вроде как сделан просто для разовой миграции данных...

Как быть? :)

сделать простой distributed - это всего несколько строк в конфиге. Подключаете так slave на master, и уже на мастере делаете MV, которое копирует что вам надо (можно и не все) в табличку, которая подключена как remote, а физически живет на slave

Спасибо 🙏 Получается что мы на мастере (проде), в конфиге прописываем несколько строк в блоке <remote_servers> и данные просто будут пересылаться аналогично FDW (Foreign Data Wrappers), просто в другую базу. Но ведь поидее он не проверяет целостность данных... Что например будет если сервак на другой стороне (slave) проглючит, временно отстанет.. Это больше похоже на sharding? Аналог proxy_pass в nginx только умней :)

не только remotes, но и MV, без него ничего само собой копироваться не будет. да, это похоже на sharding. если отвалится remote, то поведение будет непредсказуемо. но вам ведь для регулятора это не так страшно? Надежная репликация - это zookeeper или грядущий clickhouse-keeper.

Ну поидее они требуют быстрой синхронизации данных.. Но с другой стороны если в мониторинге заметить разрыв, то всегда можно починить... Я понял, хороший вариант на самом деле - сейчас поизучаем. Просто предоставляя ноду из cluster'a это больше рисков для бизнеса и в таком роде... Но спасибо большое!

лог инсертов пишется в зукипер, реплики через ЗК подписываются на лог. зукипер не нужен уже cat /etc/clickhouse-server/conf.d/zookeeper.xml <?xml version="1.0" ?> <yandex> <keeper_server> <tcp_port>2181</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>trace</raft_logs_level> </coordination_settings> <raft_configuration> <server> <id>1</id> <hostname>localhost</hostname> <port>9444</port> </server> </raft_configuration> </keeper_server> <zookeeper> <node> <host>localhost</host> <port>2181</port> </node> </zookeeper> <distributed_ddl> <path>/clickhouse/oint/task_queue/ddl</path> </distributed_ddl> </yandex>

А если некоторые таблицы используют ReplacingMergeTree - это не повлияет?

только для Replicated*любойдвижок

На сколько оно prod ready?

сложно сказать, наверное 8 из 10. Нету известных багов, оно проходит все тесты, у меня на стейдже работает. В такой простой задаче из одной пишущей ноды, да еще с одной нодой кипера должно работать. Если надо быстро и диск сильно нагружен, то естественно на отдельном ssd <log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path> <snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>

Ок, понял. Спасибо.

кстати сколько минимум нодов надо чтобы housekeeper норм работал и фейловерился, так же 3? и как он реагирует на сплит-нетворк когда число нодов четное?

да 3. про четное не знаю, кажется рафту плевать. Я уговариваю чтобы сделали чтобы на двух нодах работало (без ha понятно)

без ХА, с уходом в оффлайн до ручного intervention?

c уходом в RO