流復制的原理：

物理復制也叫流復制，流復制的原理是主庫把WAL發(fā)送給備庫，備庫接收WAL后，進行重放。

邏輯復制的原理：

邏輯復制也是基于WAL文件，在邏輯復制中把主庫稱為源端庫，備庫稱為目標端數(shù)據(jù)庫，源端數(shù)據(jù)庫根據(jù)預先指定好的邏輯解析規(guī)則對WAL文件進行解析，把DML操作解析成一定的邏輯變化信息（標準SQL語句），源端數(shù)據(jù)庫把標準SQL語句發(fā)給目標端數(shù)據(jù)庫，目標端數(shù)據(jù)庫接收到之后進行應用，從而實現(xiàn)數(shù)據(jù)同步。

流復制和邏輯復制的區(qū)別：

流復制主庫上的事務提交不需要等待備庫接收到WAL文件后的確認，邏輯復制相反。

流復制要求主備庫的大版本一致，邏輯復制可以跨大版本的數(shù)據(jù)同步，也可以實現(xiàn)異構數(shù)據(jù)庫的數(shù)據(jù)同步。

流復制的主庫可讀寫，從庫只允許讀，邏輯復制的目標端數(shù)據(jù)庫要求可讀寫

流復制是對實例級別的復制（整個postgresql數(shù)據(jù)庫），邏輯復制是選擇性的復制一些表，所以是對表級別的復制。

流復制有主庫的DDL、DML操作，邏輯復制只有DML操作。

補充：PostgreSQL 同步流復制原理和代碼淺析

背景

數(shù)據(jù)庫ACID中的持久化如何實現(xiàn)

數(shù)據(jù)庫ACID里面的D，持久化。 指的是對于用戶來說提交的事務，數(shù)據(jù)是可靠的，即使數(shù)據(jù)庫crash了，在硬件完好的情況下，也能恢復回來。

PostgreSQL是怎么做到的呢，看一幅圖，畫得比較丑，湊合看吧。

假設一個事務，對數(shù)據(jù)庫做了一些操作，并且產(chǎn)生了一些臟數(shù)據(jù)，首先這些臟數(shù)據(jù)會在數(shù)據(jù)庫的shared buffer中。

同時，產(chǎn)生這些臟數(shù)據(jù)的同時也會產(chǎn)生對應的redo信息，產(chǎn)生的REDO會有對應的LSN號（你可以理解為REDO 的虛擬地址空間的一個唯一的OFFSET，每一筆REDO都有），這個LSN號也會記錄到shared buffer中對應的臟頁中。

walwriter是負責將wal buffer flush到持久化設備的進程，同時它會更新一個全局變量，記錄已經(jīng)flush的最大的LSN號。

bgwriter是負責將shared buffer的臟頁持久化到持久化設備的進程，它在flush時，除了要遵循LRU算法之外，還要通過LSN全局變量的比對，來保證臟頁對應的REDO記錄已經(jīng)flush到持久化設備了，如果發(fā)現(xiàn)還對應的REDO沒有持久化，會觸發(fā)WAL writer去flush wal buffer。 (即確保日志比臟數(shù)據(jù)先落盤)

當用戶提交事務時，也會產(chǎn)生一筆提交事務的REDO，這筆REDO也攜帶了LSN號。backend process 同樣需要等待對應LSN flush到磁盤后才會返回給用戶提交成功的信號。(保證日志先落盤，然后返回給用戶)

數(shù)據(jù)庫同步復制原理淺析

同步流復制，即保證standby節(jié)點和本地節(jié)點的日志雙雙落盤。

PostgreSQL使用另一組全局變量，記錄同步流復制節(jié)點已經(jīng)接收到的XLOG LSN，以及已經(jīng)持久化的XLOG LSN。

用戶在發(fā)起提交請求后，backend process除了要判斷本地wal有沒有持久化，同時還需要判斷同步流復制節(jié)點的XLOG有沒有接收到或持久化（通過synchronous_commit參數(shù)控制）。

如果同步流復制節(jié)點的XLOG還沒有接收或持久化，backend process會進入等待狀態(tài)。

數(shù)據(jù)庫同步復制代碼淺析

對應的代碼和解釋如下：

CommitTransaction @ src/backend/access/transam/xact.c
RecordTransactionCommit @ src/backend/access/transam/xact.c