ClickHouse集群搭建从0到1

ClickHouse集群搭建从0到1

1. ClickHouse安装的2种方法，以及背后的坑
2. 一步步帮你实现ClickHouse从单机到集群化，以及集群化的原理、配置文件等
3. 集群化的2种方案，孰优孰劣
   如有疑问，请留言或者联系我
   组件介绍
   ClickHouse安装完后，会有几个重要命令：
   a. clickhouse-server ClickHouse的Server端，也就是CK数据库的核心程序，相当于
   mysqld命令，提供数据库服务端
   b. clickhouse-client ClickHouse自带的client端，提供命令行的交互操作方式，来连接服务
   端，相当于mysql命令
   Docker安装
   官方默认只支持Ubuntu，并且提供了Docker镜像：
   ClickHouse Server
   ClickHouse Client
   Docker安装很方便，但是有几个问题：
   默认监听了IPv6，如果你的服务器恰好没有开启V6，会导致Docker启动失败的
   解决方案：使用Docker命令，cp出默认的配置文件，修改network监
   听后，拷回Docker，重新启动即可
   默认时区问题并不是东八区，如果没有修改，一些时间函数会差8个小时
   clickhouse-client在Docker下，无法正常输入中文（调了LANG，无效，如果搞定记得
   告诉我）
   数据目录如果有要求，额外在Docker启动的时候，挂载一下
   配置文件不方便修改
   建议调整：
   挂载本地服务器时区，或者直接修改Docker里的时区文件
   拷贝所有配置文件到服务器目录，启动时做映射，方便修改
   映射一个专用的数据目录
   由于Docker方式我并不在线上采用，这里不再举例。建议仅仅作为笔记本上测试、了解用（不过前期，没有
   找到rpm包，Docker的确帮了我们很大的忙）。
   RPM包安装
   不出意外的话，99%的服务器都是CentOS系列
   官方没有提供rpm包，但是Altinity公司提供了，关于这个公司的介绍，可以参照我其他文章
   如果下载不了，看我的百度网盘，密码yv72（我这里好久没更新了，请注意看版本）
   CentOS推荐7.3以上，基本没有依赖包的问题
   rpm -ivh * 即可安装完成
   配置文件解析
   ClickHouse有几核心的配置文件：
   a. config.xml 端口配置、本地机器名配置、内存设置等
   b. metrika.xml 集群配置、ZK配置、分片配置等
   c. users.xml 权限、配额设置
   以上文件都可以在官方git下载到
   rpm启动方式
   rpm安装后，会在服务器上生成如下几个文件：

默认配置文件位置

root@localhost.localdomain:/ # ls /etc/clickhouse-server
config.xml users.xml

上述文件定义了默认数据目录，临时目录位置，日志目录

/var/lib/clickhouse
/var/lib/clickhouse/tmp/
/var/log/clickhouse-server

默认启动脚本，注意，这个名字虽然叫server，其实是个shell脚本

/etc/rc.d/init.d/clickhouse-server
root@localhost.localdomain:/ # file /etc/rc.d/init.d/clickhouse-server
/etc/rc.d/init.d/clickhouse-server: POSIX shell script, ASCII text executable, with very long lines

最大文件打开数

root@localhost.localdomain:/ # cat /etc/security/limits.d/clickhouse.conf
clickhouse soft nofile 262144
clickhouse hard nofile 262144

默认crontab目录（没啥用）

/etc/cron.d/clickhouse-server

剩下就是/usr/bin下的二进制文件，但其实都是软链接到了clickhouse这个二进制文件

root@localhost.localdomain:/usr/bin # ll | grep click -i
-rwxr-xr-x 1 root root 63M Sep 20 16:58 clickhouse
lrwxrwxrwx 1 root root 10 Dec 11 17:14 clickhouse-client -> clickhouse
-rwxr-xr-x 1 root root 3.3M Sep 20 16:58 clickhouse-compressor
lrwxrwxrwx 1 root root 10 Dec 11 17:14 clickhouse-server -> clickhouse
知道上述几个文件的作用后，我们就知道该怎么做了
默认的数据目录明显不合理，特别是对于部分机器，系统盘和数据盘是不同的配置，需
要单独挂载，以我们为例，我们统一使用/data1来放数据，数据目录以clickhouse命名，考
虑到不用单机多实例，不以clickhouse${port}来命名
默认的配置文件，对我们的管理也是个隐患，建议把配置文件、数据目录、临时目录、
日志文件，统一放到/data1/clickhouse里，即：
root@localhost.localdomain:/data1/clickhouse # tree . -L 1
.
├── config-preprocessed.xml
├── config.xml
├── cores
├── data
├── flags
├── log
├── metadata
├── metrika.xml
├── start_ck.sh
├── status
├── tmp
├── users-preprocessed.xml
└── users.xml
关于如何启动，我们的做法是：
修改默认的shell脚本，修改默认配置文件的位置，即上面的start_ck.sh [图片上传中…
(Snip20171212_37.png-4c0f8a-1513094816911-0)]

• 这里其实是可以直接使用clickhouse-server（二进制那个），并采用-d参数启动的，但是实际过程，遇到了很多意外
  的情况，比如-d后，并不会以daemon方式启动，后来就不考虑直接命令行方式了
• 修改config.xml里对数据目录的定义

