记一次 PostgreSQL 事故处理

[samin]

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

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

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

[ppllss]

线上时区问题怎么会等到线上有流量后才发现？上线后测试不走一边数据？难以理解

[FYFX]

不是，你线上数据库在还提供服务的情况下重启这么果断的，我看你总结的时候没反思这个问题啊

[FYFX]

对生产环境有敬畏之心啊

[wtfedc]

```PG 重启的过程中有 Pod 被 K8s 强制关闭```
好奇一共有几个 pod ，有配置主从吗？
k8s 在你新的 replica 跑起来，在 ready 之前，不会终止旧的 replica 的，你是直接在 pod 里操作的重启？

[kkeep]

瞎胡闹罢了。。

[billccn]

你敢这么重启数据库，真是勇！


`pg_ctl reload`不好吗？

[sadfQED2]

卧槽，生产环境，勇士啊

[LinYa]

`本次修复消耗时间大概 3 小时，排查问题，合理的修复手段很重要`

[sardina]

pg 可以在一个连接的 session 里设置时区吗 mysql 是可以的

[laolaowang]

不懂数据库，看到大家的评论，说明你还是没认识到问题

[wingor2015]

这个重启来得猝不及防，有点好奇重启是怎么操作的？

[sujin190]

大家也别这么苛刻吧，谁还不犯个傻啊，但是不能在有频繁写入过程中重启数据库，这个傻确实犯的有点低级

[lookStupiToForce]

可以的，瞎胡闹的评价是正确的

[lookStupiToForce]

@sardina #9 可以设置，估计他们不想动生产端代码吧

[HashV2]

能详细描述一下问题产生的原因吗？我生产环境从来没调过 pgsql 的时区，也没出过问题。

[Huelse]

@HashV2 #15 我们也从来没调整过，一直默认的 UTC ，我猜是他们的代码存入时带时区了

[HashV2]

@HashV2 #15 好吧 我看完文章后赶紧检查了一下，原来是框架写接口的时候会自动根据框架设置的时区转一下，我跟别人对接也都是通过自己写的接口，所以没出问题， 如果其它业务直接连这个数据库拿数据也是会出问题的

[sss495088732]

emm...业务层 UTC,监控,日志 SH

[HashV2]

@Huelse #16 你直接用命令行查一下，是有他这个问题的

[samin]

@ppllss
@FYFX
@billccn
@sadfQED2

各位放心，这个是 UAT 环境，我文章里面没提到是生产吧，给我 100 个胆也不敢去搞生产的。😂DEV 环境的 PG 是裸机装的，服务应用他们在 DEV 环境是正常的时间，上了 UAT 就不正常了，排查很多变量最终定位 PG ，所以尝试去修改。

BTW：虽说是 UAT ，但是我们做的项目大量的类真实数据假设没了，也是致命的重建工作量。

[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 哈哈哈哈

[ljf]

k8s 部署生产环境 pg ，不用考虑数据高可用，主备切换吗，我们线上都不敢直接 statefulset 跑 pg ，哪怕绑定单节点，机器挂了咋办。大佬搞个 https://github.com/sorintlab/stolon 吧

[samin]

@sampeng 哈哈 感谢 当头棒喝 写得比较口水话

bwt：其实我也就是文笔不好 不善于表达的千万程序员中的一个 想实践提升一下