数据库连接

PostgreSQL是进程架构，每个客户端连接都对应一个后端服务进程。

根据业务的复杂度，合理配置“max_connections”，例如，参考pgtune：

WEB应用：“max_connections ”配置为 200

OLTP应用：“max_connections”配置为 300

数据仓库：“max_connections”配置为 40

桌面应用：“max_connections”配置为 20

混合应用：“max_connections”配置为 100

根据业务需要限制单个用户的最大连接数。

ALTER ROLE xxx CONNECTION LIMIT xxx;

保持合理的活跃连接数，建议活跃连接数为CPU数量的2~3倍。

避免长事务，长事务会阻塞autovacuum等，导致出现性能问题。

避免长连接，长连接的缓存可能较大，导致内存不足，建议定期释放长连接。

检查应用程序框架，避免应用程序自动begin事务，但不做任何操作。

只读实例

避免长事务，长事务容易导致查询冲突，影响回放。

对实时性有要求的实例，建议配置“hot_standby_feedback”，同时根据业务设置“max_standby_streaming_delay”为合理的值。

监控长事务、长连接和复制延迟，出现问题及时处理。

可靠性、可用性

生产数据库的实例类型务必选择主备类型。

生产数据库的磁盘要有一定的冗余，正常使用保持在70%以下，防止磁盘满等异常。

将主、备机部署在不同可用区内，增加可用性。

将周期性备份设置到业务低峰期，并且不要关闭全量备份。

建议将主备的复制模式设置为“异步”，防止备机故障阻塞主机业务。

稳定性

对于两阶段提交的事务，要及时提交或回滚，防止导致数据库膨胀。

使用逻辑复制时，注意删除不再使用的复制槽，防止数据库膨胀。

选择业务低峰期变更表结构，如添加字段，索引操作。

业务高峰期创建索引时，建议使用CONCURRENTLY语法，并行创建索引，不堵塞表的DML。

业务高峰期修改表结构，要提前进行测试，防止表的REWRITE。

DDL操作需要设置锁等待超时时间，防止阻塞相关表的操作。

单个数据库库容量超过2T，需要考虑分库。

频繁访问的表，单表记录过2000万，或超过10GB，需要考虑分表或创建分区。

日常运维

在实例管理界面下载慢SQL，及时关注并解决性能问题。

定期关注数据库的资源使用情况，资源不足时，及时扩大规格。

监控并关注数据库的年龄，发现年龄过大及时处理，防止事务ID回卷导致数据库不可用。

删除和修改记录时，需要先执行SELECT，确认无误才能提交执行。

大批量数据删除、更新后，应对被操作表执行VACUUM。

关注可用复制槽数以及创建的复制槽，请始终保持至少有一个空余的复制槽可供数据库备份使用，否则数据库备份会失败。

及时清理不再使用的复制槽，防止复制槽阻塞日志回收。

安全

尽量避免数据库被公网访问，公网连接时必须绑定弹性公网IP，设置合适的白名单。

尽量使用SSL连接，保证连接的安全性。