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

--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 的主机中执行上面的命令,上面的命令是针对V2 方式的获取当前etcd 中键值信息的

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

curl 其实就是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 中的内容,可以发现这里的内容(上图),与patroni 的工作状态有关, 如果patroni 在某个节点不在工作,则这里显示\"state\":\"stopped, 如果节点是运行的状态,则显示 \"state\":\"running\ 的状态.

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

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

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

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

重点在于 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:///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 此节点不能作为事实同步节点

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。