Clickhouse: replication types in clickhouse

[lamber-ken]

ClickHouse has 2 ways of data replication.

The first one is to use cluster replication, as below:

IP1 and IP2 has same data, IP3 and IP 4 has same data.

The second one is ReplicatedMergeTree engine, which based on zookeeper.

My question is, what happened if I use both.
For example, I have a table both in IP1 and IP2, the table engine is ReplicatedMergeTree, and the share the same ZK path, which means they will exchange data each other.
But they are both in the same replication config, will the replication conflict？

[alxark]

Hello. Shard configuration doesn't setup any replication between tables, it's only a map for distributed engine to know where to search data. In your case: if you will not setup Replicated* Engine on IP1 and IP2 you will have 2 different data sets on your servers. That means that when you will query distributed table you will get different results.

[lamber-ken]

@alxark @ztlpn
hi, What does this sentence mean in the picture? ---> write data to all of the replicas

here is the clickhouse`s document

[ztlpn]

There can be four different combinations. Let us consider them one by one.

1. Non-replicated tables, internal_replication=false. Data inserted into the Distributed table is inserted into both local tables and if there are no problems during inserts, the data on both local tables stays in sync. We call this "poor man's replication" because replicas easily diverge in case of network problems and there is no easy way to determine which one is the correct replica.

2. Replicated tables, internal_replication=true. Data inserted into the Distributed table is inserted into only one of the local tables, but is transferred to the table on the other host via the replication mechanism. Thus data on both local tables stays in sync. This is the recommended configuration.

3. Non-replicated tables, internal_replication=true. Data is inserted into only one of the local tables, but _there is no mechanism to transfer it to the other table_. So local tables on different hosts end up with different data and you get confusing results when querying the Distributed table. Obviously this is an incorrect way to configure ClickHouse cluster.

4. Replicated tables, internal_replication=false. Data is inserted into both local tables, but thanks to the deduplication feature of Replicated tables only the first insert goes through and the insert into the other table on the other host gets silently discarded because it is a duplicate. The first insert is then replicated to the other table. So in this case nothing overtly bad happens, replicas stay in sync, but there is significant performance degradation due to the constant stream of duplicates. So you should avoid this configuration too and use configuration 2 instead.

[lamber-ken]

@ztlpn thank you very match