Windows?環(huán)境搭建?PostgreSQL?邏輯復(fù)制高可用架構(gòu)數(shù)據(jù)庫服務(wù)
本文主要介紹 Windows 環(huán)境下搭建 PostgreSQL 的主從邏輯復(fù)制,關(guān)于 PostgreSQl 的相關(guān)運維文章,網(wǎng)絡(luò)上大多都是 Linux 環(huán)境下的操作,鮮有在 Windows 環(huán)境下配置的教程,所以本文采用 Windows 環(huán)境作為演示系統(tǒng)來進行 PostgreSQL 高可用數(shù)據(jù)庫服務(wù)的搭建。
關(guān)于 Windows 系統(tǒng) PostgreSQL 的安裝方法可以直接看之前的博客 http://www.dbjr.com.cn/article/261744.htm
在Windows 環(huán)境運行 PostgreSQL 在連接數(shù)的配置需要注意以下這個知識點:
由于PostgreSQL所依賴的一些庫依賴于user32.dll,后者從內(nèi)存中一塊稱為桌面堆(Desktop Heap)的區(qū)域中分配內(nèi)存。桌面堆被分配給了每一個登錄的會話,在 Windows 10 以上的操作系統(tǒng)通常一個非交互的會話將會分配給768KB。每個交互登錄會話將會分配給20MB的桌面堆,每個postgres進程典型的桌面堆消耗是3.2KB。
由于PostgreSQL所依賴的一些庫依賴于user32.dll,后者從內(nèi)存中一塊稱為桌面堆(Desktop Heap)的區(qū)域中分配內(nèi)存。桌面堆被分配給了每一個登錄的會話,在 Windows 10 以上的操作系統(tǒng)通常一個非交互的會話將會分配給768KB。每個交互登錄會話將會分配給20MB的桌面堆,每個postgres進程典型的桌面堆消耗是3.2KB。
- 當(dāng)作為Windows服務(wù)運行時,因為每個非交互會話將會分配768KB的桌面堆,所以大約可以支撐 200-220個連接。
- 當(dāng)在命令行方式運行時,因為每個交互登錄會話將會分配20MB的桌面堆,所以大約可以支撐 5000-6000個連接。
以上說的值是操作系統(tǒng)默認的值,這個堆分配大小可以通過調(diào)整注冊表來進行修改,但是此操作需要非常小心,一旦指定的值過大,系統(tǒng)將無法啟動,所以不推薦去手動修改這個值。如果想要了解更多這個知識點可以看 微軟官方的這個說明:https://learn.microsoft.com/zh-CN/troubleshoot/windows/win32/user32-kernel32-not-initialize
結(jié)合上面的知識點,所以我們在Windows環(huán)境下配置 PostgreSQL 的最大連接數(shù)時,如果采用 Windows 服務(wù)模式運行則配置最大連接數(shù)為200比較好,如果需要200個以上的并發(fā)連接,則最好采用控制臺形式啟動運行PostgreSQL,同時結(jié)合計算機的可以內(nèi)存去綜合考慮一般100個連接數(shù)會消耗 1G內(nèi)存,所以假設(shè)我們電腦內(nèi)存為8G,考慮到系統(tǒng)本身運行需要2G內(nèi)存,所以這是 PostgreSQL 的最大連接數(shù)配置為500 左右即可。
PostgreSQL控制臺運行,啟動和停止命令如下:
啟動 pg_ctl.exe -D "D:\Software\PostgreSQL\data" start
停止 pg_ctl.exe -D "D:\Software\PostgreSQL\data" stop
-D 的參數(shù) "D:\Software\PostgreSQL\data" 是 PostgreSQL 的數(shù)據(jù)實例位置
今天我們采用邏輯同步復(fù)制來實現(xiàn)主從數(shù)據(jù)庫的配置,首選在主數(shù)據(jù)庫上調(diào)整 postgresql.conf 配置文件啟用邏輯復(fù)制功能
wal_level = logical

配置調(diào)整之后需要重新啟動主數(shù)據(jù)庫實例。
然后在主數(shù)據(jù)庫對我們需要配置的數(shù)據(jù)庫執(zhí)行邏輯發(fā)布CREATE PUBLICATION p FOR ALL TABLES WITH (publish = 'insert, update, delete, truncate', publish_via_partition_root = false);
其中 p 為這個發(fā)布設(shè)置的名稱,也可以自定義為其它。

