PostgreSQL Replication之第十五章 與Walbouncer 一起工作

標籤：

與Walbouncer 一起工作

在本書的最後一章，將引導您通向2014年發布的一個工具，稱為walbouncer。本書中的大多數技巧說明了如何複製整個資料庫執行個體，如何分區，等等。在最後一章，是關於wabouncer的，它是所有關於過濾交易記錄流來選擇性地複製資料庫物件從一台伺服器到到一組（不一定是完全相同的）slave。

本章將涵蓋以下主題：

• walbouncer的基本概念

•安裝walbouncer

•選擇性地複製資料庫，表，和資料表空間

walbouncer 工具適用於 PostgreSQL 9.4 或者更高版本。

walbouncer 的概念

PostgreSQL交易記錄的目的是協助一個在崩潰事件中出現故障的資料庫執行個體恢複自身。它也可以用來複製 整個資料庫執行個體，正如我們在本書中關於同步複製與非同步複製的章節所討論的。

問題在於複製整個資料庫執行個體是必須的。在許多現實世界的情境中，這是一個問題。讓我們假設，有一個中心伺服器，它包含許多大學的學生學習資訊。每個大學都應該有一個資料的副本。作為PostgreSQL9.4，使用一個資料庫執行個體這是不可能的，因為流複製只具有完全複製一個資料庫的能力。運行許多執行個體顯然是非常多的工作，也許不是所期望的一套方法。

walbouncer背後的思想是串連到PostgreSQL交易記錄並過來它。在這個情境中，slave將只接收資料的一個子集，從而過濾掉可能是規則的關鍵或者一個安全點的視圖的所有資料。在我們的大學的例子中，每個大學將只會有它自己的資料庫的複製，因此，沒有辦法看到其它組織的資料。當涉及到安全系統時，隱藏資料是一個巨大的進步。對於出於分區的目的的walbouncer來說可能是一個使用情境。

顯示了這是如何工作的：

walbouncer工具是一個位於master和slave之間的一個進程。它串連到master，擷取交易記錄，並在它被傳輸到slave之前過濾它。在這個例子中，有兩個slave可以用來消耗交易記錄，就像普通slave一樣。

對地理上分布的資料庫系統來說，walbouncer工具是理想的，因為它使我們能夠很容易地決定那些資料要去哪裡，哪個資料庫需要在哪個位置。這裡展示了一個基本的方框圖：

過濾 XLOG

現在核心的問題是：walbouncer是如何過濾日誌的？記住，交易記錄的位置是非常關鍵的，在很多情況下，篡改這些交易記錄的位置是很重要的，危險的，一點都不可行的。

解決這個問題的的關鍵在於PostgreSQL的核心深處。核心知道如何處理仿製的交易記錄條目。剪下所有註定不能到達一個特定的伺服器的所有資料，仿製的XLOG被注入，代替原來的一個。現在slave可以安全地消耗XLOG了並忽略那些仿製的記錄。事實上，這種技術的妙處在於master和slave可以保持不變—不需要修補。所有的工作可以完全由walbouncer來做，它只是簡單地作為某種XLOG的代理。

所使用的技術的因果關係如下：

•每個slave將獲得相同數目的XLOG記錄，不管目標系統中實際更改的資料量

•中繼資料（系統資料表）必須被完全地複製，千萬不能被留下

•目標系統仍然會看到一個特定的資料庫應該存在，但使用它 會失敗。

最後一項特別值得注意。記住，系統無法分析特定XLOG記錄的語義；它所做的所有 是檢查它是否還需要。因此，中繼資料必須被複製。當一個slave系統嘗試讀取過濾的資料時，它將接收到一個令人討厭的錯誤，該錯誤表明資料檔案丟失。如果不能從磁碟讀檔案，則會顯示錯誤並復原。這種行為可能會使一些人跟到困惑，但這是唯一解決潛在技術問題的可能途徑。

安裝 walbouncer

