ClickHouse高可用集羣的配置

    上一篇文章寫過centos 7下clickhouse rpm包安裝和基本的目錄結構,這裏主要介紹clickhouse高可用集羣的部署方案,由於對於默認的分佈式表的配置,每一個分片只有一份,這樣若是掛掉一個節點,則查詢分佈式表的時候直接會報錯,這個是基於clickhouse本身實現的多分片單副本集羣,配置也比較簡單,這裏說的高可用是指,每一個分片具備2個或以上副本,當某個節點掛掉時,該節點分片仍能夠由其餘機器上的副本替代工做,因此這樣實現的分佈式集羣能夠在掛掉至少1個節點時機器正常運行,隨着集羣節點數量的增長,則集羣掛掉2個節點或以上可提供服務的機率也越大,至少能避免單點故障問題,集羣的穩定性也更高.node

    clickhouse集羣的理想方案是以下所示:sql

    

     這裏有3個集羣,每一個集羣n個節點,每一個節點的數據依靠zookeeper協調同步,好比cluster1提供服務,若是cluster1裏面掛掉多臺機器那麼cluster2的副本能夠切換過來提供服務,若是cluster2的分片再掛了,那麼cluster3中的副本也能夠提供服務,cluster1~3同時掛掉的機率就很是小了,因此集羣的穩定性能夠很是高,其中單個集羣的節點個數n決定了clickhouse的性能,性能是能夠線性擴展的,具體副本集羣的個數根據機器資源配置.數據庫

    若是機器資源確實特別少,想每一個節點都用上提供服務的話,那麼能夠每一個節點存儲兩個以上的副本,即提供服務的分片和其餘機器的副本,實現相互備份,可是clickhouse不支持單個節點多個分片的配置,咱們能夠人爲設置在每一個節點上啓動兩個實例來實現,設計圖以下:centos

    

    圖畫的很是簡陋,可是能夠看出來3個節點每一個節點的tcp 9000對外提供服務,9001提供副本,其中2提供1的備份,3提供2的備份,1提供3的備份,這樣假設掛掉1個節點,集羣也能夠正常使用,可是掛掉2個幾點,就不正常了,這樣的話是機器越多越穩定一些.tcp

    上面兩種方案,官網上仍是推薦的第一種方案可用性最高,這裏爲了演示採用第二種方式配置,其實兩種方式的配置是徹底同樣的,第二種配置反而更繁瑣一些,下面詳細說一下配置的流程,軟件包結構就採用上一篇文章打包好的.分佈式

    0. 高可用原理:zookeeper + ReplicatedMergeTree(複製表) + Distributed(分佈式表)性能

    1. 前提準備:全部節點防火牆關閉或者開放端口;hosts表和主機名必定要集羣保持一致正確配置,由於zookeeper返回的是主機名,配置錯誤或不配置複製表時會失敗.測試

     clickhouse測試節點2個:192.168.0.107  clickhouse1, 192.168.0.108  clickhouse2spa

     zookeeper測試節點1個:192.168.0.103  bigdata設計

     配置方案:兩個節點各配置兩個clickhouse實例,相互備份.

     clickhouse1: 實例1, 端口: tcp 9000, http 8123, 同步端口9009, 類型: 分片1, 副本1

     clickhouse1: 實例2, 端口: tcp 9001, http 8124, 同步端口9010, 類型: 分片2, 副本2 (clickhouse2的副本)

     clickhouse2: 實例1, 端口: tcp 9000, http 8123, 同步端口9009, 類型: 分片2, 副本1

     clickhouse2: 實例2, 端口: tcp 9001, http 8124, 同步端口9010, 類型: 分片1, 副本2 (clickhouse1的副本)

    2. 修改啓動腳本和配置文件

    首先將啓動腳本複製一個出來,除了上一篇文章說的外,主要修改配置文件位置和pid文件位置,以下:

    

    這裏配置文件好比使用config1.xml,pid使用clickhouse-server-1.pid

    而後進入到配置文件目錄,將原有配置文件拷貝一份,這裏是config1.xml,而後修改配置:

    主要修改內容是:日誌文件(和以前不要衝突)、http端口、tcp端口、副本同步端口(這個改完以後clickhouse按照當前實例的端口自動和其餘實例同步)、數據文件和tmp目錄、users.xml(這個若是都同樣能夠用同一個)、最後就是集羣配置了,下面重點敘述:

    集羣配置默認爲:<remote_servers incl="clickhouse_remote_servers" />

    zookeeper默認爲:<zookeeper incl="zookeeper-servers" optional="true" />

    macros默認爲:<macros incl="macros" optional="true" />

    首先是集羣分片的配置,這個配置全部節點的全部實例徹底保持一致:

