PostgreSQL 为什么怕听到 FREEZEN 这个词的解释与"盯着"他

最新推荐文章于 2024-12-24 07:45:15 发布

原创最新推荐文章于 2024-12-24 07:45:15 发布 · 1k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#数据库 #java #mysql #python #分布式

本文深入探讨了PostgreSQL中由于32位事务ID限制带来的问题及其解决方案。当事务ID接近耗尽时，PostgreSQL通过HALFBYHALF策略和FREEZING过程来管理事务ID，避免系统停止。FREEZING包括lazy和eager两种模式，通过VACUUM过程回收事务ID。此外，介绍了如何监控和预防事务ID耗尽，以及如何调整参数以防止系统冻结。监控数据库中oldest_current_txid和autovacuum_freeze_max_age的关系是关键，及时执行VACUUM或调整设置能有效避免问题发生。

完美无缺的系统是不存在的，或者认为某个系统很完美的你，不完美，今天就的开始talk一下Postgresql 的一个“不可回避的问题”， FREEZEN.

POSTGRESQL FREEZEN 到底是什么，为什么提到这个事情心里总有些惴惴不安，的从POSTGRESQL 的原理开始，POSTGRESQL 中的事务ID 是32位组成的,也就是说系统分配的事务的ID是有限的.

在一个繁忙的系统中,事务的ID被用完怎么办,系统就停止了? POSTGRESQL 通过HALF BY HALF 的方式来解决这个问题,就是一半可用一半不可用,将可用的事务的ID 变成2.1亿.

通过下面粗略的比喻的图, 我们这样讲解,如果我就有12个事务的ID, 那么我不能说我把事务号都分了,然后我的事务分到12,下面就没有号了,我就的想着我需要将这些号分成两个部分, 一部分为不能见人的(不让你用), 一部分是被使用的.

然后我们通过增加的模式,我当前的事务号如果用到了2 ,下一个就是1 ,但是原来7 号可见, 那如果1号可见了,7号就必须要回收,变成不可见.

那么这里就会产生

我从数字1 开始使用依次为 1 12 11 10 9 8 , 当我用到 7 的时,我已经达到一半一半的状态了, 此时我就需要回收的TIX 事务号了, 1 12 11 10 9 8 这些数字我的回收了.

听上去回收事务号并不太难,但这些事务的ID 在哪里,在每行tuple 上, 那21亿个事务,并且使用这些事务的行,都要对回收的这个事情进行响应. 每行上都有 t_xmin 和 t_xmax 两个值并且这些值都存储了事务ID

那么此时系统是不是应该处于这个状态.

PostgreSQL 有三个特殊的事务的ID ,

0 是不可见的事务ID

1 是数据库初始化时的事务ID

2 是冻结的事务的ID ,这个ID 比任何的事务的ID 都老,也就是不可见,并且POSTGRESQL 会掌握处于"冻结"的

那么此时有同学会问,虽然2.1一个亿的数字也是蛮大的,但是我还是不想去脑瘫,那我应该怎么办.

POSTGRESQL 这么聪明的数据库当然有办法解决问题,怎么解决, 一个字, "滚". 滚动的滚.

vacuum_freeze_min_age 这个参数将帮助你,解决上面的问题, 默认是5000万,当你的事务的ID 使用的数量达到5000万的时候, 那么frozen的动作就开始了,

大白话就是我如果从7开始使用我不会说用到2的时候,在进行FROZEN,而是我在用到4的时候我就将6 ,7 就变成不可见,将 1 ,12 变成可见.

那么接下来的问题是,他怎么进行冻结的活动,也就是 frozen processing, forzen 的方式有两种, 我们可以叫他们 lazy 和 eager 两种模式,这两种模式中的区别是,前者lazy模式中,是通过vacuum process的方式来处理,扫描dead tuple 来进行冻结的活动,而采用eager的方式将扫描所有的PAGE来进行FROZEN的活动, 并且更新相关系统的VIEW，和清理不在使用的CLOG文件。

怎么计算那些事务的ID 是可以被回收的

可以回收的TXID = 当前最老的xmin - vacuum_freeze_min_age,普通的vacuum进程逐个扫描页面，同时与vm可见性映射协作跳过没有死元组的页面，并将元组t_infomask (xmin小于freezelimit_txid)设置为XMIN_FROZEN。清理完成后，n_live_tuple、n_dead_tuple、vacuum_count、autovacuum_count、last_autovacuum、last_vacuum等统计信息将被更新。

对于表来说，通过PG_CLASS 中的 relfrozenxid来鉴别表中的最小的xmin id ,对于数据库也是一样通过pg_database 的字段datfrozenxid 来判别。

触发数据库的急冻datfrozenxid < oldestxmin-vacuum_freeze_table_age，

怎么监控

WITH max_age AS (
SELECT 2000000000 as max_old_txid
, setting AS autovacuum_freeze_max_age
FROM pg_catalog.pg_settings
WHERE name = 'autovacuum_freeze_max_age' ),
per_database_stats AS (
SELECT datname        ,
m.max_old_txid::int        , m.autovacuum_freeze_max_age::int        ,
age(d.datfrozenxid) AS oldest_current_txid
FROM pg_catalog.pg_database d
JOIN max_age m ON (true)
WHERE d.datallowconn )
SELECT max(oldest_current_txid) AS oldest_current_txid    ,
max(ROUND(100*(oldest_current_txid/max_old_txid::float))) ASconsumed_txid_pct    ,
max(ROUND(100*(oldest_current_txid/autovacuum_freeze_max_age::float)))AS consumed_autovac_max_age
FROM per_database_stats;

oldest_current_txid 表示为当前所有数据库中最老的事务ID，

asconsumed_trix_pct 为当前消耗了多少事务ID 占据的百分比，数字越大，就说明距离危险越近了。

consumed_autovac_max_age 参数说明你距离触发FREAZON的距离还有多远

那如果发现了上面的情况不大对头的情况下,怎么办

SELECT datname, age(datfrozenxid) AS frozen_xid_age , ROUND(100*(age(datfrozenxid)/2000000000.0::float)) consumed_txid_pct , current_setting('autovacuum_freeze_max_age')::int - age(datfrozenxid) AS remaining_aggressive_vacuum FROM pg_database;