walbouncer工具可以免費地從Cybertec網站下載(http://www.cybertec.at/postgresql_produkte/walbouncer/)並使用以下步驟安裝：

1.為了本書的目的，使用了下面的檔案：

wget http://cybertec.at/download/walbouncer-0.9.0.tar.bz2

2. 首先要做的事情是解壓tar包，如下：

      tar xvfj walbouncer-0.9.0.tar.bz2

3.一旦包已經被解壓，您就可以進入該目錄。在調用make之前，檢查缺失的庫是非常重要的。確保支援YAML 。在我的 CentOS測試系統中，下面的命令可以完成該工作：

[[email protected] ~]# yum install libyaml-devel

4.庫將通過這些行來安裝：

---> Package libyaml-devel.x86_64 0:0.1.4-11.el7_0 will be installed

--->Processing Dependency: libyaml = 0.1.4-11.el7_0 for package: libyaml-devel-0.1.4-11.el7_0.x86_64

5.下一步，只調用make。代碼乾淨地編譯。最後，只剩下make install：

[[email protected] walbouncer-0.9.0]# make install

cp walbouncer /usr/local/pgsql/bin/walbouncer

運行walbouncer所需要的二進位包將被複製到您的PostgreSQL二進位目錄(在我的例子中, 是 /usr/local/pgsql/).

正如您可以看到的，部署walbouncer是很容易的，並且所有它需要的是幾個命令。

配置 walbouncer

一旦代碼被成功地部署了，就必須拿出一個簡單的配置來告訴walbouncer做什麼。為了示範walbouncer是如何工作的，這裡已經建立了一個簡單的安裝程式。在這個例子中，兩個資料庫存在於master。它們中只有一個最終會在slave上：

$ createdb a

$ createdb b

目標是複製a到slave並跳過其它的。

在開始做基礎備份之前，做一個walbouncer的config備份是有意義的。一個基本的配置是非常簡單而且容易執行的：

listen_port: 5433

master:

host: localhost

port: 5432

configurations:

- slave1:

filter:

include_databases: [a]

配置有一下組件組成：

 

•listen_port：這是必要的。它定義了walbouncer使用哪個連接埠監聽。slave可以串連到這個連接埠並且直接從bouncer流傳輸交易記錄。

•master：下一節將告訴walbouncer去哪裡找到它的master。在我們的例子中，master在同一台主機上並且監聽5432連接埠。注意，沒有資料庫被列出。該系統串連到XLOG流，所以不需要資料庫資訊。

•configurations：這涵蓋了slave配置。可以列出多個slave。對於每一個slave，可以使用幾個過濾器。在這個例子中，只包含a資料庫；其餘的資料庫被過濾掉。

建立基礎備份

一旦寫完了配置，是時候複製一個初始的資料庫執行個體了。棘手的事情是，沒有pg_basebackup之類的工具，它為您做大多數的工作。原因是，pg_basebackup被設計用來複製整個資料庫執行個體。在walbouncer的例子中，思想是在目標系統上只存在部分資料。因此，使用者必須回到建立備份的基本方法。選擇的方法是執行基礎備份的傳統方法。

然而，在開始之前，準備好標準流複製的master是很重要的。這包括：

•調整 postgresql.conf (wal_level, wal_keep_segments, max_wal_ senders, 等等)

•在master上調整pg_hba.conf  

•在slave上設定資料目錄為chmod 700

所有這些步驟都已經在第四章中描述過了，設定非同步複製。正如已經提到的，棘手的部分是初始的基礎備份。假設資料庫必須被複製，就必須找到它的對象ID：

test=# SELECT oid, datname FROM pg_database WHERE datname = ‘a‘;

oid | datname

-------+---------

24576 | a

(1 row)

在這個例子中，對象ID是24576。一般的規則如下：所有OID大於16383的資料庫有使用者建立。這是唯一可以用來有用地過濾資料庫的方法。

現在到maser的資料目錄並複製除了基礎目錄的一切到slave所在的目錄。在這個例子中，使用了這個小把戲：沒有以a開始的檔案名稱，所以安全地複製以c開始的一切並把備份標籤添加到複製進程是可能的。現在，該系統將複製除了基礎目錄的一切：

cp -Rv [c-z]* backup_label ../slave/

一旦一切都被複製到了slave，在這個例子中這恰好發生在一台伺服器上，缺少的基礎目錄可以在slave目錄中建立：

$ mkdir ../slave/base

在下一步中，所有需要的資料庫都可以被複製。目前，樣本master上的情況如下：

[[email protected] base]$ ls -l

total 72

drwx------ 2 hs hs 8192 Feb 24 11:53 1

drwx------ 2 hs hs 8192 Feb 24 11:52 13051 

drwx------ 2 hs hs 8192 Feb 25 11:49 13056

drwx------ 2 hs hs 8192 Feb 25 11:48 16384

drwx------ 2 hs hs 8192 Feb 25 10:32 24576

drwx------ 2 hs hs 8192 Feb 25 10:32 24577

所有大於16383的OID都是有終端使用者建立的。在這種情況下，有三個這樣的資料庫。

因此，所有的系統資料庫（template0,template1,和postgres）以及需要的在slave上的資料庫可以被複製到基礎目錄：

cp -Rv 24576 1 13051 13056 ../../slave/base/

[注意，通常情況下，slave在一個遠程系統上，所以應該使用rsync或者類似工具。在這個例子中，一起都是在同一個節點來使您的生活更容易。]

重要的事情是，在在大多設定中，基礎目錄是到目前為止最大的目錄。一旦資料被獲得，備份可以被停止，如下：

test=# SELECT pg_stop_backup();

NOTICE: WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup

pg_stop_backup

----------------

0/2000238

(1 row)

到目前為止，所有的一切都和 常規的流複製一樣—唯一的區別是並不是基礎目錄的所有目錄都實際地同步到slave。

在接下來的步驟中，建立一個簡單地recovery.conf檔案：

slave]$ cat recovery.conf

primary_conninfo = ‘host=localhost port=5433‘

standby_mode = on

這裡最重要的是slave的連接埠必須寫到設定檔中去。slave將再也不會不會直接看到master了，但是會通過walbouncer消耗它所有的XLOG。

啟動walbouncer

一旦完成了配置，就可以啟動walbouncer了。walbouncer的文法很簡單：

$ walbouncer –help

walbouncer工具代理PostgreSQL的流複製串連並有選擇性地過濾

Options:

-?, --help Print this message

-c, --config=FILE Read configuration from this file.

-h, --host=HOST Connect to master on this host.

Default localhost

-P, --masterport=PORT Connect to master on this port.

Default 5432

-p, --port=PORT Run proxy on this port. Default 5433

-v, --verbose Output additional debugging information

所有相關的資訊都在config檔案中，所以可以確保啟動：

$ walbouncer -v -c config.ini

[2015-02-25 11:56:57] wbsocket.c INFO: Starting socket on port 5433

選項-v不是強制的。它所做的一切都是給我們多提供一點正在發生的資訊。一旦starting socket資訊顯示出來，就意味著所有的事情都在完美地進行。

最後，可以啟動slave了。切換到slave的資料目錄並啟動它，如下：

slave]$ pg_ctl -D . -o "--port=5444" start

server starting

LOG: database system was shut down in recovery at 2015-02-25 11:59:12 CET

LOG: entering standby mode

LOG: redo starts at 0/2000060

LOG: record with zero length at 0/2000138

INFO: WAL stream is being filtered

DETAIL: Databases included: a

LOG: started streaming WAL from primary at 0/2000000 on timeline 1

LOG: consistent recovery state reached at 0/2000238

LOG: database system is ready to accept read only connections

這裡的點表示本地目錄（當然，把完整的路徑放到這裡也是一個很好的想法—絕對地）。接下來是 另外一個技巧：當為了測試的目的在同一台伺服器上一次又 一次地同步slave，一遍又一遍地更改連接埠是很煩人的。選項-O有助於在postgresql.conf中重寫設定檔，以便系統可以直接使用其它的連接埠啟動。

[如果PostgreSQL在獨立的伺服器上啟動，這對通過正常的初始化程式來啟動伺服器當然很有用。]

只要slave開始工作，walbouncer將開始發布更多的日誌資訊，告訴我們更多關於流的狀態：

[2015-02-25 11:58:37] wbclientconn.c INFO: Received conn from 0100007F:54729

[2015-02-25 11:58:37] wbclientconn.c DEBUG1: Sending authentication packet

[2015-02-25 11:58:37] wbsocket.c DEBUG1: Conn: Sending to client 9 bytes of data

[2015-02-25 11:58:37] wbclientconn.c INFO: Start connecting to host=localhost port=5432 user=hs dbname=replication replication=true application_name=walbouncer

FATAL: no pg_hba.conf entry for replication connection from host "::1", user "hs"

一旦這些訊息被顯示出來，系統就處於運行狀態了並且交易記錄在從master流向slave。

現在是測試的時候了：

$ psql -h localhost -p 5444 b

FATAL: database "b" does not exist

DETAIL: The database subdirectory "base/24577" is missing.

當一個到過濾的資料庫的串連被確立，PostgreSQL將會出錯並告訴使用者服務請求所需的檔案不存在。這正是預期的行為種類—由於缺乏資料請求應該被拒絕。

當串連到是資料庫包含一個資料庫執行個體的時候，所有的事情工作起來像一個魔力：

$ psql -h localhost -p 5444 a

psql (9.4.1)

Type "help" for help.

a=#

下一個測試檢查資料是否很好地從master複製到了slave。要執行該檢查，可以在master上情境一個表：

a=# CREATE TABLE a (aid int);

CREATE TABLE

正如預期的那樣，該表將很好地在slave上終止。

a=# \d

List of relations

Schema | Name | Type | Owner

--------+------+-------+-------

public | a | table | hs

(1 row)

該系統現在已經準備就緒並且可以安全的使用。

使用附加配置選項

walbouncer工具可以為使用者做的事情遠遠超出了目前所列出來的。一些額外的配置參數也是可以用的。

第一個例子顯示了如果有一個以上的slave可以做什麼：

listen_port: 5433

master:

host: localhost