<remote_servers>
    <distable>
        <shard>
            <!-- Optional. Shard weight when writing data. Default: 1. -->
            <weight>1</weight>
            <!-- Optional. Whether to write data to just one of the replicas. Default: false (write data to all replicas). -->
            <internal_replication>true</internal_replication>
            <replica>
                <host>192.168.0.107</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>192.168.0.108</host>
                <port>9001</port>
            </replica>
        </shard>
        <shard>
            <weight>1</weight>
            <internal_replication>true</internal_replication>
            <replica>
                <host>192.168.0.108</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>192.168.0.107</host>
                <port>9001</port>
            </replica>
        </shard>
    </distable>
</remote_servers>

    配置裏面的<distable>是分佈式標識標籤,能夠自定義,到最後建立分佈式表的時候會用到;而後weight是分片權重,即寫數據時有多大的機率落到此分片,由於這裏全部分片權重相同全部都設置爲1,而後是internal_replication,表示是否只將數據寫入其中一個副本,默認爲false,表示寫入全部副本,在複製表的狀況下可能會致使重複和不一致,因此這裏必定要改成true,clickhouse分佈式表只管寫入一個副本,其他同步表的事情交給複製表和zookeeper來進行,而後是replica配置這個好理解,就是一個分片下的全部副本,這裏副本的分佈必定要手動設計好,保證相互備份,而後再次說明是全部的節點配置一致. 此部分配置嚴格按照官網配置,參考連接:https://clickhouse.yandex/docs/en/operations/table_engines/distributed/

    而後是zookeeper配置,這個也是全部示例配置都同樣:

<zookeeper>
    <node index="1">
        <host>192.168.0.103</host>
        <port>2181</port>
    </node>
</zookeeper>

    這裏zookeeper只有一個,若是多個的話繼續往下寫,就像官網上給出的同樣,參考下圖:

    

    而後是複製標識的配置,也稱爲宏配置,這裏惟一標識一個副本名稱,每一個實例都要配置而且都是惟一的,這裏配置以下:

    clickhouse1 9000 分片1, 副本1:

<macros>
    <layer>01</layer>
    <shard>01</shard>
    <replica>cluster01-01-1</replica>
</macros>

    clickhouse1 9001 分片2, 副本2:

<macros>
    <layer>01</layer>
    <shard>02</shard>
    <replica>cluster01-02-2</replica>
</macros>

    clickhouse2 9000 分片2, 副本1:

<macros>
    <layer>01</layer>
    <shard>02</shard>
    <replica>cluster01-02-1</replica>
</macros>

    clickhouse2 9001 分片1, 副本2:

<macros>
    <layer>01</layer>
    <shard>01</shard>
    <replica>cluster01-01-2</replica>
</macros>

    由上面配置能夠看到replica的分佈規律,其中layer是雙級分片設置,在Yandex公司的集羣中用到,由於咱們這裏是單集羣因此這個值對咱們沒有影響所有同樣便可,這裏是01;而後是shard表示分片編號;最後是replica是副本標識,這裏使用了cluster{layer}-{shard}-{replica}的表示方式,好比cluster01-02-1表示cluster01集羣的02分片下的1號副本,這樣既很是直觀的表示又惟一肯定副本. 副本的文檔連接下面會給出.

    3. 建立本地複製表和分佈式表

    全部實例配置完上面這些以後,分別執行啓動命令啓動,而後全部實例都執行下面語句建立數據庫:

