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

標籤：

3.3 做基礎備份

在上一節中，您已經看到，啟用歸檔只需要幾行命令，並提供了極大的靈活性。在本節，我們將看到如何建立一個所謂的基礎備份，稍後這可以使用XLOG。一個基本備份是一個最初的資料的拷貝。

[請記住，XLOG本身是沒有什麼價值的。只是在和初始備份聯合起來的時候是有用的。]

在PostgreSQL中，有兩個主要的選擇來建立一個初始的基本備份：

• 使用 pg_basebackup

• 傳統的基於 copy/rsync 的方法

下面兩節將詳細地介紹如何建立一個基礎備份：

使用pg_basebackup

第一個也最常見的建立一個現有的伺服器備份是運行一個稱為 pg_basebackup 的命令，該命令在PostgreSQL 9.1.0 被引入。基本上，pg_basebackup 能夠直接通過一個資料庫連接擷取一個資料庫基本備份。但在slave上執行時，pg_basebackup 會串連到一個您選擇的資料庫伺服器，並複製資料目錄中的所有資料檔案到您的機器。沒有必要再登陸到伺服器，它所需要的只有一行代碼並運行它；pg_basebackup 將為您做所有剩餘的工作。

在這個例子中，我們將假設我們要對一個稱為 postgresql-support.de 的主機做一個基礎備份。必須執行以下幾步：

• 修改 pg_hba.conf  以允許複製

• 給 master 發訊號考慮 pg_hba.conf 的變化

• 調用 pg_basebackup

修改pg_hba.conf

為了允許遠程伺服器登入到一個PostgreSQL 伺服器，並允許流傳送 XLOG，您必須明確地允許複製。

在PostgreSQL中，有一個成為pg_hba.conf 的檔案，它告訴伺服器允許哪台伺服器使用哪種類型的憑據來串連。可以允許整個IP位址範圍或者乾脆通過pg_hba.conf 丟棄。

要啟用複製，我們必須為我們希望允許的IP位址範圍增加一行。

以下列表包含一個有效配置的例子：

# TYPE DATABASE USER ADDRESS METHOD

host replication all 192.168.0.34/32 md5

在這個例子中，我們允許複製從192.168.0.34 串連。IP 位址範圍使用32位來確定(這僅僅代表我們的例子)。我們決定使用MD5作為認證方法。這意味著pg_basebackup 必須給伺服器提供一個密碼。如果您在一個安全要求不高的環境中使用trust 作為認證方法可能也是一中選擇。

[ 如果您真的有一個稱為replication的資料庫在您的系統中會發生什嗎？基本上，設定資料庫為複製只會配置您流行為，如果您要為處理資料庫名為replication的資料庫引入規則，您必須引用資料庫名如下：“replication”。然而，我們強烈建議不要這樣做一避免混淆。]

向master伺服器發送訊號

一旦對pg_hba.conf做了改變，我們就可以告訴PostgreSQL重新載入配置。沒有必要完全重新啟動資料庫。我們有三個選擇來重新載入pg_hba.conf:

• 通過運行SQL命令：SELECT pg_reload_conf();

• 通過給master 發送一個訊號： kill –HUP 4711 (4711為master的進程ID)

• 通過調用 pg_ctl: pg_ctl –D $PGDATA reload ($PGDATA 是您的資料庫執行個體的home 目錄)

一旦我們告訴伺服器作為資料來源接受流串連，我們可以繼續運行pg_basebackup。

pg_basebackup-準系統

對於PostgreSQL來說，pg_basebackup 是一個非常易用的命令列工具。它必須由目標系統調用，並為您提供一個準備使用的基礎備份，它準備為即時恢複消耗交易記錄。

pg_basebackup 的文法如下：

iMac:dbhs$ pg_basebackup --help

pg_basebackup takes a base backup of a running PostgreSQL server.

Usage:

pg_basebackup [OPTION]...

Options controlling the output:

-D, --pgdata=DIRECTORY receive base backup into

directory

-F, --format=p|t output format (plain (default),

tar)

-x, --xlog include required WAL files in

backup (fetch mode)

-X, --xlog-method=fetch|stream

include required WAL files with

specified method

-z, --gzip compress tar output

-Z, --compress=0-9 compress tar output with given

compression level

General options:

-c, --checkpoint=fast|spread

set fast or spread checkpointing

-l, --label=LABEL set backup label

-P, --progress show progress information

-v, --verbose output verbose messages

-V, --version output version information, then exit

-?, --help show this help, then exit

Connection options:

-h, --host=HOSTNAME database server host or

socket directory

-p, --port=PORT database server port number

-s, --status-interval=INTERVAL

time between status packets sent to server (in seconds)

-U, --username=NAME connect as specified database

user

-w, --no-password never prompt for password

-W, --password force password prompt (should

happen automatically)

一個基本的pg_basebackup 如下：

iMac:dbhs$ pg_basebackup -D /target_directory \

-h sample.postgresql-support.de

在這個例子中，我們將從sample.postgresql-support.de擷取基礎備份，並把它放入我們的本地目錄/target_directory。它需要這一行來複製整個資料庫執行個體到目標系統。當我們建立一個基礎備份是，如本節所示，pg_basebackup將串連到伺服器並在實際進程開始之前等待一個檢查點發生。這是必須的，因為重放進程將在XLOG的該點啟動。問題是，等到一個檢查點發生需要一段時間，pg_basebackup 不強制直接在原始伺服器上做檢查點，以確保正常操作不受幹擾。

