Patroni环境的PG(PostgreSQL)数据库集群,Patroni所控制的数据库参数

概述

结论

1、在使用 Patroni 部署 PostgreSQL 集群时,了解全局参数和本地参数的区别,并合理地进行配置,是确保集群性能和稳定性的关键。全局参数涉及到数据一致性和复制要求,必须在所有节点上保持一致;而本地参数则可以根据各个节点的具体需求进行调整,以优化资源利用和性能表现。通过合理配置这些参数,可以有效提升 PostgreSQL 集群的可靠性和效率。
2、有些参数哪怕不去设置它,也会使用默认参数来保证集群的稳点定性和高可用。有些参数需要根据业务量,或者本地节点的硬件资源,去设置合适的数值,来充分发挥系统的性能。
3、为了确保数据复制和恢复的正常运行,一些参数必须在所有节点上保持一致。例如,wal_level 和 max_wal_senders 直接影响到 WAL 日志的生成和传输,如果配置不一致,会导致复制失败或数据不一致。
4、本地参数允许根据具体节点的需求进行优化配置,以充分利用资源。例如,通过为从节点配置更大的 work_mem 来优化查询性能,同时在主节点上保持较低的内存消耗以确保写操作的高效执行。

Patroni 参数配置类型

Patroni 提供了三种类型的参数配置,以满足不同的配置需求:

1. 全局参数(动态配置)

  • 它们通常涉及到数据库的一致性、复制和高可用性
  • 存储在 DCS(分布式配置存储)中
  • 应用于所有群集节点
  • 可随时使用 patronictl_edit_config 工具或 REST API <rest_api> 设置动态配置

2. 本地参数(.yml 文档配置)

  • 本地参数是只影响单个数据库实例的配置参数。它们通常与特定节点上的资源利用或节点角色有关。
  • 优先于动态配置
  • 可在运行时(无需重新启动 Patroni)通过以下方式更改和重新加载:
    • 向 Patroni 进程发送 SIGHUP
    • 执行 REST-API 请求
    • 执行 patronictl_reload

3. 环境变量参数(environment 环境变量)

  • 可使用环境变量设置/覆盖某些“本地”配置参数

全局参数列表

某些 PostgreSQL 参数必须在主数据库和副本上保持相同的值。这些参数无法通过本地 Patroni 配置文件或环境变量进行设置。要更改或设置其值,必须修改 DCS 中的共享配置。以下是这些参数的列表及默认值:

  • max_connections: 100
  • max_locks_per_transaction: 64
  • max_worker_processes: 8
  • max_prepared_transactions: 0
  • wal_level: replica
  • track_commit_timestamp: off
    全局参数说明
    wal_level: replica 参数默认是这个,原因是patroni需要实现高可用热备流复制,并结合性能问题默认为这个,logical可以支持逻辑复制和流复制,后期我们可能需要用到逻辑复制所以要修改。
    track_commit_timestamp: off 如果启用track_commit_timestamp会增加额外的写入开销,因为每次事务提交时都需要记录时间戳,只有某些特定应用场景需要跟踪事务的提交时间戳,比如审计、数据同步或者是一些特定的应用逻辑才使用。
    max_prepared_transactions: 0 默认情况下禁用了两阶段提交,这种应用场景比较少,一般用在跨数据库的业务场景里,就像MySQL的分库分表。
    max_locks_per_transaction: 64 大多数事务并不需要持有大量的锁,如果默认值过高,尤其是在系统中有大量并发事务时,会增加内存开销。
    max_worker_processes: 8 决定了数据库实例中可以运行的最大工作进程数,没有充分了解系统需求和资源情况下,过高的默认值可能导致过多的进程争夺资源,如果是大量并行查询或高负载场景,可以适当调整,默认值已经可以完全胜任系统业务且保证系统稳定性。
    max_connections: 100 过多的客户端连接会消耗更多的系统资源,大部分客户端都是长期活跃状态,100的并发量已经满足一些企业的要求了。
    本地参数配置

对于以下参数,PostgreSQL 不要求主副本和所有副本之间的值相等。然而,考虑到副本随时可能成为主副本,Patroni 将这些参数的值限制为与动态配置一致

  • max_wal_senders: 5
  • max_replication_slots: 5
  • wal_keep_segments: 8
  • wal_keep_size: 128MB

