记一次 PostgreSQL 事故处理

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

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

对生产环境有敬畏之心啊

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

瞎胡闹罢了。。

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


`pg_ctl reload`不好吗？

卧槽，生产环境，勇士啊

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

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

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

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

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

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

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

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

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

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

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

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

@ppllss
@FYFX
@billccn
@sadfQED2

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

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