ClickHouse 版本升级

oldba.cn

已于 2022-09-15 11:18:36 修改

阅读量2.7k

点赞数

文章标签： clickhouse java 数据库

于 2022-09-15 10:25:30 首次发布

本文链接：https://blog.csdn.net/weixin_45320660/article/details/126866031

版权

前言

作为面向OLAP领域的新一代产品，ClickHouse每个版本之间都有着显著不同，具有高效的数据读写性能（列式存储与压缩）、高效的数据处理性能（向量化计算、列式组织、指令优化）、灵活的计算扩展能力（多主分布式架构）、完善的SQL支持和窗口函数等特性。

自从2016年6月15日开源后，从 ClickHouse 1.1.54245（2017-07-04）发布支持分布式DDL、复制查询、字典引擎等功能，到2018年期间支持 MySQL引擎、支持 HDFS引擎、支持JDBC引擎、支持Kafka引擎使用多个消费者、支持JOIN ON 语法、支持表中存储多维数组和元组、支持format格式化查询、支持clickhouse-copier（测试版）及系统库下各表的优化等等，再到2020年期间支持MergeTree Write-Ahead-Log转储、支持MaterializeMySQL引擎的MySQL BinLog 文件检查工具、支持存储RabbitMQ、支持交叉复制集群的分布式DDL（更新/删除/删除分区）、支持 MergeTree 完整性检查、支持更多聚合方法、支持嵌套多行注释、支持删除列属性和表的TTL等等，再到2021年期间支持SQLite 表引擎、支持MaterializedPostgreSQL 引擎、支持SSL 运行 clickhouse-keeper（实验性替代 ZooKeeper）的能力、支持 INTERSECT、EXCEPT、ANY、ALL 运算符、支持分布式查询下推 LIMIT 、再到2022年期间支持implicit_transaction在事务中运行独立查询、支持全排序合并连接算法、支持SQLInsert输出格式、支持数据导出期间指定压缩级别、支持clickhouse-disks工具配置的虚拟文件系统、支持无符号整数计算哈希值、支持子查询指定为SQL 用户定义的函数等等特点。

“当笔画出地平线，你被东方之锣惊醒，回声中开放的是，时间的玫瑰”。这是来自北岛诗歌传记《时间的玫瑰》中的一个句子用在ClickHouse有机成长再好不过了。

以最近项目为例，整理下ClickHouse升级的相关注意事项，安全生产第一条：记得备份！记得备份！记得备份@重要的事情说三遍！！！

1 查看当前版本

$ clickhouse-server --version
ClickHouse server version 21.2.10.48 (official build).
$ clickhouse-client --version
ClickHouse client version 21.2.10.48 (official build).

2 查看可升级的版本

升级访问资源地址

https://packages.clickhouse.com/rpm/stable

在这里插入图片描述

下载需要的版本，4个包

wget https://packages.clickhouse.com/rpm/stable/clickhouse-client-22.4.2.1.noarch.rpm
wget https://packages.clickhouse.com/rpm/stable/clickhouse-common-static-22.4.2.1.x86_64.rpm
wget https://packages.clickhouse.com/rpm/stable/clickhouse-common-static-dbg-22.4.2.1.x86_64.rpm
wget https://packages.clickhouse.com/rpm/stable/clickhouse-server-22.4.2.1.noarch.rpm

3 执行升级

注意点：

1.跨大版本升级需要新配置文件内容，不可直接mv覆盖。

2.如果有密文password_sha256_hex配置，密文升级后会失效，需要重新配置即可。

3.回退方案要提前考虑好，升级之前要备份。

4.降低停机时间（停业务的时间），在业务不繁忙期间升级，做好足够的预演。

1 关闭服务

service clickhouse-server stop

2 备份数据目录和配置文件

# mkdir /data/backup    && cp /data/clickhouse /data/backup
# mkdir /tmp/clickhouse && cp /etc/clickhouse* /tmp/clickhouse

3 进入到下载目录，执行命令

rpm -Uvh *.rpm

说明1：目录下，最好只有刚才的下载的四个rpm
说明2：如果报错的话，一般是依赖的问题，可自行检索。

4 恢复编辑配置文件

mv /etc/clickhouse-server/config.xml.rpmorig /etc/clickhouse-server/config.xml
mv /etc/clickhouse-server/users.xml.rpmorig /etc/clickhouse-server/users.xml

也可以先执行下面 5 启动服务，测试完成之后再根据需要编辑配置
vim /etc/clickhouse-server/config.xml
vim /etc/clickhouse-server/users.xml

5 启动服务

service clickhouse-server start

6 查看升级后版本，再使用 clickhouse-client 连接测试

$ clickhouse-server --version
ClickHouse server version 22.4.2.1 (official build).
$ clickhouse-client --version
ClickHouse client version 22.4.2.1 (official build).

$ clickhouse-client -h 127.0.0.1 --port 9000 -u default --password --query='select version();'

补充：

升级完成后，客户端连接可能有Warnings信息：

$ clickhouse-client -h 127.0.0.1 --port 9000 -u default --password


Warnings:

* Linux is not using fast TSC clock source. Performance can be degraded.

* Linux memory overcommit is disabled.

* Linux transparent hugepage are set to "always".





1.处理第一个TSC时钟源警告：

# 查看查看可用时钟源

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource

kvm-clock tsc acpi_pm 



# 查看当前使用的时钟源

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource

kvm-clock



# 修改时钟源

# echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource



2.linux memory overcommit机制

linux memory overcommit策略一共分为三种；

(1)启发式策略(overcommit_memory==0):

	如果有足够可用的物理内存供使用,则内存分配成功,否则失败。

	可用物理内存可以通过对/proc/meminfo的统计信息做一下计算得到:"free + buffer + cached - shm + swap + slab_recalimable - zone_total_reserved(各zone预留内存总和，一般是固定的)"

	__vm_enough_memory通过比较请求的内存数量与当前可用的物理内存来决定是否允许请求。


(2)允许过度使用策略(overcommit_memory==1):

	无论分配多少内存都会成功，这样的好处是可以使用所有的物理内存，但是有可能引发oom。


(3)不允许过度使用策略(overcommit_memory==2):

	系统的所有虚拟内存加起来不得超过 “总物理内存 + CommitLimt”（CommitLimt=总物理内存*overcommit_ratio%）。overcommit_ratio可以在/proc/sys/vm里设定，默认是50，也就是CommitLimt默认是0.5倍的总物理内存。当前所有进程一共使用的虚拟内存Committed_AS和CommitLimt可通过/proc/meminfo查看。


# 可以通过/proc/sys/vm/overcommit_memory修改策略

# echo 0 > /proc/sys/vm/overcommit_memory



3.设置大页

	在 Linux 中大页分为两种：Huge pages (标准大页) 和 Transparent Huge pages(透明大页)。

	内存是以块即页的方式进行管理的，当前大部分系统默认的页大小为 4096 bytes 即 4K 。1MB 内存等于 256 页。CPU 拥有内置的内存管理单元，包含这些页面的列表，每个页面通过页表条目引用。当内存越来越大的时候，CPU 需要管理这些内存页的成本也就越高，这样会对操作系统的性能产生影响。

	标准大页(HugePages)是从 Linux Kernel 2.6 后被引入的，Huge Pages 可以称为大内存页或者大页面，有时候也翻译成大页/标准大页/传统大页。目的是用更大的内存页面（memory page size）以适应越来越大的系统内存，让操作系统可以支持现代硬件架构的大页面容量功能。

	透明大页（Transparent Huge Pages）缩写为 THP，透明大页(THP)在 RHEL 6 中默认情况下对所有应用程序都是启用的。内核试图尽可能分配巨大的页面，主内核地址空间本身被映射为巨大的页面，减少了内核代码的 TLB（Translation Lookaside Buffer CPU中一小块缓存）压力。

	两者区别（分配机制）：标准大页是预分配方式，而透明大页是动态分配方式。HugePages_Total 对应内核参数 vm.nr_hugepages，也可以在运行中的系统上直接修改 /proc/sys/vm/nr_hugepages，修改的结果会立即影响空闲内存 MemFree 的大小，因为 HugePages 在内核中独立管理，只要一经定义，无论是否被使用，都不再属于 free memory。



	从Red Hat Enterprise Linux 6 内核开始，透明大面在运行时默认启用。然而透明的HugePages可能会导致内存分配的延迟，因为内存是动态分配的。



# 默认情况下,状态为 always，需要调整为 never。

# cat /sys/kernel/mm/transparent_hugepage/enabled

[always] madvise never



# echo never > /sys/kernel/mm/transparent_hugepage/enabled

# echo never > /sys/kernel/mm/transparent_hugepage/defrag

# cat /sys/kernel/mm/transparent_hugepage/enabled

always madvise [never]





配置完以上内容重启生效

service clickhouse-server restart