在配置这些参数时,应验证它们是否合理或满足最小值要求。

此外,Patroni 还控制一些传递给数据库的 Postgres 参数:

  • listen_addresses: 从环境变量设置,例如 PATRONI_POSTGRESQL_LISTEN
  • port: 从环境变量设置,例如 PATRONI_POSTGRESQL_PORT
  • cluster_name: 从环境变量设置,例如 PATRONI_SCOPE
  • hot_standby: 启用,因为patroni要实现高可用,就是保证主备库正常运行。所以必须开启
  • wal_log_hints: 开启 (适用于 Postgres 9.4 及更高版本)

出于安全考虑,上述列表中的参数不会直接写入 postgresql.conf,而是作为参数列表传递给数据库启动命令,从而确保它们具有最高优先级,甚至高于通过 ALTER SYSTEM 或直接编辑 postgresql.conf 设置的参数。
本地参数说明
max_wal_senders: 5 用于指定允许的最大 WAL (Write-Ahead Logging) 发送器的数量,如果用户有更多的从节点需求,他们可以根据需要增加 max_wal_senders,而不是一开始就占用很多资源
max_replication_slots:5 设置最大复制槽数量的配置参数。复制槽(Replication Slot)是一种机制,用于在主节点和从节点之间保持持久性连接
wal_keep_size: 128MB 保留在磁盘上的 WAL(Write-Ahead Log,预写日志)文件的最小大小,有助于避免因 WAL 文件被删除而导致的复制中断,还能减小占用存储资源。
wal_keep_segments: 8 配置保留在磁盘上的 WAL(Write-Ahead Log)文件的数量,如计划中的维护或临时网络问题,可以相应地增加 wal_keep_segments 的值,保证复制不会中断。
wal_log_hints: 开启 用于控制是否启用 WAL 日志提示(WAL log hints)功能,好处是,在高并发写入场景下。启用日志提示功能有助于优化这些写入操作,减少随机访问,提高性能。减少碎片化的写入操作,这在高负载的情况下尤为重要。

参数应用优先级简述版

  • custom_conf 指定的文件
  • postgresql.base.conf
  • postgresql.conf
  • postgresql.auto.conf
  • 使用 -o --name=value 指定的运行时参数

参数设置与优先级详细版

  • postgresql.listenpostgresql.data_dir 等参数只能在本地设置,通常在 .yml 文档或环境配置文件中进行配置。

应用本地或动态配置选项时,Patroni 会执行以下步骤:

  1. 节点首先检查是否存在 postgresql.base.conf 文件或是否设置了 custom_conf 参数。
  2. 如果设置了 custom_conf 参数,Patroni 将使用该参数指定的文件作为基本配置,并忽略 postgresql.base.conf 和默认的 postgresql.conf
  3. 如果未设置 custom_conf 参数且 postgresql.base.conf 存在,Patroni 将使用 postgresql.base.conf 中的参数作为基本配置。
  4. 如果两者都不存在,Patroni 将把原始的 postgresql.conf 重命名为 postgresql.base.conf 并用作基本配置。

总结来说,Patroni 节点首先检测 postgresql.base.conf 文件和 custom_conf 参数。其中,custom_conf 所指定的配置文件具有最高优先级。如果没有指定该参数,Patroni 将查找 postgresql.base.conf 文件作为基本配置。如果该文件也不存在,Patroni 将把 postgresql.conf 复制并重命名为 postgresql.base.conf,然后继续进行正常操作。

动态选项与配置应用

动态选项(除了上述例外)会被转储到 postgresql.conf 中,并添加到基本配置(postgresql.base.conf)之后。Patroni 会使用命令行参数来覆盖一些集群管理所必需的配置。

如果更改了需要重新启动的选项(这取决于这些选项在 pg_settings 中的上下文),Patroni 将在该节点上设置 pending_restart 标志。这个标志将在数据库重新启动时被重置。

接触共享内存的 PostgreSQL 参数

  • max_connections
  • max_prepared_transactions
  • max_locks_per_transaction
  • max_wal_senders
  • max_worker_processes

