--PostgreSQL 来自欧罗巴Patroni Patroni 配置文件 4

作为关于Patroni 的第四篇文字, 总想有些深度, 那深度是从哪里而来,首先我们先从patroni 运行后,在系统中存储的键值入手.

这里仅仅是从etcd 入手,如果是使用了其他方式的DCS 的情况下还请查询其他例如zookeeper 等方式如何查询键值.另外这里使用的是 etcd 的V2 版本,所以如果您使用的是ETCD的V3版本则这里的命令不会适合您.

首先根据patroni 的原理, 关键的配置数据尤其针对服务器中的数据是要存储在DCS 系统中的.

我们先通过etcd 的命令来查看我们目前ETCD本身的分布式的状态.

首先我们先确认我们的 etcd的版本, 这里需要说明的是ETCD 如果状态不正确,则postgresql patroni 的集群状态一定也是不正常的,所以对ETCD的一些基本操作也是必须的.

例如查看当前ETCD 的状态,以及到底谁是LEADER ,谁是LEADER 那基本上那个节点上安装的数据库就是主库.

curl http://127.0.0.1:2379/v2/keys

在装有etcd 的主机中执行上面的命令,上面的命令是针对V2 方式的获取当前etcd 中键值信息的

可以从图中看到我们的信息应该在 service 目录下, 那我们就顺藤摸瓜看看怎么获取相关信息.

curl http://127.0.0.1:2379/v2/keys/service/pg_au

这里的pg_au 其实就是etcd 当中的集群名,(请参见此系列的2)

我们将pg_au 里面的信息打开