然后在從數(shù)據(jù)庫實例上選擇我們要用來訂閱主實例的數(shù)據(jù)庫,然后執(zhí)行創(chuàng)建邏輯訂閱
CREATE SUBSCRIPTION s
CONNECTION 'host=127.0.0.1 port=5432 user=postgres dbname=xxxxx connect_timeout=10 password=xxxxxx'
PUBLICATION p
WITH (connect = true, enabled = true, copy_data = true, create_slot = true, synchronous_commit = 'remote_apply');其中 s 為這個訂閱設(shè)置的名稱 'host=127.0.0.1 port=5432 user=postgres dbname=xxxxx connect_timeout=10 password=xxxxxx' 為主庫的連接信息

因為我們創(chuàng)建的訂閱 synchronous_commit 采用的是 remote_apply 模式,該模式可以理解為同步復(fù)制,當(dāng)客戶端像主庫提交事務(wù)之后,需要等 synchronous_standby_names 總配置的節(jié)點全部完成 remote_apply 收到數(shù)據(jù)之后,主庫才會給備庫返回事務(wù)成功提交的狀態(tài),創(chuàng)建好名為 s 的訂閱創(chuàng)建之后,我們再次打開 主庫的 postgresql.conf 文件進行調(diào)整設(shè)置
synchronous_standby_names = 's'

調(diào)整配置文件之后記得重啟主庫的數(shù)據(jù)庫實例
這樣我們就完成本地 localhost 的 PostgreSQL 實例中 csapp 數(shù)據(jù)庫和 遠程服務(wù)器上 caspp 數(shù)據(jù)庫的主從配置。
這里要注意的一點是 PostgreSQL 的 邏輯訂閱并不會同步DDL操作 ,所以對于數(shù)據(jù)庫的建表等操作是不會進行主從同步的,我們需要手動維護 主從實例數(shù)據(jù)庫上的表結(jié)構(gòu)使其保持一致。
當(dāng)在主和從數(shù)據(jù)庫都創(chuàng)建完成表之后需要在從庫上執(zhí)行以下刷新訂閱的 SQL,每次主庫新增或者刪除了表,從庫都需要執(zhí)行這個操作。
ALTER SUBSCRIPTION s
REFRESH PUBLICATION WITH (copy_data = true);然后我們在主庫的數(shù)據(jù)庫表中進行數(shù)據(jù)操作,所有的操作就會被同步到 從庫的數(shù)據(jù)表中。

下面介紹如果想要刪除發(fā)布設(shè)置和訂閱設(shè)置的操作
在主庫執(zhí)行
SELECT * FROM pg_publication 可以查詢當(dāng)前主庫的所有發(fā)布信息

DROP PUBLICATION p 刪除名字為 p 的發(fā)布信息
在從庫執(zhí)行:
SELECT * FROM pg_subscription 可以查詢當(dāng)前從庫的所有訂閱信息

