跳到主要内容
跳到主要内容

备份和恢复

命令摘要​

ALL

在 ClickHouse 的 23.4 版本之前，ALL 只能适用于 RESTORE 命令。

背景​

虽然 复制 提供了硬件故障的保护，但并不能防止人为错误：意外删除数据、删除错误的表或在错误的集群上删除表，以及导致数据处理不正确或数据损坏的软件漏洞。在许多情况下，这类错误会影响所有副本。ClickHouse 内置了防止某些类型错误的保障措施——例如，默认情况下 你无法仅删除包含超过 50 Gb 数据的 MergeTree 类引擎的表。然而，这些保障措施并不涵盖所有可能的情况，并且可能会被绕过。

为了有效减轻可能的人为错误，你应该提前仔细准备备份和恢复数据的策略。

每个公司可用的资源和业务需求不同，因此没有适用于所有情况的 ClickHouse 备份和恢复的通用解决方案。对一千兆数据有效的解决方案，可能不适用于数十个拍字节的数据。存在多种可能的方法，各自有优缺点，下面将进行讨论。使用几种方法而不仅仅是一种，来补偿它们的各种缺点是一个好主意。

备注

请记住，如果你备份了什么东西但从未尝试恢复，那么当你实际需要时，恢复可能无法正常工作（或者至少会比企业可容忍的时间更长）。因此，无论你选择哪种备份方法，请确保也自动化恢复过程，并定期在备用的 ClickHouse 集群上进行练习。

备份到本地磁盘​

配置备份目标​

在下面的示例中，你将看到备份目标指定为 Disk('backups', '1.zip')。为了准备目标，在 /etc/clickhouse-server/config.d/backup_disk.xml 中添加一个文件，指定备份目标。例如，该文件定义了名为 backups 的磁盘，然后将该磁盘添加到 backups > allowed_disk 列表中：

参数​

备份可以是完整的或增量的，可以包含表（包括物化视图、投影和字典）和数据库。备份可以是同步的（默认）或异步的。可以压缩备份。备份可以设有密码保护。

BACKUP 和 RESTORE 语句接受数据库和表名称的列表、一个目标（或源）、选项和设置：

  • 备份的目标，或恢复的源。这基于之前定义的磁盘。例如 Disk('backups', 'filename.zip')
  • ASYNC：异步备份或恢复
  • PARTITIONS：要恢复的分区列表
  • SETTINGS：
    • id：备份或恢复操作的 id，随机生成 UUID，若未手动指定则使用。若已有同一 id 的操作在运行，则抛出异常。
    • compression_method 和 compression_level
    • password 用于磁盘上的文件
    • base_backup：此源的前一个备份的目标。例如，Disk('backups', '1.zip')
    • use_same_s3_credentials_for_base_backup：基础备份是否应从查询中继承凭据。仅对 S3 有效。
    • use_same_password_for_base_backup：基础备份存档是否应从查询中继承密码。
    • structure_only：如果启用，仅允许备份或恢复 CREATE 语句，而不包括表的数据
    • storage_policy：恢复表的存储策略。请参见 使用多个块设备进行数据存储。此设置仅适用于 RESTORE 命令。所指定的存储策略仅适用于来自 MergeTree 家族的引擎的表。
    • s3_storage_class：用于 S3 备份的存储类。例如，STANDARD
    • azure_attempt_to_create_container：使用 Azure Blob Storage 时，指定的容器在不存在时是否尝试创建。默认值：true。
    • 核心设置 也可在此处使用

使用示例​

备份并恢复一个表：

相应的恢复：

备注

如果表 test.table 包含数据，上述 RESTORE 将失败，你必须先删除该表才能测试 RESTORE，或者使用设置 allow_non_empty_tables=true：

表可以以新名称恢复或备份：

增量备份​

通过指定 base_backup 可以进行增量备份。

备注

增量备份依赖于基础备份。基础备份必须保持可用，以便能够从增量备份中恢复。

增量存储新数据。设置 base_backup 会导致自上一个备份起的数据存储到 Disk('backups', 'incremental-a.zip')：

从增量备份和 base_backup 恢复所有数据到新表 test.table2：

为备份分配密码​

写入磁盘的备份可以对文件应用密码：

恢复：

压缩设置​

如果你想指定压缩方法或级别：

恢复特定分区​

如果需要恢复与表相关的特定分区，可以指定这些分区。要从备份恢复分区 1 和 4：

将备份作为 tar 存档​

备份也可以存储为 tar 存档。其功能与 zip 相同，只是不支持密码。

将备份写入 tar：

相应的恢复：

要更改压缩方法，应将正确的文件后缀附加到备份名称。即要用 gzip 压缩 tar 存档：

支持的压缩文件后缀为 tar.gz、.tgz、tar.bz2、tar.lzma、.tar.zst、.tzst 和 .tar.xz。

检查备份状态​

备份命令返回一个 id 和 status，并且该 id 可用于获取备份的状态。这对于检查长时间 ASYNC 备份的进度非常有用。下面的示例显示在尝试覆盖已有备份文件时发生的失败：

与 system.backups 表一起，所有备份和恢复操作也在系统日志表 backup_log 中跟踪：

配置备份/恢复以使用 S3 端点​

要将备份写入 S3 存储桶，你需要三种信息：

  • S3 端点， 例如 https://mars-doc-test.s3.amazonaws.com/backup-S3/
  • 访问密钥 ID， 例如 ABC123
  • 秘密访问密钥， 例如 Abc+123
备注

创建 S3 存储桶的过程请参见 将 S3 对象存储用作 ClickHouse 磁盘，保存策略后再返回此文档，无需配置 ClickHouse 以使用 S3 存储桶。

备份的目标将如下指定：

创建基础（初始）备份​

增量备份需要一个基础备份来开始，本示例将稍后用作基础备份。S3 目标的第一个参数是 S3 端点，后面是用于此备份的桶内目录。在本例中，目录名为 my_backup。

添加更多数据​

增量备份是基于基础备份和当前内容之间的差异填充的。在进行增量备份之前，添加更多数据：

进行增量备份​

此备份命令类似于基础备份，但添加了 SETTINGS base_backup 和基础备份的位置。请注意，增量备份的目标不是与基础相同的目录，而是同一端点下不同的目标目录。基础备份在 my_backup，增量将写入 my_incremental：

从增量备份中恢复​

此命令将增量备份恢复到新表 data3。请注意，当恢复增量备份时，基础备份也包含在内。恢复时仅指定增量备份：

验证计数​

原始表 data 中有两次插入，一次为 1,000 行，一次为 100 行，总共 1,100。验证恢复的表有 1,100 行：

验证内容​

这将比较原始表 data 与恢复的表 data3 的内容：

使用 S3 磁盘进行备份/恢复​

也可以通过在 ClickHouse 存储配置中配置 S3 磁盘来 BACKUP/RESTORE 到 S3。通过在 /etc/clickhouse-server/config.d 中添加一个文件来配置磁盘：

然后像往常一样进行 BACKUP/RESTORE：

备注

但请记住：

  • 该磁盘不应用于 MergeTree 本身，仅用于 BACKUP/RESTORE
  • 如果你的表由 S3 存储支持且磁盘类型不同，则它不会使用 CopyObject 调用将部分复制到目标存储桶，而是下载并上传，这非常低效。对于这种用例，最好使用 BACKUP ... TO S3(<endpoint>) 语法。

使用命名集合​

命名集合可以用于 BACKUP/RESTORE 参数。示例请见 这里。

替代方案​

ClickHouse 在磁盘上存储数据，有许多方法可以备份磁盘。这些是在过去使用的一些替代方案，可能适合你的环境。

