postgresql從庫搭建--物理複製

1 複製類型

PostgreSQL支持物理複製（流複製）及邏輯複製2種。經過流複製技術，能夠從實例級複製出一個與主庫如出一轍的實例級的從庫。流複製同步方式有同步、異步兩種。

另外一種複製方式爲邏輯複製，區別於物理複製的是物理複製是基於實例級的複製，只能複製整個PostgreSQL實例，而不能基於部分庫及表。從PostgreSQL10開始，出現了基於表級別的複製，即邏輯複製。

2  流複製

主庫安裝及從庫編譯此處就省略了，直接進入主從複製的安裝環節。

2.1 修改主庫配置文件postgresql.conf

/* 除了基礎參數,搭建備庫至少須要配置以下參數 */ listen_address = '*' wal_level = replica archive_mode = on archive_command = 'cp %p /data/postgresql/archive/%f ' max_wal_senders= 10 wal_keep_segments=1024 hot_standby = on

參數簡要說明：

listen_address： 按需設置,本次測試配置爲全部主機都可以訪問,生產環境能夠按需配置網段或IP等 wal_level： 設置流複製模式至少設置爲replica archive_mode: 本次啓用歸檔 archive_command：WAL日誌歸檔命令,生產環境能夠將歸檔拷貝到對應目錄或其餘機器上,本次測試配置爲歸檔到本機的另外一個目錄下 max_wal_senders： 最大WAL發送進程數，此數量需大於等於從庫個數且比max_connections小。 wal_keep_segments： pg_wal目錄下保留WAL日誌的個數,每一個WAL文件默認16M,爲保障從庫能在應用歸檔落後時依舊能追上主庫，此值建議設置較大一點。 hot_standby： 此參數控制在恢復歸檔期間是否支持只讀操做，設置爲ON後從庫爲只讀模式。

注意： 上述參數中有涉及歸檔日誌的路徑，需手動建立

mkdir -p  /data/postgresql/archive/

2.2  建立複製帳號

爲了數據安全及便於權限控制，建立一個複製專用的數據庫帳號

postgres=# create user repl  REPLICATION  LOGIN ENCRYPTED  PASSWORD 'repl123'; CREATE ROLE

2.3  修改配置文件pg_hba.conf

添加複製帳號的權限，因可能會主從切換，所以 主從機器的IP均添加。也能夠設置網段，以便於後期添加從庫。

# replication privilege. local replication all trust host replication all 127.0.0.1/32 trust host replication all ::1/128 trust host replication repl 192.168.56.33/24 md5 host replication repl 192.168.56.32/24 md5

2.4  備份數據

從機上在線備份主庫數據，並將數據放在指定路徑，此路徑建議與主庫路徑一致。可使用pg_basebackup

命令在線熱備份，具體命令以下：

pg_basebackup -h 192.168.56.32 -U repl -p 5432 -F p -X s -v -P -R -D /data/postgresql/data/ -l postgres32

pg_basebackup命令中的參數說明：

-h 指定鏈接的數據庫的主機名或IP地址，這裏就是主庫的ip

-U 指定鏈接的用戶名，此處是咱們剛纔建立的專門負責流複製的repl用戶

-F 指定生成備份的數據格式，支持p（plain原樣輸出）或者t（tar格式輸出）

