劉偉

劉偉，云和恩墨軟件開發(fā)部研究院研究員,；前微博DBA,，主要研究方向?yàn)殚_源數(shù)據(jù)庫,，分布式數(shù)據(jù)庫，擅長(zhǎng)自動(dòng)化運(yùn)維以及數(shù)據(jù)庫內(nèi)核研究,。

號(hào)外號(hào)外：2018“數(shù)據(jù)和云”精彩文章集錦點(diǎn)擊“閱讀原文”即可免費(fèi)下載,。

提語: 就復(fù)制功能來說,從遠(yuǎn)不能勝任，到功能完備種種包含在內(nèi),，PG雖然腳步略遲,，但很快地走完了這些路徑，的確當(dāng)?shù)闷鹨粋€(gè)“功能最強(qiáng)大的開源數(shù)據(jù)庫”的稱呼,。

原本我準(zhǔn)備的下一個(gè)話題,，是PostgreSQL的Redo的討論，但就PG的實(shí)現(xiàn)看,，對(duì)運(yùn)維來說,，redo的機(jī)制很少需要特別關(guān)注，所以就把redo話題下的復(fù)制主題,，單獨(dú)拉出來整理了一下,，其中第一部分，就是PG的復(fù)制這個(gè)特性的歷史來由,。

復(fù)制,，曾經(jīng)是PGer心中永遠(yuǎn)揮之不去的傷口，在PG 9.0之前的版本,，如果想要做一個(gè)PG的數(shù)據(jù)庫主從,，只能人工（PG內(nèi)置了歸檔文件的shell調(diào)度操作）不斷地復(fù)制wal日志(并且只能復(fù)制到當(dāng)前在寫的wal的前一個(gè)WAL日志)到從庫（姑且這么叫它）,，這個(gè)從庫需要設(shè)置為恢復(fù)模式,，不可對(duì)外提供服務(wù)。

從我個(gè)人的看法而言,，PG在功能性上,，的確是強(qiáng)于MySQL的。但是為什么在互聯(lián)網(wǎng)業(yè)務(wù)早期不被看好并選用,，主要原因之一,，就是其無法進(jìn)行讀能力的擴(kuò)展，而在互聯(lián)網(wǎng)業(yè)務(wù)之外,，對(duì)事務(wù),，數(shù)據(jù)安全講究的人來說，PG對(duì)比Oracle,，其差距也是肉眼可見的,。

MySQL還是一個(gè)跑在文件的SQL執(zhí)行器（其衍生出來的MyISAM真的最多只能說是一個(gè)帶B樹的文件訪問器）的時(shí)候，就已經(jīng)做出來復(fù)制這個(gè)關(guān)鍵特性,，并用這個(gè)機(jī)制,，終于等到InnoDB的引入，成為了一個(gè)“真正的數(shù)據(jù)庫”。對(duì)于早年的互聯(lián)網(wǎng)業(yè)務(wù),，MySQL這種快速擴(kuò)容從庫,，擴(kuò)展讀能力的機(jī)制，對(duì)互聯(lián)網(wǎng)業(yè)務(wù)這種先天讀遠(yuǎn)多于寫的形態(tài),，簡(jiǎn)直是天作之合,。

而PG，在那個(gè)時(shí)代而言,，的確是比較被動(dòng)的,，但終于隨著時(shí)間推移，逐步實(shí)現(xiàn)了主從復(fù)制的種種特性,。

時(shí)間來到2010年（第一波互聯(lián)網(wǎng)大潮早已過去,，第二波互聯(lián)網(wǎng)大潮也將要過去，大創(chuàng)業(yè)時(shí)代即將來臨）,，PG發(fā)布了版本9.0,，其中最重要的特性之一，就是流復(fù)制機(jī)制的實(shí)現(xiàn),，解決了兩個(gè)問題：一個(gè)是通過網(wǎng)絡(luò)連接,，從庫直接去拉redo日志（redo復(fù)制，這個(gè)也是MySQLer心中痛點(diǎn)?。?，而非從主庫走操作系統(tǒng)命令復(fù)制過來，避免了對(duì)這個(gè)復(fù)制機(jī)制本身維護(hù)的復(fù)雜性,；第二個(gè),，就是改造出來Hot Standby機(jī)制，也就是在從庫應(yīng)用redo的同時(shí),，也允許從庫提供只讀的select服務(wù),。