更改这些参数需要重新启动 PostgreSQL 才能生效,并且它们在备用节点上的共享内存结构不能小于主节点上的共享内存结构。

  1. 应用更改
    通过 :ref: 'patronictl_edit_config'(或通过 REST API 端点)应用更改到 /config

  2. 重新启动节点
    通过 :ref: 'patronictl_restart'(或通过 REST API 端点)重新启动节点/restart

注意

  • 如果重新启动 Patroni 守护程序(例如通过执行systemctl restart patroni)来重新启动 PostgreSQL,可能会导致集群中发生故障转移。

增加设置的值

  1. 首先重新启动所有备库。
  2. 之后重新启动主数据库。

降低设置的值

  1. 首先重新启动主数据库。
  2. 之后重新启动所有备库。

注意

  • 如果您在降低任何这些设置的值后尝试一次性重新启动所有节点,Patroni 将忽略更改并使用原始设置值重新启动备用数据库。因此,需要您稍后再次重新启动备用节点。Patroni 这样做是为了防止备用数据库进入无限崩溃循环,因为如果您尝试将这些参数中的任何一个设置为低于备用节点上可见的值,PostgreSQL 将退出并显示 FATAL 消息。换言之,只有当备用数据库与主数据库保持同步时,我们才能减少备用数据库的设置。

可动态更改的 Patroni 配置选项

  • ttl: 30
  • loop_wait: 10
  • retry_timeouts: 10
  • maximum_lag_on_failover: 1048576
  • max_timelines_history: 0
  • check_timeline: false
  • postgresql.use_slots: true

更改这些选项后,Patroni 将读取存储在 DCS 中的配置的相关部分,并更改其运行时值。

Patroni 节点将每次更改配置时将 DCS 选项的状态转储到 patroni.dynamic.json 文件,该文件位于 Postgres 数据目录中。如果 DCS 中完全没有这些选项或这些选项无效,则只允许领导者从磁盘转储中恢复这些选项。

一 、集群安装完成后的参数配置

1.1.1 -初始、安装时postgres0.yml文件的参数
(venv-patctl-1.8.0) [postgres@postgres confd]$ cat postgres0.yml 
scope: batman
namespace: /service/
name: postgresql109
restapi:
  listen: 192.168.6.109:8008
  connect_address: 192.168.6.109:8008
  #Provide host to do the initial discovery of the cluster topology:
zookeeper:
  hosts:
  - 192.168.6.108:2181
  - 192.168.6.109:2181
  - 192.168.6.110:2181
log:
  dir: /home/postgres/patctl/log
  dateformat: '%Y-%m-%d %H:%M:%S'
  file_size: 50000000 # 50MB
  file_num: 10  # keep history of 10 files
  level: INFO
  loggers:
    patctl.utils: INFO
bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
#    primary_start_timeout: 300
#    synchronous_mode: false
    #standby_cluster:
      #host: 127.0.0.1
      #port: 1111
      #primary_slot_name: patroni
    postgresql:
      use_pg_rewind: true
      pg_hba:
      - host replication repuser  127.0.0.1/24 trust
      - host replication repuser  192.168.6.108/24      trust
      - host replication repuser  192.168.6.109/24      trust
      - host replication repuser  192.168.6.110/24      trust
      - host all all 192.168.6.108/24 trust
      - host all all 192.168.6.109/24 trust
      - host all all 192.168.6.110/24 trust
#      use_slots: true
      callbacks:
        on_role_change: /home/postgres/patctl/logical.sh
      parameters:
        logging_collector: 'on'
        log_min_messages: 'info'
        log_min_error_statement: 'info'
        max_connections: 1000
        checkpoint_completion_target: 0.9
        wal_buffers: 16MB
        default_statistics_target: 100
        random_page_cost: 4
        effective_io_concurrency: 2
        min_wal_size: 2GB
        max_wal_size: 8GB
        wal_level: logical
  initdb:  # Note: It needs to be a list (some options need values, others are switches)
  - encoding: UTF8
  - data-checksums
  users:
    admin:
      password: admin
      options:
        - createrole
        - createdb
postgresql:
  listen: 192.168.6.109:8432
  connect_address: 192.168.6.109:8432
  data_dir: /home/postgres/data/fbase/fdata 
