记一次 PostgreSQL 事故处理

[samin]

notion 文章链接： https://gaudy-feels-700.notion.site/PostgreSQL-eb2ae9499ae94be583058f6e0cad5fa1

via： https://github.com/SaminZou/study-prj

处理完问题心血来潮写了个记录 mark 一下，希望对大家处理问题可以有点启发

[killva4624]

线上用容器跑 PgSQL 是最佳实践吗？哪怕是单 Node 单 Pod 的方式。

[encounter2017]

用 timestamp with time zone 是不是就没这么多事情了

[samin]

@killva4624 感谢，线上是 K8s 跑的 stolon

看来本帖更大的意义是让我完善文章，没交代清楚不是生产环境

再次表示感谢哈😂

[samin]

@encounter2017 确实是小伙伴对 PG 的数据类型不够清晰

[Huelse]

@HashV2 #19 好吧，我刚查了下 timestamp 的确存的 utc ，但 pg 会根据我服务器的时区自动转换，命令行查就已经是转过的了

[Huelse]

@encounter2017 #22
@samin #24

如果服务器或连接的服务器设置过时区也不用这些设置

https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES

```
For timestamp with time zone, the internally stored value is always in UTC (Universal Coordinated Time, traditionally known as Greenwich Mean Time, GMT). An input value that has an explicit time zone specified is converted to UTC using the appropriate offset for that time zone. If no time zone is stated in the input string, then it is assumed to be in the time zone indicated by the system's TimeZone parameter, and is converted to UTC using the offset for the timezone zone.
```

[csx163]

看了还是不敢用容器跑数据库啊

[fisherwei]

k8s 部署 pg 有严重的 cache 问题，楼主你们生产环境没有遇到吗？

[HashV2]

@Huelse #25 ok 那只要确保服务器时区正确就可以了，所以这其实是个 future ？😆

[adoal]

硬生生把开发和配置问题转变成了故障修复问题

[samin]

@adoal DevOps 方式研发界限不清

[samin]

@fisherwei 有 Sample 或者连接看一下吗 ？ 目前确实没遇到过 这个问题产生可能和 PG Cache 机制参数配置有关 ？

[yjhatfdu2]

@sardina 可以的，set timezone to 'Asia/Shanghai'

[samin]

@yjhatfdu2 这种方式在于 PG 服务不能重启，探究永久修改的原因是得保证减少运维变量

[fisherwei]

@samin
https://www.crunchydata.com/blog/deep-postgresql-thoughts-the-linux-assassin

[yjhatfdu2]

@samin 永久修改的话可以
ALTER SYSTEM SET timezone to 'Asia/Shanghai';
select pg_reload_conf();
这样不用重启，连配置文件都不用手动改

[raysonlu]

不懂就问，如果不是用 k8s 部署，是不是就能避免这种事？

[sampeng]

看到这一句。。。线上使用 K8s 部署（单 Node 单 Pod ） bitnami PostgreSQL 14 版本数据库。。我就表示，不是这次出事就是下次出事。
数据库放 k8s 不是不可以，开发测试环境无所谓。生产环境？你是真不怕挂啊。。。。

[sampeng]

最后看到总结。。。。
what ？你这叫啥总结？？？？

[julyclyde]

@adoal 哈哈哈哈