資訊專欄INFORMATION COLUMN
01
提到事務ID，就不得不提PostgreSQL的MVCC機制。
PostgreSQL沒有類似于Oracle的undo來保證MVCC，其數據一致性通過使用一種多版本模型來維護。
這就意味著每個 SQL 語句看到的都只是一小段時間之前的數據快照，而不管底層數據的當前狀態。
這樣可以保護語句不會看到可能由其他在相同數據行上執行更新的并發事務造成的不一致數據，為每一個數據庫會話提供事務隔離。
主要有如下特點：
A) 基于事務ID
B) ?級多版本，且都存儲于頁面內部
C) ?回滾段，?內存儲
D) ?次update操作，產?記錄的兩個版本
02
MVCC元組結構如下：
Xmin: 插入該行版本或者回滾的事務ID。對一個邏輯行的每一次更新都將創建一個新的行版本。
Xmax: 刪除事務或更新事務的事務ID，對于未刪除的行版本為0。對于一個可見的行版本，該列值也可能為非零。這通常表示刪除事務或更新事務還沒有提交，或者一個刪除或更新嘗試被回滾。
Cmin: 插入事務中的命令標識符（從0開始）。
Cmax: 刪除事務中的命令標識符，或者為0。
Ctid: 行版本在其表中的物理位置。注意盡管ctid可以被用來非常快速地定位行版本，但是一個行的ctid會在被更新或者被VACUUM FULL移動時改變。因此，ctid不能作為一個長期行標識符。應使用主鍵來標識邏輯行。
03
下面介紹下DML對應的MVCC信息：
Insert場景：
從上圖我們可以看到insert時，xmin記錄了新插入行的事務id，xmax為0。
接下來我們update來看看：
先在session A執行update。
session A沒有提交或者回滾的情況下，在session B查看事務ID如下：
此時我們發現在可見的行版本中，xmin記錄了回滾時的事務ID，xmax記錄了更新事務ID。
當我們在session A commit之后，xmin的值就會變成該行更新時的事務ID值。
最后來看看delete：
先在session A執行delete。
session A沒有提交或者回滾的情況下，在session B查看事務ID如下：
我們可以發現xmax記錄的是delete時的事務id。在session A commit之后， id = 10這行已不可見。
04
從上述DML的事務ID來看，PostgreSQL事務可見性需要依賴行頭的事務號，如果一個行版本的xmin(插入事務ID)小于或等于當前事務ID，那這個就相當于“過去的”事務，這是對其他session是可見的。
如果行版本的xmin(插入事務ID)大于當前事務id，那它是屬于“未來的”，并且對當前事務是不可見。但是因為事務 ID 是32位的，且循環使用。一個長時間（超過 40 億個事務）運行的集簇，XID 計數器回卷到 0，并且本來屬于過去的事務突然間就變成了屬于未來，這意味著之前的行均變成不可見。
這就是事務ID回卷問題，數據丟失。
為了避免發生這種情況，有必要至少每 20 億個事務就清理每個數據庫中的每個表。
事務ID復用圖：
清理原理如下：
PostgreSQL保留了一個特殊的XID（FrozenTransactionId），這個XID并不遵循普通XID的比較規則 并且總是被認為比任何普通 XID要老。
這也意味著這個插入XID為FrozenTransactionId的行版本對于所有當前和未來事務來說當然都是可見的。
這個行為就被稱之為凍結(freeze)，由VACUUM去把行標記為凍結。
因此，一旦一個行版本被凍結，這樣它們對所有普通事務來說都是“在過去”，而不管回卷問題。并且這樣的行版本將一直有效直到被刪除，不管它有多舊。
05
這里介紹下涉及凍結的三個重要參數：
參數一：vacuum_freeze_table_age
VACUUM通常會跳過不含有任何死亡行版本的頁面，但是不會跳過那些含有帶舊 XID 值的行版本的頁面。要保證所有舊的行版本都已經被凍結，需要對整個表做一次掃描。
vacuum_freeze_table_age就是控制VACUUM什么時候這樣做，如果該表經過vacuum_freeze_table_age減去vacuum_freeze_min_age個事務還沒有被完全掃描過，則會強制一次全表清掃。
官檔建議vacuum_freeze_table_age設置成0.95 * autovacuum_freeze_max_age，因為0.95的乘數為在防回卷自動清理發生之前運行一次手動VACUUM留出了一些空間。
將它設置得太接近可能導致防回卷自動清理，即使該表最近因為回收空間的目的被清理過，而較低的值將導致更頻繁的全表掃描。
參數二：autovacuum_freeze_max_age
任何包含比autovacuum_freeze_max_age配置參數所指定的年齡更老的 XID 的未凍結行的表上調用自動清理，即便自動清理被禁用，也會被強制開啟。
參數三：vacuum_freeze_min_age
說的通俗點就是事務信息保留的時間，其控制在其行版本被凍結前一個 XID 值應該有多老。如果被凍結的行將很快會被再次修改，增加這個設置可以避免不必要的工作。
當然這個不能設置過小，因為它可能導致VACUUM做無用的工作：如果該行在被替換成FrozenXID之后很快就被修改（導致該行獲得一個新的 XID），那么凍結一個行版本就是浪費時間。
因此該設置應該足夠大，這樣直到行不再可能被修改之前，它們都不會被凍結。
注：
VACUUM freeze操作涉及全表掃，對IO有一定影響，所以要盡量避免在高峰期自動觸發。應該主動監控數據庫年齡并在低峰期做VACUUM freeze。
06
vacuum freeze日常操作步驟：
1) 查詢數據庫年齡：
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前事務年齡為 61436
relname | xid_age | table_size
----------------+---------+------------
test_tab | 31260 | 4327 MB4) 建議使用vacuum freeze來對指定的表進行xid 凍結清理：
vacuum full freeze xxx.xxxx;
--vacuum后事務年齡變為0
relname | xid_age | table_size
----------------+---------+------------
test_tab | 0 | 4327 MB文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/129667.html
摘要：前言居中是網頁布局中再常見不過的一種方式了，今天我們就來聊聊居中的那點事。我是水平居中的同樣是針對塊級元素才有效果。來看代碼我是水平居中的必須配合來使用來可以實現居中的效果。方法二我是垂直居中的注意此方法要考慮的兼容性問題。 前言：居中是網頁布局中再常見不過的一種方式了，今天我們就來聊聊css居中的那點事。 我們主要從這幾個方面來了解下居中： 水平居中 垂直居中 水平垂直居中 水平...
摘要：所謂對稱加密，就是加密和解密使用同一秘鑰，這也是這種加密算法最顯著的缺點之一。非對稱加密算法由于對稱加密在通信加密領域的缺陷，年和提出了非對稱加密的概念。非對稱加密，其主要缺點之一就是慢，適合加密少量數據。 1. 加密的目的 加密不同于密碼，加密是一個動作或者過程，其目的就是將一段明文信息（人類或機器可以直接讀懂的信息）變為一段看上去沒有任何意義的字符，必須通過事先約定的解密規則才能將...
摘要：所謂對稱加密，就是加密和解密使用同一秘鑰，這也是這種加密算法最顯著的缺點之一。非對稱加密算法由于對稱加密在通信加密領域的缺陷，年和提出了非對稱加密的概念。非對稱加密，其主要缺點之一就是慢，適合加密少量數據。 1. 加密的目的 加密不同于密碼，加密是一個動作或者過程，其目的就是將一段明文信息（人類或機器可以直接讀懂的信息）變為一段看上去沒有任何意義的字符，必須通過事先約定的解密規則才能將...
摘要：從最大的同性社交平臺獲取數據好了，言歸正傳，回到題目。烏云密布的爬蟲百度網盤這件事，是我不想看到的，這類安全問題的一個共同特點用戶自身確實存在問題。 本文作者：夏之冰雪，i春秋簽約作家 《我在百度網盤上看到上萬條車主個人信息,企業、政府高官信息、各種數據庫和無窮無盡的盜版》，一時間，這篇文章就火了，火爆程度另百度猝不及防。 其實呢，這事真不能全怪百度，畢竟用戶分享出去了。之所以引起這么...
摘要：移動精英開發社群的第期，也是圍繞架構這個話題進行討論。本次我們希望結合實際開發中遇到的問題，來聊聊移動端的架構設計。這樣的模式改進一些，可能會更適合移動端架構。潘衛杰之前我們公司移動端的大項目就是插座式開發的，批量出各個行業的。 此前，58 同城的技術委員會執行主席沈劍在 OneAPM 的技術公開課上分享過一個主題，「好的架構不是設計出來的，而是演技出來的」。因為對很多創業公司而言，隨...
閱讀 1353·2023-01-11 13:20
閱讀 1699·2023-01-11 13:20
閱讀 1211·2023-01-11 13:20
閱讀 1902·2023-01-11 13:20
閱讀 4161·2023-01-11 13:20
閱讀 2751·2023-01-11 13:20
閱讀 1397·2023-01-11 13:20
閱讀 3664·2023-01-11 13:20
