ClusterControl简介
ClusterControl是一个用于部署数据库集群的无代理管理和自动化软件，它能够直接从用户界面部署，监控，管理和扩展数据库服务器/集群。ClusterControl能够处理维护数据库服务器或集群所需的大多数管理任务。
ClusterControl由许多组件组成：
| Component | Package naming | Role |
|---|---|---|
| ClusterControl Controller (cmon) | clustercontrol-controller | The 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-cmonapi | Interprets request and response data between ClusterControl UI and CMON database. |
| ClusterControl UI | clustercontrol | A 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 SSH | clustercontrol-ssh | Optional package introduced in ClusterControl 1.4.2 for ClusterControl’s web SSH console. Only works with Apache 2.4+. |
| ClusterControl Notifications | clustercontrol-notifications | Optional package introduced in ClusterControl 1.4.2 providing a service and user interface for notification services and integration with third party tools. |
| ClusterControl Cloud | clustercontrol-cloud | Optional package introduced in ClusterControl 1.5.0 providing a service and user interface for integration with cloud providers. |
| ClusterControl Cloud File Manager | clustercontrol-clud | Optional package introduced in ClusterControl 1.5.0 providing a command-line interface to interact with storage objects on cloud. |
| ClusterControl CLI | s9s-tools | Open-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地址 | 角色 | 监听端口 | 版本 |
|---|---|---|---|---|
| clustercontrol | 192.168.92.10 | clustercontrol | 80 | v 1.7.1 |
| pgmaster | 192.168.92.11 | master/haproxy/keepalived | 5432 | PostgreSQL 11.2 |
| pgslave01 | 192.168.92.12 | slave/haproxy/keepalived | 5432 | PostgreSQL 11.2 |
| pgslave02 | 192.168.92.13 | slave/haproxy/keepalived | 5432 | PostgreSQL 11.2 |
| vip | 192.168.92.15 | vip for cluster | rw: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@