官方檔案https://www.postgresql.org/docs/current/high-availability.html
主從原理或邏輯理解：
將一個基於檔案日誌傳送slave伺服器轉變成流複製slave伺服器的步驟是把該slave伺服器recovery.conf檔案中的primary_conninfo設定指向master伺服器。這樣slave伺服器可以連線到master伺服器上的偽資料庫replication。當slave伺服器被啟動並且primary_conninfo被正確設定，slave伺服器將在重放完歸檔中所有可用的WAL檔案之後連線到master伺服器。如果連線被成功建立，你將在slave伺服器中看到一個walreceiver程式，並且在master伺服器中有一個相應的walsender程式。

流複製允許一臺後備伺服器比使用基於檔案的日誌傳送(日誌傳送是非同步的，即 WAL 記錄是在事務提交後才被傳送。)更能保持為最新的狀態。後備伺服器連線到主伺服器，主伺服器則在 WAL 記錄產生時即將它們以流式傳送給後備伺服器而不必等到 WAL 檔案被填充。 預設情況下流複製是非同步的，在這種情況下主伺服器上提交一個事務與該變化在後備伺服器上變得可見之間存在短暫的延遲。不過這種延遲比基於檔案的日誌傳送方式中要小得多，在後備伺服器的能力足以跟得上負載的前提下延遲通常低於一秒。如果你使用的流複製沒有基於檔案的連續歸檔，該伺服器可能在後備機收到 WAL 段之 前回收這些舊的 WAL 段。如果發生這種情況，後備機將需要重新從一個新的基礎備 份初始化。透過設定wal_keep_segments為一個足夠高的值來確保舊 的 WAL 段不會被太早重用或者為後備機配置一個複製槽，可以避免發生這種情況。如果設定了一個後備機可以訪問的 WAL 歸檔，就不需要這些解決方案，因為該歸檔可以 為後備機保留足夠的段，後備機總是可以使用該歸檔來追趕主控機。 一旦流複製已經被配置，配置同步複製就只需要一個額外的配置步驟：synchronous_standby_names必須被設定為一個非空值。synchronous_commit也必須被設定為on，但由於這是預設值，通常不需要改變。這樣的配置將導致每一次提交都等待確認訊息，以保證後備伺服器已經將提交記錄寫入到持久化儲存中。將synchronous_commit設定為remote_write將導致每次提交都等待後備伺服器已經接收提交記錄並將它寫出到其自身所在的作業系統的確認，但並非等待資料都被刷出到後備伺服器上的磁碟。這種設定提供了比on要弱一點的永續性保障：在一次作業系統崩潰事件中後備伺服器可能丟失資料，儘管它不是一次PostgreSQL崩潰。不過，在實際中它是一種有用的設定，因為它可以減少事務的響應時間。只有當主伺服器和後備伺服器都崩潰並且主伺服器的資料庫同時被損壞的情況下，資料丟失才會發生。

主節點：172.22.136.146
從節點：172.22.136.147

pg_basebackup的過程中，主庫可讀可寫
pg_start_backup+copy+pg_stop_backup，copy的過程，主庫可讀可寫

pg_basebackup的方式

1、master節點172.22.136.146建立用於同步的賬號repdev3，修改postgresql.conf檔案和pg_hba.conf檔案
create user repdev3 SUPERUSER LOGIN password '123456';

pg_hba.conf檔案新增如下
```shell
host  replication  repdev3  172.22.136.147  md5
```

postgresql.conf修改如下
```shell
wal_level=replica
max_wal_senders = 2
wal_keep_segments = 256
```

2、重啟master節點

3、在slave節點172.22.136.147執行psql看是否可以連線master節點
```shell
psql -h172.22.136.146 -p 5432 -U repdev3 -d postgres -W
```

4、在slave節點172.22.136.147，刪除$PGDATA目錄下所有檔案，否則pg_basebackup過程會報錯pg_basebackup: directory "/XX" exists but is not empty

5、在slave節點172.22.136.147執行pg_basebackup把master的檔案複製到slave
```shell
pg_basebackup -D$PGDATA -F p -X stream -v -P -h 172.22.136.146 -p 5432 -U repdev3 -W
```

-D引數列示指定備節點用來接收主庫資料的目標路徑
-F引數列示指定pg_basebackup命令生成的備份資料格式，P表示生成的備份資料和主庫上的資料檔案佈局一樣，類似於作業系統命令將資料庫$PGDATA系統資料檔案、表空間檔案完全複製到備節點。當集簇沒有額外表空間時，整個資料庫將被放在目標目錄中。如果集簇包含額外的表空間，主資料目錄將被放置在目標目錄中，但是所有其他表空間將被放在它們位於伺服器上的相同的絕對路徑中。如果主庫存在額外的表空間且這個表空間目錄和主庫$PGDATA目錄不一樣，從庫沒有這樣的目錄，pg_basebackup過程會自動在從庫上建立表空間對應的目錄，但是如果從庫沒有許可權操作對應的目錄則pg_basebackup過程會報錯pg_basebackup: could not create directory "/Pgtablespace": Permission denied。
-X引數列示指定在備份過程中產生的WAL日誌包含在備份中的方式，fetch表示基準備份完成後再把備份過程中產生的wal日誌複製到從庫，如果備份過程很長，wal在主庫已經被覆蓋了，那麼這個備份就不成功了。stream表示主庫上除了啟動一個基準備份程式外還會額外啟動一個程式傳送主庫主庫產生的wal增量日誌(這兩個程式都屬於max_wal_senders引數指定的wal傳送程式數)，這樣的話就避免了fetch方式過程中主庫的wal被覆蓋的情況，生產環境推薦使用stream
-v引數列示命令執行過程中列印各個階段的日誌
-P引數列示顯示資料檔案、表空間檔案的傳輸百分比

