关于clickhouse:简易教程ClickHouse-的数据备份与恢复

数据备份是 IT 经营中不可或缺的重要局部。在“大数据”部署（例如剖析数据库）中，它们最具挑战性。本文将探讨备份 ClickHouse 所波及的管道，并介绍用于自动化过程的 Clickhouse 备份工具。

ClickHouse 内置的本机复制反对可提供高可用性和针对单个节点故障的弹性。然而，极少数的劫难状况可能须要从备份中复原数据。其中包含数据损坏以及分片或群集中所有正本的故障。

任何 ClickHouse 备份计划的要害组成部分都是“解冻”表。与所有数据库一样，统一的备份取决于 ClickHouse 处于“静默”状态。ClickHouse 不用齐全进行数据库，而对“解冻”表进行备份或迁徙提供了本机反对。这是无停机工夫的操作。

四个简略步骤中的手动备份

ClickHouse 通过其 ALTER TABLE…FREEZE 性能提供了对即时工夫点备份的本地反对。

1. 确认您的影子目录为空：ls /var/lib/clickhouse/shadow/
2. 解冻 ClickHouse 数据表：
   echo -n 'alter table events freeze' | clickhouse-client

3. 如果产生劫难，请保留备份：

   cd /var/lib/clickhouse/
   sudo mkdir backup
   sudo cp -r shadow/ backup/my-backup-name