-X 表示備份開始後，啓動另外一個流複製鏈接從主庫接收WAL日誌，有 f(fetch)和s (stream）兩種方式，建議使用s方式

-P 表示顯示數據文件、表空間傳輸的近似百分比 容許在備份過程當中實時的打印備份的進度

-v 表示啓用verbose模式，命令執行過程當中會打印各階段日誌，建議啓用

-R 表示會在備份結束後自動生成recovery.conf文件，這樣也就避免了手動建立

-D 指定把備份寫到哪一個目錄，這裏尤爲要注意一點就是作基礎備份以前從庫的數據目錄（/data/postgresql/data）目錄須要手動清空

-l 表示指定個備份的標識，運行命令後能夠看到進度提示

以上備份命令輸出過程以下

[postgres@PG33 data]$ pg_basebackup -h 192.168.56.32 -U repl -p 5432 -F p   -X s  -v -P -R -D /data/postgresql/data/ -l postgres32 Password: pg_basebackup: initiating base backup, waiting for checkpoint to complete pg_basebackup: checkpoint completed pg_basebackup: write-ahead log start point: 0/2000028 on timeline 1 pg_basebackup: starting background WAL receiver pg_basebackup: created temporary replication slot "pg_basebackup_17737"
56041/56041 kB (100%), 1/1 tablespace pg_basebackup: write-ahead log end point: 0/20000F8 pg_basebackup: waiting for background process to finish streaming ... pg_basebackup: base backup completed

從以上日誌信息看出pg_basebackup命令首先對數據庫作一次checkpoint，以後基於時間點作一個全庫基準備份，全備過程當中會拷貝$PGDATA數據文件和表空間文件到備庫節點對應目錄。

2.5 修改recovery.conf

以上備份命令中生成了recovery.conf 文件,所以簡單修改便可。

standby_mode = 'on' primary_conninfo = 'user=repl password=repl123 host=192.168.56.32 port=5432 sslmode=disable sslcompression=0 target_session_attrs=any' ## 添加以下信息 recovery_target_timeline = 'latest'

參數說明：

standby_mode： 設置是否啓用數據庫爲備庫，若是設置成on，備庫會不停地從主庫上獲取WAL日誌流，直到獲取主庫上最新的WAL日誌流 primary_conninfo：設置主庫的鏈接信息，這裏設置了主庫IP、端口、用戶名信息等，此處是明文密碼，生產環境建議配置非明文密碼，而是將密碼配置在另外一個隱藏文件中 covery_target_timeline： 設置恢復的時間線（timeline），默認狀況下是恢復到基準備份生成時的時間線，設置成latest表示從備份中恢復到最近的時間線，一般流複製環境設置此參數爲latest，複雜的恢復場景可將此參數設置成其餘值

2.6 啓動從庫

直接使用pg_ctl或配置服務啓動從庫便可。

pg_ctl  -D /data/postgresql/data/  -l pg33.log  start

若是啓動過程當中出現以下錯誤

waiting for server to start....2019-09-26 10:40:54.327 CST [10267] FATAL: data directory "/data/postgresql/data" has invalid permissions

2019-09-26 10:40:54.327 CST [10267] DETAIL: Permissions should be u=rwx (0700) or u=rwx,g=rx (0750).

stopped waiting

pg_ctl: could not start serve

Examine the log output.

則須要先修改權限，再啓動便可

[postgres@PG33 data]$ chmod 0750 /data/postgresql/data/ [postgres@PG33 data]$ pg_ctl -D /data/postgresql/data/  -l pg33.log start waiting for server to start.... done server started

2.7 測試主從同步

在主庫建立表並新增數據

[postgres@PG32 ~]$ psql psql (11.4) Type "help" for help. postgres=# create table test2(id int primary key, name varchar(20)); CREATE TABLE postgres=# insert into test2 values(1,'aaa'),(2,'abc'); INSERT 0 2

在從庫查看

[postgres@PG33 data]$ psql psql (11.4) Type "help" for help. postgres=# select * from test2; id | name ----+------
  1 | aaa 2 | abc

數據已正常同步

2.8 查看複製狀態

經過pg_stat_replication視圖能夠查看複製狀態

postgres=# select pid ,usesysid,usename,client_addr,state,sync_state from pg_stat_replication; pid | usesysid | usename |  client_addr   |   state   | sync_state -------+----------+---------+----------------+-----------+------------
 25123 |    16797 | repl    | 192.168.56.33 | streaming | async (1 row)

以上查詢結果sync_state字段值爲async，表示主備數據複製使用異步方式；state值爲streaming,表示流複製方式。

2.9 調整爲同步複製

前面的步驟部署的爲異步複製,如想配置爲同步複製，則調整recovery.conf配置文件裏的 synchronous_commit及synchronous_standby_names 後重啓或reload便可。

synchronous_commit = remote_write synchronous_standby_names = '*'

以後再查看結果以下：

postgres=# select pid ,usesysid,usename,client_addr,state,sync_state from pg_stat_replication; pid | usesysid | usename |  client_addr   |   state   | sync_state -------+----------+---------+----------------+-----------+------------
 16265 |    16797 | repl    | 192.168.56.33 | streaming | sync (1 row)

此時狀態已變爲同步複製了。

注： synchronous_commit 有多種方式，在流複製模式下,主要設置狀況以下：

remote_write： 當流複製主庫提交事務時，需等待備庫接收主庫發送的WAL日誌流並寫入備節點操做系統緩存中，以後向客戶端返回成功，這種狀況下備庫實例出現異常關閉時不會有已傳送的WAL日誌丟失風險，但備庫操做系統異常宕機就有已傳送的WAL丟失風險了，此時WAL可能還沒徹底寫入備節點WAL文件中，簡單地說remote_write表示本地WAL已落盤，備庫的WAL還在備庫操做系統緩存中，也就是說只有一份持久化的WAL，這個選項帶來的事務響應時間較低

on： 設置成on表示流複製主庫提交事務時，需等待備庫接收主庫發送的WAL日誌流並寫入WAL文件，以後才向客戶端返回成功，簡單地說on表示本地WAL已落盤，備庫的WAL也已落盤，也就是說有兩份持久化的WAL，但備庫此時尚未完成重作，這個選項帶來的事務響應時間較高

remote_apply： 表示表示流複製主庫提交事務時，需等待備庫接收主庫發送的WAL並寫入WAL文件，同時備庫已經完成重作，以後才向客戶端返回成功，簡單地說remote_apply表示本地WAL已落盤，備庫WAL已落盤而且已完成重作，這個設置保證了擁有兩份持久化的WAL，同時備庫也完成了重作，這個選項帶來的事務響應時間最高，即性能最差。

原文出處：https://www.cnblogs.com/gjc592/p/11586011.html