kingbase教程FG180-金仓数据库灾备切换自动化实战

内容简介：本文档详细介绍金仓数据库灾备切换自动化实现方法，包括灾备架构、切换流程、自动化脚本等。风哥教程参考kingbase官方文档kingbase8高可用集群管理手册、kingbase8灾备方案指南等。

Part01-基础概念与理论知识

1.1 灾备概述

灾备是指为应对自然灾害、人为失误、硬件故障等导致的系统故障，而建立的一套备用系统和恢复机制。灾备的目标是确保业务连续性，减少故障对业务的影响。，风哥提示：

灾备等级：

第0级：无灾备，没有任何备用系统
第1级：本地备份，定期备份数据到本地存储
第2级：本地热备，本地部署备用系统，数据实时同步
第3级：异地冷备，异地部署备用系统，定期同步数据
第4级：异地热备，异地部署备用系统，数据实时同步
第5级：多活架构，多个数据中心同时运行，负载均衡

1.2 灾备架构

常见的灾备架构：

主备架构：一个主节点，一个或多个备节点，主节点故障时切换到备节点
双活架构：两个节点同时运行，互为备份，负载均衡，学习交流加群风哥微信: itpux-com
多活架构：多个节点同时运行，分布在不同地理位置，负载均衡
级联架构：主节点→中间节点→备节点，数据逐级同步

1.3 灾备切换流程

灾备切换流程：

故障检测：检测主节点是否发生故障
故障确认：确认故障的真实性和严重程度
切换决策：决定是否进行灾备切换
执行切换：将业务流量切换到备节点
验证切换：验证备节点是否正常运行
业务恢复：恢复业务操作

Part02-生产环境规划与建议

2.1 灾备架构设计

灾备架构设计考虑因素：，学习交流加群风哥QQ113257174

业务需求：根据业务的重要性和对可用性的要求，选择合适的灾备等级
数据同步方式：根据数据量和网络带宽，选择合适的数据同步方式（同步/异步）
地理位置：根据灾难发生的可能性，选择合适的灾备站点位置
成本预算：根据预算，选择合适的灾备方案

2.2 切换策略制定

切换策略制定：

自动切换：当主节点发生故障时，自动切换到备节点
手动切换：由运维人员手动执行切换操作
半自动切换：系统检测到故障后，由运维人员确认后执行切换

2.3 自动化工具选择

自动化工具选择：

Shell脚本：简单易用，适合简单的切换场景，更多视频教程www.fgedu.net.cn
Python脚本：功能强大，适合复杂的切换场景
Ansible：自动化运维工具，适合多节点管理
监控工具：如Prometheus、Zabbix等，用于故障检测

Part03-生产环境项目实施方案

3.1 灾备配置

灾备配置步骤：

部署备节点：在异地部署备节点
配置数据同步：设置主备节点之间的数据同步
配置监控：设置主备节点的监控
配置网络：确保主备节点之间的网络连接

3.2 自动化脚本开发

自动化脚本开发步骤：

故障检测：开发故障检测脚本，检测主节点是否发生故障，更多学习教程公众号风哥教程itpux_com
切换执行：开发切换执行脚本，执行切换操作
验证脚本：开发验证脚本，验证切换是否成功
回滚脚本：开发回滚脚本，在切换失败时执行回滚

3.3 切换测试与验证

切换测试与验证：

模拟故障：模拟主节点故障
执行切换：执行切换操作
验证切换：验证备节点是否正常运行
回切测试：测试从备节点切换回主节点
性能测试：测试切换后的性能

Part04-生产案例与实战讲解

4.1 灾备配置实战

灾备配置实战：