#  bin_dir:
#  config_dir:
  pgpass: /home/postgres/.pg_pass
  authentication:
    replication:
      username: repuser
      password: repuser
    superuser:
      username: fbase
      password: fbase
  parameters:
    unix_socket_directories: '/tmp'  # parent directory of data_dir
tags:
    nofailover: false    
    noloadbalance: false
    clonefrom: false
    nosync: false
(venv-patctl-1.8.0) [postgres@postgres confd]$ 
1.1.2使用patroni -c /path/postgres0.yml show-config命令展示出来的集群配置参数
#集群配置参数
(venv-patctl-1.8.0) [postgres@postgres confd]$ patronictl -c postgres0.yml show-config
loop_wait: 10
maximum_lag_on_failover: 1048576
postgresql:
  callbacks:
    on_role_change: /home/postgres/patctl/logical.sh
  parameters:
    checkpoint_completion_target: 0.9
    default_statistics_target: 100
    effective_io_concurrency: 2
    log_min_error_statement: info
    log_min_messages: info
    logging_collector: 'on'
    max_connections: 50
    max_wal_size: 4GB
    min_wal_size: 1GB
    random_page_cost: 4
    wal_buffers: 32MB
    wal_level: logical
  pg_hba:
  - host replication repuser  127.0.0.1/24 trust
  - host replication repuser  192.168.6.108/24      trust
  - host replication repuser  192.168.6.109/24      trust
  - host replication repuser  192.168.6.110/24      trust
  - host all all 192.168.6.108/24 trust
  - host all all 192.168.6.109/24 trust
  - host all all 192.168.6.110/24 trust
  use_pg_rewind: true
retry_timeout: 10
ttl: 30

(venv-patctl-1.8.0) [postgres@postgres confd]$ 

全局设置:

loop_wait: 10:全局设置,指定了在重新尝试失败操作之前等待的时间(以秒为单位)。
maximum_lag_on_failover: 1048576:全局设置,指定了在故障切换时允许的最大事务延迟。
retry_timeout: 10:全局设置,指定了在发生错误时重新尝试操作的超时时间(以秒为单位)。
ttl: 30:全局设置,指定了Patroni领导者的生存时间(以秒为单位),在此时间后,Patroni节点会尝试放弃领导者角色。
连接设置:

pg_hba部分:包含了连接设置,指定了主机的认证规则,控制谁可以连接到数据库以及使用什么身份验证方法。
复制设置:

postgresql部分中的callbacks参数:定义了复制设置中的回调脚本的路径,用于处理角色转换事件。
postgresql部分中的parameters参数:包含了一系列复制设置,如wal_level、max_wal_size、min_wal_size等,用于配置复制的行为和性能。
use_pg_rewind: true:复制设置,指示是否启用了pg_rewind工具用于快速恢复。


1.1.3数据库中使用的实际配置参数
(venv-patctl-1.8.0) [postgres@postgres sh]$ sh check.sh -h 192.168.6.109 -p 8432 -u fbase -d postgres
  _____  _        ____  _       _       _       
 / ____|| |      / __ \| |     | |     (_)      
| (___  | |     | |  | | |__   | |_ __  _  _ __  
 \___ \ | |     | |  | | '_ \  | | '__|| || '_ \ 
 ____) || |____ | |__| | | | | | | |   | || | | |
|_____/ |______| \____/|_| |_| |_|   |_||_| |_|

 PostgreSQL Art

检查 PostgreSQL 参数设置:
--------------------------------
max_connections(最大连接数):
 50

max_locks_per_transaction(每个事务的最大锁数):
 64

max_worker_processes(后台工作进程的最大数量):
 8

max_prepared_transactions(预处理事务的最大数量):
 0

wal_level(WAL日志详细程度):
 logical

track_commit_timestamp(跟踪提交的时间戳信息):
 off

max_wal_senders(最大流复制进程数):
 10

max_replication_slots(最大复制插槽数量):
 10

wal_segment_size(WAL段大小):
 16MB

max_wal_size(最大wal文件大小):
 4GB

min_wal_size(最大wal文件大小):
 1GB

wal_keep_size(WAL文件的保留大小限制):
 128MB

listen_addresses(监听地址):
 192.168.6.109