[如果您不想等待一個檢查點，可以考慮使用—checkpoint=fast。它會強制立即執行一個檢查點，並且pg_basebackup將立即開始複製。]

預設情況下，一個基本的基礎備份將被建立。它將包括能在原始伺服器目錄中找到的所有檔案。如果基礎備份要儲存到磁帶上，我們建議使用 –format=t。他將自動建立一個TAR 歸檔(也許在磁帶上)。如果您要將資料轉移到磁帶上，您可以可以容易的省去中間步驟。當使用TAR時，和—gzip一起使用，以減少磁碟上基礎備份的大小是非常有益處的。

[還有一種方式，在做基礎備份是看進度條，但是我們不推薦使用這個選項(--progress)，因為它需要pg_basebackup來首先確定源執行個體的大小，這可能是昂貴的。]

pg_basebackup-自給自足的備份

一般情況下，沒有XLOG的基礎備份是沒有用的。這是因為基本備份是從完全正常啟動並執行master取的。儘管採取了基礎備份，那些在資料庫執行個體中儲存的檔案可能基因被嚴重修改了。XLOG的目的是為瞭解決那些依賴的資料檔案的潛在的問題。但是，如果我們要建立一個基礎備份，它可以沒有(明確歸檔的)XLOG？在這種情況下，我們可以使用—xlog-method=stream 選項。如果這個選項已被選定，pg_basebackup 將不只是複製資料，它也將流在我們為我們的目的伺服器建立基礎備份期間被建立的XLOG。這將為我們提供足夠的XLOG允許我們直接啟動使用那種方式做的基礎備份。它是自給自足的，並且不需要額外的XLOG檔案。這不針對即時恢複，但它可以在有麻煩的情況下派上用場。有一個可以馬上啟動的基礎備份通常是一件好事，並且它的成本相當低。

[請注意，--xlog-method=stream將需要資料庫連接到原始伺服器，不只是一個。當在原始伺服器上調整max_wal_senders 時，您必須記住這一點。]

如果您計劃使用即時恢複，並且不需要啟動備份，您可以放心地跳過XLOG並節省一些空間(預設模式)。

利用傳統的方法來建立基礎備份

現在 pg_basebackup 是獲得一個資料庫伺服器的初始副本最常用的方法。這並非總是如此。傳統上，一個不同的方法已被使用，工作如下：

• 調用 SELECT pg_start_backup(‘some label‘);

• 通過 rsync 或者任何其它方法複製所有資料檔案到遠程伺服器

• 運行 SELECT pg_stop_backup();

這個老方法的主要優勢是，不需要開啟資料庫連接，不需要在原始伺服器上配置XLOG流基礎設施。

另一個主要的優勢的您可以使用一些例如ZFS-snapshots 或者類似的方法，這可以減少建立初始備份的I/O數量。

[一旦您已經啟動了pg_start_backup，不要著急。不需要這樣，甚至尤其不要希望離開備份模式。如果您處於備份模式，什麼都不會發生。PostgreSQL 將和往常一樣歸檔交易記錄，使用者不會有任何不利。當然，當基礎備份在運行時PostgreSQL的內部工作方式不會發生改變。沒有東西填充，沒有磁碟I/O延遲，或者任何這種事情。]

資料表空間問題

如果您碰巧使用一個以上資料表空間，pg_basebackup 會很好地處理這個問題，如果在目標伺服器的檔案系統布局和master 上的檔案系統的布局一樣。但是，如果您的目標系統沒有使用相同的檔案系統布局，還有更多的事情要做。使用傳統的方法做基礎備份可能在這種情況下會有好處。

如果您使用的是 –format=t(對於 TAR)，將會為您提供每個資料表空間一個TAR檔案。

密切關注網路頻寬

讓我們假設一個包含兩台伺服器的情境。每台伺服器可能只有一個磁碟(沒有SSD)。我們的兩台伺服器可能通過1個千兆的連結互聯。如果第二台伺服器開始運行 pg_basebackup，您的應用會發生什麼呢？第二台伺服器將串連，開始全速流資料並通過使用您的網路的全部頻寬損壞您的硬碟。在 master 上啟動並執行應用程式可能會立即面臨磁碟等待提供較高的回應時間。因此，強烈推薦通過rsync控制頻寬使用，以確保您的商業應用有足夠的備用能力(通常來說磁碟，CPU不是問題)。

[如果您要限制rsync到20MB/sec，您可以簡單地使用rsync –bwlimit=20000。這會讓基礎備份的建立花費更長的時間，但是它將確保您的用戶端應用不會面臨問題。一般我們建議一個master 和 slave 之間的專用網路互聯，以確保基礎備份不會影響正常的操作。]

限制頻寬不能使用pg_basebackup的板載功能。當然，您可以使用任何其它工具來複製資料，並實作類別似的效果。

 [如果您正在使用—gzip使用gzip壓縮，它可以作為一個減速工具來工作。但是，這主要是一種可能的變通方法。]

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