這里實(shí)現(xiàn)的復(fù)制，當(dāng)然還只是異步復(fù)制,，而且機(jī)制我認(rèn)為很怪異：首先,，把從主庫走操作系統(tǒng)命令復(fù)制wal日志（不包含最新的正在被寫入的wal文件）全部執(zhí)行recovery之后，再發(fā)起一個(gè)網(wǎng)絡(luò)連接到主庫讀最新的wal記錄,，主庫的連接信息從recovery.conf文件中讀?。∕ySQL是change master命令之后，直接存在masterinfo文件里面,，或者每次start slave的時(shí)候,，手工指定）。

而如果從庫想要中斷主從復(fù)制,，不是執(zhí)行一個(gè)stop slave（MySQL）命令,，而是在操作系統(tǒng)設(shè)置一個(gè)trigger文件,。

2011年，pg 9.1發(fā)布,，其中引入的新復(fù)制機(jī)制,，就是同步復(fù)制這個(gè)大殺器了。

在MySQL中,，有個(gè)被稱為“半同步復(fù)制”的機(jī)制,，就是說當(dāng)主庫收到客戶端的commit發(fā)出來之后，直到從庫接受完成這個(gè)事務(wù)所有的event,，并且確認(rèn)flush到relay日志之后,，這個(gè)commit才會(huì)返回給客戶端，客戶端收到commit的時(shí)候,，就代表即便主庫宕機(jī),，數(shù)據(jù)也必然已經(jīng)存在于從庫，也就是“沒有數(shù)據(jù)丟失”,。

簡(jiǎn)單概括來說,，PG在9.1中實(shí)現(xiàn)的同步復(fù)制，也是這么一回事,，把關(guān)鍵字event替換成redo,，relay日志替換為從庫wal日志就可以。

注:下圖僅為相關(guān)流程的簡(jiǎn)化圖,僅保留了與復(fù)制相關(guān)的邏輯,對(duì)于WAL子系統(tǒng)沒有詳細(xì)展開,后續(xù)其他圖片一樣,都是簡(jiǎn)化圖.

但實(shí)現(xiàn)的細(xì)節(jié)上,，還是有很多區(qū)別的（MySQL的討論基礎(chǔ)版本一律為MySQL 8.0——好吧,，我知道這個(gè)有些不公平）。

比如允許在回話或者單個(gè)事務(wù)級(jí)別控制,，區(qū)分“重要”事務(wù)與“不重要”的事務(wù),，MySQL中，半同步會(huì)在遇到從庫響應(yīng)超時(shí)的時(shí)候,，進(jìn)行自動(dòng)的全庫降級(jí)（rpl_semi_sync_master_wait_no_slave控制）,。

比如其設(shè)置哪些從庫是半同步復(fù)制的時(shí)候,，是通過逗號(hào)切割的方式指定一個(gè)或者多個(gè)（但只支持其中的某一個(gè)作為同步從庫,，首先選取第一個(gè)作為同步節(jié)點(diǎn)，如果第一個(gè)出問題,，則選取第二個(gè),，以此類推），而MySQL的半同步復(fù)制,，則是保障“只要有rpl_semi_sync_master_wait_for_slave_count個(gè)從庫接收到”這個(gè)邊界點(diǎn),。