port(端口号):
 8432

cluster_name(集群名称):
 batman

hot_standby(是否启用热备):
 on

wal_log_hints(是否启用WAL日志提示):
 on

ttl(Patroni领导者的生存时间):

loop_wait(Patroni重新选择领导者之前的等待时间):

retry_timeouts(重新连接失败时的等待时间):

maximum_lag_on_failover(故障转移时的最大延迟允许):

max_timelines_history(最大时间线历史记录):

check_timeline(是否检查时间线):

postgresql.use_slots(是否使用复制插槽):

--------------------------------
脚本执行完毕。
(venv-patctl-1.8.0) [postgres@postgres sh]$ 

二、集群安装完成后的全部修改参数为默认的参数配置

2.1.1postgres0.yml文件全部使用默认值,修改后展示出来的集群配置参数
(venv-patctl-1.8.0) [postgres@postgres confd]$ patronictl -c postgres0.yml show-config
loop_wait: 10
maximum_lag_on_failover: 1048576
postgresql:
  callbacks:
    on_role_change: /home/postgres/patctl/logical.sh
  parameters: null
  pg_hba:
  - host replication repuser  127.0.0.1/24 trust
  - host replication repuser  192.168.6.108/24      trust
  - host replication repuser  192.168.6.109/24      trust
  - host replication repuser  192.168.6.110/24      trust
  - host all all 192.168.6.108/24 trust
  - host all all 192.168.6.109/24 trust
  - host all all 192.168.6.110/24 trust
  use_pg_rewind: true
retry_timeout: 10
ttl: 30

(venv-patctl-1.8.0) [postgres@postgres confd]$ 
2.1.2数据库中所应用的实际默认参数
(venv-patctl-1.8.0) [postgres@postgres sh]$ ./check.sh  --help
Usage: ./script.sh [OPTIONS]
Options:
  -h, --host     PostgreSQL host (default: 192.168.6.109)
  -p, --port     PostgreSQL port (default: 8432)
  -u, --user     PostgreSQL username (default: fbase)
  -d, --database PostgreSQL database name (default: postgres)
例如:sh check.sh -h 192.168.6.109 -p 8432 -u fbase -d postgres
(venv-patctl-1.8.0) [postgres@postgres sh]$ sh check.sh -h 192.168.6.109 -p 8432 -u fbase -d postgres
  _____  _        ____  _       _       _       
 / ____|| |      / __ \| |     | |     (_)      
| (___  | |     | |  | | |__   | |_ __  _  _ __  
 \___ \ | |     | |  | | '_ \  | | '__|| || '_ \ 
 ____) || |____ | |__| | | | | | | |   | || | | |
|_____/ |______| \____/|_| |_| |_|   |_||_| |_|

 PostgreSQL Art

检查 PostgreSQL 参数设置:
--------------------------------
max_connections(最大连接数):
 100

max_locks_per_transaction(每个事务的最大锁数):
 64

max_worker_processes(后台工作进程的最大数量):
 8

max_prepared_transactions(预处理事务的最大数量):
 0

wal_level(WAL日志详细程度):
 replica

track_commit_timestamp(跟踪提交的时间戳信息):
 off

max_wal_senders(最大流复制进程数):
 10

max_replication_slots(最大复制插槽数量):
 10

wal_segment_size(WAL段大小):
 16MB

max_wal_size(最大wal文件大小):
 1GB

min_wal_size(最大wal文件大小):
 80MB

wal_keep_size(WAL文件的保留大小限制):
 128MB

listen_addresses(监听地址):
 192.168.6.109

port(端口号):
 8432

cluster_name(集群名称):
 batman

hot_standby(是否启用热备):
 on

wal_log_hints(是否启用WAL日志提示):
 on

ttl(Patroni领导者的生存时间):

loop_wait(Patroni重新选择领导者之前的等待时间):

retry_timeouts(重新连接失败时的等待时间):

maximum_lag_on_failover(故障转移时的最大延迟允许):

max_timelines_history(最大时间线历史记录):

check_timeline(是否检查时间线):

postgresql.use_slots(是否使用复制插槽):

--------------------------------
脚本执行完毕。
(venv-patctl-1.8.0) [postgres@postgres sh]$ 

