关于数据库:数据库误操作后悔药来了AnalyticDB-PostgreSQL教你实现分布式一致性备份恢复

简介：本文将介绍 AnalyticDB PostgreSQL 版备份复原的原理与应用办法。

AnalyticDB PostgreSQL 版（简称 ADB PG）是阿里云数据库团队基于 PostgreSQL 内核（简称 PG）打造的一款云原生数据仓库产品。在数据实时交互式剖析、HTAP、ETL、BI 报表生成等业务场景，ADB PG 都有着独特的技术劣势。

作为一款企业级数据仓库产品，数据安全的重要性显而易见。备份复原性能是保障数据安全的根本伎俩，也是 ADB PG 应答突发状况进行数据库复原的重要保障。备份复原，顾名思义，是对数据库进行数据备份，以便在必要时进行数据的复原，防备于未然。以后，ADB PG 的备份复原性能曾经利用在以下各个用户场景中：

因为系统故障、人为误操作造成数据被毁坏或实例不可用时，基于备份数据对实例进行复原。
用户须要基于已有实例，疾速克隆出一个完全相同的实例。
在节点数不变的前提下，用户须要更改源实例的规格。

本文将介绍 ADB PG 备份复原的原理与应用办法。

ADB PG 是采纳 MPP 程度扩大架构的分布式数据库。ADB PG 实例由一个或多个协调节点 (Master) 和多个计算节点 (Compute Node) 组成，协调节点负责接管用户申请，制订分布式执行打算并下发至计算节点，收集执行后果并返回给客户端；计算节点负责并行计算剖析与数据存储。数据在计算节点之间能够随机、哈希、复制散布。下图 ADB PG 的架构图:

ADB PG 的物理备份复原性能，基于集群的根底备份和日志备份，能够在分布式数据库持续提供服务的同时备份各个节点的数据，并保证数据的一致性。在须要时，能够将分布式数据库复原至备份的时刻。

根底备份是指对数据库所有数据进行的一个齐全拷贝。根底备份会将集群全量数据快照压缩后存储在其它离线存储介质，集群在根底备份期间不会阻塞用户的读写，因而，备份期间产生的日志也会被备份来保障根底备份的完整性。

日志备份(也称为增量备份)，是指将集群产生的日志文件备份至其余离线存储介质。日志文件记录了用户对数据库的 DML 与 DDL 操作。通过一个残缺的根底备份以及间断的日志备份，能够将新集群复原到某一历史事件点，保障了这段时间的数据安全性。

ADB PG 可保障最小 RPO 为 10 分钟的备份复原。

在残缺地介绍 ADB PG 的备份复原原理之前，先简要地介绍单机 PG 的 PITR(Point in Time Recovery)备份复原机制。ADB PG 的备份复原机制基于单机 PG 的 PITR 原理，并退出了分布式数据一致性的保障机制。

WAL 日志：

PostgreSQL 数据库会将事务对数据的所有更改 (包含 DDL、DML 等操作) 记录在 WAL(Write Ahead Log)日志文件中。WAL 日志文件能够看作是一个有限增长的只追加文件，PG 会将日志数据按固定大小切分成多个文件存储。事务的每次批改数据的操作都会被追加记录至 WAL 文件中，并赋予一个惟一的 LSN 序号(Log Sequence Number)，在事务提交时，会保障 WAL 日志已长久化。

这些日志文件的作用是为了让数据库在须要复原时，能够通过“重放”WAL 日志来复原数据库解体时还未长久化，但对应事务已提交的数据。

复原点：

有了 WAL 日志能够进行“重放”操作，那么还有一个问题：须要重放到什么时候呢？这就须要复原点 (restore point) 来解决。

复原点相当于 WAL 日志中写入的一个标记，它标记了一个日志的地位。当 PG 对日志进行重放时，通过查看是否曾经达到这个标记点，来决定是否须要进行 ” 重放 ” 的操作。

