本文知识点来源于官网地址https://www.cockroachlabs.com/docs/stable/backup-architecture.html
CockachDB备份以作业的方式操作,作业是可能跨越多个SQL会话的长期运行操作。与常规SQL语句不同,BACKUP语句在作业工作流中执行。备份任务有四个主要阶段:
- 创建作业
- 解析
- 导出数据
- 写元数据
概述
CRDB在运行备份作业时执行以下任务:
- 验证BACKUP语句的参数,然后将它们写入描述备份的作业系统中的作业。
- 根据作业中记录的参数,以及在存储位置中找到的任何以前的备份,确定需要备份存储层中数据的哪个键跨度和时间范围。
- 指示集群中的各个节点分别读取这些键并将行数据写入备份存储位置。
- 记录关于备份到备份存储位置的任何附加元数据。
下图展示了在云存储中从BACKUP语句到完整备份的流程:
创建作业
我们使用以下语句来启动备份过程:
BACKUP DATABASE movr INTO 's3://bucket' WITH revision_history;
该语句请求对movr数据库进行完全备份,并带有revision_history选项。
cockachdb将验证BACKUP语句中传递的选项,并检查用户是否具有执行备份所需的权限。表与要备份的键跨度集一起标识。在本例中,备份将识别movr数据库中的所有表,并注意到需要使用revision_history选项。
作业创建阶段的最终目标是完成所有这些检查,并将备份作业应该完成的任务的详细信息写入作业记录。
如果请求了一个已分离的备份,那么backup语句就完成了,因为它已经创建了一个未提交但准备运行的备份作业。您将发现作为输出返回的作业ID。如果没有detached选项,作业将被提交,语句将等待返回结果,直到备份作业启动、运行和终止。
一旦作业记录被提交,即使客户端断开连接或处理backup语句的节点终止,集群也会尝试运行备份作业。从这一点开始,备份是一个持久化作业,集群中的任何节点都可以接管其执行,以确保其运行。作业记录将移动到系统作业表,以便节点认领它。
解析
一旦其中一个节点从系统作业表中声明了作业,它将获取作业记录的信息并概述计划。此节点成为协调器。在我们的示例中,Node 2成为协调器,并开始完成以下工作,以准备和解析分布式备份工作的目标:
测试到存储桶URL (‘s3://bucket’)的连接。
确定此备份的特定子目录,包括它是否应该从任何发现的现有目录中增量。
计算备份数据的键值,如果是增量备份,则计算时间范围。
确定要备份的键的leaseholder节点。
向将执行数据导出的节点(通常是leaseholder节点)提供计划。
为了绘制节点将写入数据的存储位置的目录,协调器标识备份的类型。这将确定用于存储备份文件的新(或编辑过的)目录的名称。例如,如果目标存储位置中存在现有的完全备份,那么即将进行的备份将是增量备份,因此在其中发现任何现有增量层之后追加到完全备份。
解析键和时间范围
在解析阶段,协调器将计算集群需要为此备份导出的所有必要的键的跨度及其时间范围。它根据哪个节点是该键跨度范围的租赁者来划分键跨度。每个节点上都有一个SQL处理器,用于处理协调器将传递给它的备份计划。通常,完成导出工作的是键范围的leaseholder节点上的备份SQL处理器。
每个节点的备份SQL处理器负责:
- 向存储层询问每个键跨度的内容。
- 从存储层接收内容。
- 将其写入备份存储位置或特定的位置。
由于集群中的任何节点都可以成为协调器,所有节点都可以在备份期间负责导出数据,因此有必要使所有节点都可以连接到备份存储位置。
导出
一旦协调器向指定备份数据的每个备份SQL处理器提供了计划,备份数据的分布式导出就开始了。
在下面的图中,节点2和节点3包含R1和R2范围的租赁者。因此,在本例备份任务中,备份数据将从这些节点导出到指定的存储位置。
在处理过程中,节点向协调器发送跟踪其备份工作的进度数据。在图中,节点3将向节点2发送进度数据。然后,协调器节点将进度数据聚合到存储桶中的检查点文件中。检查点文件为备份提供了一个标记,以便在可重试状态后恢复备份,例如当它被暂停时。
写元数据
一旦每个节点完全完成了它们的数据导出工作,协调器将通过写入备份元数据文件来结束备份任务。在图中,节点2将R1的备份数据导出因为它是该范围的租赁者,该节点还将备份的元数据导出因为它也是协调器。
备份元数据文件描述备份包含的所有内容。也就是说,还原作业成功完成所需的所有信息。如果备份中没有元数据文件,则表示备份没有正确完成,并且无法恢复。
完全备份完成后,指定的存储位置将包含备份数据及其元数据,以便进行潜在的恢复。在将movr数据库后续备份到此存储位置之后,cockachdb将创建一个备份集合。