ClickHouse：使用clickhouse-backup进行数据搬迁
基本使用
clickhouse-backup是一款针对clickhouse数据备份的开源工具：https://github.com/AlexAkulov/clickhouse-backup
下载安装
根据节点的操作系统，选择最新版本的rpm包。这里选择v2.1.3的x86版本。
安装命令：
rpm -ivh clickhouse-backup-2.1.3-1.x86_64.rpm
如果需要指定安装路径：
rpm -ivh --prefix=/path clickhouse-backup-2.1.3-1.x86_64.rpm
配置文件
clickhouse-backup default-config # 查看默认配置
clickhouse-backup print-config # 显示当前配置
如果需要修改配置，则需要在/etc/clickhouse-backup/config.yml中配置。
主要的配置：
general:
remote_storage: s3 # 如果需要将数据推送到s3或者obs时
clickhouse:
username: default # 登录的用户名
password: "" # 登录的密码
host: localhost # 节点ip
port: 9001 # 节点端口，只支持tcp端口
disk_mapping: {}
skip_tables: # 跳过的表
- system.*
- INFORMATION_SCHEMA.*
- information_schema.*
- _temporary_and_external_tables.*
s3: # obs或者s3相关的配置
access_key: "xxx"
secret_key: "xxx"
bucket: "xxx"
endpoint: "xxx"
region:
acl: private
assume_role_arn: ""
force_path_style: false
path: "zhj/"
disable_ssl: false
compression_level: 1
compression_format: tar
sse: ""
disable_cert_verification: false
use_custom_storage_class: false
storage_class: STANDARD
concurrency: 4
part_size: 536870912
max_parts_count: 10000
allow_multipart_download: true
debug: false
查看可以搬迁的表
clickhouse-backup tables
该命令会显示可以搬迁的库表，并显示对应表的数据量。
其中，第三列表示该表的存储磁盘配置，默认是default。配置可参考clickhouse的storage_configuration配置。
备份数据
clickhouse-backup create -t <db>.<table> <backup_name> # 指定需要同步的表
clickhouse-backup create <backup_name> # 同步节点上的所有表
如：clickhouse-backup create -t default.test backup_test
备份后可以通过list查看备份的结果
备份文件
备份数据存放的路径由clickhouse的config.xml中的path指定，在本例中是在：/data/bigdata/clickhouse/data1/
在该路径下，会生成metadata，shadow和metadata.json。如下：
/data/bigdata/clickhouse/data/backup/
├── backup_test
│ ├── metadata # 记录了备份表的元数据
│ │ └── default # 表所在的库名
│ │ └── test.json # test表的元数据文件
│ ├── metadata.json # 整个备份文件的元数据信息
│ └── shadow # 存放了备份数据，如果表没有数据，在此目录下不会生成
│ └── default # 库名
│ └── test # 表名
│ └── default # 存储策略对应的disk，默认为default
│ └── all_1_1_0
│ ├── checksums.txt
│ ├── columns.txt
│ ├── count.txt
│ ├── data.bin
│ ├── data.mrk3
│ ├── default_compression_codec.txt
│ └── primary.idx
table.json
以物化视图的内表为例：
{
"table": "test",
"database": "default",
"parts": {
"default": [ # 存储策略对应的disk
{
"name": "all_1_1_0"
}
]
},
"query": "CREATE TABLE default.test UUID '30a3b4d8-bba0-4922-87ea-c6e416166018' (`id` String, `name` String) ENGINE = MergeTree ORDER BY id SETTINGS index_granularity = 8192",
"size": {
"default": 403
},
"total_bytes": 145,
"metadata_only": false
}
metadata.json
{
"backup_name": "backup_test", # 备份文件名
"disks": { # 存储策略对应的disk，默认是default。
"default": "/data/bigdata/clickhouse/data/",
"disk_name_1": "/data/bigdata/disks/disk1/",
"disk_name_2": "/data/bigdata/disks/disk2/"
},
"version": "2.1.3",
"creation_date": "2023-01-11T09:09:58.363473551Z",
"tags": "regular",
"clickhouse_version": "v22.3.2.1-lts",
"data_size": 403,
"metadata_size": 368,
"databases": [
{
"name": "default",
"engine": "Atomic",
"query": "CREATE DATABASE default\nENGINE = Atomic"
},
{
"name": "test",
"engine": "Atomic",
"query": "CREATE DATABASE test\nENGINE = Atomic"
}
],
"tables": [
{
"database": "default",
"table": "test"
}
],
"functions": [],
"data_format": ""
}
上传数据到obs
clickhouse-backup upload backup_name # 上传指定的备份文件
需要指定remote_storage为s3，同时配置s3的ak，sk等信息。
在执行clickhouse-backup upload backup_test后，在obs上可以看到上传的数据。
数据则会被压缩，命名方式为diskname_分区.tar
目标节点下载数据
clickhouse-backup download <backup_name>
如：clickhouse-backup download backup_test
在config.xml指定的存储目录下会生成备份数据
恢复数据
clickhouse-backup restore <backup_name>
如：clickhouse-backup restore backup_test
恢复后，可以查询到数据已经同步完成。
进阶使用
前面已经讲了最基本的使用方式，也就是目标集群和源集群的所有配置都是一样的场景。但是，搬迁时，两个集群间往往有许多变量。针对特殊情况，现记录如下：
目标节点和源节点数据路径不一致
源节点的路径配置：
<path>/data/bigdata/clickhouse/data/</path>
目标节点的路径配置：
<path>/data/bigdata/clickhouse/data1/</path>
在源节点生成备份数据后，磁盘路径对应的是/data/bigdata/clickhouse/data/（对应的磁盘策略为default）
test_path.json
metadata.json
数据目录对应的磁盘策略为default
将数据下载到目标节点后，需要适配上述三点。
下载后的备份数据在path对应的目录下，即：/data/bigdata/clickhouse/data1/
（1）适配table_name.json
因为目标节点的表用的磁盘策略也是default，所以不用修改
（2）适配metadata.json
修改存盘策略对应的路径为实际路径，如下图
（3）适配数据目录
因为目标节点的表用的磁盘策略也是default，所以不用修改
适配后，restore操作，数据可以正常恢复。
表名变更
源节点表名 test_src
目标节点表名 test_dest
backupname为backup_test_src
方法一：
在目标节点直接恢复数据，然后使用clickhouse的rename命令
clickhouse-backup restore backup_test_src
# clickhouse sql
rename table default.test_src to default.test_dest;
方法二：
如果目标节点已经存在该表，且表不能重建，则可以用如下方法
适配内容：
（1）适配table_name.json
a. 将test_src.json重命名为test_dest.json；
b. 修改test_dest.json中的表名和uuid（uuid要填写实际的值,select uuid from system.tables where name =‘test_dest’;）
（2）适配metadata.json
（3）适配数据目录
适配完上述后，可以正常恢复该表数据。
搬迁物化视图
源节点和目标节点的物化视图sql如下：
CREATE TABLE default.test_local
(
`id` UInt8,
`name` String,
`xxx` String
)
ENGINE = MergeTree
ORDER BY id
CREATE MATERIALIZED VIEW default.test_view
(
`id` UInt8,
`name` String,
`xxx` String
)
ENGINE = AggregatingMergeTree
ORDER BY id
SETTINGS index_granularity = 8192 AS
SELECT
id,
name,
xxx
FROM
(
SELECT *
FROM default.test_local
)
GROUP BY
id,
name,
xxx
物化视图的数据迁移，应该搬迁它的inner表，因为数据都存储在inner表中。
注：inner表的关联关系：
如果有指定，则在建表语句中由TO关键字指定，如果没有指定，则默认是该物化视图对应的uuid（select uuid,name from system.tables where name=‘test_view’）
这里以不指定inner表的方式为例。
1、源节点数据备份
源节点的视图和inner的对应关系
备份inner表
clickhouse-backup create -t default..inner_id.10f71dd6-c32b-4653-aee6-31cac394ae6d backup_test_view
clickhouse-backup upload backup_test_view
2、目标节点恢复数据
在目标节点已经建立物化视图，对应的inner表为：
clickhouse-backup download backup_test_view
（1）适配table_name.json
a. 重命名table_name.json；
# 查询新名称
select metadata_path from system.tables where name='.inner_id.7238df78-039c-44d7-b238-df78039c24d7';
SELECT metadata_path
FROM system.tables
WHERE name = '.inner_id.7238df78-039c-44d7-b238-df78039c24d7'
Query id: 85aa159d-7550-44f8-be27-b0d160839a47
┌─metadata_path───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ /data/bigdata/clickhouse/data/store/d56/d56f5c79-a22b-41c9-828b-d8582f9f8ac8/%2Einner_id%2E7238df78%2D039c%2D44d7%2Db238%2Ddf78039c24d7.sql │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
所以，重命名
mv /data/bigdata/clickhouse/data/backup/backup_test_view/metadata/default/%2Einner_id%2E10f71dd6%2Dc32b%2D4653%2Daee6%2D31cac394ae6d.json /data/bigdata/clickhouse/data/backup/backup_test_view/metadata/default/%2Einner_id%2E7238df78%2D039c%2D44d7%2Db238%2Ddf78039c24d7.json
b. 修改table_name.json中的表名和uuid
（2）适配metadata.json
（3）适配数据目录
mv /data/bigdata/clickhouse/data/backup/backup_test_view/shadow/default/%2Einner_id%2E10f71dd6%2Dc32b%2D4653%2Daee6%2D31cac394ae6d /data/bigdata/clickhouse/data/backup/backup_test_view/shadow/default/%2Einner_id%2E7238df78%2D039c%2D44d7%2Db238%2Ddf78039c24d7
最后，恢复数据：
这种方式与源节点数据完全一致。在物化视图的引擎为AggregatingMergeTree时，也能够保证两节点的数据完全一致。
多盘存储
如果源节点和目标节点都是多盘存储，且路径一致，则不需要额外适配。
如果源节点是default存储策略，目标节点是多盘存储，则需要按照前面的方法进行适配。
例子如下：
源节点只设置了path，目标节点设置了多盘存储
适配如下：
（1）适配table_name.json
a. 重命名table_name.json；
表名两边一致，不需要重命名
b. 修改table_name.json中的settings和存盘策略
（2）适配metadata.json
新增存盘策略
（3）适配数据目录
mkdir -p /data/bigdata/disks/disk1/backup/backup_test_default
mv /data/bigdata/clickhouse/data/backup/backup_test_default/shadow /data/bigdata/disks/disk1/backup/backup_test_default/
mv /data/bigdata/disks/disk1/backup/backup_test_default/shadow/default/test_disk_default/default /data/bigdata/disks/disk1/backup/backup_test_default/shadow/default/test_disk_default/disk_name_1
如此操作，数据正常恢复。后续插入的数据也会在disk_name_1和disk_name_2间轮询写入。
增量搬迁
clickhouse-backup支持备份恢复某个分区的数据（不支持part级别），可以通过这种方式以达到增量搬迁的效果。
源节点中的数据内容如下：
select partition,partition_id,name from system.parts where database='default' and table ='test_partition'
┌─partition─┬─partition_id─────────────────────┬─name───────────────────────────────────┐
│ 1 │ 6711e2b2592d86d18fc0f260cf33ef2b │ 6711e2b2592d86d18fc0f260cf33ef2b_1_1_0 │
│ 2 │ d63c5d7a5ac187945961e06e17d46b6e │ d63c5d7a5ac187945961e06e17d46b6e_2_2_0 │
│ 2 │ d63c5d7a5ac187945961e06e17d46b6e │ d63c5d7a5ac187945961e06e17d46b6e_3_3_0 │
└───────────┴──────────────────────────────────┴────────────────────────────────────────┘
（1）备份某分区方式
# 源节点
clickhouse-backup create -t default.test_partition --partitions 6711e2b2592d86d18fc0f260cf33ef2b backup_test_p_1
clickhouse-backup create -t default.test_partition --partitions d63c5d7a5ac187945961e06e17d46b6e backup_test_p_2
clickhouse-backup upload backup_test_p_1
clickhouse-backup upload backup_test_p_2
# 目标节点
clickhouse-backup download backup_test_p_1
clickhouse-backup download backup_test_p_2
clickhouse-backup restore backup_test_p_1
clickhouse-backup restore --data backup_test_p_2 # 增量的要指定为data模式，否则原有数据会被覆盖
（2）备份整表，恢复部分分区方式
# 源节点
clickhouse-backup create -t default.test_partition backup_test_p
clickhouse-backup upload backup_test_p
# 目标节点
clickhouse-backup download backup_test_p
clickhouse-backup restore --data --partitions 6711e2b2592d86d18fc0f260cf33ef2b backup_test_p # 指定需要恢复的分区
clickhouse-backup restore --data --partitions d63c5d7a5ac187945961e06e17d46b6e backup_test_p
缺陷
1、目前clickhouse-backup只支持MergeTree引擎系列的表
- 点赞
- 收藏
- 关注作者
评论（0）