ClusterControl部署PostgreSQL主从复制集群

本文详细介绍如何使用ClusterControl在多节点环境下部署PostgreSQL主从复制集群,包括配置Keepalived和HAProxy实现故障自动切换,以及通过Web界面进行集群管理。

ClusterControl简介

ClusterControl是一个用于部署数据库集群的无代理管理和自动化软件,它能够直接从用户界面部署,监控,管理和扩展数据库服务器/集群。ClusterControl能够处理维护数据库服务器或集群所需的大多数管理任务。

ClusterControl由许多组件组成:

ComponentPackage namingRole
ClusterControl Controller (cmon)clustercontrol-controllerThe brain of ClusterControl. A backend service performing automation, management, monitoring and scheduling tasks. All the collected data will be stored directly inside CMON database.
ClusterControl REST API [1]clustercontrol-cmonapiInterprets request and response data between ClusterControl UI and CMON database.
ClusterControl UIclustercontrolA modern web user interface to visualize and manage the cluster. It interacts with CMON controller via remote procedure call (RPC) or REST API interface.
ClusterControl SSHclustercontrol-sshOptional package introduced in ClusterControl 1.4.2 for ClusterControl’s web SSH console. Only works with Apache 2.4+.
ClusterControl Notificationsclustercontrol-notificationsOptional package introduced in ClusterControl 1.4.2 providing a service and user interface for notification services and integration with third party tools.
ClusterControl Cloudclustercontrol-cloudOptional package introduced in ClusterControl 1.5.0 providing a service and user interface for integration with cloud providers.
ClusterControl Cloud File Managerclustercontrol-cludOptional package introduced in ClusterControl 1.5.0 providing a command-line interface to interact with storage objects on cloud.
ClusterControl CLIs9s-toolsOpen-source command line tool to manage and monitor clusters provisioned by ClusterControl.

支持的Database Server/Cluste

ClusterControl支持一下数据库服务器和集群:

  • Galera Cluster

    • Percona XtraDB Cluster (Percona)

    • MariaDB Galera Cluster (MariaDB)

  • MySQL Cluster (NDB)

  • MySQL/MariaDB Replication (master-master and master-slave)

  • MySQL Group Replication (beta)

  • MySQL/MariaDB Standalone

  • MongoDB/Percona Server for MongoDB

    • Replica set

    • Sharded cluster

    • Replicated sharded cluster

  • PostgreSQL

    • Single instance

    • Streaming replication

支持的Load Balancer

ClusterControl支持以下路由软件:

  • HAProxy

  • MariaDB MaxScale

  • ProxySQL

  • Keepalived (virtual IP address only)

使用ClusterControl,您可以:

  • 在您选择的技术堆栈上部署独立,复制或集群数据库。

  • 在多语言数据库和动态基础架构之间统一自动执行故障转移,恢复和日常任务。

  • 您可以创建完整备份或增量备份并对其进行计划。

  • 对整个数据库和服务器基础架构进行统一,全面的实时监控。

  • 使用单个操作轻松添加或删除节点。

  • 在PostgreSQL上,如果您遇到事故,您的slave节点可以自动升级为master状态。

  • 它是一个非常完整的工具,带有免费的社区版本(还包括免费的企业版试用版)。

ClusterControl原理

ClusterControl组件必须驻留在除数据库集群之外的独立节点上。 例如,如果您有一个三节点Galera集群,则应在第四个节点上安装ClusterControl。 以下是使用ClusterControl构建Galera集群的示例:
在这里插入图片描述

启动cmon服务后,它会将内部/etc/cmon.cnf和/etc/cmon.d/cmon_*.cnf(如果存在)的所有配置选项加载到CMON数据库中。每个CMON配置文件表示具有不同群集ID的群集。它首先注册主机,收集信息,并通过SSH定期在所有受管节点上执行检查和预定作业。在ClusterControl中设置无密码SSH对于无代理管理至关重要。对于监视,可以使用无代理和基于代理的设置配置ClusterControl,有关详细信息,请参阅监视操作。

