聊聊PostgreSQL事務(wù)id那點(diǎn)事

IT那活兒發(fā)布于2023-01-11 13:20 / 2990人閱讀

點(diǎn)擊上方“IT那活兒”，關(guān)注后了解更多精彩內(nèi)容?。?！

提到事務(wù)ID，就不得不提PostgreSQL的MVCC機(jī)制。

PostgreSQL沒有類似于Oracle的undo來保證MVCC，其數(shù)據(jù)一致性通過使用一種多版本模型來維護(hù)。

這就意味著每個 SQL 語句看到的都只是一小段時間之前的數(shù)據(jù)快照，而不管底層數(shù)據(jù)的當(dāng)前狀態(tài)。

這樣可以保護(hù)語句不會看到可能由其他在相同數(shù)據(jù)行上執(zhí)行更新的并發(fā)事務(wù)造成的不一致數(shù)據(jù)，為每一個數(shù)據(jù)庫會話提供事務(wù)隔離。

主要有如下特點(diǎn)：

A) 基于事務(wù)ID

B) ?級多版本，且都存儲于頁面內(nèi)部

C) ?回滾段，?內(nèi)存儲

D) ?次update操作，產(chǎn)?記錄的兩個版本

MVCC元組結(jié)構(gòu)如下：

Xmin: 插入該行版本或者回滾的事務(wù)ID。對一個邏輯行的每一次更新都將創(chuàng)建一個新的行版本。

Xmax: 刪除事務(wù)或更新事務(wù)的事務(wù)ID，對于未刪除的行版本為0。對于一個可見的行版本，該列值也可能為非零。這通常表示刪除事務(wù)或更新事務(wù)還沒有提交，或者一個刪除或更新嘗試被回滾。

Cmin: 插入事務(wù)中的命令標(biāo)識符（從0開始）。

Cmax: 刪除事務(wù)中的命令標(biāo)識符，或者為0。

Ctid: 行版本在其表中的物理位置。注意盡管ctid可以被用來非?？焖俚囟ㄎ恍邪姹?，但是一個行的ctid會在被更新或者被VACUUM FULL移動時改變。因此，ctid不能作為一個長期行標(biāo)識符。應(yīng)使用主鍵來標(biāo)識邏輯行。

下面介紹下DML對應(yīng)的MVCC信息：

Insert場景：

從上圖我們可以看到insert時，xmin記錄了新插入行的事務(wù)id，xmax為0。

接下來我們update來看看：

先在session A執(zhí)行update。

session A沒有提交或者回滾的情況下，在session B查看事務(wù)ID如下：

此時我們發(fā)現(xiàn)在可見的行版本中，xmin記錄了回滾時的事務(wù)ID，xmax記錄了更新事務(wù)ID。

當(dāng)我們在session A commit之后，xmin的值就會變成該行更新時的事務(wù)ID值。

最后來看看delete：

先在session A執(zhí)行delete。

session A沒有提交或者回滾的情況下，在session B查看事務(wù)ID如下：

我們可以發(fā)現(xiàn)xmax記錄的是delete時的事務(wù)id。在session A commit之后， id = 10這行已不可見。

從上述DML的事務(wù)ID來看，PostgreSQL事務(wù)可見性需要依賴行頭的事務(wù)號，如果一個行版本的xmin(插入事務(wù)ID)小于或等于當(dāng)前事務(wù)ID，那這個就相當(dāng)于“過去的”事務(wù)，這是對其他session是可見的。

如果行版本的xmin(插入事務(wù)ID)大于當(dāng)前事務(wù)id，那它是屬于“未來的”，并且對當(dāng)前事務(wù)是不可見。但是因為事務(wù) ID 是32位的，且循環(huán)使用。一個長時間（超過 40 億個事務(wù)）運(yùn)行的集簇，XID 計數(shù)器回卷到 0，并且本來屬于過去的事務(wù)突然間就變成了屬于未來，這意味著之前的行均變成不可見。

這就是事務(wù)ID回卷問題，數(shù)據(jù)丟失。

為了避免發(fā)生這種情況，有必要至少每 20 億個事務(wù)就清理每個數(shù)據(jù)庫中的每個表。