三、参数的设置情况以及一些参考标准

要分析这些参数在不同并发量和吞吐量下的设置,首先需要了解你的数据库应用场景以及具体的需求。以下是一些参数说明和建议设置的详细解释:

max_connections (最大连接数): 50

  • 建议: 根据应用需求设置。50个连接适用于中小型应用。如果并发用户更多,可能需要增加,前提是服务器硬件资源足够支持。
  • 考虑: 高并发情况下,可能需要更高的值,同时确保有足够的硬件资源(CPU、内存)。

max_locks_per_transaction (每个事务的最大锁数): 64

  • 建议: 默认值通常足够,但对于复杂事务管理更多表或行锁时,可能需要增加。
  • 考虑: 复杂度高的事务或大量并发写操作时,可以适当增加。

max_worker_processes (后台工作进程的最大数量): 8

  • 建议: 根据服务器的多核CPU配置来调整。8个进程在一般情况下已经较为合理。
  • 考虑: 如果有更多的并行任务处理需求,可以增加,但要考虑CPU核心数。

max_prepared_transactions (预处理事务的最大数量): 0

  • 建议: 如果不使用两阶段提交事务(2PC),设置为0是合适的。如果需要使用2PC,设置应该根据事务量调整。
  • 考虑: 为启用2PC的应用设置一个合理的值,例如与max_connections相同。

wal_level (WAL日志详细程度): logical

  • 建议: logical适用于需要逻辑复制的场景。如果不需要逻辑复制,可使用replicaminimal以减少WAL日志量。
  • 考虑: 需要逻辑复制时选择logical,否则选择replica

track_commit_timestamp (跟踪提交的时间戳信息): off

  • 建议: 如果不需要跟踪事务提交时间,关闭可以减少开销。
  • 考虑: 开启时会增加WAL日志开销,只有在需要此功能时才打开。

max_wal_senders (最大流复制进程数): 10

  • 建议: 设置为需要的复制节点数量。10个适用于多个从库或备份节点。
  • 考虑: 根据实际复制节点数量调整。

max_replication_slots (最大复制插槽数量): 10

  • 建议: 与max_wal_senders一致或略高。
  • 考虑: 每个复制节点对应一个插槽。

wal_segment_size (WAL段大小): 16MB

  • 建议: 通常保持默认值。大规模写入应用场景可以增加。
  • 考虑: 增加段大小可以减少WAL文件切换频率。

max_wal_size (最大wal文件大小): 4GB

  • 建议: 根据磁盘IO性能和恢复时间要求调整。4GB适用于多数中小型应用。
  • 考虑: 大规模写入应用可以增加。

min_wal_size (最小wal文件大小): 1GB

  • 建议: 用于控制WAL文件回收策略。1GB是较为稳健的设置。
  • 考虑: 可以根据磁盘空间和恢复时间调整。

wal_keep_size (WAL文件的保留大小限制): 128MB

  • 建议: 确保流复制节点不会因为WAL文件被回收而中断。128MB适用于小型应用。
  • 考虑: 增加值以确保复制稳定性。

listen_addresses (监听地址): 192.168.6.109

  • 建议: 根据实际网络环境设置。可以设置为特定IP或*(任意地址)。
  • 考虑: 安全性和访问需求。

port (端口号): 8432

  • 建议: 可以使用默认5432或自定义。为避免冲突,自定义端口号。
  • 考虑: 防火墙和网络配置。

cluster_name (集群名称): batman

  • 建议: 任意设置,主要用于标识集群。
  • 考虑: 唯一且描述清晰。

hot_standby (是否启用热备): on

  • 建议: 启用热备以便流复制。
  • 考虑: 需要实时读取副本时启用。

wal_log_hints (是否启用WAL日志提示): on

  • 建议: 启用以支持某些文件系统功能如pg_rewind。
  • 考虑: 增加WAL日志量,但为了数据一致性可接受。

Patroni相关参数