{"action":"get","node":

{"key":"/service/pg_au","dir":true,"nodes":[

{"key":"/service/pg_au/history",

"value":"[[1,1006633392,\"no recovery target specified\",

\"2020-09-16T05:11:37.489948-04:00\"],[2,1073741976,\

"no recovery target specified\",\"2020-09-16T05:34:53.367447-04:00\"],

[3,1140850840,\"no recovery target specified\"],[4,1207959704,\

"no recovery target specified\",\"2020-09-16T07:52:33.506535-04:00\"],[5,1543504024,\

"no recovery target specified\",\"2020-09-17T06:38:11.730196-04:00\"],[6,1543504520,\

"no recovery target specified\",\"2020-09-17T09:04:40.909532-04:00\"],[7,1543504960,\

"no recovery target specified\",\"2020-09-16T17:18:06.189193-04:00\"]]","modifiedIndex":54330,"createdIndex":54330},

{"key":"/service/pg_au/initialize","value":"6870925623183711900","modifiedIndex":10,"createdIndex":10},

{"key":"/service/pg_au/leader","

value":"pg_au02","expiration":"2020-09-16T21:41:06.383355203Z","ttl":33,

"modifiedIndex":56866,"createdIndex":56242},{

"key":"/service/pg_au/members","dir":true,"modifiedIndex":9,"createdIndex":9},

{"key":"/service/pg_au/optime","dir":true,"modifiedIndex":15,"createdIndex":15},

{"key":"/service/pg_au/config",

"value":"{\"ttl\":30,\"loop_wait\":10,\"retry_timeout\":10,

\"maximum_lag_on_failover\":1048576,\"master_start_timeout\":300,

\"synchronous_mode\":false,\"postgresql\":{\"use_pg_rewind\":true,

\"use_slots\":true,\"parameters\":null,\"wal_level\":\"locical\",

\"hot_standby\":true,\"wal_keep_segments\":12,\"max_wal_senders\":10,

\"max_replication_slots\":10,\"wal_log_hints\":\"on\",\"archive_mode\":\"on\",

\"archive_timeout\":\"1800s\"}}","modifiedIndex":13,"createdIndex":13}],

"modifiedIndex":9,"createdIndex":9}}

分析其中获得的information, 其中有几个值得注意的地方

1 /service/pg_au/members

2 /service/pg_au/config

3 /service/pg_au/optime

4 /service/pg_au/initialize

5 /service/pg_au/leader

另外在其他位置展现了部分配置的内容

例如

1 wal_level

2 master_start_timeout

3 use_pg_rewind

4 host_standby

5 wal_keep_segments

6 wal_log_hints

7 archive_mode

等等这些信息,说明最基本的配置中,这些PG节点在这些信息上是一致的

我们继续从上面其他6个键值入手, 先从leader入手, 可以看到,其中显示的是pg_au02 对应的节点是 192.168.198.67 说明此节点是 leader 也就是主节点.

通过patronictl 进行验证, 证明 67节点是当前的主节点

curl http://127.0.0.1:2379/v2/keys/service/pg_au/members

我们继续通过ETCD的接口获取members 中的内容,可以发现这里的内容(上图),与patroni 的工作状态有关, 如果patroni 在某个节点不在工作,则这里显示\"state\":\"stopped, 如果节点是运行的状态,则显示 \"state\":\"running\ 的状态.

所以通过这里面的信息,可以来获取每一个节点中patroni 到底是运行了,还是没有运行.

curl http://127.0.0.1:2379/v2/keys/service/pg_au/initialize

initialize 里面的值主要是系统初始化时的代表集群的唯一值.

curl http://127.0.0.1:2379/v2/keys/service/pg_au/config

config 里面是相关系统的设置值.上面也介绍过.

实际上我们还是要重新来回顾一下,

重点在于 Dynamic configuration 和 local configuration 两个点 另外的一个点,和docker 下的postgresql 有关.上面讲的那些都是关于 Dynamic的内容,那么具体在Dynamic 中存储的配置信息到底是要做什么的.

下面找了一个官方的patroni.yaml 的例子来说说配置文件

scope: batman 集群的名字 ETCD 上显示

namespace: /service/ 集群配置信息在ETCD 的存储位置

name: postgresql0 当前机器的配置的机器名

restapi:

listen: 127.0.0.1:8008

connect_address: 127.0.0.1:8008

etcd:

#Provide host to do the initial discovery of the cluster topology:

host: 127.0.0.1:2379 ETCD 的地址

下面是重要的postgresql的配置信息

bootstrap:

# this section will be written into Etcd:/<namespace>/<scope>/config after initializing new cluster

# and all other cluster members will use it as a `global configuration`

dcs:

ttl: 30 当数据库系统出现问题,整体集群获得新的Leader 节点的时间

loop_wait: 10 轮训中的等待时间

retry_timeout: 10 当网络出现问题后,保证整体集群不进行跳转的保留时间

maximum_lag_on_failover: 1048576 当前所有从节点到底那些是可以被作为leader的选举的,和主库之间的复制延迟的设定

# master_start_timeout: 300 :当前所有从节点到底那些是可以被作为leader的选举的,和主库之间的复制延迟的设定

# synchronous_mode: false

• max_timelines_history: 每一次触发来检测系统的信息保留的历史的长度如果选择0 ,则这些历史信息将不被删除
• master_start_timeout:这里是系统等待主库重新工作的时间,当主库出现问题后默认需要等待300S 在此期间如果主库回归正常,则不再切换. 最大的默认切换时间是 loop_wait + master_start_timeout + loop_wait 的时间. synchronous_mode: 大开此模式,则集群中的leader节点和一个从节点将使用同步模式,则这样的情况下将保证在集群切换的过程中,数据不会因为切换而丢失.但需要注意的是,如果使用此模式,备库在不能工作后,将影响整体集群的写操作.

下面是对于从库的设定 略过

#standby_cluster:

#host: 127.0.0.1

#port: 1111

#primary_slot_name: patroni

下面是与postgresql 集群中所有机器有关的配置

postgresql:

use_pg_rewind: true 是否使用pg_rewind

use_slots: true

parameters:

wal_level: hot_standby

hot_standby: "on"

wal_keep_segments: 8

max_wal_senders: 10

max_replication_slots: 10

wal_log_hints: "on"

archive_mode: "on"

archive_timeout: 1800s

archive_command: mkdir -p ../wal_archive && test ! -f ../wal_archive/%f && cp %p ../wal_archive/%f

recovery_conf:

restore_command: cp ../wal_archive/%f %p

数据库初始化的配置

initdb: # Note: It needs to be a list (some options need values, others are switches)

- encoding: UTF8

- data-checksums

对于pg_hba 的配置

pg_hba: # Add following lines to pg_hba.conf after running 'initdb'

- host replication replicator 127.0.0.1/32 md5

- host all all 0.0.0.0/0 md5

下面是针对这台机器的postgresql的配置

postgresql:

listen: 0.0.0.0:5432

connect_address: 0.0.0.0:5432

data_dir: /data/postgresql 设置当前主机的数据库目录

# bin_dir:

# config_dir:

pgpass: /tmp/pgpass0

authentication:

replication:

username: replicator

password: rep-pass

superuser:

username: postgres

password: zalando

rewind: # Has no effect on postgres 10 and lower

username: rewind_user

password: rewind_password

需要配置至少三个相关账号, replication , superuser , rewind 三个账号供基础的patroni 在操作中使用. 也就是我们的所有在patroni 中运作的数据库都需要有这三个账号,另外还拥有一些通用的系统的账号,可以在pgpass中设定的用户密码文件中使用

#watchdog:

# mode: automatic # Allowed values: off, automatic, required

# device: /dev/watchdog

# safety_margin: 5

watchdog 咱们单独拿出来讲一期

tags:

nofailover: false nofailover 说明的到底释放允许这个节点参与leader的可选择.

noloadbalance: false 如果设置为true 在使用均衡复杂中,rest api将返回给相关应用程序503 ,则此节点仅仅作为一个standby节点,而不能作为balance的读节点.

clonefrom: false 在进行节点添加中如果选择true 则添加节点将优先选择此节点作为pg_basebackup的数据复制点

nosync: false 默认false 此节点不能作为事实同步节点