PostgreSQL 13:不要让插槽杀死你的主节点__自9.4版以来，PostgreSQL中一个有趣的特性是能够使用复制插槽控制WAL文件的删除。不好的一面是，复制槽可能会导致磁盘被旧的WAL填满，从而导致主生产服务器死亡。在本文中，我将解释PostgreSQL复制槽，以及PostgreSQL 13中的一个新特性如何帮助防止这个问题。: 世界上功能最强大的开源数据库...

### **译者简介**

#### 李伟&崔鹏&海能达DBA团队,任职于海能达通信股份有限公司哈尔滨平台中心,数据库开发高级工程师,专网通信领域、公共安全领域PostgreSQL数据库的管理与维护,致力于高并发高可用数据库架构设计和数据库性能的优化。

### **校对者简介**

#### 吴聪，PostgreSQL技术爱好者。熟悉oracle、PostgreSQL、mysql等数据库，现主要从事oracle和Greenplum相关的工作。

#### 自9.4版以来，PostgreSQL中一个有趣的特性是能够使用复制插槽控制WAL文件的删除。不好的一面是，复制槽可能会导致磁盘被旧的WAL填满，从而导致主生产服务器死亡。在本文中，我将解释PostgreSQL复制槽，以及PostgreSQL 13中的一个新特性如何帮助防止这个问题。
 
### **WAL的生成**
#### 众所周知，WAL是由于主服务器上的数据库更改而产生的:插入、更新等等。一个更活跃的数据库将产生更多的WAL -在一个非常活跃的服务器中，每分钟可能产生许多GB的WAL。WAL被写入的文件名称按数字顺序递增，并且文件的大小总是相同的(16mb是默认的和典型的)。一旦文件中的数据不再需要，就可以回收该文件，这意味着将其重命名为序列中编号较高的位置，以便以后可以用新数据填充它。
#### (有一些特殊情况，比如活动激增会导致额外文件的创建;当激增结束后，这些额外的文件将被删除，而不是回收。)
#### 因为所有的数据库写活动都会产生WAL，所以磁盘空间的可用性至关重要。当存储WAL的磁盘已满时，服务器将无法处理新的事务，可能会被卡住，或者更糟:它可能会完全崩溃。因此，这是一种要尽一切可能避免的情况。
 
### **复制槽**
#### 在PostgreSQL中，复制是通过处理WAL文件来实现的。为了让它工作，所有的WAL文件必须是暂时可用的，直到它们被处理。因此，需要一种机制来告诉主WAL管理不要回收或删除文件。
#### 输入复制插槽。槽是一种机制，表明我们正在进行的备份将需要WAL文件，你能不能先不要删除它;或者这个副本还没有处理那个WAL文件，所以可以让它单独待一会儿吗?
#### 复制槽本身只占用很少的磁盘空间。它们只存储一小部分元数据，包括指向WAL中某个位置的指针。但它保护的WAL数据是另一回事:在一个高度活跃的服务器上，它可以以千兆字节或更糟的数据来测量。
 
### **WAL消费**
#### 向物理副本提供数据意味着从其主服务器复制WAL数据。类似地，逻辑副本需要读取WAL数据(并将解释版本传输给副本)。被读取的WAL位置是槽所跟踪的。一旦副本以某种方式保护了WAL数据，插槽就可以被提前;这告诉主要的WAL管理，WAL文件可以被删除。当副本处于活动状态时，这种情况会持续发生，因此主服务器上的WAL将使用相同或更多的磁盘空间。即使是两倍或十倍也可以接受，这要视情况而定。
#### 问题是，如果一个副本完全死亡，并不能恢复很长一段时间;或者副本被销毁，DBA忘记删除复制槽;或者这个槽是某个实验遗留下来的;或者即使复制是通过慢速网络链路馈电，那么保留的WAL也会无限制地增长。这就变成了一个定时炸弹。
 
### **限制槽尺寸**
#### 为了解决这个问题，Kyotaro Horiguchi自2017年2月以来一直在PostgreSQL补丁中工作，以限制一个插槽保留的WAL的大小。经过很长一段时间的回顾和修改，我把它集成到PostgreSQL 13中，改进了高可用性PostgreSQL farms的管理。
 
#### 主要原则是，最好杀死副本(通过某种方式使其插槽无效;下面将详细介绍)，而不是杀死提供该副本的主服务器，并将所有产品一起关闭。
#### 它的工作方式非常简单:将postgresql.conf中的max_slot_wal_keep_size(文档)设置为允许复制槽保留的WAL的最大磁盘空间。如果一个槽到达了那个点，并且出现了检查点，那么这个槽将被标记为无效，一些WAL文件可能会被删除。如果插槽被walsender进程积极使用，该进程将收到信号，以便它终止。如果walsender再次启动，它将发现所需的WAL文件不再存在。使用那个插槽的副本必须重新克隆。
#### 如果max_slot_wal_keep_size为0，这是默认值，则不存在限制。我不建议这样做，因为当插槽填满磁盘时，它会导致失败。
 
### **监测复制槽的状态**
#### 还包括一些监视功能。pg_replication_slots中的两列是相关的。最关键的一个是wal_status。如果该列被保留，那么槽将指向max_wal_size内的数据;如果对它进行了扩展，那么它就超过了max_wal_size，但是仍然受到wal_keep_size或max_slot_wal_keep_size的保护(包括max_slot_wal_keep_size为0时)。两种状态都是正常的。然而，当一个插槽超过限制时，它首先就会变成无保留的，这意味着它处于迫在眉睫的危险中，但如果足够快，它仍然可以恢复。最后，当WAL文件已被删除且无法恢复时，状态变为丢失。
#### 另一列是safe_wal_size:它显示了在这个槽面临WAL文件被删除的危险之前，可以写入WAL的字节数。我们建议在您的监控系统中密切关注这一栏，并在它低的时候发出告警。零或负意味着一旦出现检查点，你的副本就会死亡:
``` 
SELECT slot_name, active, wal_status, safe_wal_size
  FROM pg_catalog.pg_replication_slots;
```
#### 我们相信，这个新特性会使副本的维护更容易、更健壮;希望我们不会再看到由于这些问题而导致生产下降的灾难。
#### (注意:safe_wal_size是在13beta3中引入的，所以一定要查阅最新的文档，否则会看到min_safe_lsn。忽略这一点。)

### **原文链接：<https://www.2ndquadrant.com/en/blog/pg13-slot-size-limit/>**

### **PostgreSQL中文社区欢迎广大技术人员投稿**
### **投稿邮箱：press@postgres.cn**