这些参数在Patroni管理PostgreSQL集群时使用:

  • ttl (Patroni领导者的生存时间): 根据选主算法需求设置,通常20-30秒。
  • loop_wait (Patroni重新选择领导者之前的等待时间): 设置为3-5秒。
  • retry_timeouts (重新连接失败时的等待时间): 1-3秒。
  • maximum_lag_on_failover (故障转移时的最大延迟允许): 根据应用要求设置,通常5-10秒。
  • max_timelines_history (最大时间线历史记录): 根据需要的历史时间线数量设置。
  • check_timeline (是否检查时间线): 开启以确保时间线一致性。
  • postgresql.use_slots (是否使用复制插槽): 一般开启以确保复制序列的一致性。

): on

  • 建议: 启用热备以便流复制。
  • 考虑: 需要实时读取副本时启用。

wal_log_hints (是否启用WAL日志提示): on

  • 建议: 启用以支持某些文件系统功能如pg_rewind。
  • 考虑: 增加WAL日志量,但为了数据一致性可接受。

Patroni相关参数

这些参数在Patroni管理PostgreSQL集群时使用:

  • ttl (Patroni领导者的生存时间): 根据选主算法需求设置,通常20-30秒。
  • loop_wait (Patroni重新选择领导者之前的等待时间): 设置为3-5秒。
  • retry_timeouts (重新连接失败时的等待时间): 1-3秒。
  • maximum_lag_on_failover (故障转移时的最大延迟允许): 根据应用要求设置,通常5-10秒。
  • max_timelines_history (最大时间线历史记录): 根据需要的历史时间线数量设置。
  • check_timeline (是否检查时间线): 开启以确保时间线一致性。
  • postgresql.use_slots (是否使用复制插槽): 一般开启以确保复制序列的一致性。

这些设置需要根据具体应用场景进行调整,并持续监控性能和资源使用情况以做出必要的优化调整。

  • 11
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Patroni是一种开源的工具,用于管理PostgreSQL集群的高可用性。它是一个容器化的解决方案,可以实现自动化的集群管理和故障转移。以下是使用Patroni实现PG数据库高可用的步骤: 1. 安装Patroni 可以使用pip命令安装Patroni: ``` pip install patroni ``` 2. 配置Patroni Patroni的配置文件是YAML格式的,可以根据需要进行修改。以下是一个简单的示例: ``` scope: postgres namespace: /db/ name: pg-cluster restapi: listen: 0.0.0.0:8008 connect_address: $NODE1_IP:8008 etcd: host: $ETCD_IP:2379 bootstrap: dcs: ttl: 30 loop_wait: 10 retry_timeout: 10 maximum_lag_on_failover: 1048576 postgresql: use_pg_rewind: true parameters: max_wal_senders: 10 wal_keep_segments: 10 pg_hba: - host replication replicator 0.0.0.0/0 md5 - host all all 0.0.0.0/0 md5 synchronous_mode: off synchronous_commit: off archive_mode: off archive_command: false recovery_conf: restore_command: cp /var/lib/postgresql/backup/%f %p recovery_target_timeline: latest pgpass: /tmp/pgpass pgpassfile_mode: 600 bin_dir: /usr/lib/postgresql/9.6/bin pg_ctl: /usr/lib/postgresql/9.6/bin/pg_ctl use_slots: true create_replica_methods: - basebackup - pg_rewind ``` 在这个示例中,我们使用etcd作为DCS(分布式协调服务)来管理集群状态。我们还配置了一些PostgreSQL参数,如max_wal_senders和wal_keep_segments。这些参数都可以根据需要进行修改。 3. 启动Patroni 可以使用以下命令启动Patroni: ``` patroni postgres.yml ``` 这将启动一个PostgreSQL集群,并将其注册到etcd中。您可以使用以下命令检查集群状态: ``` curl http://$NODE1_IP:8008/patroni ``` 这将返回一个JSON格式的响应,其中包含有关集群状态的信息。 4. 测试故障转移 为了测试故障转移,您可以杀死主节点上的PostgreSQL进程。Patroni将检测到主节点已经下线,并自动将一个从节点提升为新的主节点。 您可以使用以下命令检查新主节点的状态: ``` curl http://$NODE2_IP:8008/patroni ``` 这将返回有关新主节点的信息。 总的来说,使用Patroni实现PostgreSQL集群的高可用性相对简单。它可以自动管理故障转移,并提供一些其他有用的功能,如DCS和可插拔的备份存储后端。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值