# 环境信息
# 主节点：192.168.1.101
# 备节点：192.168.1.102
# 在主节点上配置
# 修改postgresql.conf
$ vi /kingbase/data/postgresql.conf
# 添加以下配置
listen_addresses = ‘*’
port = 54321
max_connections = 1000
shared_buffers = 4GB
wal_level = logical
max_wal_senders = 10
max_replication_slots = 10
hot_standby = on
# 修改pg_hba.conf
$ vi /kingbase/data/pg_hba.conf
# 添加以下配置
host replication repmgr 192.168.1.102/32 md5
# 重启主节点
$ systemctl restart kingbase
# 在备节点上配置
# 停止数据库
$ systemctl stop kingbase
# 清理数据目录
$ rm -rf /kingbase/data/*
# 从主节点复制数据
$ pg_basebackup -h 192.168.1.101 -p 54321 -U repmgr -D /kingbase/data -Fp -Xs -P
# 创建recovery.conf
$ vi /kingbase/data/recovery.conf
# 添加以下配置
standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.101 port=54321 user=repmgr password=repmgr123 application_name=standby1’
trigger_file = ‘/kingbase/data/failover.trigger’
# 启动备节点
$ systemctl start kingbase
# 验证备节点状态
$ psql -h fgedu.localhost -p 54321 -U repmgr -d repmgr -c “SELECT * FROM pg_stat_replication;”
# 输出日志
pid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state
——-+———-+———+——————+————–+—————–+————-+——————————-+————–+———–+———–+———–+———–+————+———–+———–+————+—————+————
12345 | 16384 | repmgr | standby1 | 192.168.1.102 | | 54321 | 2026-04-09 10:00:00.000000+08 | | streaming | 0/1234567 | 0/1234567 | 0/1234567 | 0/1234567 | | | | 0 | async

4.2 自动化脚本实战

自动化脚本实战：，from DB视频:www.itpux.com

#!/bin/bash
# dr_switch.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`
# 配置信息
MASTER_HOST=”192.168.1.101″
STANDBY_HOST=”192.168.1.102″
DB_PORT=”54321″
DB_USER=”repmgr”
DB_NAME=”repmgr”
LOG_FILE=”/kingbase/log/dr_switch.log”
# 记录日志
log() {
echo “$(date ‘+%Y-%m-%d %H:%M:%S’) – $1” >> $LOG_FILE
}
# 检查主节点状态
check_master_status() {
log “检查主节点状态…”
ssh $MASTER_HOST “psql -h fgedu.localhost -p $DB_PORT -U $DB_USER -d $DB_NAME -c ‘SELECT 1;'” > /dev/null 2>&1
if [ $? -eq 0 ]; then
log “主节点状态正常”
return 0
else
log “主节点状态异常”
return 1
fi
}
# 检查备节点状态
check_standby_status() {
log “检查备节点状态…”
ssh $STANDBY_HOST “psql -h fgedu.localhost -p $DB_PORT -U $DB_USER -d $DB_NAME -c ‘SELECT 1;'” > /dev/null 2>&1
if [ $? -eq 0 ]; then
log “备节点状态正常”
return 0
else
log “备节点状态异常”
return 1
fi
}
# 执行切换
perform_switch() {
log “开始执行灾备切换…”
# 检查备节点状态
check_standby_status
if [ $? -ne 0 ]; then
log “备节点状态异常，无法执行切换”
return 1
fi
# 在备节点上执行切换
ssh $STANDBY_HOST “touch /kingbase/data/failover.trigger”
if [ $? -eq 0 ]; then
log “触发备节点切换”
else
log “触发备节点切换失败”
return 1
fi
# 等待备节点提升为主节点
sleep 10
# 验证切换是否成功
ssh $STANDBY_HOST “psql -h fgedu.localhost -p $DB_PORT -U $DB_USER -d $DB_NAME -c ‘SELECT pg_is_in_recovery();'” | grep -q “f”
if [ $? -eq 0 ]; then
log “备节点已成功提升为主节点”
return 0
else
log “备节点提升为主节点失败”
return 1
fi
}
# 验证业务
verify_business() {
log “验证业务…”
ssh $STANDBY_HOST “psql -h fgedu.localhost -p $DB_PORT -U fgedu -d fgedudb -c ‘SELECT * FROM fgedu_employee;'” > /dev/null 2>&1
if [ $? -eq 0 ]; then
log “业务验证成功”
return 0
else
log “业务验证失败”
return 1
fi
}
# 主函数
main() {
log “开始灾备切换流程”
# 检查主节点状态
check_master_status
if [ $? -eq 0 ]; then
log “主节点状态正常，无需切换”
exit 0
fi
# 执行切换
perform_switch
if [ $? -ne 0 ]; then
log “灾备切换失败”
exit 1
fi
# 验证业务
verify_business
if [ $? -ne 0 ]; then
log “业务验证失败”
exit 1
fi
log “灾备切换成功”
}
# 执行主函数
main

4.3 灾备切换实战

灾备切换实战：

# 模拟主节点故障
$ ssh 192.168.1.101 “systemctl stop kingbase”
# 执行灾备切换脚本
$ ./dr_switch.sh
# 输出日志
2026-04-09 10:00:00 – 开始灾备切换流程
2026-04-09 10:00:00 – 检查主节点状态…
2026-04-09 10:00:01 – 主节点状态异常
2026-04-09 10:00:01 – 检查备节点状态…
2026-04-09 10:00:02 – 备节点状态正常
2026-04-09 10:00:02 – 开始执行灾备切换…
2026-04-09 10:00:02 – 触发备节点切换
2026-04-09 10:00:12 – 备节点已成功提升为主节点
2026-04-09 10:00:12 – 验证业务…
2026-04-09 10:00:13 – 业务验证成功
2026-04-09 10:00:13 – 灾备切换成功
# 验证新主节点状态
$ ssh 192.168.1.102 “psql -h fgedu.localhost -p 54321 -U repmgr -d repmgr -c ‘SELECT pg_is_in_recovery();'”
# 输出日志
pg_is_in_recovery
——————-
f
# 验证业务数据
$ ssh 192.168.1.102 “psql -h fgedu.localhost -p 54321 -U fgedu -d fgedudb -c ‘SELECT * FROM fgedu_employee;'”
# 输出日志
id | name | department
—-+——+————
1 | 张三 | 技术部
2 | 李四 | 市场部
3 | 王五 | 财务部
4 | 赵六 | 技术部
5 | 钱七 | 技术部

4.4 切换后验证

切换后验证：

# 验证数据库状态
$ ssh 192.168.1.102 “systemctl status kingbase”
# 输出日志
● kingbase.service – KingbaseES Database Server
Loaded: loaded (/etc/systemd/system/kingbase.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2026-04-09 10:00:10 CST; 5min ago
Main PID: 5678 (kbserver)
CGroup: /system.slice/kingbase.service
├─5678 /kingbase/app/Server/bin/kbserver -D /kingbase/data
├─5679 postgres: logger process
├─5680 postgres: checkpointer process
├─5681 postgres: writer process
├─5682 postgres: wal writer process
├─5683 postgres: autovacuum launcher process
└─5684 postgres: stats collector process
# 验证连接
$ psql -h 192.168.1.102 -p 54321 -U fgedu -d fgedudb -c “SELECT 1;”
# 输出日志
?column?
———-
1
# 验证数据一致性
$ ssh 192.168.1.102 “psql -h fgedu.localhost -p 54321 -U fgedu -d fgedudb -c ‘SELECT COUNT(*) FROM fgedu_employee;'”
# 输出日志
count
——-
5
# 验证业务功能
$ ssh 192.168.1.102 “psql -h fgedu.localhost -p 54321 -U fgedu -d fgedudb -c ‘INSERT INTO fgedu_employee (name, department) VALUES (“孙八”, “技术部”);'”
# 输出日志
INSERT 0 1
$ ssh 192.168.1.102 “psql -h fgedu.localhost -p 54321 -U fgedu -d fgedudb -c ‘SELECT * FROM fgedu_employee WHERE name = “孙八”;'”
# 输出日志
id | name | department
—-+——+————
6 | 孙八 | 技术部

Part05-风哥经验总结与分享

5.1 灾备切换常见问题与解决方案

灾备切换常见问题与解决方案：

切换失败：检查备节点状态，确保备节点正常运行
数据不一致：确保主备节点之间的数据同步正常
网络问题：确保主备节点之间的网络连接稳定
切换时间过长：优化切换流程，减少切换时间
业务验证失败：确保备节点的业务功能正常

5.2 灾备切换最佳实践

灾备切换最佳实践：

定期测试：定期进行灾备切换测试，确保切换流程正常
监控告警：建立完善的监控告警机制，及时发现故障
自动化：使用自动化脚本执行切换操作，减少人为错误
文档化：详细记录灾备切换流程，确保操作规范
培训：对运维人员进行灾备切换培训，提高操作能力

5.3 灾备切换自动化脚本分享

以下是一个完整的灾备切换自动化脚本示例：

#!/bin/bash
# dr_automation.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`
# 配置信息
MASTER_HOST=”192.168.1.101″
STANDBY_HOST=”192.168.1.102″
DB_PORT=”54321″
DB_USER=”repmgr”
DB_NAME=”repmgr”
APP_USER=”fgedu”
APP_DB=”fgedudb”
LOG_FILE=”/kingbase/log/dr_automation.log”
ALERT_EMAIL=”admin@fgedu.net.cn”
# 记录日志
log() {
echo “$(date ‘+%Y-%m-%d %H:%M:%S’) – $1” >> $LOG_FILE
}
# 发送告警
send_alert() {
local subject=”$1″
local message=”$2″
echo “$message” | mail -s “[Kingbase DR] $subject” $ALERT_EMAIL
log “发送告警: $subject”
}
# 检查节点状态
check_node_status() {
local host=$1
log “检查节点 $host 状态…”
ssh $host “psql -h fgedu.localhost -p $DB_PORT -U $DB_USER -d $DB_NAME -c ‘SELECT 1;'” > /dev/null 2>&1
if [ $? -eq 0 ]; then
log “节点 $host 状态正常”
return 0
else
log “节点 $host 状态异常”
return 1
fi
}
# 检查复制状态
check_replication_status() {
log “检查复制状态…”
local status=$(ssh $MASTER_HOST “psql -h fgedu.localhost -p $DB_PORT -U $DB_USER -d $DB_NAME -c ‘SELECT state FROM pg_stat_replication WHERE application_name = “standby1″;’ -t”)
if [ “$status” == “streaming” ]; then
log “复制状态正常”
return 0
else
log “复制状态异常”
return 1
fi
}
# 执行切换
perform_switch() {
log “开始执行灾备切换…”
# 检查备节点状态
check_node_status $STANDBY_HOST
if [ $? -ne 0 ]; then
log “备节点状态异常，无法执行切换”
send_alert “灾备切换失败” “备节点状态异常，无法执行切换”
return 1
fi
# 在备节点上执行切换
ssh $STANDBY_HOST “touch /kingbase/data/failover.trigger”
if [ $? -eq 0 ]; then
log “触发备节点切换”
else
log “触发备节点切换失败”
send_alert “灾备切换失败” “触发备节点切换失败”
return 1
fi
# 等待备节点提升为主节点
sleep 10
# 验证切换是否成功
local is_recovery=$(ssh $STANDBY_HOST “psql -h fgedu.localhost -p $DB_PORT -U $DB_USER -d $DB_NAME -c ‘SELECT pg_is_in_recovery();’ -t”)
if [ “$is_recovery” == “f” ]; then
log “备节点已成功提升为主节点”
return 0
else
log “备节点提升为主节点失败”
send_alert “灾备切换失败” “备节点提升为主节点失败”
return 1
fi
}
# 验证业务
verify_business() {
log “验证业务…”
ssh $STANDBY_HOST “psql -h fgedu.localhost -p $DB_PORT -U $APP_USER -d $APP_DB -c ‘SELECT * FROM fgedu_employee;'” > /dev/null 2>&1
if [ $? -eq 0 ]; then
log “业务验证成功”
return 0
else
log “业务验证失败”
send_alert “灾备切换失败” “业务验证失败”
return 1
fi
}
# 主函数
main() {
log “开始灾备切换自动化流程”
# 检查主节点状态
check_node_status $MASTER_HOST
if [ $? -eq 0 ]; then
log “主节点状态正常，无需切换”
exit 0
fi
# 发送告警
send_alert “主节点故障” “主节点 $MASTER_HOST 发生故障，准备执行灾备切换”
# 执行切换
perform_switch
if [ $? -ne 0 ]; then
log “灾备切换失败”
exit 1
fi
# 验证业务
verify_business
if [ $? -ne 0 ]; then
log “业务验证失败”
exit 1
fi
# 发送成功告警
send_alert “灾备切换成功” “灾备切换已成功完成，业务已恢复正常”
log “灾备切换成功”
}
# 执行主函数
main

风哥提示：灾备切换自动化是确保业务连续性的重要手段，通过合理的架构设计和自动化脚本，可以实现快速、可靠的灾备切换。

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html