事務(wù)ID復(fù)用圖：

清理原理如下：

PostgreSQL保留了一個特殊的XID（FrozenTransactionId），這個XID并不遵循普通XID的比較規(guī)則并且總是被認(rèn)為比任何普通 XID要老。

這也意味著這個插入XID為FrozenTransactionId的行版本對于所有當(dāng)前和未來事務(wù)來說當(dāng)然都是可見的。

這個行為就被稱之為凍結(jié)(freeze)，由VACUUM去把行標(biāo)記為凍結(jié)。

因此，一旦一個行版本被凍結(jié)，這樣它們對所有普通事務(wù)來說都是“在過去”，而不管回卷問題。并且這樣的行版本將一直有效直到被刪除，不管它有多舊。

這里介紹下涉及凍結(jié)的三個重要參數(shù)：

參數(shù)一：vacuum_freeze_table_age

VACUUM通常會跳過不含有任何死亡行版本的頁面，但是不會跳過那些含有帶舊 XID 值的行版本的頁面。要保證所有舊的行版本都已經(jīng)被凍結(jié)，需要對整個表做一次掃描。

vacuum_freeze_table_age就是控制VACUUM什么時候這樣做，如果該表經(jīng)過vacuum_freeze_table_age減去vacuum_freeze_min_age個事務(wù)還沒有被完全掃描過，則會強(qiáng)制一次全表清掃。

官檔建議vacuum_freeze_table_age設(shè)置成0.95 * autovacuum_freeze_max_age，因為0.95的乘數(shù)為在防回卷自動清理發(fā)生之前運(yùn)行一次手動VACUUM留出了一些空間。

將它設(shè)置得太接近可能導(dǎo)致防回卷自動清理，即使該表最近因為回收空間的目的被清理過，而較低的值將導(dǎo)致更頻繁的全表掃描。

參數(shù)二：autovacuum_freeze_max_age

任何包含比autovacuum_freeze_max_age配置參數(shù)所指定的年齡更老的 XID 的未凍結(jié)行的表上調(diào)用自動清理，即便自動清理被禁用，也會被強(qiáng)制開啟。

參數(shù)三：vacuum_freeze_min_age

說的通俗點(diǎn)就是事務(wù)信息保留的時間，其控制在其行版本被凍結(jié)前一個 XID 值應(yīng)該有多老。如果被凍結(jié)的行將很快會被再次修改，增加這個設(shè)置可以避免不必要的工作。

當(dāng)然這個不能設(shè)置過小，因為它可能導(dǎo)致VACUUM做無用的工作：如果該行在被替換成FrozenXID之后很快就被修改（導(dǎo)致該行獲得一個新的 XID），那么凍結(jié)一個行版本就是浪費(fèi)時間。

因此該設(shè)置應(yīng)該足夠大，這樣直到行不再可能被修改之前，它們都不會被凍結(jié)。

注：

VACUUM freeze操作涉及全表掃，對IO有一定影響，所以要盡量避免在高峰期自動觸發(fā)。應(yīng)該主動監(jiān)控數(shù)據(jù)庫年齡并在低峰期做VACUUM freeze。

vacuum freeze日常操作步驟：

1) 查詢數(shù)據(jù)庫年齡：

SELECT datname, age(datfrozenxid) FROM pg_database;

2) 查詢指定表的年齡：

select relname, age(relfrozenxid) as xid_age, pg_size_pretty(pg_table_size(oid)) as table_size from 
pg_class where relname = test1;

3) 這查詢按照最老的XID排序，查看大于1G而且是排名前20的表：

select relname, age(relfrozenxid) as xid_age, pg_size_pretty(pg_table_size(oid)) as table_size

from pg_class where relkind = r and pg_table_size(oid) > 1073741824

order by xid_age desc limit 20;

--vacuum前事務(wù)年齡為 61436

    relname | xid_age | table_size

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

 test_tab | 31260 | 4327 MB

4) 建議使用vacuum freeze來對指定的表進(jìn)行xid 凍結(jié)清理：

vacuum full freeze xxx.xxxx;

--vacuum后事務(wù)年齡變?yōu)?

    relname | xid_age | table_size

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

 test_tab | 0 | 4327 MB