PostgreSQL 高可用Patroni和学习方法

最近一段时间在学习 POSTGRESQL 的高可用，相关的方法很多，但是坑也很多,在PGPOOL-II上摔不了少跤，同时在学习期间发现一个问题就是，很多时候学习知识并没有求慎解，并且网上很多帖子都是安装完毕就OK 了，如果你安装去做的话，其实很多时候是安装不成功或问题无法解决。

本着换一种方式学习的，不浪费时间在一些应该知道，但从网上划拉帖子就做，然后一头雾水的学习方法，改换为，踏踏实实的来做一次相关的知识的梳理和层次化的学习。

本次学习的是 postgresql 的高可用方式 Patroni

Patroni 本身并不是一个软件，而是一个模板通过python来构建一个高可用的postgresql的解决方案。软件本身可以通过其他的分布式软件来进行支持（ zookeeper, etcd 等），同时根据你选择的不同的模块来安装patroni.

Patroni 本身使用的数据同步方式是postgresql的流复制方式，默认的情况我们还是使用异步的方式，在Patroni 中会有一个参数，

Maximum_lag_on_failover ,通过设置，保证从库在与主库超过一定数据不同步的情况下，不会发生相关的主从转移。

在patroni 的设置中，有三种方式，1 动态设置， 2 本地设置 3 环境设置，其中有一些设置在主库和从库之间必须保持一致，这些值在本地中的配置文件是不生效的。

以下值必须在动态设置中保存并设置

max_connections:

max_locks_per_transaction:

max_worker_processes:

max_prepared_transactions

wal_level:hot_standby

wal_log_hints: on

track_commit_timestamp: off

并且还有一些值也是需要大致相同的，主要原因是主从可能发生切换，而如果在切换后，新主的机器不能调整好自身的状态，则会影响正常的数据库使用。

max_wal_sender

max_replicaiton_slots:

wal_keep_segments:

同时，

listen_address

port

cluster_name

host_standby

等参数是通过动态的方式传递给 pt_ctl (pt_ctl 是patroni的启动程序)

并且这些参数的传递要高于 alter system 的设置。

具体，patroni 是怎么做的，又是怎么样的次序来进行配置的读取

1 节点首先检查 是否有 postgresql.base.conf (一般默认在安装后的postgresql 的数据目录)或者设置了 custom_conf

2 如果custom_conf 设置了相同的参数，则以custom_conf 为主，其他的配置将被忽略

3 如果custom_conf 没有设置，则以postgresql.base.conf为主，如果还不存在，则将postgresql.conf 变更为postgresql.base.conf

4 动态的选择项，将可以不使用重新读取的方式生效，而是编写应用后就生效。

总结：参数文件被应用的顺序

1 postgresql.base.conf

2 postgresql.conf

3 postgresql.auto.conf

4 run-time parameter

而动态的文件中的修改，DCS的配置改变都会将相关的配置保存在 patroni.dynamic的磁盘文件中。

而Patroni 使用的是 YAML的方式来进行配置的，所以这也就要求，配置文件的严谨性，例如多一个空格，少一个缩进，都是不可以的。

配置文件的项目很多，这里值关心 global 和 etcd的配置

1 Global 设置

name 集群名集群内的机器必须唯一，每台机器有自己的名字

namespace 存储配置信息的区域路径（请保持默认）

scope 集群的名字

2 log 的配置

level 设置日志的等级

format 设置日志的等级 默认的设置是 asctime levelname message

dateformat 设置时间格式

dir 要写入程序日志的目录，目录必须存在并且是patroni 用户编写并且可以由您设置此值。应用程序将默认保留4个25MB 的日志。

file_num 要保留的日志的数量

file_size patroni.log的尺寸

loggers: 定义允许日志等级

引导配置：

DCS: 在集群的全局配置，更改参数需要在 DCS 中或听过API 进行更改。

loop_wait 循环休眠的描述 默认 10秒

ttl: TTL获取先导锁。可以将其视为启动自动故障转移过程之前的时间长度。默认值:30

retry_timeout: 分布式程序和POSTGRESQL 之间的失联后多长时间不触发切换。

maximum_lag_on_failover:从库和主库之间在可以能进行主从切换中运行的字节差距。

master_start_timeout 主库在故障转移中的时间容忍度，loop_wait + master_start_timeout+loop_wait

synchronous_mode 打开这个模式将选择与主库最接近的从库作为可的新主库

synchronous_mode_strict ：打开这个模式将如果发现没有和主库进行数据复制的从库，则主库将禁止写入数据。