POSTGRESQL 15 日志的JSON 格式为什么用JSON 与 PG 14 没有注意的一些参数

最新推荐文章于 2024-07-22 06:02:52 发布

Austindatabases

最新推荐文章于 2024-07-22 06:02:52 发布

阅读量403

点赞数

文章标签： postgresql json 数据库

本文链接：https://blog.csdn.net/liuhuayang/article/details/128090603

版权

POSTGRESQL 的日志与他的竞品 MYSQL 日志可谓是两个极端，一个是根据日志的类别来产生不同的日志，错误日志，慢查询日志，genernal log, 而PG 自开始，日志就只有一个，但日志里面的信息，却是这么多年操作过的数据库中最完全的，没有之一。

大到慢查询日志，整体操作的数据命令以及他们的操作时间，小到各种checkpoint 记录等等，所以通过POSTGRESQL 的日志就可以满足所有对POSTGRESQL 监控状态和了解运行情况的需求。

那么这就产生了一个问题，这些日志的信息我怎么分析的问题，太多了，太详细了，太太太了。

所以日志如何分析必然是一个要解决的问题，所以个人猜想一个做数据库的TEAM 必然要想想后面的POSTGRESQL 日志怎么搞，首先第一个问题就是铺垫，让日志成为一个格式，一个通用的格式，然后固定格式，通过固定的格式在去产生一个好的，或者第三方的日志处理工具，就好办了。

所以POSTGRESQL 的JSON 日志功能在PG 15 推出了，并且我相信后面无论是官方，还是第三方，或者商业机构会在这里上面做出 “文章”，对日志的分析工具会有新的 TOOLS。

这里摘取一段 2022年一月17日 Michael Paquier 的关于JSONLOG 的介绍，首先jsonlog 是添加在log_destination 的一个选项，提供了日志的JSON格式。

其中麦克提到了，这个功能就是为了一些其他的应用做一个钩子hook ，来通过日志中发现问题，当然也可以是一个插件。其中在 log_destination 中展示的是jsonlog 说明已经启用了 jsonlog

然后日志可以通过其他的工具来进行打印，甚至可以将JSON 的日志数据，直接写入到 MONGODB ，如果你有大量的postgresql 的数据库需要管理，将这些日志进行集中处理和分析储存，是一个好的管理的方法。

关于这部分的文字可以参考下面的连接

https://www.depesz.com/2022/01/17/waiting-for-postgresql-15-introduce-log_destinationjsonlog/

下面是这个JSON日志的固定的格式，

Key                name   Type   Description
timestamp   string   Time stamp with milliseconds
user              string   User name
dbname    string   Database name
pid   number   Process ID
remote_host   string   Client host
remote_port   number   Client port
session_id   string   Session ID
line_num      number   Per-session line number
ps   string       Current ps display
session_start   string   Session start time
vxid                 string   Virtual transaction ID
txid                 string   Regular transaction ID
error_severity   string   Error severity
state_code   string   SQLSTATE code
message   string   Error message
detail             string   Error message detail
hint               string   Error message hint
internal_query        string   Internal query that led to the error
internal_position   number   Cursor index into internal query
context   string   Error context
statement              string   Client-supplied query string
cursor_position   string   Cursor index into query string
func_name           string   Error location function name
file_name             string   File name of error location
file_line_num       number   File line number of the error location
application_name      string   Client application name
backend_type              string   Type of backend
leader_pid   number   Process ID of leader for active parallel workers
query_id        number   Query ID

其实JSON 日志的问题，后面在使用中的不断的分析其中的信息，然后做出相关的分析日志的工具。

另一个问题是,PG14 中我之前没有注意的一些参数如 min_dynamic_ shared_ memory，这个选项是出自于POSTGRESQL 14 的一个新的参数，这个参数的主要对于在数据库启动的时候，需要分配多少内存给并行查询，当此内存区域不足或被并发查询耗尽内存时，新的并行查询尝试使用dynamic_shared_memory_type配置的方法从操作系统临时分配额外的共享内存，由于内存管理开销，该方法可能会较慢。在启动时使用min_dynamic_shared_memory分配的内存受操作系统上的huge_pages设置的影响(该操作系统支持该设置)，所以需要在系统启动时先进行分配，提高并行查询时的内存的预分配的效率问题。

还有vacuum_failsafe_age 和 vacuum_multixact_failsafe_age 两个参数，用来进来防止POSTGRESQL 数据库冻结炸弹产生的可能，尽力去避免，这也是需要仔细的去看的。