PostgreSQL 怎么通过vacuum 加速事务ID回收的速度 （翻译）

此文为翻译文字原文连接在文字最下方

经历上次transaction id 回收报警的问题后，除了上次总结后，发现对于transaction id 的回收的问题还是处于一个急需在学习的过程，所以有了下面这篇翻译的文字。

翻译

——————————————————————————————

Postgresql 使用事务ID （txids,xids）去完成多版本控制的功能设计，相关的postgresql文档中有明确的对于 txids 的功能注解：

PostgreSQL 的 MVCC 事务的实现是依赖于比较事务ID XID 的数字来完成的，这里插入的行版本信息XID要大于当前的行事务XID ，并且当前的XID 信息在未来是不应该被可见的。 

基于transaction ID 被限制在 32位的基础上，一个PG的数据库在运行一段时间，将遇到事务ID 的回卷的问题，XID计数器环绕到零，突然之间，过去的事务出现在未来，简而言之，出现了灾难性的数据丢失问题。

为了克服事务ID回卷的问题，PG 使用VACUUM 来冻结已经已经提交的事务的ID，并且并且在未来可能会释放并重新使用这些  transaction id.

Vacuum 被放到后台运行自动运行并且这里我们称之为 autovacuum 自动真空，当然也可以通过手动的 vacuum来完成类似的功能。

Autovacuum 被设计为一个低优先级的定期的任务，实际的工作效果和工作的速度和数据库本身的活动有关。在有些情况下，autovacuum 可能不能够回收事务的ID，或者不及时的回收这些ID，并且这种vacuum 工作我们也对其有一个称呼 , aggressive vacuum 或者  antiwraparound vacuum.

如果TXID 的利用率超过了回收的速度，尽管 autovacuum 做了最大的努力去工作，达到一定的程度后，数据库将停止接受数据库的操作命令，避免因为事务回卷导致的数据丢失的问题发生。

下面将介绍的是通过vacuum 的功能来解决这个问题，那么基于的数据库版本是PG12， 所以下面的命令和执行必须基于PG12的版本。

Autovacuum versus manual vacuum for TXID freezing  （针对事务ID 的冻结，自动真空与手动真空的不同）

以下的信息主要标明 vacuum 的操作步骤，这