比如由于rollback實(shí)現(xiàn)機(jī)制問題，PG的rollback不會(huì)受到同步復(fù)制阻塞,，而MySQL在特定情況(可以參考https://my.oschina.net/llzx373/blog/282768 這篇文中,，討論的在rollback情況下,，也會(huì)產(chǎn)生binlog的討論)下，即便是rollback,，也需要等待半同步響應(yīng),。

比如事務(wù)可見性上，PG是直接通過事務(wù)id控制,，而MySQL在5.7引入rpl_semi_sync_master_wait_point來處理(MySQL 半同步復(fù)制在5.7之前,，主庫的其他事務(wù)可以看到在等待半同步復(fù)制返回的事務(wù)的數(shù)據(jù)，即便這個(gè)事務(wù)尚未對(duì)客戶端返回commit)

順帶一提,，pg_basebackup這個(gè)命令也是這個(gè)版本中引入,，主要用來搞從庫和數(shù)據(jù)庫備份。

PG的從庫也可以通過報(bào)告查詢所需要的最老事務(wù)點(diǎn)給主庫的方式,，避免主庫的數(shù)據(jù)清理（vacuum）清理掉從庫查詢所需要的數(shù)據(jù),，當(dāng)然，從庫的長(zhǎng)時(shí)間查詢也會(huì)導(dǎo)致主庫文件放大,，具體使用決策上,，值得考量。

而在控制復(fù)制啟停的方式上,，也提供了sql函數(shù)調(diào)用,，而非只是純粹依賴觸發(fā)文件。（pg_wal_replay_pause(),，pg_wal_replay_resume()）

級(jí)聯(lián)復(fù)制,，也就是A->B->C這種形態(tài)的復(fù)制，其最大的意義,，是降低主庫的復(fù)制負(fù)載壓力,。

復(fù)制負(fù)載這個(gè)問題的來源，是類似互聯(lián)網(wǎng)業(yè)務(wù)中,，寫少讀多,，一個(gè)主庫，可能要承擔(dān)幾十個(gè)從庫（記得有次春節(jié)時(shí)候,，我們給一個(gè)主庫擴(kuò)出幾十個(gè)從庫）的日志發(fā)送行為,，無論從磁盤壓力還是網(wǎng)絡(luò)帶寬來說，級(jí)聯(lián)復(fù)制都是有必要引入的,。

當(dāng)然,，級(jí)聯(lián)復(fù)制的C，就必然是異步復(fù)制了,。

pg_basebackup也可以在從庫執(zhí)行備份了,，可以避開備份對(duì)主庫的性能影響。

而在同步復(fù)制上,，新增了一個(gè)remote_write 級(jí)別,，意思是,，只要從庫接收到wal日志就可以，不需要保障必須flush到磁盤的情況下,，就可以確認(rèn)commit成功了,。

這個(gè)版本沒有本質(zhì)性的特性變更，但在易用性和性能上,，做了相當(dāng)大的改進(jìn),。

比如當(dāng)多個(gè)從庫中的某一個(gè)從庫被提升為主庫之后，其他從庫可以直接切換過去,，而在之前,，必須重新同步。

比如pg_basebackup可以直接生成一個(gè)recovery.conf文件,。

這個(gè)版本開始,，xlog（wal日志）支持邏輯解析方式的導(dǎo)出，用于邏輯復(fù)制,，或者跨數(shù)據(jù)庫類型復(fù)制這種操作,甚至邏輯復(fù)制連同步復(fù)制都可以支持,，唯一的限制，是邏輯復(fù)制只能作用于單庫而非全局,。

而replication slot的概念,，也是這個(gè)版本開始引入。

之前提到過,，為了避免主庫清理掉從庫尚需使用的數(shù)據(jù),，從庫需要給主庫報(bào)告所需要的事務(wù)點(diǎn)信息，在9.4開始,，這個(gè)機(jī)制被單獨(dú)提出來,，稱為replication slot，其主要的作用,，是為物理復(fù)制,，以及邏輯復(fù)制，提供維持事務(wù)點(diǎn)信息的視圖,，避免從庫連接斷開等原因?qū)е碌臄?shù)據(jù)清理,。

而在復(fù)制應(yīng)用上，這個(gè)版本開始,，PG增加了延遲復(fù)制這個(gè)特性,，對(duì)于誤刪除操作等諸多問題，這個(gè)特性可以讓數(shù)據(jù)恢復(fù)時(shí)間盡可能地縮短了,。

這個(gè)版本沒有大的變更，主要是以下一些內(nèi)容：

允許WAL日志以壓縮形態(tài)傳輸?shù)綇膸?，以主從庫CPU換取較低的網(wǎng)絡(luò)消耗,。

recovery.conf的主庫連接信息,，可以以URI（postgres://）的形式來寫。

新增了wal_retrieve_retry_interval 參數(shù)來控制從庫失敗后的重試,。

說個(gè)題外話,，PG在9.6開始，支持了并行查詢,，并在隨后的版本中做到了很大的增強(qiáng),，這點(diǎn)也是我認(rèn)為PG對(duì)比MySQL上，有絕對(duì)優(yōu)勢(shì)的一個(gè)特性,。而PG的主要槽點(diǎn)之一vacuum凍結(jié),，也是在這個(gè)版本引入不再重復(fù)處理已經(jīng)完全凍結(jié)的數(shù)據(jù)塊這個(gè)重要特性的。

前文中提到,，MySQL有個(gè)參數(shù)rpl_semi_sync_master_wait_for_slave_count控制同步的從庫數(shù)量,，而PG則是從設(shè)定的列表中選取某一個(gè)，在9.6開始,，這個(gè)設(shè)計(jì)被變更為,，可以等到wal被確認(rèn)寫入多個(gè)從庫之后，再返回commit,。

