Pacemaker+Haproxy实现高可用和负载均衡

本文详细介绍如何在server1和server2上配置Red Hat Enterprise Linux的高级yum源,通过使用pssh, crmsh和pacemaker等工具,实现双机集群的心跳同步与负载均衡。文章深入讲解了corosync配置文件的编辑,以及通过crm命令行接口设置集群资源,如VIP和Apache服务,确保在一台服务器宕机时,另一台能无缝接管服务。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

  1. 配置高级的yum源(server1、server2)
    [root@server1 yum.repos.d]# vim rhel-source.repo

     name=Red Hat Enterprise Linux $releasever - $basearch - Source
     baseurl=http://172.25.61.250/rhel6.5
     enabled=1
     gpgcheck=1
     gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
     
     [LoadBalancer]
     name=Red Hat Enterprise Linux $releasever - $basearch - Source
     baseurl=http://172.25.61.250/rhel6.5/LoadBalancer
     enabled=1
     gpgcheck=0
     gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
     
     [HighAvailability]
     name=Red Hat Enterprise Linux $releasever - $basearch - Source
     baseurl=http://172.25.61.250/rhel6.5/HighAvailability
     enabled=1
     gpgcheck=0
     gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
     
     [ResilientStorage]
     name=Red Hat Enterprise Linux $releasever - $basearch - Source
     baseurl=http://172.25.61.250/rhel6.5/ResilientStorage
     enabled=1
     gpgcheck=0
     gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
     
     [ScalableFileSystem]
     name=Red Hat Enterprise Linux $releasever - $basearch - Source
     baseurl=http://172.25.61.250/rhel6.5/ScalableFileSystem
     enabled=1
     gpgcheck=0
     gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
    

[root@server1 yum.repos.d]# yum clean all
[root@server1 yum.repos.d]# yum repolist
[root@server1 yum.repos.d]# scp rhel-source.repo server2:/etc/yum.repos.d/

  1. 下软件,提供crm命令行接口,配置心跳节点,同时启动
    [root@server1 yum.repos.d]# yum clean all
    [root@server1 yum.repos.d]# yum repolist
    [root@server1 yum.repos.d]# scp rhel-source.repo server2:/etc/yum.repos.d/

  2. 安装软件
    server1:

     yum install pssh-2.3.1-2.1.x86_64.rpm  crmsh-1.2.6-0.rc2.2.1.x86_64.rpm -y
     yum install pacemaker -y
      cd /etc/corosync/
      [root@server1 corosync]# cp corosync.conf.example corosync.conf
     [root@server1 corosync]# vim corosync.conf
                       bindnetaddr: 172.25.61.0	#同网段
                       mcastaddr: 226.94.1.1	
                       mcastport: 5413		
                       ttl: 1
       service {
               name:pacemaker
               ver:0
       }
     
     [root@server1 corosync]# scp /etc/corosync/corosync.conf server2:/etc/corosync/
     
     [root@server1 corosync]# scp /etc/corosync/corosync.conf server2:/etc/corosync/
     ##给sever2发一份
    

4.server1和server2开启服务

	[root@server2 corosync]# /etc/init.d/corosync start
	Starting Corosync Cluster Engine (corosync): [ OK ]
	[root@server1 corosync]# /etc/init.d/corosync start
	Starting Corosync Cluster Engine (corosync): [ OK ]
  1. 设置集群资源

     [root@server2 corosync]# crm
     crm(live)# configure
     crm(live)configure# show
     node server1
     node server2
     property $id="cib-bootstrap-options" \
     	dc-version="1.1.10-14.el6-368c726" \
     	cluster-infrastructure="classic openais (with plugin)" \
     	expected-quorum-votes="2"ww
     crm(live)configure# 				####初始化
     
     crm(live)configure# verify 
        error: unpack_resources: 	Resource start-up disabled since no STONITH resources have been defined
        error: unpack_resources: 	Either configure some or disable STONITH with the stonith-enabled option
        error: unpack_resources: 	NOTE: Clusters with shared data need STONITH to ensure data integrity
     Errors found during check: config not valid
     
     01.将fence设备关闭
     crm(live)configure# property stonith-enabled=false
     crm(live)configure# verify
     crm(live)configure# commit
     
     02.先设置集群资源VIP,再设置apache服务
     crm(live)configure# primitive vip ocf:heartbeat:IPaddr2 params ip=172.25.61.100 nic=eth0 cidr_netmask=24
     crm(live)configure# verify 
     crm(live)configure# commit 
    
  2. server1和server2安装http,撰写默认发布页

    [root@server1 corosync]# cd /var/www/html/
    [root@server1 html]# vim index.html
    [root@server1 html]# cat index.html
    server1

  3. 启动脚本

     crm(live)configure# primitive apache lsb:httpd op monitor interval=10s
     crm(live)configure# verify 
     crm(live)configure# commit 
    

