PostgreSQL Replication之第二章 理解PostgreSQL的交易記錄（5）

標籤：

2.5 XLOG的內部結構

我們將使用事務貫穿本書，並讓您在技術層面上更深地洞察事情是如果工作的，我們已經增加了這部分專門處理XLOG的內部工作機制。我們會盡量避免前往下降到C級，因為這將超出本書的範圍，但我們會為您提供希望足夠深的見解。

2.5.1 理解XLOG記錄

對XLOG所做的更改是基於記錄的。這意味著什嗎？讓我們假設您在給一個表添加一行資料：

test=# INSERT INTO t_test VALUES (1, ‘hans‘);

INSERT 0 1

在這個例子中，我們正在插入一個含有兩列的表。為了這個例子，我們要假定這兩個列被索引。

記得我們之前瞭解到：XLOG的目的是為了保持這些資料檔案安全。所以，這個操作將觸發一系列的XLOG條目。首先，與表相關的資料檔案將被寫入。然後，索引相關的條目將被建立。最後一個COMMIT記錄被發送到日誌。

並不是所有的XLOG記錄都是平等的：有各種類型的XLOG記錄(例如，heap，btree，clog,storage，gin，以及standby 記錄，僅舉幾例)。

XLOG記錄向後連結。這樣，每個入口指向檔案中前面的條目。通過這種方式，我們可以完全相信，只要我們要到指向前一個條目的指標，我們就已經找到了記錄的結尾。

使XLOG具有確定性

正如您所看到的，一個改變可以觸發許多XLOG條目。對所有種類的語句來說，這都是真的；例如一個大的DELETE語句可以很容易造成上百萬的變化。其原因是PostgreSQL不能簡單地把SQL本身寫入日誌；它必須真實記錄對錶所做的物理改變。這是為什嗎？考慮一下下面的例子：

test=# DELETE FROM t_test WHERE id > random();

DELETE 5335

函數random每次被調用時，都產生不同的輸出，因此，我們不能僅僅把SQL寫入日誌，因為如果在重放期間它被執行，這不能保證給我們提供相同的結果。

使XLOG可靠

在整個資料庫執行個體中，XLOG本身是最關鍵和最敏感的部分之一。因此，我們必須採取特殊照顧，以確保做所有可能的事情來保護它。在崩潰的情況下，如果沒有XLOG，資料庫執行個體通常會遭遇不幸。

在內部，PostgreSQL採取特殊的預防措施來處理XLOG：

• 使用 CRC32 校正和

• 禁用訊號

• 空間分配

首選，每條XLOG記錄包含一個CRC32校正和。這允許我們檢查日誌在啟動時的完整性。崩潰之前的最後一次寫操作完全沒有訊息是完全可行的，   因此，一個校正和絕對有助於解決這個問題。校正和由PostgreSQL自動計算，並且使用者沒有必要關心這個明確的功能。

除了校正和，當寫XLOG時，PostgreSQL將暫時禁用訊號。這給了安全一些額外的層級，並在某種程度上降低了愚蠢的極端情況的可能性。

最後，PostgreSQL使用一個固定大小的XLOG。XLOG的大小由檢查點段以及checkpoint_completion_target確定。

PostgreSQL交易記錄大小的計算方法如下：

checkpoint_segments + wal_keep_segments + 1 files

重要的是，如果某個東西的大小是固定的，它很少用盡空間。

[在基於交易記錄複製的情況下，如果交易記錄無法存檔，我們可以用盡XLOG目錄的空間。]

您可以在下一個章節瞭解這個主題更多的內容。

2.5.2 LSN和共用緩衝區的互動

如果您要修複一個表，您必須確保按照正確的順序修複表；如果一行資料在它實際產生之前被刪除，這將是一場災難。因此XLOG為您提供了所有改變的順序。在內部，通過邏輯序號(LSN)來反映這個順序。對XLOG來說LSN是必不可少的。每個XLOG條目將被直接分配給一個LSN。