ClusterControl os_user使用ssh_identityCMON配置文件中定义的SSH密钥连接到所有受管节点。有关详细信息,请参阅无密码SSH部分。

用户真正需要做的是访问位于http://ClusterControl_host/clustercontrol的ClusterControl UI 并从那里开始管理数据库集群。您可以从导入现有数据库集群开始,或者在本地或云中创建新的数据库服务器或集群。ClusterControl支持在单个ClusterControl服务器下监视多个群集和群集类型,如下图所示:

在这里插入图片描述

ClusterControl通过端口9500上的远程过程调用(RPC)(由RPC令牌进行身份验证),端口9501(带有TLS的RPC)和可访问的REST API http://ClusterControl_host/cmonapi(由API token进行身份验证)公开所有功能。ClusterControl UI与这些接口交互以检索监控数据(集群负载,主机状态,警报,备份状态等)或发送管理命令(添加/删除节点,运行备份,升级集群等)。下图说明了ClusterControl的体系结构:

在这里插入图片描述

ClusterControl对性能影响最小,尤其是基于代理的监视设置,不会导致数据库服务器或群集停机。实际上,它会在找到失败的数据库节点或集群时执行自动恢复(如果已启用)。

ClusterControl功能

ClusterControl能够处理维护数据库服务器或集群所需的大多数管理任务。以下是ClusterControl可以在您的数据库基础结构上执行的一些任务:

  • 监控主机统计信息(CPU / RAM /磁盘/网络/交换)

  • 在单个CMON进程中配置多个数据库服务器/集群

  • 监视数据库的统计信息,变量,日志文件,查询,以及单个节点以及群集范围

  • 数据库配置管理

  • 数据库集群/节点恢复

  • 触发警报并发送通知

  • 安排并执行数据库备份(mysqldump,Xtrabackup,pgdump,pg_basebackup,mongodump,mongodb-consistent-backup)

  • 数据库备份状态

  • 恢复备份

  • 验证独立主机上的备份还原

  • MySQL时间点恢复

  • 将备份上载到AWS S3 / Google云存储/ Azure存储

  • 停止/启动/引导数据库服务

  • 从备份重建数据库节点以避免SST

  • 在本地或云上部署新的数据库服务器/集群

  • 添加现有的MySQL / MariaDB服务器/集群,MongoDB副本集和PostgreSQL服务器

  • 扩展数据库集群(添加/删除Galera节点,garbd和复制从属)

  • 部署数据库负载平衡器(HAProxy,MaxScale,ProxySQL)和虚拟IP地址(Keepalived)

  • 监视HAProxy / MaxScale / ProxySQL统计信息

  • 管理MySQL用户权限

  • 升级MySQL服务器

  • 推动MySQL / PostgreSQL奴隶掌握

  • 设置延迟的奴隶

  • 从主备份或现有备份中暂存复制从站

  • 管理数据库SSL的私钥和证书

  • 客户端 - 服务器加密,复制加密,备份加密(静止或传输中)

  • 从备份创建群集

  • 还有很多…

有关更多详细信息,请参阅ClusterControl产品页面https://severalnines.com/product/clustercontrol。您可能还想查看ClusterControl更改日志以获取最新的开发更新。

部署postgresql集群

部署环境

使用ClusterControl实现一个带有负载均衡服务的主从PostgreSQL集群,并在它们之间配置keepalived,所有这一切都来自友好且易于使用的界面。

对于我们的示例,我们将创建:

  • 3个PostgreSQL服务器(一个主服务器和两个从服务器)。
  • 3个HAProxy负载均衡器。
  • 在负载均衡服务器之间配置Keepalived。
    在这里插入图片描述

节点信息:

节点名称IP地址角色监听端口版本
clustercontrol192.168.92.10clustercontrol80v 1.7.1
pgmaster192.168.92.11master/haproxy/keepalived5432PostgreSQL 11.2
pgslave01192.168.92.12slave/haproxy/keepalived5432PostgreSQL 11.2
pgslave02192.168.92.13slave/haproxy/keepalived5432PostgreSQL 11.2
vip192.168.92.15vip for clusterrw:3307/ro:3308

