PostgresSQL HA高可用架構實戰

PostgresSQL HA高可用架構實戰

原創 2015-09-25 蕭少聰 高可用架構

本文由蕭少聰在高可用架構羣所作的分享整理而來，轉載請註明高可用架構公衆號：ArchNotes。

蕭少聰（花名：鐵庵），廣東中山人，阿里雲RDS for PostgreSQL/PPAS雲數據庫產品經理。自2006年以來，長期從事RedHat及SuSE Linux的HA集羣搭建及PostgreSQL數據庫支持工做。2011年開始組建Postgres（數據庫）中國用戶會。

PostgreSQL背景介紹

有很多同窗但願瞭解PostgreSQL的背景及它與MySQL的對比結果，因此在此囉唆兩句，有興趣的同窗能夠單獨給我發E-Mail，我能夠分享詳細的介紹及一些對比結果。

2015年是PostgreSQL正式在中國起步的一年，咱們看到愈來愈多的企業選擇了PostgreSQL。

• 中國移動主動使用PostgreSQL實現分佈式數據庫架構。

• 金融業方面平安集團明確表示將使用PostgreSQL做爲新一代數據庫的選型。

• 華爲中興紛紛加入PostgreSQL內核研究隊伍。

• 阿里雲正式提供PostgreSQL服務。

大部分人瞭解MySQL應該都是從2005年左右開始，那時在互聯網帶動下LAMP空前繁榮。而你所不知道的是，那時PostgreSQL已發展了近30年，至今已經超過40年。1973年MichaelStonebraker（2014年圖靈獎得主）在伯克利分校研發了當前全球最重要的關係型數據庫實現：Ingres。此後，陸續更名爲Postgres、Postgres95，直到如今的PostgreSQL。PostgreSQL有衆多的衍生品牌產品，就如同Linux有RedHat、SUSE、Ubuntu同樣，當前，國內多個國產數據庫都是基於PostgreSQL進行開發的，同時，國際知名的針對OLAP場景的Greenplum數據庫，及EnterpriseDB公司高度兼容Oracle語法的PPAS數據庫也是基於PostgreSQL實現。

PostgreSQL與MySQL相比功能更爲完善，同時，在進行復雜SQL查詢時（特別是多表進行JOIN查詢）性能及穩定性也更爲優秀，是國外企業首選的應用於核心業務系統的開源OLTP業務關係型數據庫引擎。PostgreSQL被譽爲全球最早進的開源數據庫，支持NoSQL JSON數據類型、地理信息處理PostGIS、豐富的存儲過程操做，並可實現基於Tuple（在PostgreSQL中此單位比Block還要小）級別的StreamingReplication數據同步。

與MySQL不一樣，PostgreSQL不支持多數據引擎。但支持Extension組件擴充，以及經過名爲FDW的技術將Oracle、Hadoop、MongoDB、SQLServer、Excel、CSV文件等做爲外部表進行讀寫操做，所以，能夠爲大數據與關係型數據庫提供良好對接。

在PostgreSQL下如何實現數據複製技術的HA高可用集羣

業界大多數的數據庫的HA實現都是基於共享存儲方式的，以下圖。在這個方式下，數據庫1主1備，使用一個共享存儲保存數據。

正常狀況下主庫鏈接存儲及VIP，進行數據業務處理。備庫永遠處於非運行狀態，只有當主庫出現故障後，備庫纔會進行存儲及VIP的接管。但傳統的企業中，這樣的結構比比皆是，在我進入阿里雲以前服務過的大多數企業都使用這樣的架構（除了Oracle RAC及DB2的並行方案）。而當今，不管Oracle、MySQL、SQLServer，仍是今天咱們用做說明案例的Postgres，都已經支持基於數據庫底層的StreamingReplication模式實現數據複製了，同時支持備庫做爲只讀服務器提供業務服務。所以，備庫資源對於企業來講是極大的浪費。

傳統的HA方案在實現基於Streaming Replication方式時，每每須要經過大量人爲控制的腳本進行判斷和控制。2006年到2011年，我爲不一樣的客戶及不一樣的數據庫編寫了多種特製的腳本，當中的安裝配置及維護難度都有點讓人望而卻步。2011年，我在SUSE系統的HA支持工做中接觸到了Corosync +Pacemaker的HA結構。發現了 「Master-Slave模式」。在這個模式下，系統支持promote及demote，以解決數據庫基於Streaming Replication主備模式的切換問題。

