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

opengauss教程FG148-数据库容灾最佳实践

教程整理：风哥教程  |  更新时间：2026-04-14  |  教程分类：openGauss教程  |  文档学习：0

目录大纲

Part01-基础概念与理论知识

1.1 容灾概述

容灾（Disaster Recovery，DR）是指在自然或人为灾难发生后，能够快速恢复系统运行和数据访问的能力。容灾系统的主要目标是：

  • 数据安全：确保数据不丢失
  • 业务连续性：在灾难发生后能够快速恢复业务
  • 最小化损失：减少灾难对业务的影响

容灾等级通常分为：

  • 本地容灾：同一机房内的容灾方案
  • 异地容灾：不同机房之间的容灾方案
  • 同城容灾：同一城市不同机房的容灾方案
  • 异地多活：不同城市之间的容灾方案，支持多活部署

风哥提示：容灾方案的选择需要考虑业务重要性、数据量、恢复时间目标（RTO）和恢复点目标（RPO）等因素。

1.2 openGauss容灾架构

openGauss支持多种容灾架构，主要包括：

  • 主备复制：基于流复制的主备架构
  • 级联复制：主节点复制到中间节点，中间节点再复制到其他节点
  • 双活架构：两个数据中心同时提供服务，数据双向同步
  • 多活架构：多个数据中心同时提供服务，数据多向同步

Part02-生产环境规划与建议

2.1 容灾架构设计

在生产环境中，容灾架构设计需要考虑以下因素：

  • 地理距离：根据灾难类型选择合适的地理距离
  • 网络带宽：确保灾备数据传输所需的网络带宽
  • 存储配置：灾备站点的存储配置应与主站点相当
  • 硬件配置：灾备站点的硬件配置应与主站点相当
  • 网络延迟：考虑数据同步的网络延迟

2.2 容灾策略制定

制定有效的容灾策略：

  • RTO和RPO：根据业务需求确定恢复时间目标和恢复点目标
  • 数据同步方式：选择同步复制或异步复制
  • 切换策略：自动切换或手动切换
  • 演练计划：定期进行灾备演练
  • 恢复流程：制定详细的灾难恢复流程

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

风哥提示：

3.1 灾备环境搭建

搭建灾备环境的步骤：

  • 环境准备：准备与主站点相同的硬件和软件环境
  • 网络配置：配置主备站点之间的网络连接
  • 数据库安装：在灾备站点安装与主站点相同版本的openGauss
  • 基础备份：从主站点创建基础备份并恢复到灾备站点
  • 复制配置：配置主备复制

3.2 数据同步配置

配置数据同步：

  • 流复制：使用PostgreSQL的流复制技术
  • 逻辑复制：使用逻辑复制技术，支持跨版本复制
  • 同步方式：根据RPO要求选择同步或异步复制
  • 带宽管理：合理管理网络带宽，确保数据同步不影响正常业务

3.3 灾备演练

定期进行灾备演练：

  • 演练计划：制定详细的演练计划
  • 演练内容：包括故障模拟、切换测试、恢复测试等
  • 演练频率：根据业务重要性确定演练频率
  • 演练评估：评估演练结果，优化容灾方案

学习交流加群风哥微信: itpux-com

Part04-生产案例与实战讲解

4.1 跨机房容灾实战

案例：搭建跨机房容灾架构

# 场景：搭建跨机房容灾架构
# 操作：配置主备复制

# 主站点：192.168.1.10（A机房）
# 灾备站点：192.168.2.10（B机房）

# 1. 配置主站点
# 修改postgresql.conf
vim /opengauss/fgdata/postgresql.conf
# 添加以下配置
wal_level = logical
max_wal_senders = 10
hot_standby = on
max_replication_slots = 10

# 修改pg_hba.conf
vim /opengauss/fgdata/pg_hba.conf
# 添加以下配置
host replication fgedu 192.168.2.10/32 md5

# 重启主站点
gs_ctl restart -D /opengauss/fgdata

# 2. 配置灾备站点
# 在灾备站点上执行
pg_basebackup -h 192.168.1.10 -p 5432 -U fgedu -D /opengauss/fgdata -Fp -Xs -P

# 创建recovery.conf文件
vim /opengauss/fgdata/recovery.conf
# 添加以下配置
standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.10 port=5432 user=fgedu password=Password@123’
recovery_target_timeline = ‘latest’学习交流加群风哥QQ113257174

# 启动灾备站点
gs_ctl start -D /opengauss/fgdata

# 3. 验证复制状态
# 在主站点上执行
psql -h 192.168.1.10 -p 5432 -U fgedu -d fgedudb -c “SELECT * FROM pg_stat_replication;
”

# 在灾备站点上执行
psql -h 192.168.2.10 -p 5432 -U fgedu -d fgedudb -c “SELECT pg_is_in_recovery();
”