clustercontrol文档:

https://severalnines.com/docs/getting-started.html

https://severalnines.com/docs/installation.html

postgresql指南:

https://severalnines.com/blog/how-deploy-postgresql-high-availability

https://severalnines.com/docs/user-guide/postgresql/overview.html

部署ClusterControl节点

官方支持yum源、脚本自动安装、离线安装、docker安装等多种方式部署clustercontrol节点,这里仅介绍以下两种:

以脚本方式安装:

在192.168.92.10节点执行以下操作

wget http://severalnines.com/downloads/cmon/install-cc.sh

chmod +x install-cc.sh

sudo ./install-cc.sh

以docker方式安装:

dockerhub地址:https://hub.docker.com/r/severalnines/clustercontrol

docker run -d severalnines/clustercontrol

配置SSH免密登录

必须可以从ClusterControl节点SSH免密访问从属节点

ssh-keygen

ssh-copy-id 192.168.92.11

ssh-copy-id 192.168.92.12

ssh-copy-id 192.168.92.13

部署PostgreSQL集群

访问ClusterControl web界面,填写email地址注册用户并登陆:

http://192.168.92.10/clustercontrol

创建3节点PostgeSQL主从复制集群

点击Deploy,选择PostgreSQL,配置SSH

在这里插入图片描述

配置端口,创建复制用户moniuser/123456, PostgreSQL版本选择11。

在这里插入图片描述

配置主从节点IP

在这里插入图片描述

选择是否开启主从节点同步复制(同步或异步)

在这里插入图片描述

通过查看job观察部署进度:

在这里插入图片描述

等待部署完成后查看拓扑状态

在这里插入图片描述

部署Load Balancer

参考:

https://severalnines.com/docs/user-guide/postgresql/manage.html#postgresql-manage-load-balancer

负载均衡器

负载均衡器是故障转移时需要考虑的重要工具,特别是如果想在数据库拓扑中使用自动故障转移。

为了使故障转移对用户和应用程序都是透明的,我们需要一个中间的组件,因为它不足以将主服务器提升为从服务器。为此,我们可以使用HAProxy + Keepalived。

什么是HAProxy?

HAProxy是一种负载均衡器,可将流量从一个源分发到一个或多个目标,并可为此任务定义特定的规则和/或协议。如果任何目标停止响应,则将其标记为脱机,并将流量发送到其余可用目标。这可以防止将流量发送到不可访问的目的地,并通过将流量指向有效目的地来防止丢失此流量。

什么是Keepalived?

Keepalived允许您在主动/被动服务器组中配置虚拟IP。此虚拟IP分配给活动的"主"服务器。如果此服务器出现故障,IP将自动迁移到被发现为"被动"的"辅助"服务器,从而允许它以透明的方式继续使用相同的IP系统。

部署haproxy

在想要为负载均衡器实现故障转移的情况下,必须至少配置两个实例。HAProxy配置有两个不同的端口,一个是读写3307,一个是只读3308。

这里在3个节点上部署haproxy,以192.168.92.11节点为例(选择群集 - >管理 - >负载均衡器 - > Keepalived)。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

依次在另外两个节点执行以上操作,完成后查看haproxy状态,用户名密码admin/admin

http://192.168.92.11:9600/stats

在3个节点上部署keepalived

要执行keepalived部署,请选择群集,转到"Manage"菜单和"Load Balancer"部分,然后选择"Keepalived"选项。

在这里插入图片描述

选择3个haproxy节点,并配置虚IP和网卡。

Keepalived使用虚拟IP在发生故障时将其从一个负载均衡器迁移到另一个负载均衡器,操作完成后应该具有以下拓扑:

在这里插入图片描述

查看haproxy

在这里插入图片描述

