f 不要被autovacuum prevent wraparound 作業給嚇到 ~ 迪貝之家

不要被autovacuum prevent wraparound 作業給嚇到

這case是我在測試pgcenter的時候,看到右上角居然出現1個wraparound,下圖是個範例,我只是秀一下它的畫面在那裡,用了紅框標了出來

pgcenter

想說生意有這麼好?20億個transaction id 在短時間內都被用光?果真如此!! 怎麼動不動就說要縮減福利哩???
pgcenter  畫面是有process id的,所以我就用process id 去查詢pg_stat_activity










然後再去查找log,怎會完全沒警訊。
我們來看AWS的文件描述

transaction id health











沒錯阿!! 這就是我對transaction id wraparound 的了解。
放著讓autovacuum跑一天,跑不完!
該表大概40GB。
為了怕出事,協調了相關關人員後
手動執行vacuum,近50分鐘就結束了。
我越想越不可能,決定找文件來好好了解一番。
問題是出在autovacuum_freeze_max_age這個參數值
預設2億!!
官方文件的描述
Specifies the maximum age (in transactions) that a table's pg_class.relfrozenxid field can attain before a VACUUM operation is forced to prevent transaction ID wraparound within the table. Note that the system will launch autovacuum processes to prevent wraparound even when autovacuum is otherwise disabled.
這個數值就是txid_current - xmin >= 2億
這是查表格age的語法
SELECT c.relname as table_name, c.relkind as type, age(c.relfrozenxid) as age, c.relfrozenxid 
FROM pg_class AS c WHERE age(c.relfrozenxid) <> 2147483647 ORDER BY 3 DESC LIMIT 20;
我想Postgres社群開發人員當初的用意
應該是想給autovacuum充裕的時間做事
40GB的表格,autovacuum做了一天都做不完了!!
早先用8.x的同仁,還設定每天的排程進行vacuum
其實真的太過了!!
2020/07/28
在linkedin看到這篇文章
寫得真是不錯
夠水準
Understanding autovacuum in Amazon RDS for PostgreSQL environments