DROP SUBSCRIPTION s 刪除名字為 s 的訂閱信息
然后記得去主庫的 postgresql.conf 找到 synchronous_standby_names 刪除 s 節(jié)點的配置
#synchronous_standby_names='s'
如果只有一個從節(jié)點的,則直接添加 # 對 synchronous_standby_names 進行注釋即可
當(dāng)有多個從庫訂閱的時候synchronous_standby_names 還可以采用以下配置模式
- synchronous_standby_names='s1' 代表s1備機返回就可以提交。
- synchronous_standby_names='FIRST 2 (s1,s2,s3)' 代表s1,s2,s3三個備機中前兩個s1和s2返回主庫就可以提交。
- synchronous_standby_names='ANY 2 (s1,s2,s3)' 代表s1,s2,s3三個備機中任意兩個備機返回主庫就可以提交。
- synchronous_standby_names='ANY 2 (*)' 代表所有備機中任意兩個備機返回主庫就可以提交。
- synchronous_standby_names='*' 代表匹配任意主機,也就是任意主機返回就可以提交。
這里有一點需要注意,這是 PostgreSQL 在同步復(fù)制時的一個已知問題,假設(shè) 一個主庫,一個備庫 s1,采用同步模式,然后 synchronous_standby_names 配置為 synchronous_standby_names='s1',雖然從配置上來看似乎數(shù)據(jù)必須要提交到s1并且s1成功響應(yīng)之后,主庫才會為客戶端返回事務(wù)操作成功的響應(yīng),但是實際情況下,當(dāng)備庫掛掉的情況下,主庫在收到一個事務(wù)操作時,在等待 s1 備庫的返回時因為 s1庫已經(jīng)掛掉了所以這個操作肯定會超時,當(dāng)主備節(jié)點通信超時之后,主節(jié)點還是會像客戶端返回事務(wù)成功提交的命令,客戶端的操作還是會成功,同時因為每個事務(wù)操作都要經(jīng)歷這個超時的流程,所以客戶端的所有事務(wù)操作都會相對很卡。
比如每個 insert 都會經(jīng)過主庫和備庫的這個通信超時過程,所以每個 insert 動作都變成了大約30秒次才能完成,就會導(dǎo)致應(yīng)用程序很卡。這時候就相當(dāng)于主庫在以(很卡的)獨立模式運行,這個情況在備庫重新上線之后就會恢復(fù)正常(如果備庫短期之內(nèi)無法恢復(fù),可以調(diào)整主庫的 synchronous_standby_names設(shè)置 移除對于s1備庫的事務(wù)等待驗證,變?yōu)閱螏爝\行模式重啟實例之后也就不會卡了),但是要注意當(dāng)主庫脫離備庫獨立運行時,如果這個時候主庫發(fā)生災(zāi)難比如硬盤壞掉,則就會產(chǎn)生數(shù)據(jù)丟失。所以建議至少有2個備庫來提升保障級別
至此 Windows 環(huán)境搭建 PostgreSQL 邏輯復(fù)制高可用架構(gòu)數(shù)據(jù)庫服務(wù) 就講解完了,有任何不明白的,可以在文章下面評論或者私信我,歡迎大家積極的討論交流,有興趣的朋友可以關(guān)注我目前在維護的一個 .NET 基礎(chǔ)框架項目,項目地址如下
https://github.com/berkerdong/NetEngine.git
https://gitee.com/berkerdong/NetEngine.git
到此這篇關(guān)于Windows 環(huán)境搭建 PostgreSQL 邏輯復(fù)制高可用架構(gòu)數(shù)據(jù)庫服務(wù)的文章就介紹到這了,更多相關(guān)Windows 環(huán)境搭建 PostgreSQL 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
聊聊PostgreSql table和磁盤文件的映射關(guān)系
這篇文章主要介紹了聊聊PostgreSql table和磁盤文件的映射關(guān)系,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2021-01-01
PostgreSQL 如何獲取當(dāng)前日期時間及注意事項
這篇文章主要介紹了PostgreSQL 如何獲取當(dāng)前日期時間及注意事項,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-10-10
Postgresql源碼分析returns?setof函數(shù)oracle管道pipelined
這篇文章主要為大家介紹了Postgresql源碼分析returns?setof函數(shù)oracle管道pipelined,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-01-01
解決PostgreSQL數(shù)據(jù)庫連接報錯:psql:?error:?FATAL:?password?authent
這篇文章主要給大家介紹了關(guān)于如何解決PostgreSQL數(shù)據(jù)庫連接報錯:psql:?error:?FATAL:?password?authentication?failed?for?user?"postgres"的相關(guān)資料,在使用PostgreSQL時,一些關(guān)鍵配置的錯誤可能導(dǎo)致數(shù)據(jù)庫無法正常啟動,需要的朋友可以參考下2024-05-05
基于PostgreSQL pg_hba.conf 配置參數(shù)的使用說明
這篇文章主要介紹了基于PostgreSQL pg_hba.conf 配置參數(shù)的使用說明,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2021-01-01
Ruoyi從mysql切換到postgresql的幾個踩坑實戰(zhàn)
最近由于工作的原因,需要將Ruoyi從mysql切換到postgresql,所以這篇文章主要給大家介紹了關(guān)于Ruoyi從mysql切換到postgresql的幾個踩坑實戰(zhàn),需要的朋友可以參考下2023-02-02