pg_basebackup執行過程的輸出內容
```shell
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/3E000028 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot "pg_basebackup_25932"
33059/33059 kB , 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/3E0000F8
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: base backup completed
```

複製過程中和複製後，主庫可以正常讀寫。複製完後，發現在從庫比主庫少了postmaster.opts和postmaster.pid這兩個檔案，但是比主庫多了一個檔案backup_label，backup_label內容如下
```shell
START WAL LOCATION: 0/3E000028 (file 00000001000000000000001F)
CHECKPOINT LOCATION: 0/3E000060
BACKUP METHOD: streamed
BACKUP FROM: master
START TIME: 2022-03-21 05:58:25 PDT
LABEL: pg_basebackup base backup
START TIMELINE: 1
```

6、複製完成後，在slave節點172.22.136.147修改postgresql.conf檔案新增recovery.conf檔案，recovery.conf檔案內容如下
```shell
recovery_target_timeline = 'latest'
standby_mode = 'on'
primary_conninfo = 'host=172.22.136.146 port=5432 user=repdev3 password=123456'
```
備註：standby_mode引數為on通俗理解就是說自己是備庫並且會不停地從主庫上獲取WAL日誌流直到獲取主庫上最新的wAL日誌流

postgresql.conf檔案修改內容如下
```shell
hot_standby = on
```
可選引數max_standby_streaming_delay(流複製最大延遲)、wal_receiver_status_interval(從向主報告狀態的最大間隔時間) 
備註：hot_standby引數指定從庫在恢復期間，你是否能夠連線並執行查詢，預設為ON，設定為off的話，則psql無法連線從庫會報錯:the database system is starting up

7、啟動slave節點172.22.136.147
```shell
pg_ctl start
```
從庫的backup_label變成了backup_label.old,並且backup_label.old裡面的內容和重啟前backup_label裡面的內容一致

8、驗證
8.1、在master或slave執行ps -ef|grep wal，發現master節點出現walsender程式，slave節點出現walreceiver程式
8.2、在master執行select client_addr,sync_state from pg_stat_replication;可以看到從庫資訊
8.3、在slave從庫執行dml和ddl都會報錯，類似如下
ERROR:  cannot execute CREATE TABLE AS in a read-only transaction
ERROR:  cannot execute DELETE in a read-only transaction
8.4、如果主庫新建表空間且這個表空間目錄和主庫$PGDATA目錄不一樣，從庫沒有這樣的目錄，從庫流複製會報錯並且從庫的postgresql會down掉
```shell
2023-03-21 00:12:12.776 PDT [397] FATAL:  directory "/Pgtablespace/dw2" does not exist
2023-03-21 00:12:12.776 PDT [397] HINT:  Create this directory for the tablespace before restarting the server.
2023-03-21 00:12:12.776 PDT [397] CONTEXT:  WAL redo at 2/C4000740 for Tablespace/CREATE: 24670 "/Pgtablespace/dw2"
2023-03-21 00:12:12.779 PDT [395] LOG:  startup process (PID 397) exited with exit code 1
2023-03-21 00:12:12.779 PDT [395] LOG:  terminating any other active server processes
2023-03-21 00:12:12.780 PDT [484] WARNING:  terminating connection because of crash of another server process
2023-03-21 00:12:12.780 PDT [484] 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.
2023-03-21 00:12:12.780 PDT [484] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2023-03-21 00:12:12.789 PDT [395] LOG:  database system is shut down
```

pg_start_backup+copy_pg_stop_backup的方式
如果是使用pg_start_backup+copy_pg_stop_backup替代pg_basebackup的話，其他步驟和pb_basebackup一樣不用改，只需要把上面第五步改成如下
5.1、master節點執行select pg_start_backup ('/pgdata')設定master節點為備份狀態
此時master節點的/pgdata目錄下會出現一個檔案backup_label，內容格式大概如下
```shell
START WAL LOCATION: 0/19000028 (file 000000010000000000000019)
CHECKPOINT LOCATION: 0/19000060
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2022-03-20 07:53:54 PDT
LABEL: /pgdata
START TIMELINE: 1
```

5.2、複製master節點的資料檔案到slave節點

5.3、複製完成後，master執行select pg_stop_backup()取消備份狀態
此時master節點的/pgdata目錄下的檔案backup_label消失了
如果不執行此步，直接執行後面的步驟，則從庫無法啟動，會報錯類似如下錯誤，此時只要關閉從庫，再在主庫上執行select pg_stop_backup()，再次啟動從庫，從庫就可以正常啟動了
```shell
2022-03-20 08:35:33.450 PDT [17049] LOG:  database system was interrupted while in recovery at log time 2022-03-20 08:13:37 PDT
2022-03-20 08:35:33.450 PDT [17049] HINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
2022-03-20 08:35:33.483 PDT [17049] LOG:  entering standby mode
2022-03-20 08:35:33.485 PDT [17049] LOG:  redo starts at 0/1B000060
2022-03-20 08:35:33.485 PDT [17049] LOG:  invalid record length at 0/1B000140: wanted 24, got 0
```

Postgresql實戰：使用pg_basebackup或pg_start_backup方式搭建Postgresql主從流複製

相關文章