POSTGRESQL 12 VS 11 配置文件的改变 restart point（上次问题） 与 “傻逼” 理论

近听到一套理论叫SB理论，里面说的是一个人进步的问题，一个人如果往过去看，时间间隔的越短看自己觉得自己是一个SB ，那说明这个人进步了并且速度不慢，如果一直认为自己是“盖世武功” 或许自己已经SB 很久不自知了。  

今天要谈论的是 PG 12  和 PG 11 之间配置文件的差别的问题。之间的一致的东西都不会再提及，下面是 12 VS 11 之间的不同点。

#CONNECTIONS AND AUTHENTICATION

connection settings 

tcp settings

authentication

GSSAPI using Kerberos 

SSL

PG 11 VS PG 12 都是没有差异的

PASS 这些东西

#RESOURCE USAGE except WAL

这里就开始不一样了，首先要声明的是这里我们的系统的版本都是CENTOS7.5，版本没有不同

1   shared_memory_type = mmap  

这里只有12 具有， 11是没有这个选择项的

以上的这个添加的选择语句内存的分配和使用有关，这里需要LINUX的一些知识，这里不再扩展，建议不要修改这个配置，并且mmap也是目前在LINUX 中分配内存比较简单的一种方式。

2  wal_level = replica   V11

    wal_level = logical   V12

3  在PG V12 中添加了 

restore_command

archive_cleanup_command

recovery_end_command

recovery_target

recovery_target_name

recovery_target_time

recovery_target_xid

recovery_target_lsn

recovery_target_inclusive = on

recovery_target_timeline = lastest

recovery_target_action = pause

这里有一个问题，我清晰的记得，上次有人问过关于 archive_cleanup_command 的问题，哪个人问的问题是 command to execute at every restartpoint 是什么意思， 当时我记得他理解的是每次PG 重启启动 archive_clean_command 这个触发， 当时我也没有研究但认为这不对。

这里找到了相关的关于什么是resetartpoint 的官方解释，其中解释是

 a restartpoint is the equivalent of checkpoint  during recovery and establishes the point from which recovery can roll forward without replaying the entire recovery log. 

实际上这里我认为的就是每次check point 会触发这个位置，那实际上我们在这个位置上配置好

直接调用pg_archivecleanup 就可以了，所以这点比PG 11 是有进步的，ARCHIVE 目录里面的文件的清理，已经有了良好的解决方式。

4 在replication -- standby servers 

 添加了

primary_conninfo

primary_slot_name

promote_trigger_file

hot_standby = on

recovery_min_apply_delay = 0

3 和  4 两个部门是PG11 和 PG12 之间变动比较大的，这里注意PG12 将 

recovery.conf 不在是一个单独的文件了，而是迁移到了POSTGRESQL.CONF

5  Query tuning

plan_cache_mode = auto

这个问题是PG 对于OLAP 和 OLTP 的不同 ，OLTP 业务多的可以使用 auto 

对于OLAP 的业务，可能不会频繁执行并且每次输入的评估选择性差异会比较大，所以建议可以选择 force_custom_plan 。

并且不同的执行方式，可以对于用户和数据库信息单独的设置，所以这点是比较灵活的。

具体参见德哥的 github

https://github.com/digoal/blog/blob/master/201903/20190331_15.md

以上是我滤了一遍，可能还有错误和遗漏，请大家指正。

另外 PG 从9.X 到12 之间的变化在CONFIG 文件中的变化

近也在反思，当前数据库产品和10年前数据库在软件开发中的起到的作用，以数据库为中心的开发方式已经渐行渐远，但数据库模块化，功能化，为软件开发提供服务的时代应该已经是现在时，数据库应该不应该像MYSQL 一样沦为一个容器化的数据存储工具，还是应该成为一个提供模块化功能扩展和性能优化的功能提供者，这点见仁见智，也看所处的使用场景和人员，我认为MYSQL分表，并且在架构上对运维和开发以及DB人员在初期部署，软件设计，运维难度（备份，操作，数据汇聚）等等问题MYSQL本身不能解决，而需要更多技术架构的加入，这点对于一些非互联网企业或者技术能力薄弱的单位，选择MYSQL是否合适，值得思索。

因为3年前，在没有深入接触PG之前，我的确是认为分表扩展，MYSQL比 SQL SERVER ORACLE 高大上的太多了，但至少今时今日的我，看过去，我还真有点 SB， 希望我是进步了。

另外经常清理超过3个月不发言的同学，是在是不好意思，这边我准备在弄一个QQ 号。