在读写端口中,将主服务器设置为在线,将其余节点设置为脱机。在只读端口中,主站和从站都是在线状态。通过这种方式,我们可以平衡节点之间的读取流量。写入时,将使用读写端口,该端口将指向主站。

当HAProxy检测到我们的某个节点(主节点或从节点)无法访问时,它会自动将其标记为脱机。HAProxy不会向其发送任何流量。此检查由部署时由ClusterControl配置的运行状况检查脚本完成。这些检查实例是否已启动,是否正在进行恢复,或者是否为只读。

当ClusterControl将从属服务器提升为主服务器时,我们的HAProxy将旧主服务器标记为脱机(对于两个端口),并将提升的节点置于联机状态(在读写端口中)。通过这种方式,我们的系统继续正常运行。

如果我们的活动HAProxy(分配了我们系统连接的虚拟IP地址)失败,Keepalived会自动将此IP迁移到我们的被动HAProxy。这意味着我们的系统能够继续正常运行。

测试集群功能

基本配置

配置数据库远程连接

所有节点修改配置文件允许远程连接

修改pg_hba.conf配置文件

vim /var/lib/pgsql/11/data/pg_hba.conf

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only            
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
host    all             all             192.168.92.0/24         md5
# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.

新增一行允许192.168.92.0/24所有主机使用所有合法的数据库用户名访问数据库,并提供加密的密码验证。

重启数据库使配置生效

systemctl restart postgresql-11.service

为postgres用户设置密码

su - postgres

psql

ALTER USER postgres WITH PASSWORD ‘123456’;

安装psql客户端

这里在clustercontrol节点安装psql客户端进行测试。

yum install -y https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-centos11-11-2.noarch.rpm

yum install -y postgresql11

配置环境变量

cat >> /etc/profile << EOF

export PATH=$PATH:/usr/pgsql-11/bin

EOF

source /etc/profile

连接数据库

用户名密码postgres/123456连接默认数据库postgres。

访问读写数据库:92.168.92.15:3307

访问只读数据库:92.168.92.15:3308

测试主从复制

客户端连接数据库3307端口

psql -h 192.168.92.15 -U postgres -p 3307 -d postgres

在主库查看流复制信息

postgres=# select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;
  pid  |   state   |  client_addr  | sync_priority | sync_state 
-------+-----------+---------------+---------------+------------
 55316 | streaming | 192.168.92.12 |             1 | sync
 55233 | streaming | 192.168.92.13 |             0 | async
(2 rows)

postgres=# 

创建测试数据库test:

postgres=\# create database test;

在主库上,我们可以正常的进行读写操作。

登录slave节点(以192.168.92.12节点为例)查看是否同步成功:

psql -h 192.168.92.12 -U postgres -p 5432 -d postgres

postgres=\# \\l

slave节点为只读节点,创建数据库报错:

postgres=\# create database test1;

ERROR: cannot execute CREATE DATABASE in a read-only transaction

在备库上,我们只能进行读操作。

测试主从切换

clustercontrol支持web界面手动或主库故障时自动将从库切换为主库,但未加载license时该功能不可用,这里以访问数据库执行手动切换为例:

停止主库服务模拟故障

[root@pg-master ~]# su - postgres
-bash-4.2$ /usr/pgsql-11/bin/pg_ctl stop -m fast
waiting for server to shut down.... done
server stopped
-bash-4.2$ 
-bash-4.2$ /usr/pgsql-11/bin/pg_controldata | grep 'Database cluster state'        
Database cluster state:               shut down
-bash-4.2$ 

切换从库

登录从库节点,手动执行以下命令,将从库切换为主库

[root@bogon ~]# su - postgres
Last login: Sun Feb 17 21:09:20 CST 2019
-bash-4.2$  /usr/pgsql-11/bin/pg_ctl promote
waiting for server to promote.... done
server promoted
-bash-4.2$ /usr/pgsql-11/bin/pg_controldata | grep 'Database cluster state'
Database cluster state:               in production
-bash-4.2$ 

在clusterclotrol web界面查看, 192.168.92.12节点升级为主库,同时原主库为failed状态:

在这里插入图片描述

完成后重新从psql客户端连接:

[root@clustercontrol ~]# psql -U postgres -h 192.168.92.15 -d postgres -p 3307
Password for user postgres: 
psql (11.2, server 11.1)
Type "help" for help.

postgres=# select pg_is_in_recovery(); 
 pg_is_in_recovery 
-------------------
 f
(1 row)

postgres=# 

写入数据测试正常,但是该节点为独立master节点,未与另一个slave节点建立主从关系

postgres=# create database test1;
CREATE DATABASE
postgres=# 
postgres=# select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;
 pid | state | client_addr | sync_priority | sync_state 
-----+-------+-------------+---------------+------------
(0 rows)

postgres=#

修改pgslave02节点配置,将其重新连接到新主库

[root@pgslave02 ~]# sed -i 's/192.168.92.11/192.168.92.12/g' /var/lib/pgsql/11/data/recovery.conf
[root@pgslave02 ~]# su - postgres
-bash-4.2$ pg_ctl restart

新主库pgslave01查看备份状态

postgres=# select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;
 pid  |   state   |  client_addr  | sync_priority | sync_state 
------+-----------+---------------+---------------+------------
 1637 | streaming | 192.168.92.13 |             0 | async
(1 row)

查看拓扑状态,已经连接到新主库

在这里插入图片描述

将原主库作为从库连接到新主库,复制一份recovery.conf配置文件到原主库节点即可

[root@pgslave02 ~]# scp /var/lib/pgsql/11/data/recovery.conf 192.168.92.11:/var/lib/pgsql/11/data/recovery.conf
[root@pgmaster data]# chown postgres: recovery.conf

重新启动原主库

su - postgres

pg_ctl restart

查看拓扑状态,已经恢复正常:

在这里插入图片描述

新主库pgslave01查看备份状态

postgres=# select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;
  pid  |   state   |  client_addr  | sync_priority | sync_state 
-------+-----------+---------------+---------------+------------
 59545 | streaming | 192.168.92.11 |             0 | async
  1637 | streaming | 192.168.92.13 |             0 | async
(2 rows)

postgres=# 

自动主从切换

ClusterControl支持手动或故障时自动进行主备切换,开启30天企业版试用权限,测试相应功能。

要执行手动故障转移,请转到ClusterControl - >选择Cluster - > Nodes,然后在我们的某个从站的Action Node中,选择"Promote Slave"。通过这种方式,几秒钟后,我们的slave成为master,而我们以前的master就变成了slave。

这里以将slave01节点手动转为master节点为例:

在这里插入图片描述

查看拓扑状态,192.168.92.12节点成为master:

在这里插入图片描述

然后停掉192.168.92.12节点服务,模拟master故障,测试自动切换:

[root@pgslave01 ~]# su - postgres

-bash-4.2$ pg_ctl stop

在这里插入图片描述

等待几秒后192.168.92.11自动切换为master,并且slave02也正常连接到该节点:

在这里插入图片描述

下面将192.168.92.12作为slave节点连接到192.168.92.11

在这里插入图片描述

注意,如果我们设法恢复旧的失败主库,它将不会自动重新引入群集。我们需要手动完成。其中一个原因是,如果我们的副本在失败时被延迟,如果我们将旧主服务器添加到集群,则意味着信息丢失或跨节点的数据不一致。我们可能还想详细分析这个问题。如果我们只是将故障节点重新引入群集,我们可能会丢失诊断信息。此外,如果故障转移失败,则不再进行尝试。需要手动干预来分析问题并执行相应的操作。这是为了避免ClusterControl作为高可用性管理器尝试提升下一个奴隶和下一个奴隶的情况。

完成后状态:

在这里插入图片描述

添加slave节点

如果我们想要在另一个数据中心添加一个从服务器,或者作为意外事件或者要迁移您的系统,我们可以转到Cluster Actions,然后选择Add Replication Slave。

在这里插入图片描述

