1. 簡述

Clickhouse預設是多分片單副本集群，分散式表的配置是每個分片只有一份，如果某個節點掛掉的話，則會直接導致寫入或查詢異常；Clickhouse是具有高可用特性的，即每個分片具有2個或以上的副本，當某個節點掛掉時，其他節點上的副本會替代其繼續工作，以保證集群正常運行。

本文主要介紹近期針對clickhouse高可用配置的方法以及數據複製的幾種方式進行總結。

2. 環境說明

2.1. 軟硬體環境

2.2. 集群介紹

3. 配置文件說明

clickhouse高可用配置主要用到metrika.xml，預設路徑：/etc/metrika.xml。

  internal_replication

表示是否只將數據寫入其中一個副本，預設為false，表示寫入所有副本，在複製表的情況下可能會導致重覆和不一致，所以這裡一定要改為true。

四種複製模式：

• 非複製表，internal_replication=false。寫入單機表時，不同伺服器查詢結果不同；插入到分散式表中的數據被插入到兩個本地表中，如果在插入期間沒有問題，則兩個本地表上的數據保持同步。我們稱之為“窮人的複製”，因為複製在網路出現問題的情況下容易發生分歧，沒有一個簡單的方法來確定哪一個是正確的複製。
• 非複製表，internal_replication=true。數據只被插入到一個本地表中，但沒有任何機制可以將它轉移到另一個表中。因此，在不同主機上的本地表看到了不同的數據，查詢分散式表時會出現非預期的數據。顯然，這是配置ClickHouse集群的一種不正確的方法。
• 複製表，internal_replication=true。插入到分散式表中的數據僅插入到其中一個本地表中，但通過複製機制傳輸到另一個主機上的表中。因此兩個本地表上的數據保持同步。這是官方推薦配置。
• 複製表，internal_replication=false。數據被插入到兩個本地表中，但同時複製表的機制保證重覆數據會被刪除。數據會從插入的第一個節點複製到其它的節點。其它節點拿到數據後如果發現數據重覆，數據會被丟棄。這種情況下，雖然複製保持同步，沒有錯誤發生。但由於不斷的重覆複製流，會導致寫入性能明顯的下降。所以這種配置實際應該是避免的。

一條數據要insert到ontime_all_2中，假設經過rand()實際是要寫入到hadoop1的ontime_local表中，此時ontime_local配置了兩個副本。
如果internal_replication是false，那麼就會分別往兩個副本中插入這條數據。註意！！！分別插入，可能一個成功，一個失敗，插入結果不檢驗！這就導致了不一致性；
而如果internal_replication是true，則只往1個副本里寫數據，其他副本則是由ontime_local自己進行同步，這樣就解決了寫入一致性問題。

配置文件中macros若省略，則建複製表時每個分片需指定zookeeper路徑及副本名稱，同一分片上路徑相同，副本名稱不同；若不省略需每個分片不同配置：

<!-- wuxiang-test-1 -->  

1. <macros>  
2. <shard>01</shard>  
3. <replica>replica1</replica>  
4. </macros>  

<!-- wuxiang-test-2 -->  

1. <macros>  
2. <shard>01</shard>  
3. <replica>replica2</replica>  
4. </macros>  

<!-- wuxiang-test-3 -->  

1. <macros>  
2. <shard>02</shard>  
3. <replica>replica1</replica>  
4. </macros>  

<!-- wuxiang-test-4 -->  

1. <macros>  
2. <shard>02</shard>  
3. <replica>replica2</replica>  
4. </macros>  

4. 複製表引擎說明

複製表引擎採用Replicated*MergeTree表引擎，此類表引擎支持表級別的數據副本，要使用副本，需在配置中設置zookeeper集群地址。

--創建複製表  

1. CREATE TABLE test.szt_data_rep   
2. (  
3. id String,   
4. card_id String,   
5. deal_time String,   
6. trade_type String,   
7. trade_sum Int16,   
8. trade_value Int16,   
9. terminal_code String,   
10. com_line String,   
11. line_station String,   
12. car_gate String,   
13. flag String,   
14. finish_time Date  
15. )  
16. ENGINE = ReplicatedMergeTree('/data/clickhouse/{shard}/szt_data_rep', '{replica}')  
17. PARTITION BY finish_time  
18. ORDER BY (card_id, terminal_code)  
19. SAMPLE BY card_id;  

ReplicatedMergeTree參數

• zoo_path — ZooKeeper 中該表的路徑，可自定義。
• replica_name — ZooKeeper 中的該表的副本名稱，自定義。

以上參數則是讀取配置文件中macros自動填充

表副本創建完成後，可連接zk查看對應路徑：

/share/apps/zookeeper-3.4.14/bin/zkCli.sh -server 192.168.40.218:2181

5. 數據副本

本文檔主要研究兩種數據備份方式：伺服器備份、交叉備份。

5.1. 伺服器備份

伺服器備份，按照本文研究的2分片2副本的情況，即一個分片下兩個伺服器作為兩個副本，這兩個伺服器的數據互相備份。

  配置文件修改如下：

若internal_replication為true，則是由表自動同步數據，若為false則由集群自動同步數據，若使用複製表推薦internal_replication設置為true。

此種配置優點在於若分片中有一臺伺服器掛掉，則另一臺可以立即替代其繼續運行，待機器啟動後數據會自動同步；缺點：複製表需占用整台伺服器，耗費資源。

5.2. 交叉備份

交叉備份與上一種備份方式的區別在於，每台機器上運行多個clickhouse實例，以不同埠區分，這樣兩台伺服器上的表數據即可交叉備份。

 配置文件修改如下：

  此種配置方式優點在於節省伺服器成本，缺點在於clickhouse對於複雜查詢本身占用CPU比較多，多一個伺服器同時運行多個實例，可能會對性能造成一定影響。

多實例配置方法：

複製並修改clickhouse server文件：clickhouse-server-1

cp /etc/rc.d/init.d/clickhouse-server  /etc/rc.d/init.d/clickhouse-server-1

vim /etc/rc.d/init.d/clickhouse-server-1

  複製並修改配置文件：config1.xml 

cp /etc/clickhouse-server/config.xml /etc/clickhouse-server/config1.xml

vim /etc/clickhouse-server/config1.xml

  users.xml以及/etc/metrika.xml可根據實際情況決定是否創建新的配置文件；

修改完成之後啟動新的實例，並按新設定的埠連接clickhouse即可。

  #若沒有對應的服務啟動埠，需添加
　firewall-cmd --zone=public --add-port=9021/tcp --permanent

#啟動新的服務
service clickhouse-server-1 start

#用新的埠啟動
clickhouse-client -m -u default -h 192.168.40.218 --password F7Us3TU1 --port 9021

6.集群擴展

對於增加或減少伺服器的情況，分散式操作只需修改metrika.xml配置文件即可，至於表數據同步，目前找到兩種方法：

6.1. 手動同步

在新的伺服器上創建相同的表，將需遷移的伺服器上的表數據移動到新的伺服器對應目錄下，然後連接clickhouse執行以下語句：

1. detach table szt_data_t3; --先將表與數據分離（若表已存在）  
2. attach table szt_data_t3; --然後重新添加進來  

6.2. 創建臨時表

在新的伺服器上創建表結構相同但表名不同的臨時分散式表，然後執行以下語句：

1. insert into {new_table} select * from {old_table};  

然後刪除原分散式表，將臨時表重命名即可。