以下 SQL 能够在 WAL 日志文件中创立一个名为 t1 的标志点：

postgres=# select pg_create_restore_point('t1');
LOG:  restore point "t1" created at 0/2205780
STATEMENT:  select pg_create_restore_point('t1');
 pg_create_restore_point
-------------------------
 0/2205780
(1 row)

当数据库程序回放 WAL 日志时，会查看以后日志蕴含此复原点名称，若已蕴含，则进行重放。另外，PG 还反对复原至指定的任意工夫点，事务号，LSN 序号等操作。

根底备份与增量备份：

根底备份是对数据库数据的一份残缺拷贝。能够应用 pg_basebackup 工具对单机 PG 进行一次根底备份，备份数据可保留至本地，也可存储在其余离线存储介质 (OSS) 中。

$ pg_basebackup -D pg_data_dir/ -p 6000
NOTICE:  pg_stop_backup complete, all required WAL segments have been a

增量备份是指对产生的 WAL 日志文件进行备份。在 PG 中，可通过数据库参数 archive_command 来指定如何备份 WAL 日志数据。当 PG 生成一个 WAL 日志文件时，会通过执行 archive_command 的命令来尝试备份归档该日志文件。比方，如下命令会将日志文件发送至指定的 OSS。

archive_command="ossutil cp %p oss://bucket/path/%f"

单机 PG 的全量备份与增量备份

须要留神的是，根底备份期间并不会阻塞数据库的读写，因而备份期间的数据更新对应的 WAL 日志也须要备份，以备复原时保证数据的一致性。

PITR 复原：

当须要复原数据库时，首先下载根底备份数据，而后应用根底备份开启集群，再下载日志文件备份，“重放”至指定的复原点即可进行数据库的复原。在单机 PG 中, 指定的复原点的指标能够是事务号、工夫戳、WAL 序号 (LSN) 以及某个复原点名称。

ADB PG 作为分布式数据库，应用两阶段事务提交来治理分布式事务。如果照搬单机 PG 的 PITR 机制，会造成数据的不统一。比方如下场景：分布式事务依照 A、B、C 工夫程序调配，但因为种种原因（如网络延时、节点负载、显式提交等），分布式模式下事务的提交的程序在各个节点可能各不相同，如下图所示：

Master 依照 A、B、C 程序提交
Compute Node 1 依照 A、C、B 程序提交
Compute Node 2 依照 B、C、A 程序提交

如果在此过程中，创立了复原点，当复原时如果指定复原至该复原点，不言而喻，复原后集群中各个节点所处的状态是不统一的。

两阶段事务提交锁与一致性复原点：

为了解决上述的问题，咱们引入了两阶段事务提交锁。分布式事务提交会以 SHARED 模式取得该锁，而创立复原点都须要以 EXCLUSIVE 模式取得该锁。于是在集群中如果有分布式事务正在期待各个节点上提交，那么集群创立复原点的动作必须期待所有节点上的分布式事务提交完后，能力进行。

这从根本上解决了上述这就解决了在分布式事务还在提交的同时创立复原点而造成复原时数据不统一的问题。引入了两阶段提交锁机制之后，咱们能够保障创立的复原点所对应的各节点状态是统一的，因而咱们将 ADB PG 中创立的复原点称为一致性复原点。

分布式备份与复原过程：

有了事务提交锁与一致性复原点之后，咱们就能够释怀地对 ADB PG 各个节点进行备份和创立一致性复原点，而无需放心节点状态不统一的问题。

ADB PG 的备份也分为根底备份和日志备份(也称为增量备份)。根底备份是对集群每个节点进行的一次残缺拷贝，ADB PG 会对计算节点和协调节点并发地进行备份，将备份数据流式保留至离线存储(如 OSS)。在进行根底备份的期间，不会阻塞集群的读写服务。因而，如果在根底备份期间，用户有写入和更新的数据，也须要将数据更改对应的 WAL 日志进行备份。如下图所示，ADB PG 会对每个节点并行地进行一次数据拷贝，将数据流式上传至 OSS。