Corosync + Pacemaker MS 模式介紹

本次講解主要針對架構及這個模式的處理原理。若是你們想要了解具體的配置方式，能夠參考http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster。同時，當前最新的Red Hat Enterprise Linux 7及SUSE Linux Enterprise Server 11/12中的HA組件都基於此架構，你也能夠經過廠商的官方文檔或官方技術支持獲得配置的詳細說明。

上圖有3個網段：0.x網段，用於數據庫對外業務；1.X網段，用於Pacemaker心跳通信；2.X網段，用於數據庫的數據複製。同時提供主庫讀寫服務VIP1 192.168.0.3和備庫只讀服務VIP2 192.168.2.3。用戶的主應用程序能夠經過VIP1進行讀寫操做，而只讀處理能夠經過VIP2實現。

上圖中，左邊是正常運行的模式：全部讀寫操做經過VIP1進入到Master節點；Slave節點的會鏈接到VIP2，經過此IP支持只讀操做；Streaming Replication經過eth2進行兩節點的數據同步。右邊是Master故障時的模式：原Slave會promote成爲Master節點；VIP1切換到node2繼續提供服務；VIP2切換到node2繼續提供服務。

在此處，系統從node1切換到node2有多種可能性。

1. Master節點經過pacemaker控制人爲進行Switchover切換。這種狀況下主備模式會進行調換，而且過程當中能夠保證全部Master節點中的數據會複製到Slave後再進行node2上的promote操做。所以，數據庫中全部的事務都是完整的，且不會出現任何數據丟失。這種狀況大多用於硬件須要進行主動維護時。

2. Master節點意外出現故障時，將進行Failover。因爲PostgreSQL在雙節點推薦使用的是async模式，所以若是Master節點故障時還有數據沒來得及複製到Slave。這些數據將丟失，但因爲PostgreSQL的Streaming Replication是以事務爲單位的，所以數據庫的事務一致性是能夠獲得保障的，絕對不會出現備庫中某個事務只恢復到一半的狀況。

當前有一個比較嚴重的問題，就是如上圖所示，切換後node1若是想要從新成爲主節點，將須要從新進行全量的數據複製恢復。這是由於Master故障時若是有數據沒複製到Slave，Master的最後一個事務時間將比Slave中的事務時間更新（如Master最後一個事務號爲1001，但Slave中的事務只恢復到999）。此時Slave節點promote成爲新的Master後，全部新的操做將由999號事務的結果爲基礎。也就是說原Master中的1000及1001事務所處理的數據將不可恢復。因爲在當前設計中數據庫中已經提交的事務不支持直接回退，因此，若是你的數據庫到達TB級別，這將須要6~7小時。

但這個狀況很快將會被改善。PostgreSQL9.5將爲用戶提供pg_rewind功能。當Master節點Failover後，原Master節點能夠經過pg_rewind操做實現故障時間線的回退。回退後再重新的主庫中獲取最新的後續數據。所以，雖然以前沒有提交的事務因爲ACID原則沒法從新使用，但原Master的數據無須進行從新全量初始化就能夠繼續進行Streaming Replication，並做爲新的Slave使用。

Corosync + Pacemaker M/S 環境配置

如下內容中截圖來自於http://clusterlabs.org/wiki/PgSQL_Replicated_Cluster。

Corosync + Pacemaker M/S配置環境準備

• RA：Resource Agent資源代理，PostgreSQL最新的RA能夠經過https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/pgsql下載。若是你發現這個RA不符合你的需求，也能夠自行改寫。

• 操做系統版本：Fedora19及以上、Red Hat Enterprise Linux 7及以上、SUSE Linux Enterprise Server 11 SP3及以上。

• 數據庫要求：PostgreSQL9.1及以上，因爲PostgreSQL 9.1以上才支持Streaming Replication，所以，比這個版本低的數據庫沒法實現此功能。

• 兩臺服務器配置相同的NTP時間源及相同的時區。

