PostgreSQL Replication之第三章 理解即時恢複（1）

標籤：

到現在為止，您已經掌握了一定的理論。因為生活不僅由理論組成(它可能同樣重要)，是時候深入實際的工作了。

本章的目標是讓您明白如何恢複資料到一個給定的時間點。當您的系統崩潰或者有人意外地刪除了一個表，不重放整個交易記錄，而是重放 其中的一小部分，這是非常重要的。即時恢複(PITR，Point-In-Time-Recovery)將是做這種部分交易記錄重放的工具。

在本章中，您將學到關於即時恢複(PITR)的所有您需要知道的資訊，並且會有實際的例子來引導您。因此，我們將應用所有您已經在第二章所學習的概念，理解 PostgreSQL 交易記錄，建立增量備份或者設定一個簡單的，基本的備份系統。

下面是我們將在本章講解的主題的概述：

• 理解 PITR 背後的概念

• 配置 PostreSQL PITR

• 運行 pg_basebackup

• 恢複 PostgreSQL 到一個特定的時間點

3.1 理解PITR的作用

PostgreSQL 提供了一個可以備份一個資料庫的工具，叫做pg_dump。基本上，pg_dump 會串連到資料庫，讀取交易隔離等級“序列化”所有的資料，並把資料以文本的形式返回。由於我們使用的是“序列化”，轉儲始終保持一致。所以，如果您的pg_dump 在午夜開始，結束於上午六點。您將建立一個備份，其包含截至午夜的所有資料，但沒有進一步的資料。對從少量到中量的資料來說，這種快照建立是非常方便，並且是完全可行的。

[轉儲始終保持一致。這意味著所有的外鍵都完好無損；開始轉儲後，新添加的資料將丟失。這可能是最有可能的執行標準備份的最常見的方式。]

但是，如果您的資料是如此寶貴並且規模也是如此之大，以至於您要對它進行整理備份；對於高度關鍵的資料，它顯然不是。除此之外，以文本形式重放20TB的資料效率也不高。已經設計了即時恢複來解決這個問題。它是如何工作的呢？基於資料庫的快照，稍後，XLOG 將會被重放。這可以無限制地執行，或者到一個您選擇的時間點。通過這種方式，您可以到達任何時間點。此方法開啟了許多不同的方法和功能的大門。

• 還原資料庫執行個體到一個給定的時間點

• 建立一個備份資料庫，其中包含未經處理資料庫的副本

• 建立一個所有更改的記錄

在本章中，我們將專門研究增量備份的功能。並描述如何通過增量歸檔改變一個選擇的媒介使您的資料更安全。

3.1.1移動到架構角度

下面的圖片提供了一個使用即時恢複的通用架構圖的概貌：

我們已經在前面的章節看到PostgreSQL產生16MB的交易記錄段。每當這些段中的一個被填滿並準備就緒是，PostgreSQL將調用所謂的archive_command。archive_command 的目的是把 XLOG檔案從資料庫執行個體傳輸到存檔。在我們的圖片中，歸檔在圖片的右下角的小方框表示。

該設計的妙處在於，您基本上可以使用任意的shell指令碼來歸檔交易記錄。這裡有一些想法：

• 使用一些簡單的複製來傳輸資料到一個NFS共用

• 運行 rsync 來移動檔案

• 使用定製指令碼來校正XLOG檔案並將其移動到一個FTP伺服器

• 複製 XLOG 檔案到磁帶

可能的管理XLOG的選擇值受到想象力的限制。

restore_command 準確地與archive_command 相對應。它的作用是從歸檔擷取資料並將其提供給執行個體，這是為了重放它(在我們的圖片中，這被標記為還原備份)。正如您所看到的，如本章所述，重放可能被用於複製或者僅僅恢複一個資料庫到一個給定的時間點。同樣，restore_command 只是一個簡單的可以一個檔案一個檔案地做您所希望的事情的指令碼。

[ 作為全能的管理者的您負責歸檔是很重要的。您必須決定保持多少的XLOG，什麼時候刪除它。這項任務的重要性不能被低估。]

請記住，當由於某種原因archive_command 失敗時，PostgreSQL 將保持XLOG檔案幾秒鐘後會重新嘗試。如果歸檔從某個特定的點不斷地失敗，可能是master填滿了。XLOG檔案的順序不能被中斷；如果一個檔案丟失了，您就不能繼續重放XLOG了。所有的XLOG檔案必須存在，因為PostgreSQL需要一個序列不間斷的XLOG檔案。如果一個檔案丟失，恢複進行將停止在最新的位置。

PostgreSQL Replication之第三章 理解即時恢複（1）