之前做運維時遇到過這么一件事：凌晨三點，數(shù)據(jù)庫服務器突然宕機，業(yè)務直接停擺。值班電話一個接一個，翻箱倒柜找備用方案，結果發(fā)現(xiàn)根本沒有——就一臺單機 PostgreSQL，掛了就是掛了。

那時候最痛苦的是：每次做數(shù)據(jù)備份都要手動停庫，恢復時間以小時計；監(jiān)控報警了還得 SSH 登錄查日志；最怕的是主庫掛了之后，從庫還傻乎乎等著指令。量化一下痛點：一次宕機損失至少 2 小時業(yè)務時間，數(shù)據(jù)恢復要 30 分鐘到 1 小時，而且還得人工介入。

后來換了 PostgreSQL 主從復制，情況變了。

主庫掛了可以直接從庫切換，業(yè)務中斷時間從小時級縮短到分鐘級；自動同步保證數(shù)據(jù)不丟失；監(jiān)控一看就知道同不同步、延遲多少。最核心的改變就是：不再把雞蛋放在一個籃子里，也不再半夜被電話叫醒修數(shù)據(jù)庫。

如果你也經(jīng)歷過單點故障的痛，或者正在考慮給數(shù)據(jù)庫做高可用，下面這套方案可以直接用。

本文將摒棄空泛理論，以CentOS/Ubuntu 環(huán)境下的PostgreSQL 14為例，手把手帶你完成從零搭建、配置調(diào)優(yōu)到故障演練的完整流程。無論你是DevOps工程師、DBA，還是希望提升系統(tǒng)容災能力的開發(fā)者，都能通過本指南，真正掌握PostgreSQL高可用的核心實踐。

讓數(shù)據(jù)多一份副本，讓服務少一分風險。

從今天起，告別單點故障，構建屬于你的高可用數(shù)據(jù)庫基石。

1.環(huán)境準備

1.1 基礎環(huán)境要求

1.2 安裝PostgreSQL

還沒安裝PostgreSQL的小伙伴可以去cpolar官網(wǎng)參考《誰說沒公網(wǎng)IP不能遠程連數(shù)據(jù)庫？PostgreSQL+cpolar打通任督二脈》這篇文章哦~

2.1 修改PostgreSQL主配置文件

主配置文件路徑：/var/lib/pgsql/14/data/postgresql.conf

vim /var/lib/pgsql/14/data/postgresql.conf

修改以下核心參數(shù)（取消注釋并調(diào)整值）：

# 1. 監(jiān)聽地址（允許從庫連接，可指定從庫IP或0.0.0.0允許所有）
listen_addresses = '*'
 
# 2. 開啟歸檔模式（主從復制依賴）
archive_mode = on
archive_command = 'cp %p /var/lib/pgsql/14/archive/%f'  # %p=歸檔文件路徑，%f=歸檔文件名
# 提前創(chuàng)建歸檔目錄
mkdir -p /var/lib/pgsql/14/archive && chown -R postgres:postgres /var/lib/pgsql/14/archive
 
# 3. WAL日志配置（保證復制可靠性）
wal_level = replica  # 復制所需的WAL級別（replica/archive/logical，replica足夠）
wal_buffers = 16MB   # 根據(jù)內(nèi)存調(diào)整，默認通常足夠
max_wal_senders = 10 # 最大并發(fā)復制連接數(shù)，大于從庫數(shù)量即可
wal_keep_size = 1GB  # 保留WAL日志的大小，防止從庫同步滯后導致日志被清理
 
# 4. 同步模式（可選，按需配置）
# synchronous_commit = on  # 默認同步提交，保證主從數(shù)據(jù)一致性；追求性能可設為off
# synchronous_standby_names = 'slave1'  # 指定從庫名稱（需與從庫recovery.conf對應）
 
# 5. 其他優(yōu)化（可選）
max_connections = 1000  # 大于從庫的max_connections

2.2 修改客戶端認證配置文件

文件路徑：/var/lib/pgsql/14/data/pg_hba.conf

vim /var/lib/pgsql/14/data/pg_hba.conf

添加從庫的連接授權（允許從庫 IP 通過復制用戶連接）：

host    replication     repl_user       192.168.42.145/32       md5 # 從庫IP，repl_user為復制專用用戶
host    all             all             192.168.42.0/24         md5 # 可選，允許內(nèi)網(wǎng)其他機器連接

2.3 創(chuàng)建復制專用用戶