synchronous_standby_names參數(shù)也不僅僅是逗號(hào)切割的列表,，變成了 n(s1,s2,s3)這種形態(tài)，讓前n個(gè)數(shù)據(jù)庫達(dá)到wal條件后確認(rèn)commit,。

在前面同步復(fù)制的討論中,，提到PG的同步復(fù)制，與MySQL半同步復(fù)制實(shí)現(xiàn)機(jī)理基本類似,，但在9.6開始,，新增了remote_apply 這個(gè)同步點(diǎn)，也就是,，直到從庫應(yīng)用了對(duì)應(yīng)的wal日志,，主庫才能返回commit成功，可以做到主庫提交從庫立即可見的效果,。我相信不止我一個(gè)人被開發(fā)問到,，說我主庫寫入的語句，到從庫去查,，為啥查不著的問題,，而在當(dāng)代的大型項(xiàng)目中，可能上層應(yīng)用直接調(diào)用讀寫的假設(shè),，就是寫入立即可讀,，下層如果貿(mào)然采用了傳統(tǒng)的讀寫分離手段，可能就會(huì)導(dǎo)致上層應(yīng)用無法馬上看到數(shù)據(jù)的問題了,，這個(gè)問題再摻和上主從延遲的種種糾結(jié),，是我在傳統(tǒng)行業(yè)客戶中,，遇到最多的問題之一。

邏輯復(fù)制在這個(gè)版本得到了極大的增強(qiáng),。

首先,，是支持了邏輯復(fù)制這個(gè)特性本身。雖然9.4開始,，xlog就已經(jīng)可以解析并提供給邏輯復(fù)制使用,，但PG在當(dāng)時(shí)，并沒有內(nèi)置邏輯復(fù)制的相關(guān)組件,，在10版本開始,，支持了到表級(jí)別的邏輯復(fù)制，并且支持跨大版本,，跨操作系統(tǒng),，跨機(jī)器架構(gòu)之間的邏輯復(fù)制，靈活性上遠(yuǎn)勝物理復(fù)制（MySQL的binlog復(fù)制就是如此）,。

synchronous_standby_names再次變更了語法,，包括first和any兩個(gè)語義，first指定的列表的話,，會(huì)按照順序優(yōu)先級(jí)確認(rèn)返回的從庫響應(yīng)達(dá)到指定數(shù)量(比如first 1（s1,，s2）就類似舊的實(shí)現(xiàn)，選取第一個(gè)作為同步點(diǎn),，如果第一個(gè)s1失敗了,，再選取第二個(gè)s2作為同步點(diǎn))，而any語義的話,，舉個(gè)例子,，類似any 2（s1,s2,s3）這種，則是允許三個(gè)從庫中,，任意兩個(gè)從庫只要返回同步成功,，就可以確認(rèn)commit了。any來說,，更類似MySQL中半同步的確認(rèn)語義,。

recovery模式的恢復(fù)目標(biāo)點(diǎn)，除了timestamp,，事務(wù)id之外,，也支持了LSN號(hào)，恢復(fù)的時(shí)候更加靈活了,。

另外估計(jì)是由于slot維持wal,，導(dǎo)致一些為臨時(shí)會(huì)話維護(hù)的slot導(dǎo)致wal積累（比如pg_basebackup，每次備份都需要?jiǎng)?chuàng)建slot，備份完成后,，slot還需要處理掉）,，這個(gè)版本開始,，slot支持僅為當(dāng)前會(huì)話提供的臨時(shí)slot避免這個(gè)問題,。

11大版本的主要功能變化，是分區(qū)表終于可以用了,，而不是必須得采用第三方插件,，包括hash分區(qū)，分區(qū)表上的主鍵,，外鍵,，全局索引，觸發(fā)器這些,，都終于支持了,。

而在復(fù)制特性上，這個(gè)版本基本上沒有什么大的變化,，都是些邊邊角角的修補(bǔ),。

比方在做備份的時(shí)候，增加對(duì)數(shù)據(jù)塊的校驗(yàn),。

比如pg_stat_wal_receiver 視圖,，增加了機(jī)器與端口信息。

乏陳可述,，但就PG目前在復(fù)制上已經(jīng)做的事情來看,，的確也沒有更強(qiáng)的需求來驅(qū)動(dòng)這方面的進(jìn)一步增強(qiáng)。