經過yum、zypper安裝pacemaker（主要用於HA資源管理）、corosync（HA心跳同步控制）、pcs3（HA的命令行配置工具）。經過yum、zypper或任何其餘方式安裝PostgreSQL數據庫，安裝時務必確認其pg_ctl命令、psql命令、data目錄的存放位置，由於配置時要用到。

PostgreSQL Streaming Replication配置

在node1中初始化PostgreSQL數據庫。

對其postgresql.conf文件作以下修改。

注意：wal_level = hot_standby，使得日誌支持Streaming Replication；archive_mode = on，啓動歸檔模式；archive_command = 'xxx'，指定歸檔的保存方法；hot_standby = on，備庫啓動爲standby模式時可實現只讀查詢；其餘參數主要用於性能及延遲的設定。

將data目錄下的pg_hba.conf文件作以下修改。

注意：這樣配置後，全部192.168.x.x網段的IP都將能夠無密碼對此數據庫進行訪問，安全性可能會下降。所以，只做爲練習使用，在生產環境中請嚴格控制IP。如指定只trust某IP能夠寫成192.168.100.123/32。

配置完成後，啓動node1上的PostgreSQL。

在node2進行數據初始化。

注意：經過pg_basebackup命令將從node1中將全部數據庫中的數據都同步到/var/lib/pgsql/data去。

數據basebackup完成後，在node2中的data目錄下創建recovery.conf文件並錄入如下內容。

注意：primary_conninfo指定了主服務器所在的位置、replicate所使用的用戶名。因爲咱們在pg_hba.conf中使用trust方式，因此在此參數中不須要加入password。

配置完成後，啓動node2上的PostgreSQL，準備檢查同步效果。

若是在node1中經過psql命令登陸數據庫後能夠獲得如下信息，證實數據庫端的Replication已運行正常。

自此，PostgreSQL的Streaming Replication配置完成，兩個數據庫的數據將進行持續複製。

注意：以上兩個服務器已經完成Streaming Replication配置，在配置HA前請將兩個服務器上的PostgreSQL都中止。由於在HA架構中，全部資源都應該是由HA軟件進行管理的，因此與此同時也請確認系統啓動時PostgreSQL不會自動啓動（你能夠經過chkconfig檢查）。

Corosync + Pacemaker HA 基礎配置

corosync配置文件只有一個，/etc/corosync/corosync.conf。

咱們能夠看到，當前quorum中expected_votes爲2，這是由於咱們使用2節點。totem中有bindnetaddr:192.168.1.0及mcastaddr: 239.255.1.1，這裏說明corosync會使用本服務器上192.168.1.X網段的IP做爲心跳。此處注意，不須要寫明此IP的詳細地址，系統會自動發現。經過scp命令將此文件複製到node2中相同的目錄並保證其權限一致。

接下來就能夠在兩個節點中啓動corosync了。如下是系統在Fedora 1九、RHEL七、SUSE12後的服務啓動命令。若是你使用的是低版本操做系統，請用/etc/init.d/corosync start或service corosync start 。

pacemaker默認狀況下是無污染的，但爲了保證HA初始狀態咱們會進行如下操做。此操做會清空全部HA資源的配置。它在另一些狀況下也十分實用，若有時咱們會發現兩個節點HA啓動時資源信息不一樣步。此時咱們能夠先擇定一個可信的節點，而後將另外一節點上的cib文件清空，而後進再啓動pacemaker，這樣新節點就會自動同步現有節點的全部配置。

Pacemaker資源配置

經過pcs命令行工具進行HA資源的配置。pcs命令行能夠協助生成名爲config.pcs的配置腳本，以進行最後的HA配置導入。首先，咱們進行一個全局信息的配置，指明因爲當前是2節點，因此忽略no-quorum-policy；默認的resource-stickiness爲INFINITY，即任何資源默認都是與其餘資源可共同運行的；•默認的migration-threshold爲1，即任何狀況下migration時都會重試一次。

注意：stonith-enabled="false"表示不使用任何電源控制設備，這個狀況不建議在生產中使用。熟悉RHEL集羣的同窗能夠認爲Stonith等同於Fence設備。