切換到postgres用戶，執(zhí)行 SQL 命令創(chuàng)建用于主從復制的專用用戶（需授予復制權限）：

su - postgres
psql

執(zhí)行SQL：

-- 創(chuàng)建復制用戶（密碼自定義，示例：Repl@123456）
CREATE ROLE repl_user WITH REPLICATION LOGIN ENCRYPTED PASSWORD '********';
 
-- 驗證用戶（可選）
\du repl_user;
 
-- 退出psql
\q

2.4 重啟主庫使配置生效

systemctl restart postgresql-14
systemctl status postgresql-14
sudo -u postgres psql -c "SELECT pg_is_in_recovery();" # 主庫返回f（非恢復模式）

2.5 備份主庫數(shù)據(jù)（供從庫初始化）

使用pg_basebackup工具備份主庫數(shù)據(jù)，該工具專門用于PostgreSQL復制環(huán)境的從庫初始化：

# 切換到postgres用戶
su - postgres
 
# 執(zhí)行備份（備份到臨時目錄，后續(xù)拷貝到從庫）
pg_basebackup -h 192.168.42.140 -U repl_user -p 5432 -D /tmp/pg_master_backup -F p -X s -P -R
 
# 參數(shù)說明：
# -h：主庫地址
# -U：復制用戶
# -p：主庫端口
# -D：備份目錄
# -F p：輸出格式為普通文件（與主庫數(shù)據(jù)目錄結構一致）
# -X s：備份過程中同步復制WAL日志，保證備份一致性
# -P：顯示備份進度
# -R：自動生成復制所需的standby.signal文件和postgresql.auto.conf配置，簡化從庫配置

備份完成后，將備份目錄打包拷貝到從庫的/var/lib/pgsql/14/目錄下（可通過 scp 傳輸）：

tar -zcvf pg_master_backup.tar.gz /tmp/pg_master_backup # 主庫上打包備份
                                                                                                                                                                                                                                        
scp pg_master_backup.tar.gz root@192.168.1.101:/var/lib/pgsql/14  # 傳輸?shù)綇膸?

到從庫所在地址查看一下是否傳送成功到/var/lib/pgsql/14：

3.從庫配置

3.1 停止從庫PostgreSQL服務并清理原有數(shù)據(jù)目錄

# 停止從庫服務
systemctl stop postgresql-14
 
# 清理原有數(shù)據(jù)目錄（初始化后的空目錄，需替換為主庫備份）
mv /var/lib/pgsql/14/data /var/lib/pgsql/14/data_bak  # 備份原有目錄，防止誤刪
mkdir -p /var/lib/pgsql/14/data

3.2 解壓主庫備份到從庫數(shù)據(jù)目錄

# 切換到postgres用戶
su - postgres
 
# 解壓備份包
tar -zxvf /var/lib/pgsql/14/pg_master_backup.tar.gz -C /var/lib/pgsql/14/
 
