创建快照
快照备份 使用标准的BACKUP 命令,并将 experimental_lightweight_snapshot = true。id 设置是必需的——它用于为快照命名,并在解锁和可观测性命令中引用该快照:
id 和 status,可使用 id 在 system.backups 中跟踪该操作。
将单个表备份到 S3:
恢复到同一服务
由于快照保存的是对象存储中文件的引用,而不是数据副本,因此要恢复到新的或其他 ClickHouse 服务,就必须能够访问原始对象存储。正因如此,不支持通过 SQL 执行跨服务恢复——只能通过 UI 进行。通过 SQL,你可以使用snapshot_from_current_service = 1,从外部备份 bucket 将快照恢复到同一服务。这样会经由目标端磁盘直接读取对象,而不是通过远程快照读取器:
AS 子句会将数据恢复到一个新的表名下,原始表保持不变。若要覆盖原始表,请先将其删除:
解锁快照
每个快照都会在 ClickHouse Keeper 中持有锁,防止其引用的对象存储文件被垃圾回收。在 恢复 完成后,或当某个快照不再需要时,应将其解锁以释放这些锁。 解锁分为两种形式:一种是系统级解锁,一次性移除该快照的所有锁;另一种是按表解锁,只移除单个表的锁,同时保持快照其余部分不变。 系统级解锁 — 移除该快照的所有锁:FROM 子句为可选项 (可在 system.snapshot_locks 的 info 列中查看) :
system.snapshot_locks 中消失,而不再被其他快照引用的 parts 也会从 system.snapshot_parts 中消失。
可观测性
system.backups
所有快照操作都会显示在system.backups 中,与常规的备份和恢复操作一并列出。使用你设置的 id (或命令返回的 UUID) 查询即可:
system.snapshot_locks
system.snapshot_locks 显示当前在 Keeper 中注册的已提交快照。当快照被提交时,会在 /clickhouse/snapshot/committed/{snapshot_id} 下创建一个 Keeper 节点。在删除任何数据分区片段之前,服务器会检查是否有某个已提交快照持有该分区片段的锁。如果有,则会跳过删除。该锁会一直保留,直到你显式对该快照执行解锁。
每一行代表一个已提交的快照。如果你看到某些快照锁对应的 backup destination 已不再有效,请运行
SYSTEM UNLOCK SNAPSHOT 将其清理掉。
要检查某个特定快照锁是否存在:
system.snapshot_parts
system.snapshot_parts 显示当前被至少一个快照锁固定的数据分区片段。对于每个被锁定的数据分区片段,/clickhouse/snapshot/{table_uuid}/{part_name} 处都会有一个 Keeper 节点,其中包含该分区片段的压缩大小和未压缩大小。此表通过读取这些节点,显示当前哪些数据分区片段受保护而不会被删除。
snapshots_size > 1 的数据分区片段被多个快照引用,在所有持有锁的快照都解锁之前,不会从对象存储中删除。
要检查被固定的存储总量: