PostgreSQL 時間點恢復

wongchaofan發表於2024-07-21

SQL

PostgreSQL“時間點恢復”（PITR）也稱為增量資料庫備份、線上備份或存檔備份。PostgreSQL 伺服器記錄所有使用者的資料修改事務，如插入、更新或刪除，並將其寫入一個檔案，稱為預寫 (WAL) 日誌檔案。此機制使用儲存在 WAL 檔案中的歷史記錄來執行自上次資料庫完整備份以來所做的前滾更改。
它是自上次備份以來的最新存檔日誌的備份，而不是完整的資料庫備份。

優點

零停機時間 – 增量資料庫備份對於關鍵系統非常重要，因為該系統不能承受哪怕一分鐘的停機時間。使用時間點恢復，可以完全消除資料庫備份停機時間，因為此機制可以使資料庫備份和系統訪問同時發生。
節省儲存大小 ——使用增量資料庫備份，我們每天備份自上次備份以來的最新存檔日誌檔案，而不是完整的資料庫備份。

PostgreSQL 伺服器中的即時恢復（增量備份）。
備份步驟：

修改postgresql.conf支援歸檔日誌
進行基礎備份（完整資料庫備份）
備份基礎備份至遠端儲存。
將 WAL（存檔日誌檔案）備份到遠端儲存（持續過程）

時間點恢復步驟：

從基礎備份中提取檔案
從 pg_xlog 資料夾複製檔案
建立 recovery.conf 檔案
開始恢復

1）使用 initdb 建立測試資料庫 叢集，/usr/local/pgsql/pgDataPITR/ 下的所有資料庫檔案

-bash-3.2$ pwd/opt/PostgresPlus/9.1AS/bin
-bash-3.2$ initdb start -D /u02/data1/

Start the database-bash-3.2$ ./pg_ctl start -D /u02/data1

2）在 Postgresql 配置檔案（postgresql.conf）中進行更改 ，我們需要在 postgresql.conf 檔案中做一些更改來告訴 PostgreSQL 如何複製或存檔從 PostgreSQL 伺服器生成的 WAL 檔案。

archive directory:
-bash-3.2$ mkdir -p /u02/ssslocation/pgpitr/walbkp 

Backup Data directory(#tar -cvzf u02/ssslocation/pgpitr/databkp/basebkp.tar.gz /u02/data1/):
-bash-3.2$ mkdir -p /u02/ssslocation/pgpitr/databkp 

Modify postgresql.conf
-bash-3.2$ vi /u02/data1/postgresql.conf 
archive_mode = on               # allows archiving to be done(change requires restart)
archive_command = 'cp %p /u02/ssslocation/pgpitr/walbkp/%f' # command to use to archive a logfile segment
wal_level = hot_standby         # minimal, archive, or hot_standby

Restart the database:
-bash-3.2$ ./pg_ctl stop -D /u02/data1 -m i
waiting for server to shut down....LOG:  received immediate shutdown request
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
 done
server stopped

 -bash-3.2$ ./pg_ctl start -D /u02/data1 
server starting
LOG:  
        ** EnterpriseDB Dynamic Tuning Agent ********************************************
         *       System Utilization: 66 %                                               
*        *         Database Version: 9.1.2.2                                             
*        * Operating System Version:                                                     
*        *     Number of Processors: 0                                                  
*        *           Processor Type:                                                     
*        *   Processor Architecture:                                                     
*        *            Database Size: 0.1    GB                                           
*        *                      RAM: 1.0    GB                                           
*        *            Shared Memory: 1011   MB                                           
*        *       Max DB Connections: 104                                                 
*        *               Autovacuum: on                                                  
*        *       Autovacuum Naptime: 60   Secnds                                        
*        *            InfiniteCache: off                                                      
*        *    InfiniteCache Servers: 0                                                   
*        *       InfiniteCache Size: 0.000  GB                                           
*       ***********************************************************************
-bash-3.2$ LOG:  loaded library "$libdir/dbms_pipe"
LOG:  loaded library "$libdir/edb_gen"
LOG:  loaded library "$libdir/plugins/plugin_debugger"
LOG:  loaded library "$libdir/plugins/plugin_spl_debugger"
LOG:  database system was interrupted; last known up at 2012-11-14 12:10:38 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  consistent recovery state reached at 0/20FA714
LOG:  record with zero length at 0/20FA714
LOG:  redo is not required
LOG:  
         ** EnterpriseDB Dynamic Tuning Agent ********************************************
         *       System Utilization: 66 %                                                
*        *         Database Version: 9.1.2.2                                             
*        * Operating System Version:                                                     
*        *     Number of Processors: 0                                                   
*        *           Processor Type:                                                     
*        *   Processor Architecture:                                                     
*        *            Database Size: 0.1    GB                                           
*        *                      RAM: 1.0    GB                                           
*        *            Shared Memory: 1011   MB                                           
*        *       Max DB Connections: 104                                                 
*        *               Autovacuum: on                                                  
*        *       Autovacuum Naptime: 60   Secnds                                        
*        *            InfiniteCache: off                                                 
*        *    InfiniteCache Servers: 0                                                   
*        *       InfiniteCache Size: 0.000  GB                                           
*        ****************************************************************************
LOG:  autovacuum launcher started
LOG:  database system is ready to accept connections

3）首先你需要了解PostgreSQL如何處理日誌檔案，pg_xlog和歸檔日誌

pg_xlog 是 PostgreSQL 日誌檔案資料夾，用於儲存所有資料歷史記錄。它位於 /u02/data1/pg_xlog。
當使用者插入、更新或刪除一條記錄時，所有事務歷史記錄將自動建立或附加到 pg_xlog 資料夾下的檔案日誌檔案。
日誌檔案格式如下 000000010000000000000001 -> 000000100000000000000006
每個日誌檔案可以處理大約16M的資料，當超過此限制時，它會自動建立一個新的日誌檔案，檔名遵循0-9和AZ

0000000100000000000000001 
.. 
.. 
000000010000000000000009 
.. 
.. 
00000001000000000000000A 
.. 
.. 
00000001000000000000000Z

例如，

[root@asmhost pg_xlog]# ls -lsh
總計 33M 
 17M -rw------- 1 enterprisedb enterprisedb 16M 11月14日 12:28 000000010000000000000002 
 17M -rw------- 1 enterprisedb enterprisedb 16M 11月9日 14:55 0000000100000000000000003 
4.0K drwx------ 2 enterprisedb enterprisedb 4.0K 11月9日 12:20 archive_status

這是我們將用作前滾 PostgreSQL 時間點恢復的日誌檔案。
在 postgresql.conf 檔案中配置 WAL 檔案路徑：-

-bash-3.2$ ./psql -p 5445 sssdb

 sssdb=# show archive_command;
             archive_command             
-----------------------------------------
 cp %p /u02/ssslocation/pgpitr/walbkp/%f
(1 row)

sssdb=# show archive_mode;
  archive_mode 
 --------------
   on
(1 row)

這意味著當 pg_xlog 資料夾增長到某個限制時，比如 6 個日誌檔案每個包含 16M，當 PostgreSQL 嘗試插入新的歷史記錄並檢測到 pg_xlog 已滿時，它將自動存檔最舊的歷史日誌檔案並將其移動到 /u02/ssslocation/pgpitr/walbkp/ 資料夾。
我們必須不斷地備份這些存檔檔案（這就是為什麼它被稱為增量備份）。我們不再需要進行完整的資料庫備份，但我們會不斷備份那些存檔日誌檔案。

重要日誌檔案資料夾

[root@asmhost pg_xlog]# pwd 
/u02/data1/pg_xlog 
/u02/ssslocation/pgpitr/walbkp/ 
/u02/ssslocation/pgpitr/databkp

4）資料模擬和備份過程
建立虛擬表和記錄 - 我們將在新表中動態記錄，1000k 條記錄將強制 PostgreSQL 在 pg_xlog 資料夾中建立足夠的日誌檔案，並觸發存檔過程將日誌檔案從 /u02/data1/pg_xlog 存檔到 /u02/ssslocation/pgpitr/walbkp，每個日誌檔案包含大約 16M 大小的檔案。

sssdb=# create table test_1 as select * from pg_class;
SELECT 456
 
sssdb=# select * from current_timestamp;
        current_timestamp         
----------------------------------
 14-NOV-12 12:36:23.264212 +05:30
(1 row)

sssdb=# create table test_2 as select * from pg_description;
SELECT 3534

sssdb=# create table test_3 as select * from pg_description;
SELECT 3534

sssdb=# create table test_4(id number);
CREATE TABLE
 
sssdb=# select * from current_timestamp;
        current_timestamp         
----------------------------------
 14-NOV-12 12:46:00.076725 +05:30
(1 row)
 
sssdb=# insert into test_4 values(generate_series(100000,10000000));
INSERT 0 990000
 
sssdb=# select * from current_timestamp;
        current_timestamp         
----------------------------------
 14-NOV-12 12:51:42.144344 +05:30
(1 row)

Log files look like following
[root@asmhost pg_xlog]# cd /u02/ssslocation/pgpitr/walbkp
[root@asmhost walbkp]# ls
000000010000000000000002  00000001000000000000000F  00000001000000000000001C
000000010000000000000003  000000010000000000000010  00000001000000000000001D
000000010000000000000004  000000010000000000000011  00000001000000000000001E
000000010000000000000005  000000010000000000000012  00000001000000000000001F
000000010000000000000006  000000010000000000000013  000000010000000000000020
000000010000000000000007  000000010000000000000014  000000010000000000000021
000000010000000000000008  000000010000000000000015  000000010000000000000022
000000010000000000000009  000000010000000000000016  000000010000000000000023
00000001000000000000000A  000000010000000000000017  000000010000000000000024
00000001000000000000000B  000000010000000000000018  000000010000000000000025
00000001000000000000000C  000000010000000000000019  000000010000000000000026
00000001000000000000000D  00000001000000000000001A  000000010000000000000027
00000001000000000000000E  00000001000000000000001B

[root@asmhost walbkp]# pwd
/u02/ssslocation/pgpitr/walbkp
 
[root@asmhost walbkp]# ls
000000010000000000000002  00000001000000000000000F  00000001000000000000001C
000000010000000000000003  000000010000000000000010  00000001000000000000001D
000000010000000000000004  000000010000000000000011  00000001000000000000001E
000000010000000000000005  000000010000000000000012  00000001000000000000001F
000000010000000000000006  000000010000000000000013  000000010000000000000020
000000010000000000000007  000000010000000000000014  000000010000000000000021
000000010000000000000008  000000010000000000000015  000000010000000000000022
000000010000000000000009  000000010000000000000016  000000010000000000000023
00000001000000000000000A  000000010000000000000017  000000010000000000000024
00000001000000000000000B  000000010000000000000018  000000010000000000000025
00000001000000000000000C  000000010000000000000019  000000010000000000000026
00000001000000000000000D  00000001000000000000001A  000000010000000000000027
00000001000000000000000E  00000001000000000000001B

[root@asmhost walbkp]# cd /u02/data1/pg_xlog
[root@asmhost pg_xlog]# pwd
/u02/data1/pg_xlog

[root@asmhost pg_xlog]# ls
000000010000000000000002  000000010000000000000010  00000001000000000000001E
000000010000000000000003  000000010000000000000011  00000001000000000000001F
000000010000000000000004  000000010000000000000012  000000010000000000000020
000000010000000000000005  000000010000000000000013  000000010000000000000021
000000010000000000000006  000000010000000000000014  000000010000000000000022
000000010000000000000007  000000010000000000000015  000000010000000000000023
000000010000000000000008  000000010000000000000016  000000010000000000000024
000000010000000000000009  000000010000000000000017  000000010000000000000025
00000001000000000000000A  000000010000000000000018  000000010000000000000026
00000001000000000000000B  000000010000000000000019  000000010000000000000027
00000001000000000000000C  00000001000000000000001A  000000010000000000000028
00000001000000000000000D  00000001000000000000001B  archive_status
00000001000000000000000E  00000001000000000000001C
00000001000000000000000F  00000001000000000000001D

5）建立完整資料庫備份 - 基礎備份

sssdb=# select pg_start_backup('Full backup');
 pg_start_backup 
-----------------
 0/29000020
(1 row)

pg_start_backup 用於建立標籤，並將其記錄到日誌檔案中。（實際上這是可選的，好習慣）
使用 tar 命令壓縮所有 pgDataPITR 資料夾以製作資料庫基礎備份。

[root@asmhost databkp]# pwd 
/u02/ssslocation/pgpitr/databkp 
[root@asmhost databkp]# tar -cvzf basebkp.tar.gz /u02/data1/   #打包整個資料目錄，不需要停機
[root@asmhost databkp]# ls 
basebkp.tar.gz

basebkp.tar.gz 這是完整的資料庫備份（基礎備份），包括 Postgresql 配置、系統和所有其他檔案和資料夾。
pg_stop_backup() 也在日誌檔案中建立一個標籤。（實際上這是可選的，好習慣）

sssdb=# select pg_stop_backup();
注意：pg_stop_backup 完成，所有必需的 WAL 段都已歸檔
 pg_stop_backup 
---------------- 
 0/29000144 
(1 行)

6) 準備時間點恢復
pg_start_backup() 和 pg_stop_backup() 備份標籤將在 0000000100000000000000029.00000020.backup 檔案中建立。在這裡建立標籤是一個好習慣。

[root@asmhost pg_xlog]# pwd 
/u02/data1/pg_xlog 

[root@asmhost pg_xlog]# cat 000000010000000000000029.00000020.backup
開始 WAL 位置：0/29000020 (file 000000010000000000000029)
停止 WAL 位置：0/29000144 (file 0000000100000000000000029)
檢查點位置：0/29000050
備份方法：pg_start_backup
開始時間：2012-11-14 12:57:05 IST
標籤：完整備份
停止時間： 2012-11-14 13:04:17 IST

[root@asmhost pg_xlog]# ls -l|wc -l 
43 

[root@asmhost pg_xlog]# cd /u02/ssslocation/pgpitr/walbkp/ 
[root@asmhost walbkp]# echo *.backup 
000000010000000000000029.00000020.backup 

[root@asmhost walbkp]# cat 000000010000000000000029.00000020.backup 
START WAL 位置：0/29000020 (file 0000000100000000000000029) 
STOP WAL 位置：0/29000144 (file 000000010000000000000029）
檢查點位置：0/29000050
備份方法：pg_start_backup
開始時間：2012-11-14 12:57:05 IST
標籤：完整備份
停止時間：2012-11-14 13:04:17 IST 

[root@asmhost walbkp]# ls -l|wc -l 
42

7）表 test_5、test_6 建立時間通知——準備進行時間點恢復 #建立測試表

sssdb=# create table test_5(id number(8));
CREATE TABLE
sssdb=# insert into test_5 values(generate_series(1,1000000));
INSERT 0 1000000
sssdb=# insert into test_5 values(generate_series(1,1000000));
INSERT 0 1000000
 
sssdb=# select * from current_timestamp;
        current_timestamp         
----------------------------------
 14-NOV-12 13:13:54.047576 +05:30
(1 row)

sssdb=# create table test_6(id number(8));
CREATE TABLE

sssdb=# select * from current_timestamp;
        current_timestamp         
----------------------------------
 14-NOV-12 13:14:34.626699 +05:30
(1 row)

sssdb=# create table test_7(id number(8));
CREATE TABLE
sssdb=# insert into test_6 values(generate_series(1,1000000));
INSERT 0 1000000
sssdb=# insert into test_7 values(generate_series(1,10000000));
INSERT 0 10000000

[root@asmhost walbkp]# pwd
/u02/ssslocation/pgpitr/walbkp
[root@asmhost walbkp]# ls -l|wc -l
91

[root@asmhost walbkp]# cd /u02/data1/pg_xlog
[root@asmhost pg_xlog]# ls -l|wc -l
53

在繼續之前，請先研究一下 PostgreSQL 生成的上述事務日誌檔案移動。我們必須充分了解 PostgreSQL 何時建立新日誌檔案以及何時將其移動到存檔資料夾，不要忘記日誌檔案格式 :) ~ 花點時間回顧並理解上述日誌檔案生成順序

sssdb=# select table_name, status from user_tables;
 table_name | status 
------------+--------
 TEST_1     | VALID # created time   14-NOV-12 12:36:23
 TEST_2     | VALID # created time   14-NOV-12 12:46:00
 TEST_3     | VALID # created time
 TEST_4     | VALID # created time   14-NOV-12 12:51:42
 TEST_5     | VALID     # created time   14-NOV-12 13:13:54
 TEST_6     | VALID # created time   14-NOV-12 13:14:34
 TEST_7     | VALID # created time   14-NOV-12 14:07:40
(7 rows)

8)災難來襲
我們必須採取一些措施來讓我們的 PostgreSQL 伺服器癱瘓。

sssdb=# select * from current_timestamp;
        current_timestamp        
---------------------------------
 14-NOV-12 14:07:40.00999 +05:30
(1 row)

sssdb=# select * from current_timestamp;
        current_timestamp        
---------------------------------
 14-NOV-12 14:07:40.00999 +05:30
(1 row)

--Kill the postgresql process
[root@asmhost ~]# ps -ef|grep data1
506       6536     1  0 12:28 pts/1    00:00:00 /opt/PostgresPlus/9.1AS/bin/edb-postgres -D /u02/data1
root      9542  6101  0 14:21 pts/3    00:00:00 grep data1

[root@asmhost ~]# kill -9 $(head -1 /u02/data1/postmaster.pid)

[root@asmhost ~]# ps -ef|grep data1
root      9680  6101  0 14:24 pts/3    00:00:00 grep data1

9）恢復過程 的步驟 最後我們進入恢復過程，請記住1個檔案和2個資料夾

基礎備份檔案 /u02/ssslocation/pgpitr/databkp/basebkp.tar.gz
日誌檔案尚未歸檔 - /u02/data1/pg_xlog （Pg_xlog 資料夾下的所有檔案）
WALs – /u02/ssslocation/pgpitr/walbkp （資料夾下的所有存檔檔案在真實環境中可能是遠端儲存）

步驟1.將data1重新命名為olddata1.bad.data，假設data1資料夾中的資料庫檔案由於我們剛才建立的災難而損壞，我們需要稍後建立一個新的資料庫。

[root@asmhost u02]# mv data1 olddata1.bad.data 
[root@asmhost u02]# ls 
admin data lost+found spl_bkp ssslocation sssw.csv tbs1 
app olddata1.bad.data oradata sss.csv sssnew.csv tbs 

[root@asmhost u02]# pwd 
/u02 
[root@asmhost u02]# mkdir data1 
[root@asmhost u02]# ls -l|grep data1 
drwxr-xr-x 2 root root 4096 Nov 14 14:38 data1 
drwx------ 14 enterprisedb enterprisedb 4096 Nov 14 13:04 data1.bad.data --更改所有者許可權
[root@asmhost u02]# chown enterprisedb:enterprisedb資料1 / 
[root@asmhost u02]# ls -l|grep 資料1 
drwxr-xr-x 2 enterprisedb enterprisedb 4096 11月14日 14:38 資料1 
drwx------ 14 enterprisedb enterprisedb 4096 11月14日 13:04 資料1.bad.dat

step2.解壓/提取檔案 basebkp.tar，在下建立一個新的 data1 資料夾，就像我們之前所做的一樣。將所有提取的檔案從當前位置移動到 /u02/data1

[root@asmhost pgpitr]# pwd 
/u02/ssslocation/pgpitr 

[root@asmhost pgpitr]# cd databkp/ 
[root@asmhost databkp]# ls 
basebkp.tar.gz 

[root@asmhost databkp]# mv /u02/data1

步驟3.啟動資料庫 #直接啟動基礎備份

-bash-3.2$ ./pg_ctl start -D /u02/data1 
pg_ctl: 另一臺伺服器可能正在執行；嘗試啟動伺服器 無論如何
伺服器啟動
-bash-3.2$ LOG：   
         ** EnterpriseDB 動態最佳化代理 ******************************************** 
         * 系統利用率：66%                                                 
* * 資料庫版本：9.1.2.2                                              
* * 作業系統版本：                                                      
* * 處理器數量：0                                                    
* * 處理器型別：                                                      
* * 處理器架構：*                                                      
* 資料庫大小：0.1 GB                                            
* * RAM：1.0 GB                                            
* * 共享記憶體：1011 MB                                            
* * 最大 DB 連線數：104                                                  
* * 自動清理：開啟                                                  
* * 自動清理休息時間：60 秒                                        
* * InfiniteCache：關閉                                                 
* * InfiniteCache 伺服器：0                                                    
* * InfiniteCache 大小：0.000 GB                                            
* ***************************************************************************** 
LOG：已載入庫“$libdir/dbms_pipe” 
LOG：已載入庫“$libdir/edb_gen” 
LOG：已載入庫“$libdir/plugins/plugin_debugger”
日誌：已載入庫“$libdir/plugins/plugin_spl_debugger”
日誌：** EnterpriseDB 動態最佳化代理 ******************************************** 

         * 系統利用率：66%                                                 
* * 資料庫版本：9.1.2.2                                              
* * 作業系統版本：                                                      
* * 處理器數量：0                                                   
* * 處理器型別：                                                      
* * 處理器架構：                                                     
* * 資料庫大小：0.5 GB                                            
* * RAM：1.0 GB                                            
* * 共享記憶體：1011 MB                                            
* * 最大 DB 連線數：104                                                  
* * 自動清理：開啟                                                  
* * 自動清理休息時間：60 秒                                        
* * InfiniteCache：關閉                                                 
* * InfiniteCache 伺服器：0                                                    
* * InfiniteCache 大小：0.000 GB                                            
* ***************************************************************************** 
LOG：資料庫系統已中斷；最後一次啟動的時間為 2012-11-14 12:57:05 IST 
LOG：資料庫系統未正確關閉；自動恢復正在進行中
LOG：在 0/29000050 達到一致恢復狀態
LOG：在 0/29000020 開始重做
LOG：在 0/290000A0 記錄長度為零
LOG：在 0/29000050 完成重做
LOG：自動清理啟動器已啟動
LOG：資料庫系統已準備好接受連線

-bash-3.2$ pwd 
/opt/PostgresPlus/9.1AS/bin 
-bash-3.2$ ./psql -p 5445 sssdb 
psql (9.1.2.2)
鍵入“help”獲取幫助
。sssdb=# select * from user_tables; 
    owner | schemaname | table_name | table_space | status 
--------------+------------+------------+------------+-------- 
 ENTERPRISEDB | PUBLIC | TEST_1 | | VALID 
 ENTERPRISEDB | PUBLIC | TEST_2 | | VALID 
 ENTERPRISEDB | PUBLIC | TEST_3 | | VALID 
 ENTERPRISEDB | PUBLIC | TEST_4 | | VALID 
(4 行)

直到恢復表 test_4。此 testPITR1 表是在啟動基礎備份過程之前建立的，因此這是正確的。
步驟 4. 從 pg_xlog 資料夾複製日誌檔案。災難發生時，一些日誌檔案仍位於 pgDataPITR.bad.data pg_xlog 資料夾中（這些日誌檔案尚未存檔），我們需要將日誌檔案複製回來並儘可能恢復它。

[root@asmhost pg_xlog]# pwd 
/u02/olddata1.bad.data/pg_xlog 
[root@asmhost pg_xlog]# cp -R 000* /u02/data1/pg_xlog/

步驟5. 建立一個recovery.conf檔案並將其放在/u02/data1/下

vi recovery.conf 
restore_command = 'cp /u02/ssslocation/pgpitr/walbkp/%f %p'   #歸檔檔案複製過來，未歸檔的wal日誌檔案前面已經手動複製過來
recovery_target_time = '14-NOV-12 13:14:34'

這是最後的過程，也是最關鍵的備份過程

/usr/local/pgsql/pgbackup/wals/ 是我們備份存檔日誌檔案的資料夾
recovery_target_time 是我們需要恢復到的時間。省略此設定將使 PostgreSQL 儘可能地恢復，它可能會恢復所有更改。

-bash-3.2$ ./pg_ctl stop -D /u02/data1 -mi 
LOG：收到立即關閉請求
警告：由於另一個伺服器程序崩潰而終止連線
詳細資訊：郵政局長已命令此伺服器程序回滾當前事務並退出，因為另一個伺服器程序異常退出並可能損壞共享記憶體。
提示：您稍後應該能夠重新連線到資料庫並重復您的命令。
等待伺服器關閉...完成
伺服器已停止
-bash-3.2$ ./pg_ctl start -D /u02/data1
伺服器正在啟動
-bash-3.2$ LOG：   
 
        ** EnterpriseDB 動態最佳化代理 ******************************************** 
         * 系統利用率：66%                                                 
* * 資料庫版本：9.1.2.2                                             
* * 作業系統版本：                                                      
* * 處理器數量：0                                                    
* * 處理器型別：                                                      
* * 處理器架構：                                                      
* * 資料庫大小：0.1 GB                                            
* * RAM：1.0 GB                                            
* * 共享記憶體：1011 MB                                            
* * 最大 DB 連線數：104                                                  
* * 自動清理：開啟                                                  
* * 自動清理休息時間：60 秒                                        
* * InfiniteCache：關閉                                                 
* * InfiniteCache 伺服器：0                                                    
* * InfiniteCache 大小：0.000 GB                                            
* ************************************************************************************ 
LOG：已載入庫“$libdir/dbms_pipe”
日誌：已載入庫“$libdir/edb_gen”
日誌：已載入庫“$libdir/plugins/plugin_debugger”
日誌：已載入庫“$libdir/plugins/plugin_spl_debugger”
日誌：資料庫系統已中斷；最後一次已知時間為 2012-11-14 14:52:03 IST
日誌：** EnterpriseDB 動態最佳化代理 ********************************************
         * 系統利用率：66%                                                 
* * 資料庫版本：9.1.2.2                                              
* * 作業系統版本：                                                      
* * 處理器數量：0                                                    
* * 處理器型別：                                                      
* * 處理器架構：                                                      
* * 資料庫大小：0.5 GB                                            
* * RAM：1.0 GB                                            
* * 共享記憶體：1011 MB                                            
* * 最大 DB 連線數：104                                                  
* * 自動清理：開啟                                                  
* * 自動清理時間：60 秒                                        
* * InfiniteCache：關閉                                                 
* * InfiniteCache 伺服器：0                                                    
* * InfiniteCache 大小：0.000 GB                                            
* ******************************************************************************** 
LOG：開始將時間點恢復至 2012-11-14 13:14:34+05:30 
LOG：從存檔中恢復日誌檔案“0000000100000000000000029”
日誌：主檢查點記錄中的資源管理器 ID 無效
日誌：在 0/29000050 使用上一個檢查點記錄
日誌：在 0/290000A0 達到一致恢復狀態
日誌：重做從 0/29000020 開始
日誌：從存檔中還原
了日誌檔案“00000001000000000000002A” 日誌：從存檔中還原了日誌檔案“00000001000000000000002B”
日誌：從存檔中還原了日誌檔案“00000001000000000000002C” 日誌
：從存檔中還原了日誌檔案“00000001000000000000002D”
日誌：從存檔中還原了日誌檔案“00000001000000000000002E”
日誌：還原了日誌檔案來自存檔日誌的“00000001000000000000002F” 
：來自存檔日誌的已還原日誌檔案“000000010000000000000030” 
：來自存檔日誌的已還原日誌檔案“000000010000000000000031” 
：恢復在提交事務 2237 之前停止，時間 2012-11-14 13:14:38.881279+05:30
日誌：重做完成於 0/31A76348
日誌：最後完成的事務記錄時間為 2012-11-14 13:14:17.399818+05:30
cp：無法統計“/u02/ssslocation/pgpitr/walbkp/00000002.history”：沒有此檔案或目錄
LOG：選定的新時間線 ID：2 
cp：無法統計“/u02/ssslocation/pgpitr/walbkp/00000001.history”：沒有此檔案或目錄
LOG：存檔恢復完成
LOG：資料庫系統已準備好接受連線
LOG：自動真空啟動器已啟動

上述 recovery.conf 檔案將使 PostgreSQL 從 /usr/local/pgsql/pgbackup/wals/ 資料夾中獲取存檔日誌檔案並恢復截至 2012 年 11 月 14 日 13:14:34 （表 test_6 建立）的資料更改。

-bash-3.2$ ./psql -p 5445 sssdb 
psql (9.1.2.2)
鍵入“help”獲取幫助

。sssdb=# select * from user_tables; 
    owner | schemaname | table_name | table_space | status 
--------------+------------+------------+-------------+-------- 
 ENTERPRISEDB | PUBLIC | TEST_1 | | VALID 
 ENTERPRISEDB | PUBLIC | TEST_2 | | VALID 
 ENTERPRISEDB | PUBLIC | TEST_3 | | VALID 
 ENTERPRISEDB | PUBLIC | TEST_4 | | VALID 
 ENTERPRISEDB | PUBLIC | TEST_5 | | VALID 
 ENTERPRISEDB | PUBLIC | TEST_6 | | VALID                              
(6 行)

表 testpitr2 已恢復。
PS恢復過程完成後，PostgreSQL 將把 recovery.conf 重新命名為 recovery.done，以避免再次啟動恢復過程。
我們可以檢視pg.log檔案來了解PostgreSQL如何處理恢復過程。
這是一個一次性過程，恢復過程開始和結束後，我們不能做任何恢復更改（比如前滾到另一個時間）。#詳細原理待補充

如果我們想要前滾到另一個恢復時間，我們需要重新啟動整個恢復過程，例如從基礎備份中提取檔案並複製日誌檔案。這是因為在 PostgreSQL 恢復資料後，所有日誌檔案格式都將更改為其他格式，如下所示

[root@asmhost data1]# cat recovery.done 
restore_command = 'cp /u02/ssslocation/pgpitr/walbkp/%f %p' 
recovery_target_time = '14-NOV-12 13:14:34' 
[root@asmhost data1]#

PostgreSQL啟動恢復期間，恢復到的時間線的確定
2018-08-12
SQL
postgreSQL 恢復至故障點精準恢復
2019-01-01
SQL
PostgreSQL12中實現增量備份與任意時間點恢復
2024-08-05
SQL
《PostgreSQL 指南：內幕探索》之基礎備份與時間點恢復（上）
2019-06-26
SQL
mongodb 基於oplog的時間點恢復
2019-12-03
MongoDB
DM8 基於時間點的恢復
2021-06-07
備份與恢復：Polardb資料庫資料基於時間點恢復
2020-11-12
資料庫
mongodb使用備份後的oplog做時間點恢復
2024-04-28
MongoDB
7.5 使用binary log 做基於時間點的恢復
2020-10-21
使用NineData構建任意時間點（PITR）資料恢復能力
2023-03-24
資料恢復
win10恢復到上一個時間節點的方法
2021-03-01
Win10
mongodb異機做時間點恢復(基於時間範圍查詢匯出oplog)
2024-04-28
MongoDB
ORACLE資料庫基於時間點的不完全恢復
2019-05-01
Oracle資料庫
Postgresql 備份與恢復
2018-04-08
SQL
DM7使用DMRMAN恢復資料庫到指定時間點/LSN
2020-12-11
資料庫
MySQL binlog基於時間點恢復資料失敗是什麼鬼？
2019-08-02
MySql
2.MongoDB 4.2副本集環境基於時間點的恢復
2020-08-18
MongoDB
PostGreSql12.6的備份恢復
2021-04-14
SQL
基於percona xtrabackup之innobackupex實現基於時間點資料庫恢復
2019-11-05
資料庫
win10恢復到上一個時間節點的檔案還在嗎
2021-03-01
Win10
PostgreSQL 插入時間與更新時間（qbit）
2022-12-01
SQL
大事務導致資料庫恢復時間長
2023-10-23
資料庫
Oracle & MySQL & PostgreSQL資料庫恢復支援
2021-11-22
OracleMySql資料庫
postgresql備份與恢復資料庫
2020-12-15
SQL資料庫
Prometheus 告警恢復時，怎麼獲取恢復時的值？
2024-08-29
Prometheus
通過事務日誌恢復SqlServer資料庫到一個特定的時間點
2019-01-08
SQLServer資料庫
1.MongoDB 2.7主從複製(master –> slave)環境基於時間點的恢復
2020-08-17
MongoDBAST
教你一招，告警恢復時如何拿到恢復時的值？
2024-06-12
PostgreSQL從小白到高手教程 - 第41講：postgres表空間備份與恢復
2024-01-12
SQL
PostgreSql資料庫的備份和恢復
2021-04-17
SQL資料庫
Oracle RMAN 表空間恢復
2021-07-11
Oracle
PostgreSQL/Oracle 時間改成秒
2022-07-27
SQLOracle
教你一招，告警恢復時如何拿到恢復時的值？合
2024-06-27
(Les16 執行資料庫恢復)-表空間恢復
2018-05-22
資料庫
PostgreSQL備份恢復管理器pg_probackup
2024-04-06
SQL
表空間TSPITR恢復-實驗
2022-08-02
【Oracle 恢復表空間】實驗
2022-08-06
Oracle
PostgreSQL自動更新時間戳
2021-12-16
SQL時間戳

PostgreSQL 時間點恢復

相關文章