注意:动态监控下看到此时的VIP在server1上,httpd在server2上

  1. 设置资源组

     crm(live)configure# group website vip apache 
     crm(live)configure# verify 
     crm(live)configure# commit 
    
  2. 测试

     [root@foundation61 Desktop]# curl 172.25.61.100
     server1
     [root@foundation61 Desktop]# curl 172.25.61.100
     server1
     [root@foundation61 Desktop]# curl 172.25.61.100
     server1
     [root@foundation61 Desktop]# curl 172.25.61.100
     server2
     [root@foundation61 Desktop]# curl 172.25.61.100
     server2
     [root@foundation61 Desktop]# curl 172.25.61.100
     server2
    

用客户主机访问,server1的corosyna服务停掉之后,有访问到了server2节点

<think>好的,我现在需要回答用户关于PostgreSQL高可用负载均衡方案的问题。首先,我得回忆一下PG的高可用方案有哪些。用户之前问过索引类型,这次是另一个主题,需要确保回答准确且全面。 高可用方面,常见的方案有流复制、逻辑复制、基于共享存储的方案,还有第三方工具比如Patroni、Pgpool-II,以及云服务商的方案。负载均衡可能涉及到连接池、读写分离、中间件等。 可能需要分点说明,先高可用负载均衡,或者将两者结合起来。用户可能需要具体的实现方式工具,比如流复制的配置,Patroni的工作原理,或者PgBouncerPgpool-II的区别。 要注意不要遗漏关键点,比如自动故障转移、数据同步方式、主从切换机制等。同时,负载均衡部分要区分读写的处理,可能不同的工具有不同的侧重点,比如HAProxy用于连接分发,Pgpool-II还可以处理查询负载。 另外,用户可能需要知道各种方案的优缺点,比如流复制的延迟问题,或者基于共享存储的成本。可能需要给出一些实际应用场景,比如金融行业常用哪些,Web应用适合哪些。 还要考虑版本差异,比如PG12之后的改进是否影响高可用方案的选择。比如逻辑复制在较新版本中功能增强,可能更适合某些场景。 需要结构化回答,可能用列表或表格来比较不同方案。确保术语正确,比如流复制(Streaming Replication)、同步复制与异步复制的区别,以及它们在高可用中的作用。 可能还需要提到监控自动化工具,比如Repmgr或Patroni如何管理故障切换,以及如何与负载均衡器集成。例如,Patroni与HAProxy结合实现自动的故障转移连接重定向。 负载均衡方面,要区分连接池查询分发。PgBouncer是连接池,减少连接开销,而Pgpool-II可以解析SQL并分发到不同的节点,支持读写分离。 还要注意一些方案可能同时提供高可用负载均衡,比如Pgpool-II,但需要说明其优缺点,比如单点故障问题,或者配置复杂性。 需要检查是否有遗漏的重要方案,比如基于Kubernetes的部署,使用StatefulSetsOperators(如Crunchy Data的PG Operator或Zalando的Patroni Operator),这在云原生环境中越来越常见。 最后,总结时可能需要给出选择建议,根据不同的业务需求、团队熟悉度基础设施环境来推荐合适的方案。比如,小团队可能适合使用RepmgrPgpool,而大规模云环境可能更适合Kubernetes加Patroni的方案。 需要确保回答清晰易懂,避免过于技术化的术语,但又要足够详细,让用户了解各方案的核心机制。可能还需要给出配置示例或官方文档链接,但用户没有明确要求,可能暂时不需要。 另外,用户可能关心如何实现自动故障转移,避免手动干预,以及数据一致性的保证。在介绍每个方案时,需要提到这些方面,比如同步复制如何保证数据不丢失,但可能影响性能,而异步复制可能有数据丢失风险但更快。 可能还需要提到备份恢复策略作为高可用的一部分,但用户的问题集中在高可用负载均衡,所以可能不需要深入备份细节,除非相关方案中包含备份整合。 最后,确保回答结构合理,分点明确,使用用户容易理解的语言,同时覆盖主流方案新兴趋势。</think>以下是 PostgreSQL 高可用负载均衡的主流方案及其实践要点: ```sql -- 基础配置示例:流复制 ALTER SYSTEM SET wal_level = replica; CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'secret'; ``` ### 一、高可用核心方案 #### 1. 流复制架构 ```markdown 主库 ───(WAL流)──> 备库(同步/异步) ↗ 级联备库 ``` - **同步复制**:`synchronous_commit = on`(数据零丢失) - **级联复制**:支持多层级备库扩展 - **故障转移工具**: - **pg_rewind**:主备角色反转后数据修复 - **Patroni**:基于DCS(Etcd/ZooKeeper)的自动故障转移 #### 2. 逻辑复制方案 ```sql -- 创建发布端 CREATE PUBLICATION pub_multi FOR TABLE users, orders; -- 订阅端 CREATE SUBSCRIPTION sub_west CONNECTION 'host=primary dbname=app' PUBLICATION pub_multi; ``` - 支持跨版本复制 - 可选择性复制表/数据分区 #### 3. 共享存储方案 ```markdown 主库 ── SAN/NAS ── 备库(故障时挂载存储) ``` - **推荐方案**:DRBD + Pacemaker - **优点**:避免数据复制延迟 - **缺点**:存储单点风险 ### 二、负载均衡实现方式 #### 1. 连接池方案对比 | 工具 | 工作模式 | 特点 | |-------------|---------------|-------------------------------| | **PgBouncer** | 事务/会话级 | 轻量级,支持超百万连接 | | **Pgpool-II** | 中间件代理 | 集成负载均衡+故障转移 | #### 2. 读写分离配置 ```sql /* Pgpool-II 示例配置 */ backend_hostname0 = 'primary' # 主库 backend_hostname1 = 'replica1' # 备库1 backend_hostname2 = 'replica2' # 备库2 ``` #### 3. 智能路由策略 - **权重分配**:按节点性能设置查询权重 - **基于SQL类型**: ```python # HAProxy ACL规则示例 acl is_write hdr_reg(X-SQL-Command) ^(INSERT|UPDATE|DELETE) use_backend pg_primary if is_write ``` ### 三、云原生高可用方案 ```yaml # Kubernetes示例(使用Crunchy PostgreSQL Operator) apiVersion: postgres-operator.crunchydata.com/v1beta1 kind: PostgresCluster metadata: name: ha-cluster spec: instances: - name: instance1 replicas: 3 dataVolumeClaimSpec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 10Gi backups: pgbackrest: repos: - name: repo1 volume: volumeClaimSpec: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 20Gi ``` ### 四、典型架构组合 #### 1. 金融级高可用 ```markdown 主库 ── 同步备库 ── 异步备库 ↑ ↖ Patroni WAL归档 ↓ HAProxy集群 ``` #### 2. 互联网常用方案 ```markdown 主库 → Pgpool-II → 多个异步备库 ↑ Keepalived(VIP漂移) ``` #### 3. 混合云部署 ```markdown 本地主库 ── 逻辑复制 ─→ 云上备库 ↖ 双向复制 → 灾备中心 ``` ### 五、监控指标关键点 ```bash # 查看复制状态 SELECT client_addr, state, sync_state, pg_wal_lsn_diff(sent_lsn, write_lsn) AS write_l
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值