我们需要输入一些基本数据,例如IP或主机名,数据目录(可选),同步或异步从站。我们应该让我们的slave节点在几秒钟后启动并运行。

在使用其他数据中心的情况下,我们建议创建异步从站,否则延迟会显着影响性能。

配置文件参考

pg_hba.conf配置文件

cat /var/lib/pgsql/11/data/pg_hba.conf
......
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host  all  s9smysqlchk  ::1/128  md5
host  all  s9smysqlchk  localhost  md5
host  all  s9smysqlchk  127.0.0.1/32  md5

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
host    all             all             192.168.92.0/24         md5
# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            ident
host    replication     all             ::1/128                 ident
host  replication  cmon_replication  192.168.92.11/32  md5
host  replication  cmon_replication  192.168.92.13/32  md5
host  replication  cmon_replication  192.168.92.12/32  md5
host  all  moniuser  192.168.92.10/32  md5
host  all  s9smysqlchk  192.168.92.12/32  md5
[root@bogon data]# 

postgresql.conf配置文件

pgmaster比pgslave多一行配置synchronous_standby_names = ‘pgsql_node_0’

$ cat postgresql.conf | grep -v "^[[:space:]].*#" | grep -v "^#" | grep -v "^$"
data_directory = '/var/lib/pgsql/11/data'       # use data in another directory
listen_addresses = '*'  # what IP address(es) to listen on;
port = 5432     # (change requires restart)
max_connections = 100                   # (change requires restart)
shared_buffers = 503955kB                       # min 128kB
work_mem = 10079kB      # min 64kB
maintenance_work_mem = 125988kB # min 1MB
dynamic_shared_memory_type = posix      # the default is the first option
wal_level = hot_standby # minimal, replica, or logical
full_page_writes = on   # recover from partial page writes
wal_log_hints = on      # also do full page writes of non-critical updates
max_wal_size = 1GB
min_wal_size = 80MB
checkpoint_completion_target = 0.9      # checkpoint target duration, 0.0 - 1.0
max_wal_senders = 16    # max number of walsender processes
wal_keep_segments = 32  # in logfile segments; 0 disables
synchronous_standby_names = 'pgsql_node_0'      # standby servers that provide sync rep
hot_standby = on        # "off" disallows queries during recovery
effective_cache_size = 1511865kB
log_destination = 'stderr'              # Valid values are combinations of
logging_collector = on                  # Enable capturing of stderr and csvlog
log_directory = 'log'                   # directory where log files are written,
log_filename = 'postgresql-%a.log'      # log file name pattern,
log_truncate_on_rotation = on           # If on, an existing log file with the
log_rotation_age = 1d                   # Automatic rotation of logfiles will
log_rotation_size = 0                   # Automatic rotation of logfiles will
log_line_prefix = '%m [%p] '            # special values:
log_timezone = 'PRC'
track_activity_query_size = 2048        # (change requires restart)
datestyle = 'iso, mdy'
timezone = 'PRC'
lc_messages = 'en_US.UTF-8'                     # locale for system error message
lc_monetary = 'en_US.UTF-8'                     # locale for monetary formatting
lc_numeric = 'en_US.UTF-8'                      # locale for number formatting
lc_time = 'en_US.UTF-8'                         # locale for time formatting
default_text_search_config = 'pg_catalog.english'
shared_preload_libraries = 'pg_stat_statements' # (change requires restart)
pg_stat_statements.track=all

recovery.conf配置文件

$ cat recovery.conf
standby_mode = 'on'
primary_conninfo = 'application_name=pgsql_node_0 host=192.168.92.11 port=5432 user=cmon_replication password=jvEDSGDzwZ'
recovery_target_timeline = 'latest'
trigger_file = '/tmp/failover.trigger'

haproxy.cfg配置文件

[root@pgmaster ~]# cat /etc/haproxy/haproxy.cfg
global
        pidfile /var/run/haproxy.pid
        daemon
        user haproxy
        group haproxy
        stats socket /var/run/haproxy.socket user haproxy group haproxy mode 600 level admin
        node haproxy_192.168.92.11
        description haproxy server

        #* Performance Tuning
        maxconn 8192
        spread-checks 3
        quiet