port: 5432

configurations:

- slave1:

match:

application_name: slave1

filter:

include_tablespaces: [spc_slave1]

exclude_databases: [test]

在配置塊中，有一個slave1的部分。如果一個slave使用slave1作為application_name（按照application_name列出的條款）串連自身，slave1的配置將被選中。如果這個配置被伺服器（可以有很多這樣的slave部分）選中，在下一個塊中列出的過濾器將被應用。

基本上，每種類型的過濾器有兩種體現：include_ 和exclude_。在這個例子中，只包含spc_slave1資料表空間。最後的設定說，只有test被排除（如果資料表空間過濾器匹配它們，所有其它資料庫被包括）。

當然，這樣看描述也是有可能的：

exclude_tablespaces: [spc_slave1]

include_databases: [test]

在種情況下，所有資料表空間只有spc_slave1被包括。只有系統資料庫和資料庫test被複製。鑒於這些include_ 和 exclude_ 設定，可以靈活地配置複製什麼到那個slave。

請記住，同步複製也需要application_name。如果通過walbouncer傳遞的application_name參數與在synchronous_standby_names裡面列出來的application_name一樣，就可以進行同步複製。

正如您可以看到的，application_name這裡用於兩個目的：它決定使用哪些config塊，並告訴master需要哪個層級的複製。

調整過濾規則

經常被問的一個問題是看，是否可以調整過濾規則。對象隨後可能被添加，或者對象可能被刪除。在許多情況下，這是人們經常問的一個很常見的情境。

改變一個walbouncer設定的配置看起來並不簡單。核心問題是同步XLOG並確保所有相關對象準備就緒。讓我們一個一個地通過核心挑戰。

刪除與過濾對象

基本上，刪除對象是相當簡單。第一件事就是關掉slave以及walbouncer。一旦這樣做了，那些不再需要的對象可以從slave的檔案系統物理地刪掉。這裡重要的部分是找到那些對象。再次，這裡選擇的方法是挖掘系統資料表。所涉及的核心系統資料表或者視圖如下：

•pg_class: 該表包含一系列對象 (表, 索引, 等等).從該表中取出對象的表示是很重要的。  

•pg_namespace:這是用於擷取模式的資訊的。

•pg_inherit: 繼承使用的資訊在這表中。

沒有一個關於如何找到所有這些對象的總指南，因為事情高度取決於應用的過濾類型。

準備好適當的SQL查詢來找到這些必須要被刪除的對象（檔案）的最簡單的方式是和psql一起使用選項-E，它顯示在反斜線命令後面所有的SQL代碼。前端的SQL代碼可以派上用場。下面是一些樣本輸出：

test=# \q

[email protected]:~$ psql test -E

psql (9.4.1)

Type "help" for help.

test=# \d

********* QUERY **********

SELECT n.nspname as "Schema",

c.relname as "Name",

CASE c.relkind WHEN ‘r‘ THEN ‘table‘ WHEN ‘v‘ THEN ‘view‘ WHEN ‘m‘ THEN ‘materialized view‘ WHEN ‘i‘ THEN ‘index‘ WHEN ‘S‘ THEN ‘sequence‘ WHEN ‘s‘ THEN ‘special‘ WHEN ‘f‘ THEN ‘foreign table‘ END as "Type",

pg_catalog.pg_get_userbyid(c.relowner) as "Owner"

FROM pg_catalog.pg_class c

LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace

WHERE c.relkind IN (‘r‘,‘v‘,‘m‘,‘S‘,‘f‘,‘‘)

AND n.nspname <> ‘pg_catalog‘

AND n.nspname <> ‘information_schema‘

AND n.nspname !~ ‘^pg_toast‘

AND pg_catalog.pg_table_is_visible(c.oid)

ORDER BY 1,2;

**************************

List of relations

Schema | Name | Type | Owner

--------+--------------------+-------+-------

...

一旦檔案從基礎目錄被刪除，walbouncer和slave執行個體可以可以被重新啟動。請記住，walbouncer是一個用來使常規流更強大的工具。因此，slave仍然是唯讀，並且是不可能使用DELET和DROP之類的命令的。您真的必須從磁碟刪除檔案。

添加對象到slaves

添加對象是目前最複雜的任務。因此，強烈推薦使用更安全，更簡單的方法來 解決這個問題。最安全和最可靠的方法是完全同步一個執行個體，這需要新的對象。

簡單地使用本章前面所描述的機制，以避免所有的陷阱。

總結

在本章中，討論了walbouncer的工作，一個用於過濾交易記錄的工具。除了安裝過程，對所有的配置選項和一個基本設定進行的概述。

您學會了如何建立地理分布的設定。

 

PostgreSQL Replication之第十五章 與Walbouncer 一起工作