postgresql 集群_PostgreSQL来自欧罗巴Patroni系列技术主题三

文章转载自公众号：AustinDatabases

本次阅读时长：

.

.

系列三：Patroni 安装

作为一个系列，下面在介绍完为什么使用patroni以及为什么选择etcd后，接下来介绍patroni的安装，由于patroni是一个基于python的程序，这就与patroni的版本和python有关。 

目前使用patroni就需要考虑使用python3了，centos上需要去单独安装python3。

yum -y install libffi-devel

wget https://www.python.org/ftp/python/3.8.2/Python-3.8.2.tgz

xz -d Python-3.9.2.tgz

tar xvf Python-3.8.2.tar

pip3 install patroni[etcd] -i https://mirrors.aliyun.com/pypi/simple/

pip3 install psycopg2-binary -i https://mirrors.aliyun.com/pypi/simple/

pip3 install patroni -i https://mirrors.aliyun.com/pypi/simple/

安装是完毕了，但比较困难和难以理解的问题仍然存在。

既然是使用了etcd的分布式数据库，那就会牵扯到一个问题，数据库的配置，这在之前的repmgr以及其他的高可用没有遇到这样的问题，因为repmgr在操作的过程中，整体的配置(如果你的配置文件在制作repmgr standby节点的时候就复制过了了，前提是你的配置文件一同通过备份过来)

有一个点是我们的PostgreSQL的配置，是存在在Distributed Configuration Store，数据主要分三类

1. 动态配置文件 

2. 本地配置文件

3. 环境配置

首先Dynamic Configuration主要是在DCS分布式系统的设定，这些选项在系统的启动的时候被应用，同时如果在系统启动时并未被使用，在下一个执行的周期会将这些配置进行应用。如果有不能被立即应用的配置，则会在相关位置添加pending restart的标识。

其次，local configuration的优先级要大于dynamic configuration，在启动时将这些配置通过sighup信号的方式发送给patroni。

另外还有environment configuration，有些配置是需要本地的一些参数的配置。

etcd --config-file /etc/etcd.conf &

首先需要确认etcd是否正常工作，etcd不正常工作则后续的工作很难完成。

安装方面etcd在上期已经完成这里就不在说明了。

在本篇中的安装完成后，需要配置patroni的配置文件，在patroni启动之前，需要将PostgreSQL的三台机器进行相关的复制。

当然之前需要对PostgreSQL的pg_hba和postgresql.conf的初始化进行配置，pg_basebackup -h 192.168.198.66 -U repuser -p 5432 -D /pgdata/data/ -P -Xs -R

这里就不多说如何进行相关的复制的连接的建立，这属于前期需要知晓的问题。

scope: pg_patroni

namespace: /service/

name: pg_patroni1

restapi:

  listen: 192.168.198.66:8008

  connect_address: 192.168.198.66:8008

etcd:

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

  host: 192.168.198.66:2379

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

  loop_wait: 10

  retry_timeout: 10

restapi:

  listen: 192.168.198.66:8008

  connect_address: 192.168.198.66:8008

etcd:

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

  host: 192.168.198.66:2379

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

  loop_wait: 10

  retry_timeout: 10

  maximum_lag_on_failover: 1038571

  master_start_timeout: 300

  synchronous_mode: false

  postgresql:

    use_pg_rewind: true

    use_slots: true

    parameters:

    wal_level: locical

    hot_standby: "on"

    wal_keep_segments: 12

    max_wal_senders: 10

    max_replication_slots: 10

    wal_log_hints: "on"

    archive_mode: "on"

    hot_standby: on

postgresql:

  listen: 0.0.0.0:5432

  connect_address: 192.168.198.66:5432

  data_dir: /pgdata/data

  bin_dir: /usr/local/postgres/bin

  config_dir: /pgdata/data/

  pgpass: /home/postgres/patroni/.pgpass

  authentication:

   replication:

     username: repuser

     password: repuser

   superuser:

     username: postgres

     password: postgres

   rewind:  # Has no effect on postgres 10 and lower

     username: pgrewind

     password: pgrewind

tags:

   nofailover: false

   noloadbalance: false

   clonefrom: false

   nosync: false

启动patroni一个

patroni /etc/patroni.yml > /pgdata/patroni.log 2>&1 &

patronictl -c /etc/patroni.yml list

基本上patroni的安装就完毕了，但实际上一个软件的安装紧紧是开始使用这个软件的开始，并不是终结。

到底一个软件的设计思路和构造是需要弄明白的，首先patroni的使用的原理以及前置条件是什么。

Patroni主要是基PostgreSQL的streaming replication，基本上软件的分发是通过pip的方式来进行安装的，对于Centos，Rhel的rmp包一般有cybertec来进行提供。

Patroni创建集群，初始化流复制，包括同步需求，监控复制的状态，另外patroni也负责改变集群成员的配置，或者重新reload设置，同时会负责计划中的primary standby的手动交换，以及意外情况的failover，通过rewind将一个失败的primary节点重新拉上线，重新初始化复制的连接。

Patroni在被设计的之初就考虑了稳定和容错性，避免了Brain-Split的问题。

Patroni收集的所有数据都镜像在一个分布式键-值存储中，并且基于存储中提供的信息，所有的patroni实例在决策上达成一致，例如，如果主服务器失败，应该提升哪个副本,通过分布式键值存储，达到集群中的每台机器的状态的共享，通过这些组件来进行高可用方面的切换工作等。同时PostgreSQL也提供相关的接口，如果通过其他软件获知当前的系统的状态也是可行的，例如进行读写分离。

那么上一篇提到的patroni在配置文件上有三种，那么就涉及一个点，就是配置文件中配置的是否需要一致。举例下面的配置在patroni管理的服务器集群中配置一定是要一致的，因为在切换的过程中必须要求，这些都是动态值，不允许在单一服务器上生效。

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

以上的参数也需要在所有的集群的机器中保持一致。

预告：目前待发布Patroni系列技术主题(四、五、六、七)

关注分会官方微信并设为星标★，Patroni系列技术主题文章精彩不断！

I Love PG

关于我们

中国开源软件推进联盟PostgreSQL分会(简称：中国PG分会)于2017年成立，由国内多家PostgreSQL生态企业所共同发起，业务上接受工信部中国电子信息产业发展研究院指导。中国PG分会是一个非盈利行业协会组织。我们致力于在中国构建PostgreSQL产业生态，推动PostgreSQL产学研用发展。

欢迎投稿

做你的舞台，show出自己的才华 。

投稿邮箱：partner@postgresqlchina.com

                    ——愿能安放你不羁的灵魂

往期回顾

 

活动成就

PostgresConf.CN & PGConf.Asia2020大会预告

PG ACE计划的正式发布

三期PostgreSQL国际线上沙龙活动的举办

六期PostgreSQL国内线上沙龙活动的举办

PGCM高级认证培训的正式开启

经典文章

PostgreSQL 13.0 正式版发布通告

深度报告：开源协议那些事儿

从“非主流”到“潮流”，开源早已值得拥有

Oracle中国正在进行新一轮裁员，传 N+6 补偿

PostgreSQL与MySQL版权比较

PostgreSQL与Oracle：成本、易用性和功能上的差异

使用ora2pg完成从Oracle到Postgres的迁移

精彩专辑

PostgreSQL活动篇