2. 首页 > 国产数据库教程 > Kingbase教程 > 正文

kingbase教程FG091-金仓数据库灾备演练与实战

教程整理：风哥教程  |  更新时间：2026-03-02  |  教程分类：Kingbase教程  |  文档学习：27

内容简介

本文档介绍金仓数据库的灾备演练与实战，包括灾备演练的目的、流程、实施步骤以及实际案例。风哥教程参考金仓官方文档《金仓数据库高可用解决方案》和《金仓数据库备份恢复指南》等相关文档。

灾备演练是确保数据库系统在灾难发生时能够快速恢复的重要手段，本文档将详细介绍金仓数据库的灾备演练方法，并通过实际案例展示其应用效果。

目录大纲

Part01-基础概念与理论知识

Part02-生产环境规划与建议

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

Part04-生产案例与实战讲解

Part05-风哥经验总结与分享

Part01-基础概念与理论知识

1.1 灾备演练的目的和意义

灾备演练的目的和意义包括：

  • 验证灾备方案的有效性：确保灾备方案能够在灾难发生时正常工作
  • 提高应对灾难的能力：通过演练，提高运维人员应对灾难的能力
  • 发现并解决潜在问题：在演练过程中发现并解决潜在的问题
  • 确保业务连续性：确保在灾难发生时业务能够快速恢复
  • 满足合规要求：满足相关法律法规和行业标准的要求

风哥提示：灾备演练是确保数据库系统高可用性的重要手段，应该定期进行。

1.2 金仓数据库灾备架构

金仓数据库支持以下灾备架构：

  • 主备复制：一主一备或一主多备架构
  • 集群架构：多节点集群，提供高可用性和负载均衡，学习交流加群风哥微信: itpux-com
  • 异地灾备：跨机房或跨地域的灾备架构
  • 多活架构：多个数据中心同时提供服务

Part02-生产环境规划与建议

2.1 灾备环境规划

灾备环境规划建议如下：

  • 硬件配置：灾备服务器的硬件配置应与主服务器相当
  • 软件配置：灾备服务器的软件配置应与主服务器一致
  • 网络配置：确保主备服务器之间网络通畅
  • 存储配置：灾备服务器的存储容量应大于等于主服务器

2.2 网络环境规划

网络环境规划建议如下：

  • 网络隔离：灾备环境与生产环境网络隔离
  • 带宽要求：主备服务器之间的网络带宽应满足数据同步需求，学习交流加群风哥QQ113257174
  • 延迟要求：主备服务器之间的网络延迟应尽可能低
  • 冗余网络：配置冗余网络，确保网络可靠性

2.3 存储环境规划

存储环境规划建议如下：

  • 存储类型：使用与主服务器相同类型的存储
  • 存储容量：灾备服务器的存储容量应大于等于主服务器
  • 存储性能：灾备服务器的存储性能应与主服务器相当
  • 存储冗余：配置存储冗余，确保存储可靠性

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

3.1 灾备配置

配置主备复制的步骤如下：


# 主库配置
# 编辑kingbase.conf
vi /kingbase/fgdata/kingbase.conf


# 主库配置
wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
synchronous_commit = on
listen_addresses = ‘*’


# 编辑pg_hba.conf
vi /kingbase/fgdata/pg_hba.conf


# 主库pg_hba.conf配置
host replication kingbase 192.168.1.2/32 md5


# 重启主库
systemctl restart kingbase
# 在主库创建复制用户
ksql -U system -d fgedudb -c “CREATE USER kingbase REPLICATION LOGIN ENCRYPTED PASSWORD ‘Kingbase123!'”;


CREATE ROLE


