当前位置: 首页 > 科技观察

AnalyticDBPostgreSQL教你如何实现分布式一致性备份和恢复

时间:2023-03-19 15:25:22 科技观察

一、背景AnalyticDBPostgreSQL(简称ADBPG)是阿里云数据库团队基于PostgreSQL内核(简称PG)打造的云原生数据仓库产品).在数据实时交互分析、HTAP、ETL、BI报表生成等业务场景中,ADBPG具有独特的技术优势。作为企业级数据仓库产品,数据安全的重要性不言而喻。备份恢复功能是保障数据安全的基本手段,也是ADBPG在突发事件中恢复数据库的重要保障。备份恢复,顾名思义就是对数据库的数据进行备份,以便在需要的时候恢复数据,防患于未然。目前,ADBPG的备份恢复功能已经应用于以下用户场景:当由于系统故障或人为误操作导致数据被破坏或实例不可用时,基于备份数据恢复实例。用户需要在现有实例的基础上快速克隆出一个完全相同的实例。在节点数量不变的前提下,用户需要更改源实例的规格。本文将介绍ADBPG备份与恢复的原理和使用方法。2.简介ADBPG是一个采用MPP水平扩展架构的分布式数据库。一个ADBPG实例由一个或多个协调节点(Master)和多个计算节点(ComputeNodes)组成。协调节点负责接收用户请求,制定分布式执行计划并发送给计算节点,收集执行结果返回给客户终端;计算节点负责并行计算分析和数据存储。数据可以在计算节点之间随机分布、散列和复制。下图ADBPG的架构图:ADBPG的物理备份和恢复功能,基于集群基础备份和日志备份,可以在分布式数据库持续提供服务的同时备份各个节点的数据,保证数据一致性。需要时,分布式数据库可以恢复到备份时刻。基本备份是数据库中所有数据的完整副本。基础备份会将集群的全量数据快照进行压缩,存储在其他离线存储介质中。集群在基础备份时不会阻塞用户的读写。因此,备份过程中产生的日志也会被备份,以保证基础备份的完整性。日志备份(也称为增量备份)是指将集群产生的日志文件备份到其他离线存储介质中。日志文件记录了用户对数据库的DML和DDL操作。通过完整的基础备份和持续的日志备份,可以将新集群恢复到某个历史事件点,保证这段时间的数据安全。ADBPG可以保证至少10分钟RPO的备份恢复。3.原理在全面介绍ADBPG的备份恢复原理之前,先简单介绍一下单机PG的PITR(PointinTimeRecovery)备份恢复机制。ADBPG的备份恢复机制是在单机PG的PITR原理基础上,增加了分布式数据一致性的保证机制。(1)单机PG的PITR机制WAL日志:PostgreSQL数据库会在WAL(WriteAheadLog)日志文件中记录对数据的所有更改(包括DDL、DML等操作)。WAL日志文件可以看作是一个无限增长的append-only文件,PG会把日志数据按照固定的大小分成多个文件进行存储。事务的每一次数据修改操作都会附加到WAL文件中,并赋予一个唯一的LSN序列号(LogSequenceNumber)。当事务提交时,WAL日志将保证持久化。这些日志文件的作用是让数据库在数据库需要恢复的时候,通过“重放”WAL日志的方式,恢复在数据库崩溃时还没有持久化,而对应的事务已经提交的数据。恢复点:有了WAL日志,就可以进行“replay”操作了,那么还有一个问题:什么时候需要replay?这就需要一个还原点(restorepoint)来解决。一个recoverypoint相当于写在WALlog中的一个标记,标记了一个日志所在的位置。PG在重放日志时,通过检查是否到达这个标记点来决定是否停止“重放”操作。下面的SQL可以在WAL日志文件中创建一个名为t1的标记点:postgres=#selectpg_create_restore_point('t1');LOG:restorepoint"t1"createdat0/2205780STATEMENT:selectpg_create_restore_point('t1');pg_create_restore_point-----------------------0/2205780(1row)当数据库顺序重放WAL日志时,会检查当前日志是否包含恢复点的名称,并且如果包含,则停止重播。此外,PG还支持恢复到任意指定时间点、交易号、LSN序号等操作。基本备份和增量备份:基本备份是数据库数据的完整副本。可以使用pg_basebackup工具对单机PG进行基础备份,备份数据可以保存在本地,也可以保存在其他离线存储介质(OSS)中。$pg_basebackup-Dpg_data_dir/-p6000NOTICE:pg_stop_backupcomplete,allrequiredWALsegmentshavebeena增量备份是指备份生成的WAL日志文件。在PG中,可以通过数据库参数archive_command来指定如何备份WAL日志数据。PG在生成WAL日志文件时,会尝试通过执行archive_command命令对日志文件进行备份归档。例如,下面的命令会将日志文件发送到指定的OSS。archive_command="ossutilcp%poss://bucket/path/%f"单机PG的全量备份和增量备份需要注意的是基本备份时不会阻塞数据库,所以数据更新时备份对应的WAL日志也需要备份,以保证恢复时数据的一致性。PITR恢复:当需要恢复数据库时,先下载基础备份数据,然后使用基础备份启动集群,再下载日志文件备份,“replay”到指定恢复点恢复数据库。在独立的PG中,指定恢复点的目标可以是事务号、时间戳、WAL序列号(LSN)和恢复点名称。(2)ADBPG的分布式一致性备份和恢复机制作为分布式数据库,ADBPG采用两阶段事务提交的方式来管理分布式事务。如果复制单机PG的PITR机制,会造成数据不一致。例如下面的场景:分布式事务按照A、B、C时间的先后顺序分发,但是由于各种原因(比如网络延迟、节点负载、显式提交等),事务提交的顺序在分布式模式可能因每个节点而异。它们是不同的,如下图所示:Master按照A、B、C的顺序提交ComputeNode1。按照A、C、B的顺序提交ComputeNode1。按照A、C、B的顺序提交ComputeNode2。B、C、A。如果这个过程中创建了恢复点,如果在恢复时指定恢复到恢复点,很明显恢复后集群中各个节点的状态不一致。两阶段事务提交锁和一致性恢复点:为了解决以上问题,我们引入了两阶段事务提交锁。分布式事务提交会在SHARED模式下获取锁,创建恢复点需要在EXCLUSIVE模式下获取锁。因此,如果集群中的每个节点上都有分布式事务等待提交,那么在集群中创建恢复点的动作必须等待所有节点上的分布式事务都提交后才能进行。这从根本上解决了上述在分布式事务还在提交的情况下创建恢复点导致恢复时数据不一致的问题。引入两阶段提交锁机制后,我们可以保证创建的恢复点对应的各个节点的状态是一致的,所以我们称ADBPG中创建的恢复点为一致恢复点。分布式备份和恢复过程:通过事务提交锁和一致恢复点,我们可以安全的为ADBPG的每个节点备份和创建一致恢复点,而不用担心节点状态不一致。ADBPG的备份也分为基础备份和日志备份(又称增量备份)。基本备份是集群中每个节点的完整副本。ADBPG会同时备份计算节点和协调节点,并将备份数据流式传输到离线存储(如OSS)。基础备份时,集群的读写服务不会被阻塞。因此,如果用户在基础备份时有写入和更新数据,则还需要备份数据变化对应的WAL日志。如下图,ADBPG会在每个节点上并行的进行数据拷贝,并将数据流上传到OSS。ADBPG基本备份流程ADBPG的日志备份是对集群中计算节点和协调节点产生的WAL日志的备份。每个节点都会将自己产生的WAL日志dump到离线存储(比如OSS)。同时,集群会定时创建一致恢复点,并备份包含一致恢复点的WAL日志。当需要恢复一个新的集群时,需要同时使用基础备份和日志备份,首先创建一个与原实例节点数相同的恢复实例。每个节点并行拉取指定的基础备份到本地。之后,每个节点拉取自己需要的WAL日志备份文件,并在本地重播,直到停在指定的一致恢复点。最终我们可以得到一个新的集群,并且在一致恢复点保证数据和状态与源实例对应的数据和状态一致。恢复流程如下图所示:4.使用(1)控制台备份信息查看基础备份集用户可以在实例控制台的“备份与恢复”页面查看数据库的基础备份数据。目前基础备份数据保存在OSS上,默认保存期限为7天。表中每一行代表一条基本备份数据,记录了备份开始时间、结束时间、备份状态(成功/失败)、备份数据大小、一致性时间点。一致性时间点是指基础备份数据可以将集群恢复到这个历史时间点,并保持数据库的一致性状态。查看一致恢复点一致恢复点是指集群可以恢复到的历史时间点。用户可以在备份恢复页面的“恢复点”页面查看当前实例的所有恢复点。表中的每一行代表一个一致的恢复点,记录了恢复点的时间戳,表示恢复点可以将集群恢复到这个历史时间点。查看日志文件列表。日志文件记录了对数据库的所有更改。当集群恢复时,将使用相应的日志文件将集群恢复到一致状态。当前用户集群恢复的日志文件都保存在OSS上。用户可以在备份恢复页面的“日志备份”中查看日志文件列表。检查备份策略备份策略是指实例备份的周期和时间段、创建一致恢复点的频率、数据备份保留的天数。用户可以在备份与恢复的“备份设置”中查看和修改备份策略。修改备份策略单击“修改备份配置”按钮修改备份策略。(2)实例恢复步骤首先查看源实例上的数据,进入恢复页面。用户可以在控制台的实例列表、数据备份列表或恢复点列表中点击恢复,进入实例恢复页面;恢复页面如下:恢复实例的销售页面和购买实例的页面大致相同,但是有以下限制:1.当前恢复实例的个数为master,必须是1个选择。2、所选实例的网段(计算机节点)数必须与源实例一致。3.所选实例的存储空间必须大于或等于源实例选择恢复时间点在“克隆源备份集”下拉框中选择实例需要恢复到的历史时间点在恢复页面上,即指定一个一致的恢复点。点击购买用户点击购买后,购买新实例的流程与购买新实例相同。创建实例后,可以在控制台看到新恢复的实例。恢复后的新实例查看恢复后的新实例上的数据,可以看到数据与源实例完全一致。五、小结备份恢复对ADBPG保障数据安全具有重要价值。目前备份恢复功能已经应用于多个用户场景,保证至少10分钟的RPO。未来ADBPG备份恢复功能将持续优化备份恢复性能,支持差异备份,支持更多存储介质,提升用户体验,为用户提供更多功能、性能和成本优化。