defaults
        #log    global
        mode    tcp
        option  dontlognull
        option tcp-smart-accept
        option tcp-smart-connect
        #option dontlog-normal
        retries 3
        option redispatch
        maxconn 8192
        timeout check   3500ms
        timeout queue   3500ms
        timeout connect 3500ms
        timeout client  10800s
        timeout server  10800s

userlist STATSUSERS
        group admin users admin
        user admin insecure-password admin
        user stats insecure-password admin

listen admin_page
        bind *:9600
        mode http
        stats enable
        stats refresh 60s
        stats uri /
        acl AuthOkay_ReadOnly http_auth(STATSUSERS)
        acl AuthOkay_Admin http_auth_group(STATSUSERS) admin
        stats http-request auth realm admin_page unless AuthOkay_ReadOnly
        #stats admin if AuthOkay_Admin

listen  haproxy_192.168.92.11_3307_rw
        bind *:3307
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check expect string master\ is\ running
        balance leastconn
        option tcp-check
#       option allbackups
        default-server port 9201 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 192.168.92.11 192.168.92.11:5432 check 
        server 192.168.92.12 192.168.92.12:5432 check 
        server 192.168.92.13 192.168.92.13:5432 check 


listen  haproxy__3308_ro
        bind *:3308
        mode tcp
        timeout client  10800s
        timeout server  10800s
        tcp-check expect string is\ running
        balance leastconn
        option tcp-check
#       option allbackups
        default-server port 9201 inter 2s downinter 5s rise 3 fall 2 slowstart 60s maxconn 64 maxqueue 128 weight 100
        server 192.168.92.11 192.168.92.11:5432 check 
        server 192.168.92.12 192.168.92.12:5432 check 
        server 192.168.92.13 192.168.92.13:5432 check 

keepalived.conf配置文件

[root@pgmaster ~]# cat /etc/keepalived/keepalived.conf 
#haproxy - You can add more types manually after this.
        
vrrp_script chk_haproxy {
   script "killall -0 haproxy"   # verify the pid existance
   interval 2                    # check every 2 seconds
   weight 2                      # add 2 points of prio if OK
}
vrrp_instance VI_HAPROXY {
   interface ens33                # interface to monitor
   state MASTER
   virtual_router_id 51          # Assign one ID for this route
   priority 102                   
   unicast_src_ip 192.168.92.11
   unicast_peer {
      192.168.92.12
192.168.92.13

   }
   virtual_ipaddress {
       192.168.92.15                        # the virtual IP
   } 
   track_script {
       chk_haproxy
   }
#    notify /usr/local/bin/notify_keepalived.sh
}