# 移動備份數(shù)據(jù)到data目錄
mv /var/lib/pgsql/14/tmp/pg_master_backup/* /var/lib/pgsql/14/data/
 
 
# 修改目錄權限（必須為postgres用戶和組）
chown -R postgres:postgres /var/lib/pgsql/14/data
chmod 700 /var/lib/pgsql/14/data

3.3 驗證 / 修改從庫復制配置

由于主庫備份時使用了-R參數(shù)，會自動生成standby.signal（標識從庫身份）和postgresql.auto.conf（包含復制連接信息），無需手動創(chuàng)建：

# 查看自動生成的復制配置
cat /var/lib/pgsql/14/data/postgresql.auto.conf

ls /var/lib/pgsql/14/data/

若沒有，則手動創(chuàng)建standby.signal并修改postgresql.conf：

# 手動創(chuàng)建standby.signal（標識為從庫）
touch /var/lib/pgsql/14/data/standby.signal
 
# 編輯postgresql.conf，添加復制配置,添加以下參數(shù)：
vim /var/lib/pgsql/14/data/postgresql.conf

# 從庫專屬配置
hot_standby = on  # 允許從庫處于恢復模式時提供查詢服務（只讀）
max_connections = 500  # 小于主庫的max_connections
primary_conninfo = 'user=repl_user password=Repl@123456 host=192.168.42.140 port=5432'  # 主庫連接信息

3.4 啟動從庫服務

# 啟動從庫
systemctl start postgresql-14
systemctl enable postgresql-14
 
# 驗證從庫狀態(tài)
systemctl status postgresql-14

4.驗證主從復制是否生效

4.1 主庫驗證復制狀態(tài)

su - postgres
psql
 
# 查看復制連接狀態(tài)（可看到從庫的連接信息）
SELECT * FROM pg_stat_replication;
 
# 輸出說明：
# - usename：repl_user（復制用戶）
# - client_addr：192.168.1.101（從庫IP）
# - state：streaming（表示正在流式復制）
# - sync_state：async（異步復制）或 sync（同步復制，需主庫配置synchronous_commit=on）

從提供的pg_stat_replication查詢結果來看，PostgreSQL主從復制已經(jīng)成功建立，并且處于正常運行狀態(tài)。這是一個非常關鍵的監(jiān)控視圖，用于查看 主庫上的復制連接狀態(tài)。

4.2 從庫驗證復制狀態(tài)

su - postgres
psql
 
# 1. 驗證是否處于恢復模式（從庫返回t，主庫返回f）
SELECT pg_is_in_recovery();

4.3 驗證主從數(shù)據(jù)一致性

# 主庫創(chuàng)建測試表并插入數(shù)據(jù)
# 主庫執(zhí)行：
CREATE DATABASE test_repl;
\c test_repl;
CREATE TABLE user_info (id int, name varchar(50));
INSERT INTO user_info VALUES (1, 'test_replication');

# 從庫執(zhí)行（查看是否同步到數(shù)據(jù)）
\c test_repl;
SELECT * FROM user_info; 

主庫：

從庫：

從上圖我們可以看出，主從復制成功啦！

5.主從復制常用操作

5.1 切換主從（故障轉(zhuǎn)移，簡易版）

當主庫故障時，可將從庫提升為主庫：

# 從庫執(zhí)行（停止恢復模式，提升為主庫）
su - postgres
psql -c "SELECT pg_promote();"

# 驗證：提升后從庫pg_is_in_recovery()返回f
psql -c "SELECT pg_is_in_recovery();"

5.2 監(jiān)控復制延遲

# 從庫執(zhí)行，查看復制延遲（單位：秒）
SELECT 
  now() - pg_last_xact_replay_timestamp() AS replication_delay;

5.3新增從庫

只需重復 “從庫配置” 步驟，使用主庫（或現(xiàn)有從庫，需開啟級聯(lián)復制）的pg_basebackup備份初始化即可。

5.4 拓展

主從復制已經(jīng)成功搭建，但我們的目標遠不止于此。

回想一下，在開發(fā)、測試，甚至小型項目交付中，你是否也曾陷入這樣的困境：

• “我在家搭了個PostgreSQL數(shù)據(jù)庫，同事怎么連不上？”
• “客戶急著看Demo，可服務跑在內(nèi)網(wǎng)，根本沒法訪問！”
• “沒有公網(wǎng)IP，難道只能租云服務器，或者干脆放棄遠程演示？”

別焦慮——沒有公網(wǎng)IP，并不意味著你的服務只能困在局域網(wǎng)里。借助一個輕量級但強大的內(nèi)網(wǎng)穿透工具，你可以輕松將本地運行的PostgreSQL服務“暴露”到公網(wǎng)，自動生成一個安全、可分享的HTTPS隧道地址。無論你身處家庭寬帶、公司防火墻后，還是校園網(wǎng)深處，外部用戶都能像訪問普通網(wǎng)站一樣，通過標準端口安全連接你的數(shù)據(jù)庫。本文將手把手帶你完成這一過程：從零配置，到安全地將PostgreSQL服務映射至公網(wǎng)，打通內(nèi)網(wǎng)與外部世界的連接通道。從此，“我的數(shù)據(jù)庫在哪，服務就在哪” 不再是一句空話。準備好了嗎？讓我們開啟這場高效、安全、低成本的“內(nèi)網(wǎng)突圍”之旅！

6.實現(xiàn)隨時隨地開發(fā)

6.1 它是什么？

它是一款安全高效的內(nèi)網(wǎng)穿透工具，無需公網(wǎng)IP或復雜配置，只需一條命令，即可將本地服務器、Web服務或任意端口映射到公網(wǎng)，讓你隨時隨地遠程訪問內(nèi)網(wǎng)應用，特別適合開發(fā)調(diào)試、遠程運維和應急部署等場景。

6.2 部署

它可以將你本地電腦中的服務（如 SSH、Web、數(shù)據(jù)庫）映射到公網(wǎng)。即使你在家里或外出時，也可以通過公網(wǎng)地址連接回本地運行的開發(fā)環(huán)境。

??以下是安裝步驟：

使用一鍵腳本安裝命令：

sudo curl https://get.cpolar.sh | sh

安裝完成后，執(zhí)行下方命令查看

sudo systemctl status cpolar

安裝和成功啟動服務后，在瀏覽器上輸入虛擬機主機IP加9200端口即:http://localhost:9200訪問管理界面，使用官網(wǎng)注冊的賬號登錄,登錄后即可看到web 配置界面,接下來在web 界面配置即可：

打開瀏覽器訪問本地9200端口，使用賬戶密碼登錄即可,登錄后即可對隧道進行管理。

7.配置公網(wǎng)地址

通過配置，你可以在本地 WSL 或 Linux 系統(tǒng)上運行 SSH 服務，并通過 它將其映射到公網(wǎng)，從而實現(xiàn)從任意設備遠程連接開發(fā)環(huán)境的目的。

• 隧道名稱：可自定義，本例使用了:postgres，注意不要與已有的隧道名稱重復
• 協(xié)議：tcp
• 本地地址：192.168.42.140:5432
• 端口類型：隨機臨時TCP端口
• 地區(qū)：China Vip

創(chuàng)建成功后，打開左側(cè)在線隧道列表,可以看到剛剛通過創(chuàng)建隧道生成了公網(wǎng)地址，接下來就可以在其他電腦或者移動端設備（異地）上，使用任意一個地址在終端中訪問即可。

• tcp 表示使用的協(xié)議類型

• 2.tcp.vip.cpolar.cn是 Cpolar 提供的域名

• 11084是隨機分配的公網(wǎng)端口號

  

通過它提供的公網(wǎng)地址和端口，使用 SSH 協(xié)議從任意一臺主機連接到postgres賬號啦！

psql -h 2.tcp.vip.cpolar.cn -p 11084 -U postgres -d mydb

8.保留固定TCP公網(wǎng)地址

使用為其配置TCP地址，該地址為固定地址，不會隨機變化。

選擇區(qū)域和描述：有一個下拉菜單，當前選擇的是“China VIP”。
右側(cè)輸入框，用于填寫描述信息。
保留按鈕：在右側(cè)有一個橙色的“保留”按鈕，點擊該按鈕可以保留所選的TCP地址。
列表中顯示了一條已保留的TCP地址記錄。

• 地區(qū)：顯示為“China VIP”。

• 地址：顯示為“8.tcp.vip.cpolar.cn:13299”。

  

登錄web UI管理界面，點擊左側(cè)儀表盤的隧道管理——隧道列表，找到所要配置的隧道postgres，點擊右側(cè)的編輯。

修改隧道信息，將保留成功的TCP端口配置到隧道中。

• 端口類型：選擇固定TCP端口
• 預留的TCP地址：填寫保留成功的TCP地址

點擊更新。

創(chuàng)建完成后，打開在線隧道列表，此時可以看到隨機的公網(wǎng)地址已經(jīng)發(fā)生變化，地址名稱也變成了保留和固定的TCP地址。

最后測試一下固定的地址是否好用，測試命令：

psql -h 8.tcp.vip.cpolar.cn -p 13299 -U postgres -d mydb

這樣，我們成功打破了“沒有公網(wǎng) IP 就無法遠程訪問數(shù)據(jù)庫”的固有認知。

總結

對比下來，單庫和主從復制的差別很明顯：

*不用主從復制時：*

• 數(shù)據(jù)庫宕機 = 業(yè)務停擺，恢復靠手動
• 備份要停機，數(shù)據(jù)有丟失風險
• 維護升級必須 downtime
• 全靠人工救火

*用了主從復制后：*

• 主庫掛了可以快速切換到從庫
• 數(shù)據(jù)實時同步，最多丟失幾秒
• 從庫可以分擔讀取壓力
• 運維從救火變成預防

不過也得承認，主從復制不是萬能藥：配置錯了照樣出問題，網(wǎng)絡不穩(wěn)定會有延遲，高并發(fā)場景還要考慮讀寫分離。而且，異步復制模式下主庫掛了還是可能有數(shù)據(jù)丟失，真正要求不丟數(shù)據(jù)得上同步復制或者 PgPool 這種更復雜的方案。

如果你也有類似的痛點，比如擔心單點故障、想降低運維壓力，可以試試這個方案。先在測試環(huán)境跑通再上生產(chǎn)，別直接懟線上。

到此這篇關于在CentOS/Ubuntu環(huán)境下搭建PostgreSQL主從復制的文章就介紹到這了,更多相關PostgreSQL主從復制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論