在其他地方复制源数据​

通常，导入 ClickHouse 的数据是通过某种持久队列传递的，比如 Apache Kafka。在这种情况下，可以配置一个额外的订阅者集合，这些订阅者将读取相同的数据流，同时在写入 ClickHouse 的时候将其存储在其他冷存储中。大多数公司已经有一些推荐的冷存储，可能是对象存储或 HDFS 这样的分布式文件系统。

文件系统快照​

一些本地文件系统提供快照功能（例如，ZFS），但它们可能不是服务实时查询的最佳选择。一个可能的解决方案是使用这种文件系统创建附加副本，并将其排除在用于 SELECT 查询的 Distributed 表之外。此类副本上的快照将无法被任何修改数据的查询访问。作为额外好处，这些副本可能具有额外的硬件配置，每个服务器连接更多磁盘，从而具有成本效益。

对于较小的数据量，简单的 INSERT INTO ... SELECT ... 到远程表也可能有效。

处理分区​

ClickHouse 允许使用 ALTER TABLE ... FREEZE PARTITION ... 查询创建表分区的本地副本。这是通过对 /var/lib/clickhouse/shadow/ 文件夹的硬链接实现的，因此通常不会为旧数据占用额外的磁盘空间。创建的文件副本不由 ClickHouse 服务器处理，因此你可以将它们留在那里：你将会有一个简单的备份，无需任何额外的外部系统，但它仍然容易受到硬件问题的影响。出于这个原因，最好将它们远程复制到另一个位置，然后删除本地副本。分布式文件系统和对象存储仍然是不错的选择，但正常的附加文件服务器只要容量足够也可能有效（在这种情况下，传输将通过网络文件系统或rsync 进行）。 可以通过 ALTER TABLE ... ATTACH PARTITION ... 从备份中恢复数据

有关与分区操作相关的查询的更多信息，请参见 ALTER 文档。

有一个第三方工具可用于自动化此方法：clickhouse-backup。

设置以禁止并发备份/恢复​

要禁止并发备份/恢复，可以分别使用以下设置。

默认情况下，这两个的值为 true，因此默认允许并发备份/恢复。 当这些设置在集群上为false时，同一时间，仅允许在集群上运行1个备份/恢复。

配置备份/恢复以使用 AzureBlobStorage 端点​

要将备份写入 AzureBlobStorage 容器，你需要以下信息：

  • AzureBlobStorage 端点连接字符串 / URL，
  • 容器，
  • 路径，
  • 账户名称（如果指定 URL）
  • 账户密钥（如果指定 URL）

备份的目标将如下指定：

备份系统表​

系统表也可以包含在你的备份和恢复工作流中，但其包含取决于具体用例。

备份日志表​

存储历史数据的系统表，例如带有 _log 后缀的那些（例如，query_log、part_log），可以像任何其他表一样备份和恢复。如果你的用例依赖于分析历史数据，例如，使用 query_log 跟踪查询性能或调试问题，建议在备份策略中包括这些表。然而，如果不需要这些表的历史数据，可以排除它们以节省备份存储空间。

备份访问管理表​

与访问管理相关的系统表，如用户、角色、行策略、设置配置文件和配额，在备份和恢复操作中会受到特别处理。当这些表包含在备份中时，它们的内容会导出到一个特殊的 accessXX.txt 文件中，该文件封装了创建和配置访问实体的等效 SQL 语句。在恢复时，恢复过程会解释这些文件并重新应用 SQL 命令以重建用户、角色和其他配置。

此功能确保 ClickHouse 集群的访问控制配置可以作为集群整体设置的一部分进行备份和恢复。

注意：此功能仅适用于通过 SQL 命令管理的配置（称为 "SQL驱动的访问控制和帐户管理"）。在 ClickHouse 服务器配置文件中定义的访问配置（例如 users.xml）不包括在备份中，并且无法通过此方法恢复。