postgresql 备份_在Kubernetes上使用PostgreSQL的正确姿势：总结

在第1至第3部分中，我们在Kubernetes上列出了PostgreSQL的编排问题-应用程序应如何表现，然后如何以Kubernetes方式协调这种行为。 底层(或上层)模式将应用程序的行为表示为一组代理，每个代理都将其组件移动到中央定义的所需状态。 Kubernetes本身就是这种方式。

理解业务流程的基本框架是朝着使任何分布式应用程序自动化的方向迈出的一大步。 在这最后一篇文章中，我们将介绍一些剩余的细节。

备份

主要(主)PostgreSQL实例正在不断将预写日志(WAL)块写入备份卷。 它也会定期写入完整备份。 此卷的管理方式有两个要求：

· 音量没有限制； 最终它将耗尽空间。

· 该卷必须始终包含足够的信息以启动新的PostgreSQL实例。

答案之一是要有一个额外的工作程序(也许是一个单独的Pod)，它比最新的完整备份更早地丢弃WAL，并将旧的完整备份移至长期存储。 从那时起，只要备份卷始终至少包含最新的完整备份和WAL，就有足够的信息来更新新实例。

监控方式

用户和应用程序编排层都需要关注PostgreSQL实例的运行状况。 例如，当主服务器发生故障时，控制器需要启动故障转移过程。 为此，控制器首先需要知道主要节点何时发生故障。

一种方法可能是使用Kubernetes的内置Pod健康检查系统。 如果我们的PostgreSQL实例Pod实现了运行状况检查，则当Pod变得不正常时，控制器可以在Kubernetes API中看到。 为了进行更精细的监视，控制器可以建立与每个PostgreSQL实例Pod的直接连接，该Pod可以流式传输我们所需的任何监视信息。 当然，根据您的需要，还有更多复杂的选择。

负载平衡和故障转移

虽然只有一个主实例可以处理写查询，但PostgreSQL可以将只读查询卸载到任意数量的备用实例中。 为了处理传入的请求，我们可以使用两个Kubernetes服务-一个用于主服务，一个用于后备服务。 当备用数据库提升为主要数据库时，只需更新其标签，使其属于主要服务而不是备用服务。 使用PostgreSQL服务的组件可以依赖于服务的DNS名称，因此它们无需知道已发生更改。

跨故障区域分布

在故障区域之间分布PostgreSQL实例非常简单。 实际上，它甚至不需要任何代码。 这是一项内置的Kubernetes功能，称为Pod Affinity。 我已经针对该主题编写了单独的教程。 在这里阅读。 简短的版本是您在每个PostgreSQL实例Pod上声明一个反亲和力。 当调度程序选择运行它们的位置时，它们将彼此排斥到不同的区域。

想要更多？ 问吧！

自动化像PostgreSQL这样的复杂应用程序是一个大话题。 我已经介绍了我认为更有趣和更有价值的作品。 如果您想进一步了解本系列中的任何内容(或我遗漏的任何内容)，请发表评论！

我很高兴听到大家都对学习感兴趣，并且我想写更多！

> PostgreSQL (src)

(本文翻译自Kynan Rilee的文章《PostgreSQL on Kubernetes the Right Way: Wrapping it up》，参考：https://medium.com/kokster/postgresql-on-kubernetes-the-right-way-wrapping-it-up-d6b953c2ecbe)