# 主站点重启输出
waiting for server to shut down…. done
server stopped
waiting for server to start….2024-01-01 10:00:00.000 CST [12345] LOG: starting openGauss 3.0.0 (build 1234567) distributed by openGauss community
2024-01-01 10:00:00.001 CST [12345] LOG: listening on IPv4 address “0.0.0.0”, port 5432
2024-01-01 10:00:00.002 CST [12345] LOG: listening on IPv6 address “::”, port 5432
2024-01-01 10:00:00.003 CST [12345] LOG: listening on Unix socket “/tmp/.s.PGSQL.5432”
2024-01-01 10:00:00.100 CST [12346] LOG: database system was shut down at 2024-01-01 09:59:59 CST
2024-01-01 10:00:00.105 CST [12345] LOG: database system is ready to accept connections
done
server started

# 灾备站点基础备份输出
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/1234567 on timeline 1
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot “pg_basebackup_12345”
pg_basebackup: write-ahead log end point: 0/1234567
pg_basebackup: waiting for background process to finish streaming …
pg_basebackup: base backup completed

# 灾备站点启动输出
waiting for server to start….2024-01-01 10:05:00.000 CST [12345] LOG: starting openGauss 3.0.0 (build 1234567) distributed by openGauss community
2024-01-01 10:05:00.001 CST [12345] LOG: listening on IPv4 address “0.0.0.0”, port 5432
2024-01-01 10:05:00.002 CST [12345] LOG: listening on IPv6 address “::”, port 5432
2024-01-01 10:05:00.003 CST [12345] LOG: listening on Unix socket “/tmp/.s.PGSQL.5432”
2024-01-01 10:05:00.004 CST [12345] LOG: entering standby mode更多视频教程www.fgedu.net.cn
2024-01-01 10:05:00.005 CST [12345] LOG: redo starts at 0/1234567
2024-01-01 10:05:00.006 CST [12345] LOG: consistent recovery state reached at 0/1234567
2024-01-01 10:05:00.007 CST [12346] LOG: database system is ready to accept read only connections
done
server started

# 验证复制状态（主站点）
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
—–+———-+———+——————+————-+—————–+————-+—————+————–+——-+———-+———–+———–+————+———–+———–+————+—————+————
1234 | 16384 | fgedu | walreceiver | 192.168.2.10 | | 12345 | 2024-01-01 10:05:00 | | streaming | 0/1234567 | 0/1234567 | 0/1234567 | 0/1234567 | | | | 0 | async

# 验证灾备站点状态
pg_is_in_recovery
——————-
t

4.2 灾难恢复实战

案例：主站点故障后的灾难恢复

# 场景：主站点发生灾难，需要从灾备站点恢复业务
# 操作：执行灾难恢复步骤

# 1. 确认主站点故障
ping 192.168.1.10

# 2. 在灾备站点上执行故障切换
# 停止灾备站点
gs_ctl stop -D /opengauss/fgdata

# 移除recovery.conf文件
rm /opengauss/fgdata/recovery.conf

# 创建recovery.signal文件
touch /opengauss/fgdata/recovery.signal

# 启动灾备站点为新的主站点
gs_ctl start -D /opengauss/fgdata

# 3. 验证新主站点状态更多学习教程公众号风哥教程itpux_com
psql -h 192.168.2.10 -p 5432 -U fgedu -d fgedudb -c “SELECT pg_is_in_recovery();
”

# 4. 重新配置应用连接
# 修改应用配置，将数据库连接地址指向新的主站点
# 例如：修改应用配置文件中的数据库连接串
# jdbc:postgresql://192.168.2.10:5432/fgedudb

# 5. 验证业务恢复
# 测试应用功能，确保业务正常运行

# 确认主站点故障
ping: connect: Network is unreachable

# 灾备站点停止输出
waiting for server to shut down…. done
server stopped

# 灾备站点启动为新主站点输出
waiting for server to start….2024-01-01 10:10:00.000 CST [12345] LOG: starting openGauss 3.0.0 (build 1234567) distributed by openGauss community
2024-01-01 10:10:00.001 CST [12345] LOG: listening on IPv4 address “0.0.0.0”, port 5432
2024-01-01 10:10:00.002 CST [12345] LOG: listening on IPv6 address “::”, port 5432
2024-01-01 10:10:00.003 CST [12345] LOG: listening on Unix socket “/tmp/.s.PGSQL.5432”
2024-01-01 10:10:00.100 CST [12346] LOG: database system was shut down at 2024-01-01 10:09:59 CST
2024-01-01 10:10:00.105 CST [12345] LOG: database system is ready to accept connections
done
server started

# 验证新主站点状态from DB视频:www.itpux.com
pg_is_in_recovery
——————-
f