配置VIP1及VIP2，以及pgsql資源。

vip-master(VIP1)及vip-rep(VIP2)相對比較好理解。而在pgsql資源中，若是你們有熟悉Linux集羣的會發現，通常狀況下HA中添加應用資源都會加入一個帶有start/stop/status的腳本。而此處是經過一個agent實現，咱們只要配置好PostgreSQL的pgctl、psql、pgdata的文件或目錄位置便可，處理十分方便。主要由於PostgreSQL RA已經包含start|stop|status|monitor|promote|demote|notify的操做腳本（https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/pgsql）。感謝開源，感謝貢獻者吧，這裏頭有2070行代碼，相比我之前本身寫的要精妙得多。

將以上的IP及pgsql資源進行關聯，這也是pacemaker最精妙的地方。咱們能夠看到，首先，有一個「resource master」咱們命名爲msPostgresql，pgsql屬於這個Master模式資源。這個模型的資源，基於clone模型，將會在兩個節點同時啓動。而後，創建了一個master-group，將vip-master及vip-rep加到這個組中。接下來，constraintcolocation指定了master-group中的資源（vip-master及vip-rep）傾向於與msPostgresql的Master節點運行在一塊兒。最後，orderpromote及order demote負責管理節點的啓動順序。

注意：Master節點會由RA自動識別；msPostgresql進行promote之後纔會進行master-group的IP掛接；同時，在進行demote時也是隻有等msPostgresql完成停庫後才進行master-group的IP斷開處理。

此處的config.pcs是由前面的pcs所生成，經過crm_mon你能夠看到全部的資源狀況。

自此全部配置結束，你能夠將node1中PostgreSQL的data目錄mv到其餘地方看看切換的效果，再也不贅述。

關於排錯，全部HA日誌信息會保存在/var/log/message中。若是系統有問題，能夠經過此日誌進行分析。但有一點很重要，建議你們在配置HA前必定要確認NTP服務是否正常，保障兩個服務器時間不要差距太大。否則排錯會很麻煩，還會有可能致使集羣的其餘問題。

過去兩年，這樣的集羣架構已經在不少企業使用，數據量多在20G到1T之間。PG是一個用於OLTP的系統，當前我所實施的企業大可能是傳統行業。大部份用戶主要是從Oracle遷移來的。在大數據及分析方面，會先用Greenplum或Hadoop等進行處理，這時PostgreSQL也可使用FDW功能進行對接。

PostgreSQL Sync模式當前的問題

前面提到當前PostgreSQL在2節點狀況下推薦使用的是async的模式，那sync是否是不支持？不是的，當前PostgreSQL支持sync模式，即便2節點也能夠配置，但會有如下問題：

• 因爲sync同步模式要求Master在Slave數據寫入成功後才結束事務的Commit操做，所以性能會受到影響。

• 若是系統運行過程當中slave出現故障，主節點也將受到影響使系統出現故障，在HA下這也會Failover。Pacemaker當前最新的PostgreSQLRA也尚未解決此問題。

• 若是須要使用sync模式的Streaming Replication，我建議搭建1主2備的模型實現，而這個模型下Pacemaker尚未提供3節點的實現方案，尚待改進。

最後簡單介紹一下「PostgreSQL中國用戶會」，Postgres中國用戶會是一個非營利團體，致力於爲中國的PostgreSQL用戶服務，當前各QQ及微信羣已經有超過4000人規模，在過去的2周咱們在全國9個城市舉辦了名爲「象行中國 Let'sPostgres」的線下技術沙龍，同時支持了香港及臺灣地區的PostgreSQL技術活動。

Q&A

Q1：排除年限，PG相對MySQL和Oracle有啥優點？

A1：PG有不少MySQL沒有的功能，就以O2O行業爲例，PG直接提供PostGIS，能夠有效地在數據庫中經過SQL進行復雜的定位查詢並與業務直接關聯，更多功能歡迎線下交流。

Q2：金融企業中用async複製，怎麼應對數據丟失？靠對帳麼？

A2：首先，金融行業中若是要求100%數據不丟失，應該使用sync而不是async，這個功能PostgreSQL是支持的，只是要用3節點方案。當前在這個方案下進行HA切換也是能夠的，只是Corosync+Pacemaker沒有直接支持，須要咱們對RA進行附加的腳本控制。

