这是一个创建于 833 天前的主题，其中的信息可能已经有所发展或是发生改变。
notion 文章链接： https://gaudy-feels-700.notion.site/PostgreSQL-eb2ae9499ae94be583058f6e0cad5fa1
via： https://github.com/SaminZou/study-prj
处理完问题心血来潮写了个记录 mark 一下，希望对大家处理问题可以有点启发
42 条回复 • 2022-08-26 09:52:21 +08:00
 |
1
ppllss 2022-08-24 23:23:04 +08:00  1
线上时区问题怎么会等到线上有流量后才发现？上线后测试不走一边数据？难以理解
|
 |
2
FYFX 2022-08-24 23:23:56 +08:00
不是，你线上数据库在还提供服务的情况下重启这么果断的，我看你总结的时候没反思这个问题啊
 |
|
3
FYFX 2022-08-24 23:25:18 +08:00 3
对生产环境有敬畏之心啊
|
 |
4
wtfedc 2022-08-25 00:50:32 +08:00 1
```PG 重启的过程中有 Pod 被 K8s 强制关闭```
好奇一共有几个 pod ，有配置主从吗？ k8s 在你新的 replica 跑起来，在 ready 之前，不会终止旧的 replica 的，你是直接在 pod 里操作的重启？ |
 |
5
kkeep 2022-08-25 07:03:29 +08:00 via Android
瞎胡闹罢了。。
|
 |
6
billccn 2022-08-25 07:24:44 +08:00
你敢这么重启数据库，真是勇！
`pg_ctl reload`不好吗？ |
 |
7
sadfQED2 2022-08-25 07:43:26 +08:00 via Android
卧槽，生产环境，勇士啊
|
 |
8
LinYa 2022-08-25 08:42:22 +08:00
`本次修复消耗时间大概 3 小时，排查问题，合理的修复手段很重要`
|
 |
9
sardina 2022-08-25 09:01:55 +08:00 via iPhone
pg 可以在一个连接的 session 里设置时区吗 mysql 是可以的
|
 |
10
laolaowang 2022-08-25 09:06:09 +08:00
不懂数据库，看到大家的评论，说明你还是没认识到问题
|
 |
11
wingor2015 2022-08-25 09:35:33 +08:00
这个重启来得猝不及防，有点好奇重启是怎么操作的？
|
 |
12
sujin190 2022-08-25 09:43:04 +08:00
大家也别这么苛刻吧，谁还不犯个傻啊，但是不能在有频繁写入过程中重启数据库，这个傻确实犯的有点低级
|
 |
13
lookStupiToForce 2022-08-25 09:47:34 +08:00
可以的，瞎胡闹的评价是正确的
|
|
14
lookStupiToForce 2022-08-25 09:48:11 +08:00
@sardina #9 可以设置，估计他们不想动生产端代码吧
|
 |
15
HashV2 2022-08-25 09:54:49 +08:00
能详细描述一下问题产生的原因吗？我生产环境从来没调过 pgsql 的时区，也没出过问题。
|
|
17
HashV2 2022-08-25 10:04:51 +08:00
@HashV2 #15 好吧 我看完文章后赶紧检查了一下，原来是框架写接口的时候会自动根据框架设置的时区转一下，我跟别人对接也都是通过自己写的接口，所以没出问题， 如果其它业务直接连这个数据库拿数据也是会出问题的
|
 |
18
sss495088732 2022-08-25 10:06:18 +08:00
emm...业务层 UTC,监控,日志 SH
|
 |
20
samin OP |
 |
21
killva4624 2022-08-25 10:15:49 +08:00
线上用容器跑 PgSQL 是最佳实践吗？哪怕是单 Node 单 Pod 的方式。
|
 |
22
encounter2017 2022-08-25 10:26:09 +08:00
用 timestamp with time zone 是不是就没这么多事情了
|
|
23
samin OP |
|
24
samin OP @encounter2017 确实是小伙伴对 PG 的数据类型不够清晰
|
 |
25
Huelse 2022-08-25 10:32:57 +08:00
@HashV2 #19 好吧，我刚查了下 timestamp 的确存的 utc ，但 pg 会根据我服务器的时区自动转换，命令行查就已经是转过的了
|
|
26
Huelse 2022-08-25 10:39:19 +08:00
@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. ``` |
 |
27
csx163 2022-08-25 10:45:49 +08:00
看了还是不敢用容器跑数据库啊
|
 |
28
fisherwei 2022-08-25 10:57:29 +08:00
k8s 部署 pg 有严重的 cache 问题，楼主你们生产环境没有遇到吗？
|
 |
30
adoal 2022-08-25 12:18:49 +08:00
硬生生把开发和配置问题转变成了故障修复问题
|
|
32
samin OP @fisherwei 有 Sample 或者连接看一下吗 ？ 目前确实没遇到过 这个问题产生可能和 PG Cache 机制参数配置有关 ？
|
|
35
fisherwei 2022-08-25 15:04:22 +08:00
|
 |
36
yjhatfdu2 2022-08-25 17:42:53 +08:00
@samin 永久修改的话可以
ALTER SYSTEM SET timezone to 'Asia/Shanghai'; select pg_reload_conf(); 这样不用重启，连配置文件都不用手动改 |
 |
37
raysonlu 2022-08-25 17:53:25 +08:00
不懂就问，如果不是用 k8s 部署，是不是就能避免这种事？
|
 |
38
sampeng 2022-08-25 18:39:43 +08:00
看到这一句。。。线上使用 K8s 部署（单 Node 单 Pod ） bitnami PostgreSQL 14 版本数据库。。我就表示，不是这次出事就是下次出事。
数据库放 k8s 不是不可以，开发测试环境无所谓。生产环境？你是真不怕挂啊。。。。 |
|
39
sampeng 2022-08-25 18:41:13 +08:00
最后看到总结。。。。
what ？你这叫啥总结？？？？ |
 |
41
ljf 2022-08-26 09:06:23 +08:00
k8s 部署生产环境 pg ，不用考虑数据高可用，主备切换吗，我们线上都不敢直接 statefulset 跑 pg ，哪怕绑定单节点，机器挂了咋办。大佬搞个 https://github.com/sorintlab/stolon 吧
|
Select Language