在前面的一個章節，我們已經討論了一致性層級。synchronous_commit設定為off，即便XLOG記錄還沒有被重新整理到磁碟，用戶端也會獲得一個OK。因為更改必須在快取中反映，並且由於寫XLOG必須在寫資料表之前完成，系統必須確保並不是在共用快取中的所有塊都可以被立即寫出來。LSN會保證，如果相應的變化已經寫到了XLOG，我們只能從共用快取把資料區塊寫到資料檔案。寫入XLOG是根本，在崩潰後，違反了這個規則肯定會導致問題。

調試XLOG並把它們放在一起

既然我們已經知道了XLOG的基本工作原理，我們就可以把它們放在一起並研究一下XLOG。到了PostgreSQL9.2，工作原理如下：我們要從原始碼編譯PostgreSQL。在我們這樣做之前，我們應該修改位於src/include/pg_config_manual.h的檔案。在大約250行，我們可以取消WAL_DEBUG的注釋並正常編譯。這將允許我們設定一個稱為wal_debug的用戶端變數：

test=# SET client_min_messages TO log;

SET

test=# SET wal_debug TO on;

SET

除此之外，我們要設定client_min_messages，以確保日誌訊息會到達我們的用戶端。

我們為我們的測試使用下面的表結構：
test=# \d t_test

Table "public.t_test"

Column | Type | Modifiers

--------+---------+-----------

id | integer |

name | text |

Indexes:

"idx_id"btree (id)

"idx_name"btree (name)

如果PostgreSQL已經正常編譯(只有這樣)，我們將在螢幕上看到關於XLOG的資訊：

test=# INSERT INTO t_test VALUES (1, ‘hans‘);

LOG: INSERT @ 0/17C4680: prev 0/17C4620; xid 1009; len 36: Heap -

insert(init): rel 1663/16384/16394; tid 0/1

LOG: INSERT @ 0/17C46C8: prev 0/17C4680; xid 1009; len 20: Btree

- newroot: rel 1663/16384/16397; root 1 lev 0

LOG: INSERT @ 0/17C4700: prev 0/17C46C8; xid 1009; len 34: Btree

- insert: rel 1663/16384/16397; tid 1/1

LOG: INSERT @ 0/17C4748: prev 0/17C4700; xid 1009; len 20: Btree

- newroot: rel 1663/16384/16398; root 1 lev 0

LOG: INSERT @ 0/17C4780: prev 0/17C4748; xid 1009; len 34: Btree

- insert: rel 1663/16384/16398; tid 1/1

LOG: INSERT @ 0/17C47C8: prev 0/17C4780; xid 1009; len 12:

Transaction - commit: 2013-02-25 18:20:46.633599+01

LOG: XLOG flush request 0/17C47F8; write 0/0; flush 0/0

正如本章所述，PostgreSQL將先向表本身(heap)添加一行。然後XLOG包含所有與索引相關的條目。最後，添加一個提交記錄。

總之，156位元組已經能夠成功寫入XLOG；這遠遠超過了我們實際添加的資料。一致性，效能(各項指標)和可靠性都配備了價格標籤。

2.6 總結

本章，您已經瞭解了PostgreSQL的事物日誌的目的。我們已經廣泛地討論的磁碟上的資料格式和一些非常重要的主題，例如：一致性和效能。在下一章中，我們複製我們的第一個資料庫時就會需要所有這些主題。

下一章將建立在您剛才學到的主題之上，重點關注即時恢複。目標是使PostgreSQL及時恢複到一個特定的時間點並提供好像後面的事務從來沒有發生過的資料。

原文地址：http://www.cnblogs.com/songyuejie/p/4743344.html

原文地址：http://www.cnblogs.com/songyuejie/p/4743344.html

PostgreSQL Replication之第二章 理解PostgreSQL的交易記錄（5）