<?xml version="1.0"?> trace /data1/clickhouse/log/server.log /data1/clickhouse/log/error.log 1000M 10 8123 9000 9009 这里需要用域名，如果后续用到复制的话 0.0.0.0 64 3 16 8589934592 10737418240 /data1/clickhouse/ /data1/clickhouse/tmp/ users.xml default 1 default 3600 0 /data1/clickhouse/metrika.xml 单机 无需多解释，就是单机部署 按照上述方式安装rpm包，修改默认的config文件和启停控制脚本，启动即可 我上面的配置文件里，直接包含了集群的配置文件，如果只用了上述文件，是无法正常启动的 看这个文章的，应该都是冲着后面的集群搭建来的吧，所以，忽略这一个吧 分布式集群 CK是如何实现分布式的 CK的分布式，完全依赖配置文件，即每个节点，都共享同样的配置文件，这个配置文件里，写了我跟谁是一 个cluster的，我自己的名字是啥 如下面的配置文件里，有3个分片，各自用域名来标记，如果需要密码的话，集群也要写上明文密码和用户名 这样，就行程了ClickHouse的集群 集群怎么用? 答案是指定引擎 CK里的引擎有十几个，这里只推荐3个： i. MergeTree，是CK里最Advanced的引擎，性能超高，单机写入可以达 到50w峰值，查询性能非常快，有兴趣看我其他文章 ii. ReplicatedMergeTree，基于MergeTree，同时引入ZK，做了复制， 下文会说 iii. Distributed，分布式引擎，本身不存储数据，可认为就是一张View， 如果写入，会把请求丢到集群里的节点（有算法控制），如果查询，会帮 你做查询转发再聚合返回 metrika.xml false ck31.xxxx.com.cn 9000 default 6lYaUiFi false ck32.xxxx.sina.com.cn 9000 default 6lYaUiFi false ck33.xxxxa.com.cn 9000 default 6lYaUiFi ck1 ::/0 1.xxxx.sina.com.cn 2181 2.xxxx.sina.com.cn 2181 3.xxxxp.sina.com.cn 2181 10000000000 0.01 lz4 user.xml 关于用户名密码的问题，在另一篇文章有解释，这里只贴上配置文件 <?xml version="1.0"?> 10000000000 0 random 10000000000 0 random 1 3600 0 0 0 0 0 967f3bf355dddfabfca1c9f5cab39352b2ec1cd0b05f9e1e6b8f629705fe7d6e ::/0 default default 967f3bf355dddfabfca1c9f5cab39352b2ec1cd0b05f9e1e6b8f629705fe7d6e ::/0 readonly default 简单分布式方案 MergeTree + Distributed CREATE TABLE db.tb (date Date, ……) ENGINE = MergeTree(date, (date, hour, datetime), 8192) CREATE TABLE db.tb_all (date Date, ……) ENGINE = Distributed(bip_ck_cluster, 'ck_test', 'dagger', rand())" db.tb为本地表，数据只是在本地 db.tb_all为分布式表，查询这个表，引擎自动把整个集群数据计算后返回 像不像一台手动挡的车 分布式+高可用方案1 上述方案，使用过后，会发现CK的性能真的是超级快，这里我就不在贴图了，有兴趣可以看我那122页的PPT 但是有个问题，以上面3个节点为例，每个节点占1/3，如果宕机1个节点，直接丢掉1/3的数据，不能忍啊 于是，就得考虑数据的安全性，即副本 MergeTree + Distributed + 集群复制 配置如下： 解释都在图里了，提一点，如果IP1挂了，IP2还在，不影响集群查询 这种方案为什么我们没有用呢? 如果IP1临时宕机，从宕机开始到恢复，期间的增量数据是可以补全的，依赖的IP2上的 推送机制，会有临时目录 但是，如果IP1彻底玩完，硬盘坏了，无法恢复，只能重做，引入一个IP5来替换IP1，这 时候问题就来了，存量数据无法恢复 这个方案之前有过争议，我坚持上面的观点，由于时间有限，没有详细测试，从CK原理 上来讲，的确存在上述的问题，所以我们不用 分布式+高可用方案2 ReplicatedMergeTree + Distributed 仅仅是把MergeTree引擎替换为ReplicatedMergeTree引擎 ReplicatedMergeTree里，共享同一个ZK路径的表，会相互，注意是，相互同步数据 CREATE TABLE db.tb (date Date, ……) ENGINE = ReplicatedMergeTree('/clickhouse/db/tb/name', 'node_name', date, (date, hour, datetime), 8192) CREATE TABLE db.tb_all (date Date, ……) ENGINE = Distributed(bip_ck_cluster, 'ck_test', 'dagger', rand())" 示意图架构就是这样： 每个IDC有3个分片，各自占1/3数据 每个节点，依赖ZK，各自有2个副本 这样，就不怕宕机啦~ CK分布式的问题 写哪个表 可以写xxx_all，也可以写xxx本地表 前者由于分布式表的逻辑简单，仅仅是转发请求，所以在转发安全性上，会有风险，并 且rand的方式，可能会造成不均衡 我们建议，通过DNS轮训，写本地表，这样最保险和均衡 读哪个表 毫无疑问，是xxx_all表 3个节点，要么都用，要么都不用，不能只用2个或者1个 集群配置里，我们用了域名，本想着方便切换，但是CK只有在启动的时候，才会做解析 那故障了怎么切换? CK有一个厉害的地方，节点变动，无需重启，会自动加载 利用上述特性，我们先去掉一个节点的配置，再加上这个节点的配置（DNS变更后）， 即可不重启就完成fail over 总结 ClickHouse的性能令人印象深刻，但是，整个操作，又非常像一台手动挡的车，如果不是老司机，用着用着 可能数据都没了，所以，掌握好原理，是开好这辆“超跑”的关键 上述集群中，你是否觉得表管理非常麻烦呢？的确，又要区分集群，又要区分副本，建议写一个脚本来统一建 表，我们就是这么搞的