维护大型PostgreSQL数据库

提出数据库大小这个话题，是件滑稽的事情。划分小型、中型、大型甚至超大型数据库并不像你想象的那么简单。区分数据的大小，基于许多因素，这些因素的特征分为有形的、无形的；有形的可以以客观方式衡量，无形的就取决于很多了。例如，一个2TB的数据库，对很多人来说是大型数据库；另一方面，经验丰富的dba可能会将超过PB级别的数据库才称为大型数据库。

以下是PostgreSQL基本能力的回顾

数据库大小	无限制
数据库数量	4,294,950,911
每个数据库中关系(relations)数量	1,431,650,303
表大小	32TB
表中行数，由页中容纳的元组定义	4,294,967,295 pages
表中的列数	1,600
列的大小	1GB
标识符长度	63 bytes
单表上的索引	无限制
分区键	32
每个索引中的列数	32

注意：尽管在创建大量schema时可能面临物理限制，但在postgres 中创建的数量在理论上没有限制。

我使用以下caveats来区分小型数据库和大型数据库。虽然大型数据库的一些注意事项确实可以应用于小型数据库，反之亦然，但事实是，大多数设置都遵循以下观察结果：

1.小数据库通常由单人管理

2.可以手动个管理小数据库

3.小数据库很少被调优

4.相比大数据库，小数据库可以容忍效率低下

5.大数据库使用工具管理

6.大数据库必须被持续监控、贯穿整个调优周期

7.大型数据库需要对迫在眉睫的和持续的生产问题做出快速响应，以保持最佳性能。

8.大型数据库对技术债敏感

 

大数据库通常会引起以下问题和现象：

1.系统性能是否对生产负载变化很敏感？

2.系统性能是否对较小的调整效果特别敏感？

3.是否存在大量数据流失？

4.数据库负载系统是否使硬件性能饱和？

5.逻辑备份和表的repack等维护活动是否需要几天甚至一周以上的时间？ 6.灾难恢复协议是否需要非常小的恢复点目标 (RPO) 或恢复时间目标 (RTO)？

 

小库和大库的关键区别在于它们是如何被管理的：

1.手动管理小型数据库很常见，但这不是最佳实践；在大型数据库的许多此类情况下，使用自动化是行业默认的操作模式。

2.由于环境变化很快，大型数据库对生产问题特别敏感。

3.调优不断演进，新环境通常被做了很好的调优，但是随着时间的推移，情况会发生变化，而且大型数据库尤其脆弱。

 

好的计划是你的益友：通过预期未来的状况来强调潜在的问题是你的目标。例如测试整个基础架构，在进入生产之前。

使用Ansible、Puppet、Terraform等工具为你的构建环境编写脚本可以减少配置底层基础设施时的人为错误。能够以一致且可重复的方式进行构建非常重要的。

一旦数据库投入生产，就必须对其进行监控，并针对各种关键阈值发出警报。除了标准错误，配置监控解决方案应该遵循“三法则”：只选择和观察三个统计信息来跟踪和报警某个特殊的状态变化。

这不应与关注特定问题相混淆，而是旨在告诉你应该注意你的系统，以便了解某些事情已经与被认为是正常的行为发生了变化。根据你的偏好，可能希望关注已知的生产问题，或者当系统稳定时，可能对趋势警报更感兴趣，例如查询性能已低于预定义阈值。

关于系统调优：小型数据库可以使用默认的参数值，在一定程度上得到令人满意的执行结果，但是大型数据库不行。配置初始化调整参数（例如shared_buffers 等）是必要的，但还应该监控以发现诸如膨胀和长期查询性能等问题的趋势。请记住，其他稳定且经过深思熟虑的架构遇到的最常见问题是表和索引膨胀。通过调整autovacuum特性来解决膨胀是必不可少的。

监控，尤其是在维护窗口之前和之后，是很必要的，因为你可以捕获潜在问题，以便在进入生产之前得到更新。

 

在你的系统的整个生命周期将注意力放在以下维护活动上：

·逻辑备份和其它数据库冗余

·架构演进：应用栈更新，升级和回滚；应用和数据库扩展

·postgresql server升级：次要升级、重要升级

·数据库迁移

·硬件升级

·集群扩展(节点的添加、删除)

 

定期执行逻辑备份和PostgreSQL次要升级等维护活动。

规划逻辑dump和WAL归档的空间使用要求。

关于逻辑备份：如果备份整个数据库可能需要一周时间，就很难证明它是合理的。差异备份是一种潜在的解决方案。以更快的频率，备份哪些定期被更新和删除的表，而不是更新慢的表。这种方法需要恰当的架构设计，例如，考虑分区表。

逻辑备份的替代方法是考虑写入时复制 (COW：copy on write) 或文件系统，例如 ZFS 和 BTRFS。例如，容器内的环境可以利用快照和克隆，从而在灾难恢复场景中实现近乎即时的恢复。

复杂的操作（例如硬件和数据库扩展）包含许多子活动，并且通常可能涉及同时与多个团队合作。在这种情况下，维护参考文档至关重要。此类活动最好在看板或Scrum环境中进行跟踪和计划。

 

关于灾难恢复 (DR)，请考虑自动化以下操作：

·通过逻辑备份恢复 ·将PRIMARY故障转移到 REPLICA ·删除/建立一个新的副本 ·时间点恢复 (PITR)：将集群重建到某个时间点

作为 PITR 的一个旁白：与其从头开始将整个数据集群重建到特定时间点，不如创建一个延迟复制的STANDBY，并且可以恢复到特定时间点或在当前时间点升级状态。 有关详细信息，请参阅运行时参数 recovery_min_apply_delay。

总之，虽然可以通过临时方式管理小型数据库，但必须始终使用更严格和认真的方法来管理大型数据库。

从管理大型数据库中学到的知识可以用于管理小型数据库。