pg数据库参数重载的问题
问题
pg数据库的参数都是在postgresql.conf中，一般情况下，initdb后，数据库会给一个初始的配置参数。但是很多业务场景下，需要进行针对性的调整。但是调整完后，生效就比较头疼，有的参数是需要重启数据库的，有的只需要重载一下配置 文件，有的可以是会话级别的。这里配置文件就没有每个参数都说明生效方式。生产数据库进行重启的话，有时候是不太好操作的，因为会强制暂停业务，影响到业务的连续性。本文探讨的就是这个问题。
参数重载
更改参数的类别
在pg数据库中，有一个视图pg_settings,该视图详细地记录了每一个参数的名称、设定值、类别，最小值，最大值，上下文等等，这里关注一个字段上下文context字段。
postgres=# select distinct(context) from pg_settings;
context
-------------------
backend
user
internal
postmaster
superuser
sighup
superuser-backend
(7 行记录)
官方文档没有对上下文做过多的解释，下面是一些用户可以更改内容的具体说明，按照更改的难度由难道易排序：
- internal：这些设置主要是在编译期间的数据库内部进行设置。包含了用户新的的视图，如果需要更改，只能进行软件的重新编译来进行。
- postmaster：只有在服务器重启后才进行更新。所有的共享内存都归到这个类别。
- sighup:给服务器发送hup信号时会使服务器重新加载postgresql.conf的配置，并且对参数说做的更改会立即生效，这是在实际中影响最小的一种方式。
- backend:这个与signup很像，但是所做的更改不会影响当前数据库正在运行的数据库后端的会话。只有在新的会话开始的时候才会生效。这个属性只有几个参数，很多影响行为的只在会话结束或者开始的时候才发生。只有启动log_connections后创建的新连接会被记录。
- superuser：这个属性可由任意一个数据库superuser权限的用户（通常是postgres)随时进行修改，并且不用重新加载配置文件即可以生效。
- user：单个用户的会话可以在任意时间调整这些参数。所做的变更只会影响到改会话。这里的大多数的参数会改变查询执行的方式，在每一个会话的基础上，允许调整查询的执行。
参数生效的方式
- set
可以在会话级别设置这种。
postgres=# set work_mem=262144;
SET
postgres=# show work_mem;
work_mem
----------
256MB
(1 行记录)
重新登录后
λ psql -U postgres
psql (9.6.12, 服务器 9.6.3)
输入 "help" 来获取帮助信息.
postgres=# show work_mem;
work_mem
----------
4MB
(1 行记录)
- pg_reload_conf函数
更改完sighup类的参数，可以直接使用下面语句来重载
postgres=# select pg_reload_conf();
pg_reload_conf
----------------
t
(1 行记录)
- pg_ctl
使用pg_reload,这个操作会重载配置文件。
[postgres@localhost ~]$ pg_ctl reload
server signaled
- 重启
pg_ctl restart来重启数据库，这些会直接更改能改的一切参数，但是注意的是一些会话级别的参数可能因此会丢失。
[postgres@localhost ~]$ pg_ctl restart -D /data1/pgdata
waiting for server to shut down.... done
server stopped
server starting
[postgres@localhost ~]$ < 2019-11-07 10:44:19.478 CST > 日志: 日志输出重定向到日志收集进程
< 2019-11-07 10:44:19.478 CST > 提示: 后续的日志输出将出现在目录 "pg_log"中.
总结
上面说明了更改参数的类别和重载的方法。主要是方便线上的运维，参数一般会随着业务进行不断的调整，有利于提供数据库的性能，保证业务的高效运行。
