每當PostgreSQL數(shù)據(jù)庫中的表中的行被更新或刪除時,死亡行會被遺留下來。VACUUM則會把它們除去來使空間能被重新利用。如果一個表沒有被清空,它會變得臃腫,浪費磁盤空間而且會降低順序表掃描的速度,而且在較小范圍內(nèi)也會降低索引掃描的速度。
VACUUM命令只可以移除這些不再被需要的行版本(也被稱為元組)。如果被刪除事務(wù)的事務(wù)ID(存儲在xmax系統(tǒng)列中)比仍然活躍在PostgreSQL數(shù)據(jù)庫(或者共享表的整個集群)中最老的事務(wù)(xmin界限)更老,那么這個元組將不再被需要。
注意以下三種情況就可以抑制PostgreSQL集群中的xmin界限
1、 查找長時間運行的事務(wù)
我們可以查找長時間運行的事務(wù),然后使用pg_terminate_backend()函數(shù)去終止阻礙VACUUM命令的數(shù)據(jù)庫會話。
2、 查找復制槽
復制槽是一種數(shù)據(jù)結(jié)構(gòu),它使PostgreSQL服務(wù)器免于丟棄備用服務(wù)器仍然需要的信息。如果復制被推遲或者備用服務(wù)器被關(guān)閉,復制槽就會阻止VACUUM命令刪除舊的行。
復制槽提供了一種自動化的方式來確保主服務(wù)器不移除WAL塊直到它們被所有的從服務(wù)器接收。而且主服務(wù)器即使當從服務(wù)器斷開連接時也不移除可能導致恢復沖突的行。
復制槽只保留已知所需數(shù)量的WAL塊而不是多于所需數(shù)量。
使用復制槽可以避免這個問題:在從服務(wù)器未連接的任意時間段內(nèi)不提供保護。
我們可以使用pg_drop_replication_slot()函數(shù)去丟棄不需要的復制槽。
這種情況只會發(fā)生在當hot_standby_feedback參數(shù)設(shè)置為on時的物理復制中。如果是邏輯復制,那么會有一個相似的危險,但是只有系統(tǒng)目錄會被影響。
3、查找準備好的事務(wù)
二階段提交協(xié)議是一種原子性確認協(xié)議。它是一種分布式算法,用來協(xié)調(diào)參與分布式原子事務(wù)的所有進程,確定是否提交或者終止(回滾)這個事務(wù)。
在二階段提交過程中,一個分布式事務(wù)首先使用PREPARE TRANSACTION,為二階段提交準備當前事務(wù)。如果由于任何原因PREPARE TRANSACTION 命令失敗,會變成ROLLBACK,而當前事務(wù)則會被取消。
然后我們使用COMMIT PREPARED,提交一個之前為兩階段提交預(yù)備的事務(wù)。
一旦一個事務(wù)被準備好,它會一直保持一種“游蕩”狀態(tài)直到被提交或者中止。通常情況下,事務(wù)不會在準備狀態(tài)中保持很長時間,但有時會出現(xiàn)錯誤所以事務(wù)必須被管理員手動移除。
我們也可以使用ROLLBACK PREPARED,取消一個之前為兩階段提交準備好的事務(wù)。
補充:postgresql vacuum操作
PostgreSQL數(shù)據(jù)庫管理工作中,定期vacuum是一個重要的工作.
vacuum的效果
1.1釋放,再利用 更新/刪除的行所占據(jù)的磁盤空間.
1.2更新POSTGRESQL查詢計劃中使用的統(tǒng)計數(shù)據(jù)
1.3防止因事務(wù)ID的重置而使非常老的數(shù)據(jù)丟失。
第一點的原因是PostgreSQL數(shù)據(jù)的插入,更新,刪除操作并不是真正放到數(shù)據(jù)庫空間.如果不定期釋放空間的話,由于數(shù)據(jù)太多,查詢速度會巨降.
第二點的原因是PostgreSQL在做查詢處理的時候,為了是查詢速度提高,會根據(jù)統(tǒng)計數(shù)據(jù)來確定執(zhí)行計劃.如果不及時更新的話,查詢的效果可能不如預(yù)期.
第三點的原因是PostgreSQL中每一個事務(wù)都會產(chǎn)生一個事務(wù)ID,但這個數(shù)字是有上限的. 當事務(wù)ID達到最大值后,會重新從最小值開始循環(huán).這樣如果不及時把以前的數(shù)據(jù)釋放掉的話,原來的老數(shù)據(jù)會因為事務(wù)ID的丟失而丟失掉.
雖然在新版本的Postgresql中有自動的vacuum,但是如果是大批量的數(shù)據(jù)IO可能會導致自動執(zhí)行很慢,需要配合手動執(zhí)行以及自己的腳本來清理數(shù)據(jù)庫。
1. vacuumdb 是 SQL 命令 VACUUM的封裝
所以用vacuumdb和vacuum來清理數(shù)據(jù)庫都可以,效果是一樣的。
2.vacuumdb 中的幾個重要參數(shù)
可以用vacuumdb --help查詢。
-a/--all vacuum所有的數(shù)據(jù)庫
-d dbname 只vacuum dbname這個數(shù)據(jù)庫
-f/--full 執(zhí)行full的vacuum
-t table 只vacuum table這個數(shù)據(jù)表
-z/--analyze Calculate statistics for use by the optimizer
3. 切換到postgres用戶下
vacuumdb -d yourdbname -f -z -v 來清理你的數(shù)據(jù)庫。
或者加到conrtab中15 1 * * * postgres vacuumdb -d mydb -f -z -v >> /tmp/vacuumdb.log
每天的一點一刻開始進行清理。
4. 如何查詢我的XID是否接近臨界值的命令:
select age(datfrozenxid) from pg_database;
或者:
select max(age(datfrozenxid)) from pg_database;
5. 然而我們關(guān)心的是哪一個大的表組要真正的vacuum
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 age(relfrozenxid) DESC LIMIT 20;
這個命令是查詢按照最老的XID排序,查看大于1G而且是排名前20的表。
下面是一個例子:
relname | xid_age | table_size
------------------------+-----------+------------
postgres_log | 199785216 | 12 GB
statements | 4551790 | 1271 MB
normal_statement_times | 31 | 12 GB
然后你可以單獨每個表進行vacuum:
vacuumdb --analyze --verbose --table 'postgres_log' mydb
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方,望不吝賜教。
您可能感興趣的文章:- PostgreSQL對GROUP BY子句使用常量的特殊限制詳解
- PostgreSQL 如何查找需要收集的vacuum 表信息
- PostgreSQL備份工具 pgBackRest使用詳解
- postgresql數(shù)據(jù)合并,多條數(shù)據(jù)合并成1條的操作
- postgresql數(shù)據(jù)添加兩個字段聯(lián)合唯一的操作
- postgreSQL使用pgAdmin備份服務(wù)器數(shù)據(jù)的方法
- Postgresql 查看SQL語句執(zhí)行效率的操作