CREATE DATABASE monchickey;

    而後對於全部實例分別建立對應的複製表,這裏測試建立一個簡單的表

    clickhouse1 9000 實例: 

CREATE TABLE monchickey.image_label ( label_id UInt32,  label_name String,  insert_time Date) ENGINE = ReplicatedMergeTree('/clickhouse/tables/01-01/image_label','cluster01-01-1',insert_time, (label_id, insert_time), 8192)

    clickhouse1 9001 實例:

CREATE TABLE monchickey.image_label ( label_id UInt32,  label_name String,  insert_time Date) ENGINE = ReplicatedMergeTree('/clickhouse/tables/01-02/image_label','cluster01-02-2',insert_time, (label_id, insert_time), 8192)

    clickhouse2 9000 實例:

CREATE TABLE monchickey.image_label ( label_id UInt32,  label_name String,  insert_time Date) ENGINE = ReplicatedMergeTree('/clickhouse/tables/01-02/image_label','cluster01-02-1',insert_time, (label_id, insert_time), 8192)

    clickhouse2 9001 實例:

CREATE TABLE monchickey.image_label ( label_id UInt32,  label_name String,  insert_time Date) ENGINE = ReplicatedMergeTree('/clickhouse/tables/01-01/image_label','cluster01-01-2',insert_time, (label_id, insert_time), 8192)

    到這裏複製表就建立完畢了,注意引號部分只能用單引號,其中核心的地方是同一個分片在zookeeper上面的znode相同,下面包含數據表的多個副本,當一個副本寫入數據時會自動觸發同步操做. 上面建表語句和配置文件對應着看應該容易理解,更詳細的說明參考文檔:https://clickhouse.yandex/docs/en/operations/table_engines/replication/ 文檔關於ReplicatedMergeTree敘述以下:

    

    而後建立完上面複製表以後,能夠建立分佈式表,分佈式表只是做爲一個查詢引擎,自己不存儲任何數據,查詢時將sql發送到全部集羣分片,而後進行進行處理和聚合後將結果返回給客戶端,所以clickhouse限制聚合結果大小不能大於分佈式表節點的內存,固然這個通常條件下都不會超過;分佈式表能夠全部實例都建立,也能夠只在一部分實例建立,這個和業務代碼中查詢的示例一致,建議設置多個,當某個節點掛掉時能夠查詢其餘節點上的表,分佈式表的建表語句以下:

CREATE TABLE image_label_all AS image_label ENGINE = Distributed(distable, monchickey, image_label, rand())

    分佈式表通常用本地表加all來表示,這裏distable就是上面xml配置中的標籤名稱,最後的rand()表示向分佈式表插入數據時,將隨機插入到副本,在生產環境建議插入的時候客戶端能夠隨機分桶插入到本地表,查詢的時候走分佈式表,即分佈式表只讀,本地複製表只寫.

    配置好上面這些能夠嘗試經過不一樣clickhouse實例寫入數據測試,而後查詢能夠發現分片都會單獨同步,不一樣分片間數據互不影響,經過分佈式表查詢能夠查詢到全部的數據;若是停掉clickhouse2這個節點,此時clickhouse會自動切換爲可用的副本使用,無需人工干預,如今查詢分佈式表仍然可用,當clickhouse2上面的實例啓動恢復的時候,clickhouse會自動切換回來而且作數據的同步,這樣就實現了高可用性.

    上面就是clickhouse高可用集羣的基本配置,確實如一些文章所說像一輛手動擋的車,用的越熟練越好用,另外關於性能和深刻的配置隨着之後使用會繼續分享,最後本人表達能力不是太好,若是文中有錯誤或敘述的不當,但願路過的大牛們指出,很是感謝^_^

相關文章
相關標籤/搜索