PostgreSQL教程FG317-PostgreSQL主从复制
本文档风哥主要介绍PostgreSQL主从复制,包括主从复制概念、类型、架构和实施等内容。风哥教程参考PostgreSQL官方文档Server Administration部分,适合DBA人员在生产环境中使用。
Part01-基础概念与理论知识
1.1 主从复制概述
主从复制是指将主数据库的变更复制到从数据库的过程,是实现高可用、负载均衡和数据备份的重要技术。PostgreSQL支持多种复制方式,包括物理复制和逻辑复制。
- 高可用性:当主数据库出现故障时,可以快速切换到从数据库
- 负载均衡:将读操作分散到从数据库,减轻主数据库的负担
- 数据备份:从数据库可以作为主数据库的备份
- 灾难恢复:当主数据库发生灾难时,可以从从数据库恢复
- 数据分布:将数据分布到不同的地理位置,提高访问速度
1.2 主从复制类型
PostgreSQL支持以下几种复制类型:
- 物理复制:基于WAL日志的复制,复制整个数据库集群
- 逻辑复制:基于逻辑变更的复制,可以复制特定的表或数据库
- 流复制:实时复制WAL日志,减少数据延迟
- 异步复制:主数据库不需要等待从数据库确认,性能较高
- 同步复制:主数据库需要等待从数据库确认,数据一致性更高
1.3 主从复制架构
PostgreSQL主从复制架构主要包括以下组件:
1. 主数据库(Master):负责处理所有写操作,生成WAL日志
2. 从数据库(Slave):接收主数据库的WAL日志,应用到本地数据库
3. WAL发送进程(WAL Sender):在主数据库上运行,负责发送WAL日志到从数据库
4. WAL接收进程(WAL Receiver):在从数据库上运行,负责接收WAL日志
5. 应用进程(Apply Process):在从数据库上运行,负责应用WAL日志到本地数据库
# 主从复制流程
1. 主数据库执行写操作,生成WAL日志
2. WAL发送进程将WAL日志发送到从数据库
3. WAL接收进程接收WAL日志并写入本地WAL文件
4. 应用进程读取WAL文件并应用到本地数据库
5. 从数据库保持与主数据库的数据一致性
Part02-生产环境规划与建议
2.1 主从复制规划
在生产环境中,合理的主从复制规划是确保系统高可用的关键:
1. 明确复制目标:确定复制的目标,如高可用、负载均衡或数据备份
2. 选择复制类型:根据需求选择合适的复制类型
3. 设计复制拓扑:设计合理的复制拓扑,如一主一从、一主多从等
4. 网络规划:确保主从数据库之间的网络连接稳定
5. 存储规划:确保从数据库有足够的存储空间
6. 监控规划:建立主从复制监控系统
7. 故障转移规划:制定故障转移策略和流程
# 主从复制规划示例
– 复制目标:高可用和负载均衡
– 复制类型:流复制
– 复制拓扑:一主两从
– 网络规划:主从数据库之间使用专用网络
– 存储规划:从数据库与主数据库使用相同的存储配置
– 监控规划:使用Prometheus监控主从复制状态
– 故障转移规划:使用Repmgr实现自动故障转移
2.2 主从复制设计
主从复制设计应包括以下内容:
- 复制类型选择:根据需求选择物理复制或逻辑复制
- 复制模式选择:根据数据一致性要求选择异步复制或同步复制
- 复制拓扑设计:设计合理的复制拓扑结构
- 网络设计:确保主从数据库之间的网络连接稳定
- 存储设计:确保从数据库有足够的存储空间
- 监控设计:设计主从复制监控系统
- 故障转移设计:设计故障转移策略和流程
2.3 主从复制实施
主从复制实施应包括以下步骤:
1. 环境准备:准备主从数据库服务器
2. 主数据库配置:配置主数据库的复制参数
3. 从数据库配置:配置从数据库的复制参数
4. 初始化从数据库:使用pg_basebackup初始化从数据库
5. 启动复制:启动主从复制
6. 验证复制:验证主从复制状态
7. 监控配置:配置主从复制监控
8. 故障转移测试:测试故障转移流程
# 主从复制实施注意事项
1. 网络连接:确保主从数据库之间的网络连接稳定
2. 存储配置:确保从数据库有足够的存储空间
3. 权限配置:确保从数据库有足够的权限
4. 防火墙配置:确保防火墙允许主从数据库之间的通信
5. 监控系统:建立主从复制监控系统,及时发现问题
Part03-生产环境项目实施方案
3.1 主从复制搭建
3.1.1 主数据库配置
# 1. 修改postgresql.conf文件
$ sudo vi /postgresql/fgdata/postgresql.conf
# 监听地址
listen_addresses = ‘*’
# WAL级别
wal_level = replica
# 最大WAL发送进程数
max_wal_senders = 10
# 最大复制槽数
max_replication_slots = 10
# WAL保持时间
wal_keep_size = 1GB
# 2. 修改pg_hba.conf文件
$ sudo vi /postgresql/fgdata/pg_hba.conf
# 添加复制用户的访问权限
host replication replicator 192.168.1.0/24 md5
# 3. 创建复制用户
$ psql -U postgres -c “CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD ‘password’;”
# 4. 重启主数据库
$ sudo systemctl restart postgresql
# 5. 验证主数据库状态
$ psql -U postgres -c “SELECT pg_is_in_recovery();”
pg_is_in_recovery
——————-
f
(1 row)
3.1.2 从数据库配置
# 1. 停止从数据库
$ sudo systemctl stop postgresql
# 2. 清理从数据库数据目录
$ sudo rm -rf /postgresql/fgdata/*
# 3. 使用pg_basebackup初始化从数据库
$ pg_basebackup -h 192.168.1.100 -U replicator -D /postgresql/fgdata -F p -X stream -P
# 4. 创建recovery.conf文件
$ sudo vi /postgresql/fgdata/recovery.conf
standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.100 port=5432 user=replicator password=password’
primary_slot_name = ‘replica_slot’
# 5. 修改postgresql.conf文件
$ sudo vi /postgresql/fgdata/postgresql.conf
# 热备模式
hot_standby = on
# 6. 启动从数据库
$ sudo systemctl start postgresql
# 7. 验证从数据库状态
$ psql -U postgres -c “SELECT pg_is_in_recovery();”
pg_is_in_recovery
——————-
t
(1 row)
3.2 主从复制配置
3.2.1 复制参数优化
# 1. 主数据库参数优化
$ sudo vi /postgresql/fgdata/postgresql.conf
# WAL级别
wal_level = logical
# 最大WAL发送进程数
max_wal_senders = 20
# 最大复制槽数
max_replication_slots = 20
# WAL保持时间
wal_keep_size = 2GB
# 同步复制
# synchronous_commit = on
# synchronous_standby_names = ‘replica1’
# 2. 从数据库参数优化
$ sudo vi /postgresql/fgdata/postgresql.conf
# 热备模式
hot_standby = on
# 热备反馈
hot_standby_feedback = on
# 从数据库最大延迟
max_standby_streaming_delay = 30s
# 3. 重启主从数据库
$ sudo systemctl restart postgresql
# 4. 验证复制状态
$ psql -U postgres -h 192.168.1.100 -c “SELECT * FROM pg_stat_replication;”
3.3 主从复制监控
3.3.1 复制监控配置
# 1. 使用pg_stat_replication监控复制状态
$ psql -U postgres -c “SELECT fgapplication_name, state, sync_state, write_lag, flush_lag, replay_lag FROM pg_stat_replication;”
# 2. 使用pg_replication_slots监控复制槽
$ psql -U postgres -c “SELECT slot_name, plugin, slot_type, active FROM pg_replication_slots;”
# 3. 使用Prometheus监控复制状态
$ sudo vi /etc/prometheus/prometheus.yml
– job_name: ‘postgresql’
static_configs:
– targets: [‘fgedu.localhost:9187’]
# 4. 配置Grafana面板
# 导入PostgreSQL复制监控面板
# 5. 设置告警规则
$ sudo vi /etc/prometheus/rules/replication_alerts.yml
groups:
– name: replication_alerts
rules:
– alert: ReplicationLag
expr: pg_replication_lag > 30
for: 5m
labels:
severity: warning
annotations:
summary: “Replication lag on {{ $labels.instance }}”
description: “Replication lag is {{ $value }} seconds”
# 6. 验证监控
$ curl http://fgedu.localhost:9090/targets
Part04-生产案例与实战讲解
4.1 主从复制搭建案例
4.1.1 一主两从复制搭建
# 1. 环境准备
– 主数据库:192.168.1.100
– 从数据库1:192.168.1.101
– 从数据库2:192.168.1.102
– PostgreSQL版本:14.0
# 2. 主数据库配置
$ sudo vi /postgresql/fgdata/postgresql.conf
listen_addresses = ‘*’
wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
wal_keep_size = 1GB
$ sudo vi /postgresql/fgdata/pg_hba.conf
host replication replicator 192.168.1.0/24 md5
$ psql -U postgres -c “CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD ‘password’;”
$ sudo systemctl restart postgresql
# 3. 从数据库1配置
$ sudo systemctl stop postgresql
$ sudo rm -rf /postgresql/fgdata/*
$ pg_basebackup -h 192.168.1.100 -U replicator -D /postgresql/fgdata -F p -X stream -P
$ sudo vi /postgresql/fgdata/recovery.conf
standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.100 port=5432 user=replicator password=password’
primary_slot_name = ‘replica1_slot’
$ sudo vi /postgresql/fgdata/postgresql.conf
hot_standby = on
$ sudo systemctl start postgresql
# 4. 从数据库2配置
$ sudo systemctl stop postgresql
$ sudo rm -rf /postgresql/fgdata/*
$ pg_basebackup -h 192.168.1.100 -U replicator -D /postgresql/fgdata -F p -X stream -P
$ sudo vi /postgresql/fgdata/recovery.conf
standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.100 port=5432 user=replicator password=password’
primary_slot_name = ‘replica2_slot’
$ sudo vi /postgresql/fgdata/postgresql.conf
hot_standby = on
$ sudo systemctl start postgresql
# 5. 验证复制状态
$ psql -U postgres -h 192.168.1.100 -c “SELECT * FROM pg_stat_replication;”
4.2 主从复制故障转移案例
4.2.1 手动故障转移
# 1. 检查主数据库状态
$ psql -U postgres -h 192.168.1.100 -c “SELECT pg_is_in_recovery();”
# 2. 停止主数据库
$ sudo systemctl stop postgresql
# 3. 提升从数据库为主数据库
$ psql -U postgres -h 192.168.1.101 -c “SELECT pg_promote();”
# 4. 验证新主数据库状态
$ psql -U postgres -h 192.168.1.101 -c “SELECT pg_is_in_recovery();”
# 5. 配置其他从数据库连接到新主数据库
$ sudo vi /postgresql/fgdata/recovery.conf
primary_conninfo = ‘host=192.168.1.101 port=5432 user=replicator password=password’
# 6. 重启从数据库
$ sudo systemctl restart postgresql
# 7. 验证复制状态
$ psql -U postgres -h 192.168.1.101 -c “SELECT * FROM pg_stat_replication;”
4.3 主从复制性能优化案例
4.3.1 复制性能优化
# 1. 问题分析
– 主从复制延迟较高
– 复制性能影响主数据库性能
# 2. 优化措施
– 调整WAL发送参数
– 优化网络连接
– 使用异步复制
– 调整从数据库参数
# 3. 优化实施
# 调整主数据库参数
$ sudo vi /postgresql/fgdata/postgresql.conf
max_wal_senders = 20
wal_sender_timeout = 60s
# 优化网络连接
– 使用专用网络连接主从数据库
– 调整网络缓冲区大小
# 使用异步复制
$ sudo vi /postgresql/fgdata/postgresql.conf
synchronous_commit = off
# 调整从数据库参数
$ sudo vi /postgresql/fgdata/postgresql.conf
hot_standby = on
hot_standby_feedback = on
max_standby_streaming_delay = 30s
# 4. 验证优化效果
$ psql -U postgres -h 192.168.1.100 -c “SELECT fgapplication_name, state, sync_state, write_lag, flush_lag, replay_lag FROM pg_stat_replication;”
# 优化前复制延迟:10秒
# 优化后复制延迟:1秒
Part05-风哥经验总结与分享
5.1 主从复制最佳实践
PostgreSQL主从复制的最佳实践:
- 网络配置:使用专用网络连接主从数据库,确保网络稳定
- 存储配置:从数据库使用与主数据库相同的存储配置
- 参数优化:根据系统特点调整复制参数
- 监控系统:建立完善的主从复制监控系统
- 故障转移:制定合理的故障转移策略和流程
- 定期测试:定期测试故障转移流程,确保系统可靠性
- 备份策略:结合主从复制和备份策略,确保数据安全
- 文档化:记录主从复制配置和操作流程
5.2 风哥经验分享
1. 网络稳定性是关键:确保主从数据库之间的网络连接稳定,避免网络波动影响复制
2. 存储配置要匹配:从数据库的存储配置应与主数据库相同,避免性能瓶颈
3. 参数调整要适当:根据系统特点和业务需求调整复制参数
4. 监控系统要完善:实时监控主从复制状态,及时发现和解决问题
5. 故障转移要测试:定期测试故障转移流程,确保在故障发生时能够快速切换
6. 备份策略要结合:主从复制不能替代备份,应结合备份策略确保数据安全
7. 文档记录要详细:详细记录主从复制配置和操作流程,便于后续维护
通过合理的主从复制配置和管理,可以显著提高系统的高可用性和可靠性,为业务提供更好的支持。from PostgreSQL视频:www.itpux.com
5.3 主从复制技巧
PostgreSQL主从复制的技巧:
1. 使用复制槽:确保从数据库能够接收到所有WAL日志,避免数据丢失
2. 监控复制延迟:定期监控复制延迟,及时发现问题
3. 优化网络连接:使用专用网络,调整网络参数
4. 合理设置同步模式:根据数据一致性要求选择同步或异步复制
5. 定期维护:定期清理WAL日志,优化数据库性能
6. 故障转移测试:定期测试故障转移流程,确保系统可靠性
7. 备份策略:结合主从复制和备份策略,确保数据安全
8. 文档化:详细记录主从复制配置和操作流程
# 常见问题解决方案
1. 复制延迟高:检查网络连接,优化复制参数,使用异步复制
2. 复制中断:检查WAL日志,使用复制槽,重新初始化从数据库
3. 故障转移失败:检查故障转移流程,确保从数据库状态正常
4. 性能问题:优化复制参数,调整系统资源,使用专用网络
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
