ClickHouse提供了非常高级的基于ZK的表复制方式，同时也提供了基于Cluster的复制方式
二者非常容易搞混
特写此PPT来说明
<!–more–>
关于 “一台超大机器只做备份用” 的离线备份方案，请教下具体怎么实现呢？
我们的需求是希望支持每天增量备份前一天的数据。 比如，用clickhouse copier，能实现按天增量备份吗？
@jackpgao 我不太想用zookeeper；复制表建立、维护也比较麻烦。
我们不需要复制表实时性这么好的备份方案，想找一个离线、增量备份方案——维护成本比较低。
- 通过域名解析/负载均衡服务（如GSLB），确保http访问请求，一定被路由到客户端所在的IDC，即你说的“当前IDC”
- 在每个IDC，分别为本IDC建立tb-all分布式表，底层只访问本IDC的ClickHouse集群。
@kikanjuu 配置文件是不是类似下面这样，然后再建个tb-all2表，Distributed(cluster2,…) 这样貌似就没有当host11,host12挂掉一台，还能继续服务了。如果有类似nginx的backup功能，当前idc为主，当主服务器不可用，到Backup的服务器。
<clickhouse_remote_servers>
<cluster1>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>host11</host>
<port>9000</port>
</replica>
<replica>
<host>host21</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>host12</host>
<port>9000</port>
</replica>
<replica>
<host>host22</host>
<port>9000</port>
</replica>
</shard>
</cluster1>
<cluster2>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>host11</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>host12</host>
<port>9000</port>
</replica>
</shard>
</cluster2>
</clickhouse_remote_servers>
-
既然cluster1和cluster2是属于两个不同的IDC的，为什么它们里面都有host11, host12 ？ 一台机器不可能同时属于两个IDC。
-
在一个shard里，有两个replica——host11和host12，也就是两个副本。那么当host11挂掉了，host12这个副本仍然可以提供数据。 为什么说 “就没有当host11,host12挂掉一台，还能继续服务了” 呢？
@kikanjuu ，大致如下图
host11,host12 在idc1; host21,host22 在idc2
host11,host21 之间复制 ；host12,host22 之间复制
本来是只有cluster1的，但担心查询会跑到idc2比较慢，想尽量在idc查询。于是建了个cluster2分片，只有idc1的机器。
那你上面的配置没错。应当通过cluster1写入数据；通过cluster2查询数据。
-
基于cluster1，建立写入用的分布式表。 CREATE TABLE … ENGINE = Distributed(cluster1,…) cluster1保证了数据在“host11,host21 之间复制 ；host12,host22 之间复制”
-
基于cluster2，建立查询用的分布式表。 CREATE TABLE … ENGINE = Distributed(cluster2,…)
由于cluster2只包含IDC1的两台机器，因此通过这张表查询，只会查询到IDC1的两台机器。IDC2的机器不提供查询服务。 但是不要通过这张表写入cluster2。