從遠(yuǎn)不能勝任,，到功能完備種種包含在內(nèi),，PG雖然腳步略遲，但很快地走完了這些路徑,，就功能性而言,，的確當(dāng)?shù)闷鹨粋€(gè)“功能最強(qiáng)大的開源數(shù)據(jù)庫”的稱呼。

佛門講修行,，其中一道障礙稱為“知見障”,，是說對(duì)一個(gè)東西認(rèn)知越多，看其他東西的時(shí)候,，成見也就越多,，也就越難有一個(gè)清晰的認(rèn)知（注：這個(gè)是知見障的一種解釋，而且應(yīng)該是佛教禪宗本土化后的頓宗解釋,，原始佛教中,，這個(gè)詞應(yīng)該是類似六根不凈的一個(gè)概念，不是我這里要表達(dá)的意思）。

的確,，我自己的感覺也好,，和其他人聊數(shù)據(jù)庫時(shí)候的感覺也罷，每個(gè)人都有以自己熟悉的,，認(rèn)知的“數(shù)據(jù)庫”來去看其他數(shù)據(jù)庫的習(xí)慣,。

以我自己來說。

比如我對(duì)pg的vacuum這么糾結(jié),，是因?yàn)檫@個(gè)問題上,，在MySQL，Oracle這倆我熟知的數(shù)據(jù)庫中,，都是（相對(duì)）很好地解決了這個(gè)問題的,，而PG非得別別扭扭地不處理——是的，是可以有很多人工策略可以搞,，是有很多參數(shù)設(shè)置合適可以避開,，但為什么非得我去管？它自個(gè)安安靜靜地處理好不就得了,？哪怕是最低限度的單表上的并行vacuum也可以啊(MySQL 5.6之前單線程purge也是一個(gè)大坑,后來就改多線程了),。

比如對(duì)于DB2，這個(gè)是我學(xué)校學(xué)習(xí)數(shù)據(jù)庫時(shí)候的教材數(shù)據(jù)庫,，我的諸多知識(shí)都是從這個(gè)數(shù)據(jù)庫上學(xué)會(huì)的,，當(dāng)我之后不久去看Oracle的時(shí)候，第一個(gè)反應(yīng)是,，隔離級(jí)別到哪里去了,？——Oracle的隔離級(jí)別，除了RC,，Serializable之外,，其他隔離級(jí)別都是通過變通方式實(shí)現(xiàn)的，而DB2,，是有很齊全的4個(gè)隔離級(jí)別的（雖然各個(gè)隔離級(jí)別名字和SQL標(biāo)準(zhǔn)的名字不是很一致）——后來我給別人講隔離級(jí)別課程的時(shí)候,，都是用DB2講課，而不是拉一個(gè)其他數(shù)據(jù)庫出來（MySQL InnoDB在RR處理了幻讀,，那Serializable級(jí)別和RR的區(qū)別,，解釋起來就很費(fèi)工夫，而PG的幾個(gè)隔離級(jí)中,，讀未提交讀不到臟讀,，可重復(fù)讀讀不到幻讀就更不用說了），我不知道有多少人拿著Oracle這種講隔離級(jí)別,，但就我個(gè)人的感覺來說,，哪怕到現(xiàn)在,，依然感覺非常別扭。

如果說要打破成見,，莫過于了解下其他的東西,，切切實(shí)實(shí)地了解其優(yōu)缺點(diǎn)，做到在“應(yīng)該用的地方去用”,，在技術(shù)成長(zhǎng)上,，相信會(huì)有更好地進(jìn)步。

另外,，由于不同數(shù)據(jù)庫之間,，雖然以外部視角看,，都是SQL語言控制的數(shù)據(jù)庫,，但內(nèi)部實(shí)現(xiàn)的種種細(xì)節(jié)卻都是全然不同的，作為DBA來說,，如果不想要讓自己的職業(yè)生命,，被迫維系在某一個(gè)數(shù)據(jù)庫上的話（DB2前車之鑒，我當(dāng)初差點(diǎn)入走了這條路）,，那么打開思路,，去切實(shí)了解一下其他數(shù)據(jù)庫的種種特點(diǎn)，也不失為一個(gè)很好的防御措施,。

http://mysql./monthly/2015/12/05/

https://www./docs/11/release.html

https://dev./doc/refman/8.0/en/replication-semisync.html

https://my.oschina.net/llzx373/blog/282768 mysql復(fù)制對(duì)事務(wù)的處理

原創(chuàng)：劉偉

關(guān)于PostgreSQL的復(fù)制特性大家有什么見解,，歡迎在評(píng)論區(qū)交流回復(fù)。