PostgreSQL的 PITR实战---运用 recovery_target_time

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,企业版 4核16GB
推荐场景:
HTAP混合负载
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
简介:

看了很多的例子,没有发现具体讲 recovery_target_time的例子,于是自己作一个吧

在开始之前,先把postgresql.conf的配置设置好:

复制代码
                                            
wal_level = archive             # minimal, archive, or hot_standby  
                                # (change requires restart) 
                                            
# - Archiving -                                            
                                            
archive_mode = on               # allows archiving to be done                                            
                                # (change requires restart) 
archive_command
= 'cp %p /usr/local/pgsql/arch/%f' # command to use to archive a logfile segment #archive_timeout = 0 # force a logfile segment switch after this # number of seconds; 0 disables
复制代码

然后启动PostgreSQL:

[postgres@pg201 pgsql]$ ./bin/pg_ctl -D ./data start

在开始备份前,先作一条数据:此时,时间大约是13:40之前:

postgres=# create table test(id integer);                
CREATE TABLE                
postgres=# insert into test values(100);                
INSERT 0 1                

然后开始进行基础备份:

postgres=# select pg_start_backup('gao');                
 pg_start_backup                 
-----------------                
 0/2000020                
(1 row)                

tar命令打包:

tar -cvf ./base.tar ./data

结束基础备份:

postgres=# select pg_stop_backup();                
NOTICE:  pg_stop_backup complete, all required WAL segments have been archived                
 pg_stop_backup                 
----------------                
 0/20000A0                
(1 row)                

此时大约是13:40左右,再插入一条数据:

postgres=# insert into test values(200);                
INSERT 0 1                

等待,到13:50左右,再插入一条数据:

postgres=# insert into test values(300);                
INSERT 0 1                

为了方便操作,进行一次强制的日志切换:

复制代码
postgres=# select pg_switch_xlog();                
 pg_switch_xlog                 
----------------                
 0/30002A0                
(1 row)                
                
postgres=#                 
复制代码

现在,模拟崩溃,强制杀掉进程:

[root@pg201 ~]# kill -s SIGQUIT Postmaster进程号                        

然后,原有data目录改名保存,开始恢复过程:

[postgres@pg201 pgsql]$ mv ./data ./data.bak
[postgres@pg201 pgsql]$ tar -xvf base.tar ./data                    

把崩溃时后的online wal log 也准备好:

复制代码
[postgres@pg201 pgsql]$ rm -rf ./data/pg_xlog                    
[postgres@pg201 pgsql]$ cp -r ./data.bak/pg_xlog/ ./data                    
[postgres@pg201 pgsql]$ cd ./data/pg_xlog                    
[postgres@pg201 pg_xlog]$                    
                    
                    
[postgres@pg201 archive_status]$ pwd                    
/usr/local/pgsql/data/pg_xlog/archive_status                    
[postgres@pg201 archive_status]$ rm -f *                    
[postgres@pg201 archive_status]$                     
复制代码

作一个 recovery.conf文件,指明要恢复到13:45,也就是200数据已经出现,300数据尚未插入的时候

复制代码
[postgres@pg201 data]$ pwd                        
/usr/local/pgsql/data    

                    
[postgres@pg201 data]$ cat recovery.conf                        
restore_command = 'cp /usr/local/pgsql/arch/%f %p'                    
                    
recovery_target_time = '2013-08-07 13:45:00+08'                        
                        
[postgres@pg201 data]$                         
复制代码

再次启动PostgreSQL,发生了恢复:

复制代码
[postgres@pg201 pgsql]$ ./bin/pg_ctl -D ./data start                                        
pg_ctl: another server might be running; trying to start server anyway                                        
server starting                                        
[postgres@pg201 pgsql]$ LOG:  database system was interrupted; last known up at 2013-08-07 13:39:51 CST                                        
LOG:  starting point-in-time recovery to 2013-08-07 13:45:00+08                                        
LOG:  restored log file "000000010000000000000002" from archive                                        
LOG:  redo starts at 0/2000078                                        
LOG:  consistent recovery state reached at 0/3000000                                        
LOG:  restored log file "000000010000000000000003" from archive                                        
LOG:  recovery stopping before commit of transaction 1685, time 2013-08-07 13:51:05.407695+08                                        
LOG:  redo done at 0/3000240                                        
LOG:  last completed transaction was at log time 2013-08-07 13:40:44.338862+08                                        
cp: cannot stat `/usr/local/pgsql/arch/00000002.history': No such file or directory                                        
LOG:  selected new timeline ID: 2                                        
cp: cannot stat `/usr/local/pgsql/arch/00000001.history': No such file or directory                                        
LOG:  archive recovery complete                                        
LOG:  autovacuum launcher started                                        
LOG:  database system is ready to accept connections                                        
复制代码

验证:

复制代码
[postgres@pg201 ~]$ cd /usr/local/pgsql
[postgres@pg201 pgsql]$ ./bin/psql
psql (9.1.2)
Type "help" for help.

postgres=# select * from test;
 id  
-----
 100
 200
(2 rows)

postgres=# \q
复制代码





相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
3月前
|
存储 JSON 关系型数据库
《Postgresql实战》笔记(二)
《Postgresql实战》笔记(二)
66 0
|
1月前
|
JavaScript 关系型数据库 API
Nest.js 实战 (二):如何使用 Prisma 和连接 PostgreSQL 数据库
这篇文章介绍了什么是Prisma以及如何在Node.js和TypeScript后端应用中使用它。Prisma是一个开源的下一代ORM,包含PrismaClient、PrismaMigrate、PrismaStudio等部分。文章详细叙述了安装PrismaCLI和依赖包、初始化Prisma、连接数据库、定义Prisma模型、创建Prisma模块的过程,并对比了Prisma和Sequelize在Nest.js中的使用体验,认为Prisma更加便捷高效,没有繁琐的配置。
Nest.js 实战 (二):如何使用 Prisma 和连接 PostgreSQL 数据库
|
10月前
|
关系型数据库 数据管理 Go
《PostgreSQL数据分区:原理与实战》
《PostgreSQL数据分区:原理与实战》
157 0
|
3月前
|
关系型数据库 网络安全 数据库
《Postgresql实战》笔记(一)
《Postgresql实战》笔记(一)
77 0
|
SQL 存储 DataWorks
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(上)——一、产品概述
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(上)——一、产品概述
|
SQL 存储 Cloud Native
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(上)——二、产品架构及原理
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(上)——二、产品架构及原理
|
存储 算法 Cloud Native
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(上)——三、产品相关概念(上)
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(上)——三、产品相关概念(上)
|
存储 SQL Cloud Native
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(上)——三、产品相关概念(中)
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(上)——三、产品相关概念(中)
|
存储 监控 Cloud Native
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(下)——一、数据同步
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(下)——一、数据同步
|
SQL 并行计算 Cloud Native
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(下)——三、SQL性能调优(上)
《阿里云认证的解析与实战-数据仓库ACP认证》——云原生数据仓库AnalyticDB PostgreSQL版解析与实践(下)——三、SQL性能调优(上)