ADB PG 根底备份过程

ADB PG 的日志备份是对集群中的计算节点和协调节点产生的 WAL 日志的备份。各个节点会将本人生成的 WAL 日志转储至离线存储(如 OSS)。同时，集群会定时地创立一致性复原点，并将蕴含一致性复原点的 WAL 日志进行备份。

当须要复原新的集群时，须要同时应用根底备份与日志备份，并首先创立一个节点数和原实例雷同的复原实例。各个节点并行拉取指定的根底备份至本地。之后，每个节点本人拉取本人所需的 WAL 日志备份文件，在本地重放，直到重放至指定的一致性复原点而进行。最终，咱们就能失去一个新的集群，并保证数据和状态与源实例在一致性复原点对应的数据与状态统一。复原的过程如下图所示：

查看根底备份集

用户在实例控制台的“备份复原”页面，能够查看数据库的根底备份数据。目前根底备份数据保留在 OSS 上，默认保留天数为 7 天。

表格中每一行示意一份根底备份数据，并记录了备份的开始工夫，完结工夫，备份状态(胜利 / 失败)，备份数据大小以及一致性工夫点。一致性工夫点示意此基础备份数据能够将集群复原至该历史工夫点，并使数据库处于一致性状态。

查看一致性复原点

一致性复原点是指集群能够复原到的某个历史工夫点。用户在备份复原页面的“复原点”页能够查看以后实例的所有复原点。

表格中每一行示意一个一致性复原点，并记录了复原点的工夫戳，示意该复原点能够让集群复原至此历史工夫点。

查看日志文件列表

日志文件记录了数据库的所有更改，在集群复原时会应用相应的日志文件将集群复原至一致性状态，以后用户集群复原的日志文件都保留在 OSS 上。用户在备份复原页面的 ” 日志备份 ” 中可查看日志文件列表。

查看备份策略

备份策略是指实例进行备份的周期与时间段，创立一致性复原点的频率，以及数据备份的保留天数等等。

用户可在备份复原的“备份设置”中查看和批改备份策略。

批改备份策略

点击“批改备份配置”按钮，能够对备份策略进行批改。

首先查看源实例上的数据

进入复原页面

用户能够在控制台的实例列表，数据备份列表或复原点列表点击复原进入实例复原页面；

复原页面如下：

复原实例的售卖页面与购买实例的页面大体一致，但多了如下限度:

1. 以后复原实例是 master 数量必须抉择 1 个

2. 抉择的实例 segment(computer node)数量必须与源实例保持一致

3. 抉择的实例存储空间必须大于或等于源实例

抉择复原工夫点

在复原页面的 ” 克隆源备份集 ” 的下拉框中抉择须要复原实例到哪一个历史工夫点，即指定一个一致性复原点。

点击购买

用户点击购买后，与购买新实例的流程一样，须要期待实例创立实现后，可在控制台看到新复原出的实例。

复原的新实例

查看复原的新实例上的数据，能够看到数据与源实例完全一致。

备份复原对 ADB PG 保障数据安全的具备很重要的价值。以后备份复原性能曾经利用多个用户场景，并保障了起码为 10 分钟的 RPO。将来 ADB PG 备份复原性能会持续优化备份复原性能，反对差异化备份，反对更多的存储介质，进步用户应用体验，为用户提供更多的性能、性能和老本优化。

原文链接
本文为阿里云原创内容，未经容许不得转载。

关于数据库:数据库误操作后悔药来了AnalyticDB-PostgreSQL教你实现分布式一致性备份恢复

一、背景

二、简介

三、原理

（一）单机 PG 的 PITR 机制

（二）ADB PG 的分布式一致性备份复原机制

四、应用

（1）控制台备份相干信息

（2）实例复原步骤

五、总结