# 验证业务恢复
# 应用测试结果：业务正常运行

4.3 容灾监控实战

案例：配置容灾监控

# 场景：配置容灾监控，监控主备复制状态
# 操作：使用Prometheus和Grafana监控复制状态

# 1. 安装PostgreSQL exporter
wget https://github.com/prometheus-community/postgres_exporter/releases/download/v0.13.0/postgres_exporter-0.13.0.linux-amd64.tar.gz
tar -xzf postgres_exporter-0.13.0.linux-amd64.tar.gz
cd postgres_exporter-0.13.0.linux-amd64

# 2. 创建监控用户
psql -h 192.168.1.10 -p 5432 -U fgedu -d fgedudb << EOF CREATE USER pg_exporter WITH PASSWORD 'Exporter@123';
GRANT CONNECT ON DATABASE fgedudb TO pg_exporter;
GRANT SELECT ON pg_stat_database TO pg_exporter;
GRANT SELECT ON pg_stat_replication TO pg_exporter;
EOF

# 3. 配置PostgreSQL exporter
cat > .env << EOF DATA_SOURCE_NAME=postgresql://pg_exporter:Exporter@123@localhost:5432/fgedudb?sslmode=disable EOF # 4. 启动PostgreSQL exporter ./postgres_exporter --web.listen-address=:9187 & # 5. 配置Prometheus cat > /etc/prometheus/prometheus.yml << EOF global: scrape_interval: 15s scrape_configs: - job_name: 'postgres' static_configs: - targets: ['192.168.1.10:9187', '192.168.2.10:9187'] EOF # 6. 启动Prometheus systemctl start prometheus # 7. 配置Grafana仪表板 # 导入PostgreSQL仪表板模板，添加复制状态监控面板

# 安装PostgreSQL exporter输出
–2024-01-01 10:20:00– https://github.com/prometheus-community/postgres_exporter/releases/download/v0.13.0/postgres_exporter-0.13.0.linux-amd64.tar.gz
Resolving github.com (github.com)… 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 7654321 (7.3M) [application/octet-stream]
Saving to: ‘postgres_exporter-0.13.0.linux-amd64.tar.gz’

postgres_exporter-0.13.0.linux-amd64.tar.gz 100%[=========================================================================>] 7.30M 2.50MB/s in 2.9s

2024-01-01 10:20:03 (2.50 MB/s) – ‘postgres_exporter-0.13.0.linux-amd64.tar.gz’ saved [7654321/7654321]

# 创建监控用户输出
CREATE ROLE
GRANT
GRANT
GRANT

# 启动PostgreSQL exporter输出
INFO[0000] Established connection to PostgreSQL
INFO[0000] Starting Server: :9187

# 启动Prometheus输出
Job for prometheus.service started.

Part05-风哥经验总结与分享

5.1 容灾最佳实践总结

  • 架构设计：根据业务需求选择合适的容灾架构，如同城容灾或异地容灾
  • 网络配置：确保主备站点之间的网络连接可靠，带宽足够
  • 硬件配置：灾备站点的硬件配置应与主站点相当
  • 数据同步：根据RPO要求选择合适的同步方式
  • 监控告警：建立完善的监控体系，及时发现复制异常
  • 定期演练：定期进行灾备演练，确保在实际灾难时能够快速恢复
  • 文档完善：制定详细的容灾方案文档和恢复流程
  • 人员培训：对运维人员进行容灾相关培训，提高灾难处理能力
  • 多维度防护：结合备份和容灾，构建多层次的数据安全体系
  • 持续优化：根据业务发展和技术进步，持续优化容灾方案

5.2 常见容灾问题与解决方案

问题1：复制延迟

解决方案：

  • 检查网络连接，确保网络带宽足够
  • 调整wal_sender_delay和wal_receiver_status_interval参数
  • 使用更快的存储设备，如SSD
  • 减少主站点的写入负载

问题2：灾备站点故障

解决方案：

  • 定期检查灾备站点状态
  • 配置自动故障检测和告警
  • 建立灾备站点的监控体系
  • 定期进行灾备站点的维护和检查

问题3：灾难恢复时间过长

解决方案：

  • 优化恢复流程，减少人工干预
  • 使用自动化工具进行故障切换
  • 定期进行恢复演练，熟悉恢复流程
  • 考虑使用多活架构，减少恢复时间

问题4：数据一致性问题

解决方案：

  • 使用同步复制，确保数据实时同步
  • 定期验证主备站点数据一致性
  • 使用pg_rewind工具修复数据不一致问题
  • 制定数据一致性检查和修复流程

风哥提示：容灾方案的选择需要考虑业务重要性、数据量、RTO和RPO等因素

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

相关推荐

联系我们

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

微信号：itpux-com

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