# DO NOT REMOVE THE NEXT LINE
#@S9S_NEXT_SECTION@ 
<think>嗯,用户这次是明确要求一个基于两台服务器的PostgreSQL主从集群部署教程,而且特别提到参考之前的引用内容。看来用户是在搭建生产环境或测试环境,需要简洁实用的方案。用户之前提供的引用其实挺全面的,涵盖了主从复制配置的不同实现方式:引用1是传统的主从复制指南,引用2提到docker容器化部署,引用3展示了异步复制的验证方法,引用4涉及故障切换操作,引用5强调权限配置要点。不过用户这次明确要求两台物理服务器的部署方案,所以应该聚焦在传统方式上。注意到用户上次提问时我给出的高可用方案(Patroni)可能有些复杂,这次用户只要主从复制,所以需要简化。但作为专业建议,还是应该提一下高可用选项作为扩展方案。用户可能是运维工程师或开发人员,正在搭建数据库基础设施。ta连续两次询问集群部署,说明项目已经进入实施阶段,时间应该比较紧张。需要把关键步骤和常见避坑点说清楚,比如主从节点的时间同步和密码安全这种容易忽略的细节。技术要点要突出:1.主节点必须开启wal_level=replica(引用1/3)2.pg_hba.conf的replication规则是复制的关键(引用5)3.pg_basebackup是最安全的初始同步方式(引用2)4.standby.signal文件的创建标识了从库角色(现代PG版本特性)操作上需要重点强调:-主节点创建replication用户时要避免使用postgres超级用户(引用2)-同步模式下可能导致主库阻塞的风险(引用3的async配置)-配置后必须重启主库使参数生效(引用1)最后验证部分要给出直观的SQL命令,像用户引用3里展示的pg_stat_replication查询就很实用。故障切换方案虽然用户没要求,但作为完整方案应该包含(引用4的pg_ctlpromote操作)。对了,所有命令行必须标注清楚执行位置(主库/从库),这点在引用2的docker操作中体现得很好。用户可能在多台服务器之间操作,容易混淆节点。</think> 以下是基于两台服务器的 **PostgreSQL 主从复制集群部署教程**,结合引用内容整理的关键步骤: --- ### **一、环境准备** | **节点** | **IP** | **角色** | |----------|---------------|----------| | 节点A | 192.168.1.10 | 主库 | | 节点B | 192.168.1.11 | 从库 | **要求**: - 所有节点时间同步(`ntp/chrony`) - PostgreSQL 版本一致(以 v14 为例) - 防火墙开放端口:`5432`(数据库)、`8008`(监控) --- ### **二、主库配置(节点A)** #### 1. **修改 `postgresql.conf`** ```bash # 启用流复制 wal_level = replica max_wal_senders = 10 hot_standby = on # 同步提交(可选异步)[^3] synchronous_commit = remote_write ``` #### 2. **修改 `pg_hba.conf`** ```bash # 允许从库复制流 host replication repuser 192.168.1.11/32 md5 # 从库IP ``` #### 3. **创建复制用户** [^2] ```sql CREATE ROLE repuser LOGIN REPLICATION ENCRYPTED PASSWORD 'rep123'; ``` #### 4. **重启服务** ```bash sudo systemctl restart postgresql-14 ``` --- ### **三、从库配置(节点B)** #### 1. **清空数据目录** ```bash rm -rf /var/lib/pgsql/14/data/* ``` #### 2. **从主库同步数据** ```bash pg_basebackup -h 192.168.1.10 -U repuser \ -D /var/lib/pgsql/14/data -Ft -Xs -P -v ``` #### 3. **创建 `standby.signal` 文件** [^1] ```bash touch /var/lib/pgsql/14/data/standby.signal ``` #### 4. **配置 `postgresql.auto.conf`** ```ini primary_conninfo = 'host=192.168.1.10 port=5432 user=repuser password=rep123' ``` --- ### **四、启动与验证** #### 1. **启动从库** ```bash sudo systemctl start postgresql-14 ``` #### 2. **主库检查复制状态** [^3] ```sql SELECT client_addr, state, sync_state FROM pg_stat_replication; ``` **输出示例**: ``` client_addr | state | sync_state ---------------+-----------+------------ 192.168.1.11 | streaming | async ``` #### 3. **从库验证只读** ```sql SELECT pg_is_in_recovery(); -- 返回 `t` 表示只读模式 ``` --- ### **五、故障切换(主库宕机时)** [^4] 1. 在从库执行提升为主库: ```bash sudo -u postgres pg_ctl promote -D /var/lib/pgsql/14/data ``` 2. 检查新主库状态: ```bash sudo -u postgres pg_controldata | grep 'Database cluster state' # 输出 `in production` 表示提升成功 ``` --- ### **关键注意事项** 1. **异步 vs 同步复制**: - 异步:`synchronous_commit = off`(高性能,可能丢数据)[^2] - 同步:`synchronous_standby_names = 's1'`(强一致,性能损失) 2. **密码安全**: - 使用强密码 + `pg_hba.conf` IP白名单 [^5] 3. **监控**: - 定期检查 `pg_stat_replication` 和复制延迟 --- **
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

willops

你的鼓励将是我创作的最大动力!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值