# 备库配置
# 停止备库
systemctl stop kingbase
# 清空数据目录
rm -rf /kingbase/fgdata/*
# 从主库同步数据
pg_basebackup -h 192.168.1.1 -p 54321 -U kingbase -D /kingbase/fgdata -F p -X stream -P


25362/25362 kB (100%), 1/1 tablespace


# 创建recovery.conf文件
vi /kingbase/fgdata/recovery.conf


# 备库recovery.conf配置
standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.1 port=54321 user=kingbase password=Kingbase123! application_name=standby1’
recovery_target_timeline = ‘latest’


# 启动备库
systemctl start kingbase
# 检查复制状态
ksql -U system -d fgedudb -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 | kingbase | standby1 | 192.168.1.2 | | 54321 | 2023-07-01 10:00:00.000000+08 | | streaming | 0/12345678 | 0/12345678 | 0/12345678 | 0/12345678 | | | | 1 | sync
(1 row)

3.2 灾备演练流程

灾备演练的基本流程如下：

  1. 演练准备：制定演练计划，准备演练环境
  2. 演练执行：执行故障切换和故障恢复演练，更多视频教程www.fgedu.net.cn
  3. 演练评估：评估演练结果，发现并解决问题
  4. 演练总结：总结演练经验，完善演练方案

3.3 故障切换演练

故障切换演练的步骤如下：


# 1. 模拟主库故障
# 停止主库
systemctl stop kingbase


# 2. 检查备库状态
ksql -U system -d fgedudb -c “SELECT pg_is_in_recovery();”


pg_is_in_recovery
——————-
t
(1 row)


# 3. 提升备库为主库
# 停止备库
systemctl stop kingbase
# 删除recovery.conf文件
rm /kingbase/fgdata/recovery.conf
# 启动备库
systemctl start kingbase


# 4. 检查备库状态
ksql -U system -d fgedudb -c “SELECT pg_is_in_recovery();”


pg_is_in_recovery
——————-
f
(1 row)

3.4 故障恢复演练

故障恢复演练的步骤如下：


# 1. 修复主库故障
# 启动主库
systemctl start kingbase


# 2. 将原主库设置为备库
# 停止原主库
systemctl stop kingbase
# 清空数据目录
rm -rf /kingbase/fgdata/*
# 从新主库同步数据
pg_basebackup -h 192.168.1.2 -p 54321 -U kingbase -D /kingbase/fgdata -F p -X stream -P


25362/25362 kB (100%), 1/1 tablespace


# 创建recovery.conf文件
vi /kingbase/fgdata/recovery.conf


# 原主库recovery.conf配置
standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.2 port=54321 user=kingbase password=Kingbase123! application_name=standby2’
recovery_target_timeline = ‘latest’


# 启动原主库
systemctl start kingbase
# 检查复制状态
ksql -U system -d fgedudb -h 192.168.1.2 -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
——-+———-+———-+——————+—————+—————–+————-+——————————-+————–+———–+————+————+————+————+———–+———–+————+—————+————
12346 | 16384 | kingbase | standby2 | 192.168.1.1 | | 54321 | 2023-07-01 10:30:00.000000+08 | | streaming | 0/12345678 | 0/12345678 | 0/12345678 | 0/12345678 | | | | 1 | sync
(1 row)

Part04-生产案例与实战讲解

4.1 案例背景

某金融机构需要构建一个高可用的数据库系统，要求在主库发生故障时能够快速切换到备库，确保业务连续性。经过选型，最终选择了金仓数据库作为核心数据库系统，并配置了主备复制架构。

4.2 实施过程

实施过程分为以下几个阶段：

4.2.1 需求分析

  • 可用性要求：99.99%
  • 故障恢复时间：<30秒
  • 数据一致性：强一致性
  • 演练频率：每季度一次，更多学习教程公众号风哥教程itpux_com

4.2.2 架构设计

  • 部署架构：一主一备
  • 网络：万兆网络
  • 存储：SSD RAID 10
  • 监控：Zabbix+Grafana

4.2.3 实施步骤


# 1. 环境准备
# 检查服务器状态
ping -c 3 192.168.1.1
ping -c 3 192.168.1.2


PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.123 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.112 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.105 ms
— 192.168.1.1 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.105/0.113/0.123/0.008 ms
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.135 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.121 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.118 ms
— 192.168.1.2 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.118/0.125/0.135/0.007 ms


# 2. 配置主备复制
# 主库配置
vi /kingbase/fgdata/kingbase.conf


wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
synchronous_commit = on
listen_addresses = ‘*’


# 备库配置
pg_basebackup -h 192.168.1.1 -p 54321 -U kingbase -D /kingbase/fgdata -F p -X stream -P


25362/25362 kB (100%), 1/1 tablespace


# 3. 执行故障切换演练
# 模拟主库故障
ssystemctl stop kingbase
# 提升备库为主库
rm /kingbase/fgdata/recovery.conf
systemctl restart kingbase


# 4. 执行故障恢复演练
# 修复主库故障
systemctl start kingbase
# 将原主库设置为备库
pg_basebackup -h 192.168.1.2 -p 54321 -U kingbase -D /kingbase/fgdata -F p -X stream -P
vi /kingbase/fgdata/recovery.conf


standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.2 port=54321 user=kingbase password=Kingbase123! application_name=standby2’
recovery_target_timeline = ‘latest’

4.3 运行效果

系统上线后，运行效果如下：

  • 可用性指标：
    • 系统可用性：99.99%
    • 故障切换时间：<30秒
  • 演练效果：
    • 演练成功率：100%
    • 演练时间：<1小时
  • 业务连续性：
    • 业务中断时间：<30秒，from DB视频:www.itpux.com
    • 数据一致性：强一致

# 监控系统状态
ksql -U system -d fgedudb -c “SELECT pg_is_in_recovery(), pg_postmaster_start_time();”


pg_is_in_recovery | pg_postmaster_start_time
——————-+——————————————
f | 2023-07-01 00:00:00.000000+08
(1 row)


# 查看复制状态
ksql -U system -d fgedudb -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 | kingbase | standby1 | 192.168.1.2 | | 54321 | 2023-07-01 10:00:00.000000+08 | | streaming | 0/12345678 | 0/12345678 | 0/12345678 | 0/12345678 | | | | 1 | sync
(1 row)

Part05-风哥经验总结与分享

5.1 实施建议

  • 定期演练：每季度至少进行一次灾备演练
  • 演练计划：制定详细的演练计划，包括演练步骤、时间安排和人员分工
  • 演练环境：确保演练环境与生产环境一致
  • 演练评估：演练后进行评估，发现并解决问题
  • 文档记录：详细记录演练过程和结果，形成演练报告

5.2 演练技巧

  • 模拟真实故障：模拟真实的故障场景，如主库宕机、网络中断等
  • 测试不同故障场景：测试不同类型的故障场景，确保系统能够应对各种情况
  • 监控演练过程：在演练过程中监控系统状态，及时发现问题
  • 记录演练时间：记录故障切换和恢复的时间，评估系统性能
  • 总结经验教训：演练后总结经验教训，完善灾备方案

# 查看日志
tail -n 100 /kingbase/fgdata/log/kingbase.log


2023-07-01 10:00:00.000 CST [12345] LOG: starting KingbaseES V8R6C3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 7.3.0, 64-bit
2023-07-01 10:00:00.000 CST [12345] LOG: listening on IPv4 address “0.0.0.0”, port 54321
2023-07-01 10:00:00.000 CST [12345] LOG: listening on IPv6 address “::”, port 54321
2023-07-01 10:00:00.000 CST [12345] LOG: listening on Unix socket “/tmp/.s.KINGBASE.54321”
2023-07-01 10:00:00.000 CST [12346] LOG: database system was shut down at 2023-07-01 09:59:59 CST
2023-07-01 10:00:00.000 CST [12346] LOG: database system is ready to accept connections

5.3 故障处理

  • 故障监测：使用监控系统及时发现故障
  • 故障定位：根据日志和监控信息定位故障原因
  • 故障恢复：按照演练流程进行故障恢复
  • 故障分析：分析故障原因，制定预防措施
  • 故障记录：详细记录故障发生的时间、原因和解决方法

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

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息