Q3：threshold設置爲1時，嘗試1次，若是再有問題就直接切換了。設置爲2時， 2次嘗試，這個計數器不會在成功後恢復原值，該測試結果是否正確？

A3：是的，意思就是嘗試1次，在Pacemaker這些值都是有限時的，超時就會恢復原值，你能夠經過clean操做對這個節點上的計數器進行數值恢復操做。

Q4：MySQL的binlog處理和PG的有什麼區別？

A4：MySQL我只用過4及如下版本，對binlog不是十分了解，與公司MySQL大牛討論中，我感受這兩個方式是很接近的，都是使用日誌進行恢復。但PostgreSQL的操做中會以Tuple爲單位，這個多是一個row，甚至就是某個row中被修改過的1個字段的值。有一個討論結果是PG的StreamingReplication粒庫更細。

Q5：3節點方案寫成功2個就返回，仍是,3個都成功才返回？

A5：3節點狀況下，系統中有2個節點是同步，第3個是異步，因此成功2個就返回。

Q6：PG的HA除了今天分享的還有其餘方案嗎？

A6：PG的HA還能夠用LiveKeeper、微軟的MSCS等方案，對於HA來說PG就只是一個服務，因此任何HA軟件均可以與PG對接，但若是要進行StreamingReplication的切換就要本身寫腳本了。

Q7：我感受PG這個HA相比MySQL自帶的主從沒多大亮點。PG有相似mysql-proxy這樣的負載均衡中間件及MMA這類解決方案嗎？以前據說PG在集羣這塊不是更好，方案複雜且性能損失大，是否是PG仍是更適合單機？

A7：當前PG業界能夠經過PGPool實現1個Master進行讀寫，n個Slave進行只讀負載均衡的方案；PG分佈式集羣當前方案的Postgres-X2，確實複雜，咱們這方面也正在努力；單機的這個問題上，咱們有不少PG用戶會選擇經過應用程序自定義進行分庫集羣模型，畢竟在要求強一致性又沒有InfiniBand或更高級的網絡的狀況下，事務和延遲都很差在傳統集羣中解決。

Q8：PG有sharding功能嗎？可否簡單介紹一下。

A8：最近PG出現了一個名爲pg_shard的第三方組件，能夠對數據庫中的一個特定的表進行sharding，能夠擴展到64臺服務器，但不保證此表的事務，一些分析場景能夠考慮嘗試。

Q9：可否簡單對比一下PG的HA方案？

A9： Corosync + Pacemake，支持Replication模式，在Linux下這是我個爲最推薦的方案，共享存儲一樣也沒有問題；原RHEL中的RHCS，配置簡單，若是有共享存儲，Linux下這個方案最方便，但要注意RHCS是要求付費使用的；LiveKeeper，配置相對複雜一些，若是要支持Replication須要寫比較複雜的腳本；微軟MSCS，Windows平臺必備，中國還真有幾個用戶是這樣用的；VCS，跨Windows及Linux平臺但一樣只建議在有共享存儲狀況下使用。

Q10： PG的表分區和MySQL的表分區差異在哪？各自的優勢在哪？我印象中PG分區表對外會顯示成單獨的一個分區表，分區多了很難看。

A10：PG默認的表分區基於對象數據庫結構的表集成，經過觸發器進行數據調度，表大了之後性能不好，聽說在9.6之後（當前9.4）會改善。在此打個廣告，分區表性能在阿里雲的PPAS中已經獲得解決，2~1000個表分區性能表表現恆定，不會由於表分區愈來愈多致使性能瓶頸。

本文策劃啓明@迅雷 ，內容由余長洪@暴走漫畫編輯，劉芸@博文視點校對與發佈，其餘多位志願者對本文亦有貢獻。更多關於架構方面的內容，讀者能夠經過搜索"ArchNotes"或點擊頁首的藍字，關注"高可用架構"公衆號，查看更多架構方面內容，獲取通往架構師之路的寶貴經驗。轉載請註明來自"高可用架構(ArchNotes)"微信公衆號。