4. 最初，为下次清理备份源：
   sudo rm -rf /var/lib/clickhouse/shadow/*

ClickHouse 应用文件系统硬链接来实现即时备份，而不会导致 ClickHouse 服务停机（或锁定）。这些硬链接能够进一步用于无效的备份存储。在反对硬链接的文件系统（例如本地文件系统或 NFS）上，将 cp 与 - l 标记一起应用（或将 rsync 与–hard-links 和–numeric-ids 标记一起应用）以防止复制数据。

当应用硬链接时，磁盘上的存储效率更高。因为它们依赖于硬链接，所以即便防止了重复使用磁盘空间，每个备份实际上都是“残缺”备份。

测试您的备份

正确地说，如果未测试还原过程，则备份毫无价值。执行惯例的测试还原，以确保您的数据在须要时就在那里。

以下是手动复原的步骤：

1. 删除测试表，或找到其余服务器进行测试。
2. 创立测试表以进行复原：
   cat events.sql | clickhouse-client

3. 将您的备份复制到表的“detached”目录中：

   cd /var/lib/clickhouse
   sudo cp -rl backup/my-backup-name/* data/default/events/detached/

4. 附上拆散的整机：
   echo 'alter table events attach partition 202006' | clickhouse-client
5. 确认您的数据已还原：
   echo 'select count() from events' | clickhouse-client

应用以下形式自动化备份过程 clickhouse-backup

由 Alex Akulov 创立的 clickhouse-backup 工具有助于自动化上述手动步骤：https : //github.com/AlexAkulov/clickhouse-backup。咱们喜爱 clickhouse-backup，并实现了一些新性能，在此首次进行介绍。

要开始应用，您须要装置clickhouse-backup。残缺阐明位于 ReadMe.md 文件中。这是从 tarball 装置的示例。还提供了 RPM，Debian 软件包和 Docker 映像。

wget https://github.com/AlexAkulov/clickhouse-backup/releases/download/v0.6.3/clickhouse-backup.tar.gz
tar -xf clickhouse-backup.tar.gz 
cd clickhouse-backup/ 
sudo cp clickhouse-backup /usr/local/bin 
clickhouse-backup -v

此博客文章中介绍的 API 性能和新的存储选项（例如 ’remote_storage’）尚未在正式版本中提供。您须要从源代码构建或运行最新的 docker 映像。这是后者的一个例子。

docker run --rm -it --network host 
  -v "/var/lib/clickhouse:/var/lib/clickhouse" 
  -e CLICKHOUSE_PASSWORD="password" 
  -e S3_BUCKET="clickhouse-backup" 
  -e S3_ACCESS_KEY="access_key" 
  -e S3_SECRET_KEY="secret" 
  alexakulov/clickhouse-backup:master --help

对于本文的其余部分，咱们假设您具备一个具备新性能的外部版本。在命令行上应用 Clickhouse-backup 时，须要配置文件。这是一个最小的示例。

$ cat /etc/clickhouse-backup/config.yml
general:
  remote_storage: none

您将须要为非默认的 ClickHouse 装置或身份验证增加其余配置选项。能够通过运行来创立残缺的配置示例clickhouse-backup default-config。这是您应用的一个很好的终点，它显示了所有可用的设置。

配置实现后，clickhouse-backup 将提供各种用于治理备份的子命令。

$ clickhouse-backup help
NAME:
clickhouse-backup - Tool for easy backup of ClickHouse with cloud support
...
COMMANDS:
   tables          Print list of tables
   create          Create new backup
   upload          Upload backup to remote storage
   list            Print list of backups
   download        Download backup from remote storage
   restore         Create schema and restore data from backup
   delete          Delete specific backup
   default-config  Print default config
   freeze          Freeze tables
   clean           Remove data in 'shadow' folder
   server          Run API server
   help, h         Shows a list of commands or help for one command

就像下面的手动备份示例一样，您将须要以 Clickhouse 用户身份应用 sudo 或运行clickhouse-backup。

该配置文件容许疏忽某些数据库或表。该 tables 子命令将向您显示要备份的表：

$ clickhouse-backup tables
default.events
system.metric_log   (ignored)
system.query_log    (ignored)
system.query_thread_log (ignored)
system.trace_log    (ignored)

创立备份非常简单：

$ sudo clickhouse-backup create
2020/07/06 20:13:02 Create backup '2020-07-06T20-13-02'
2020/07/06 20:13:02 Freeze `default`.`events`
2020/07/06 20:13:02 Skip `system`.`metric_log`
2020/07/06 20:13:02 Skip `system`.`query_log`
2020/07/06 20:13:02 Skip `system`.`query_thread_log`
2020/07/06 20:13:02 Skip `system`.`trace_log`
2020/07/06 20:13:02 Copy metadata
2020/07/06 20:13:02   Done.
2020/07/06 20:13:02 Move shadow
2020/07/06 20:13:02   Done.

如您在下面的示例中看到的，备份在同一秒内实现。

您能够查看现有的本地备份：

$ sudo clickhouse-backup list
Local backups:
- '2020-07-06T20-13-02' (created at 06-07-2020 20:13:02)

留神，出于性能起因，本地备份不计算“大小”。

clickhouse-backup如上所述，在外部尽可能应用硬链接。备份存储在中 /var/lib/clickhouse/backup/BACKUPNAME。备份名称默认为工夫戳，然而您能够抉择应用–name 标记指定备份名称。备份蕴含两个目录：一个“元数据”目录，其中蕴含从新创立架构所需的 DDL SQL 语句；以及一个“影子”目录，其中蕴含作为ALTER TABLE ... FREEZE 操作后果的数据。

从备份还原也很容易。例如：

$ echo 'drop table events' | clickhouse-client

$ sudo clickhouse-backup restore 2020-07-06T20-13-02
2020/07/06 20:14:46 Create table `default`.`events`
2020/07/06 20:14:46 Prepare data for restoring `default`.`events`
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_1_1_4'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_2_2_2'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_3_3_3'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_4_4_3'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_5_5_2'
2020/07/06 20:14:46 ALTER TABLE `default`.`events` ATTACH PART '202006_6_6_1'

该 restore 子命令主动模式和数据恢复。如果只想还原架构，请应用可选--schema 标记。或者，如果只想还原数据（假如架构已存在），则能够应用该 --data 标记。后一种状况在还原到曾经具备现有数据的服务器时特地有用。

另一个有用的性能是反对应用大多数命令（例如创立和还原）指定表模式。该 --table 参数容许您备份（或还原）特定表。你也能够应用一个正则表达式，例如，针对特定的数据库：--table=dbname.*。

近程备份指标

当然，您能够将备份同步到远程目标，将其保留到 S3 之类的对象存储中，或应用现有的备份解决方案对其进行存档。本地存储通常不足以满足数据持久性要求。

clickhouse-backup 工具反对从近程对象存储（例如 S3，GCS 或 IBM COS）上载和下载备份。最小的 AWS S3 配置如下所示：

s3:
  access_key: <YOUR AWS ACCESS KEY>
  secret_key: <YOUR AWS SECRET KEY>
  bucket: <YOUR BUCKET NAME>
  region: us-east-1
  path: "/some/path/in/bucket"

配置 clickhouse-backup 完凭据和指标存储段后，即可实现其余工作：

$ clickhouse-backup upload 2020-07-06T20-13-02
2020/07/07 15:22:32 Upload backup '2020-07-06T20-13-02'
2020/07/07 15:22:49   Done.

The remote backup can be downloaded to local storage before restoration:
$ sudo clickhouse-backup download 2020-07-06T20-13-02
2020/07/07 15:27:16   Done.

该 clickhouse-backup 配置文件反对 backups_to_keep_local 和backups_to_keep_remote 设置 - 调整它们以满足数据保留要求。例如，set backups_to_keep_local: 7 并且 backups_to_keep_remote: 31 保留了一周的夜间备份的本地和一个月的近程管制。将两者都设置为 0 可禁用备份修剪。

--diff-fromupload 子命令也有一个选项。此性能将文件与以前的本地备份进行比拟，仅上载新的 / 更改的文件。必须保留先前的备份，以便从新备份中进行还原。

数据传输工夫和老本是近程存储的要害方面。将大表还原到新服务器须要多长时间？这将在很大水平上取决于网络和存储带宽。测试各种复原计划以充沛理解故障中能够实现的复原工夫至关重要。如果您应用公共云，则老本治理将十分重要。

应用 Clickhouse-backup API

最初，clickhouse-backup能够作为提供 REST API 的服务运行。这是一个新性能。该 API 反映了命令行命令和选项，并且可能是与现有调度或 CI / CD 系统集成的更不便的办法。

$ sudo clickhouse-backup server &
$ curl localhost:7171/backup/list
{"Type":"local","Name":"2020-07-06T20-13-02","Size":0,"Date": "2020-07-06T20:13:02.328066165Z"}

能够在以下地位找到 API 端点的文档：https : //github.com/AlexAkulov/clickhouse-backup#api

clickhouse-backup在生产中应用

重要的是要留神的已知限度clickhouse-backup，在此处记录了这些限度：https : //github.com/AlexAkulov/clickhouse-backup#limitations

此外，文档还蕴含以下重要正告：

切勿在中更改文件权限/var/lib/clickhouse/backup。此门路蕴含硬链接。磁盘上雷同数据的所有硬链接上的权限始终雷同。这意味着，如果您更改备份门路中硬链接上的权限 / 所有者 / 属性，与 ClickHouse 一起应用的文件的权限也将更改。这可能会导致数据损坏。

复原计划

复制失败

到目前为止，单个服务器或节点的故障是生产中最常见的劫难状况。在简直所有状况下，都应替换产生故障的正本并从新创立架构。ClickHouse 的本机复制将接管并确保替换服务器是统一的。此故障场景值得进行当时测试，以理解网络并计算重建新正本的影响。

碎片失败

在群集环境中，每个分片至多应备份一个正本。该clickhouse-backupAPI 是在集群编排备份命名和执行一种办法。

如果一个分片中的所有正本都失败了，或更常见的是，数据已损坏，则必须如上所述从备份中还原整个分片。现实状况下，将备份还原到一个正本，将架构还原到其余正本，并容许 ClickHouse 的本机复制接管。

集群失败

齐全故障的群集，无论是因为基础架构故障还是数据损坏，都能够通过与故障的碎片雷同的形式进行复原。必须通过上述过程复原每个独自分片中的一个正本。

备用备份策略

具备文件系统快照的脱机正本

一种常见的代替办法是应用“脱机正本”进行备份。配置了正本（通常在另一个区域），该正本不作为任何分布式表的一部分用于查问。“离线正本”不打算进行任何合并，能够应用“always_fetch_merged_pa​​rt”和“replica_can_become_leader”ClickHouse MergeTree 设置来指定。尽管生产正本最好由 ext4 文件系统提供服务，然而备份正本应用 ZFS（或反对快照的另一个文件系统）。这种办法提供了疾速的复原过程。请留神，在这种状况下，备份仍在服务器 / 节点本地，并且不肯定提供足够的数据持久性。ZFS 提供了对单个快照的基于目录的文件系统拜访，因而能够将这些快照的存储自动化到近程零碎或对象存储中。

带快照的存储即服务

云部署通常应用基于网络的块存储（例如 AWS EBS 或 GCP 永恒磁盘）。为此，某些本地部署应用 Ceph 或 OpenEBS。这些“存储即服务”技术均反对通明的卷快照。通过首先解冻表以进行备份，而后创立快照，您能够实现近乎即时的备份。

在外部，快照仅在磁盘上存储自上次快照以来已更改的块。这些零碎尽管不是真正的“增量”备份，但能够高效利用磁盘空间。留神基于网络的块存储很少具备与本地磁盘一样的性能，并确保监督快照的保留和老本。

应用 Kafka 改善备份

到目前为止，咱们曾经探讨了按小时或每小时创立的特定工夫点备份（例如）。一些组织要求可能复原到任意工夫点。因为 ClickHouse 没有本地二进制日志（例如 Postgres WAL），因而自上次特定工夫点备份以来，还须要某种其余机制来“重播”数据。

许多组织应用 Kafka 来满足此要求。通过 Kafka 将数据流传输到 ClickHouse 具备可用性和容错能力方面的许多劣势。另一个长处是可能将摄取重置为 Kafka 分区中的任何偏移量。执行工夫点备份时，必须存储 Kafka 偏移量。在复原期间，ClickHouse Kafka Engine 配置会在创立备份时设置为 Kafka 偏移量，并且将提取该工夫点之后的数据。

存储 Kafka 偏移量的一种简略办法是将它们插入到备份中蕴含的 ClickHouse 中的表中。这能够在包装脚本中实现，该脚本暂停从 Kafka 的摄取，写入以后主题分区偏移量，开始备份，而后再次启用摄取。还原数据时，能够重置使用者组的偏移量，而后从新启用摄取。无关重置偏移量的示例，请参见此博客上的 ClickHouse Kafka 引擎教程。

下一步

在深入研究并施行备份解决方案之前，请花点工夫思考一下您的业务和最终用户的需要。充沛理解环境的复原工夫指标（RTO）和复原点指标（RPO）。而后，思考下面概述的办法以确定最合适的办法。

ClickHouse 的最大劣势之一就是多元化和投资社区的反对和奉献。Clickhouse 备份提供的自动化也不例外：非常感谢 Alex Akulov！

在 Altinity，咱们和您一样在乎您的数据。与咱们分割以获取备份方面的帮忙，或其余任何 ClickHouse 挑战！