热备
来自 PostgreSQL wiki
跳转到导航跳转到搜索有一些可用的项目可以帮助您设置热备系统
但实际上手动设置热备是一个相当简单的过程。 以下是仅供参考,旨在帮助您理解。 如果您想使它正常工作,请遵循手册,该手册内容全面且维护准确。
预处理建议
- 在备用服务器的 recovery.conf 文件中,使用 pg_standby 作为您的 restore_command。 pg_standby 包含在 PostgreSQL 8.3 中,您可以从那里复制源代码,然后自己为 8.2 编译它。 它与 8.1 不兼容。
- 将备用服务器的主机环境和目录结构设置为主服务器完全相同。 否则,您需要花费时间更改您在主服务器上为 xlogs、表空间等创建的任何符号链接,这实际上只是错误的机会。
- 预先配置备用服务器的 postgresql.conf 和 recovery.conf 文件。 我通常将所有不同服务器的所有不同配置文件保存在一个版本控制的目录中,然后可以检出并链接到该目录。 同样,一致的环境和目录设置使符号链接成为您最好的朋友。
- 使用 ssh 密钥简单且安全地传输主机之间文件。
- 遵循手册中有关处理错误的所有建议。
使热备正常工作的步骤概述
- 确保主服务器的 postgresql.conf 中启用了 archive_mode。
- 在主服务器的 postgresql.conf 中设置 archive_command。 rysnc 是一个流行的选择,或者您也可以使用文档中的一个示例。 我使用
rsync -a %p postgres@standbyhost:/path/to/wal_archive/%f
- 您必须在这里使用一个执行原子复制的命令,这意味着在完全复制完成之前,文件永远不会出现在目标文件名下。 这将使备用服务器不会尝试读取部分文件。 rsync 已知有效。 一个值得注意的非原子命令是 scp。 如果您想为此目的使用 scp,您需要将文件传输到辅助服务器上的另一个目录,然后在传输完成后将它们移动到恢复命令查找它们的位置。
- 如果您使用的是 pg_standby,它会拒绝应用文件,除非它们具有正确的长度,这降低了非原子复制被应用的风险。 在 Windows 上,它甚至在那之后会休眠一会儿,以便让事情沉淀下来。 以非原子方式执行复制仍然是一个应该避免的坏主意。
- 您必须在这里使用一个执行原子复制的命令,这意味着在完全复制完成之前,文件永远不会出现在目标文件名下。 这将使备用服务器不会尝试读取部分文件。 rsync 已知有效。 一个值得注意的非原子命令是 scp。 如果您想为此目的使用 scp,您需要将文件传输到辅助服务器上的另一个目录,然后在传输完成后将它们移动到恢复命令查找它们的位置。
- 重新加载主服务器的配置 - 或者:从 psql 中执行 SELECT pg_reload_conf(); 或者:pg_ctl reload -D data_dir/ 。 如果您必须启用 archive_mode,您需要重新启动 postgres 服务器:pg_ctl restart -D data_dir/ 。
- 验证 WAL 是否正在发送到其目标位置。
- 在 psql 中,SELECT pg_start_backup('some_label');
- 运行您的基本备份。 同样,rsync 对于像这样的简单操作来说是不错的选择
rsync -a --progress /path/to/data_dir/* postgres@standbyhost:/path/to/data_dir/
- 我建议在屏幕终端窗口中运行它,--progress 标志将让您看到 rsync 的进度。 -a 标志将保留符号链接以及所有文件权限和所有权。
- 在 psql 中,SELECT pg_stop_backup();
- 这会删除一个要存档的文件,该文件的名称与调用 pg_start_backup() 之后发送的第一个 WAL 相同,并带有 .backup 后缀。 内部将包含开始和停止 WAL 记录,定义在您可以将备用服务器从恢复模式中移出之前需要重播的 WAL 文件范围。
- 在备用服务器的 data_dir 中添加或链接您的 recovery.conf 文件。
- 恢复命令应该使用 pg_standby(它的帮助/自述文件简单明了)。 我建议将 pg_standby 的所有输出重定向到一个日志文件,这样您就可以在启动后观察该日志文件,以验证一切是否正常工作。
- 在备用服务器的 data_dir 中添加或链接您的 postgresql.conf 文件。
- 如果您没有将 pg_xlog 目录链接到另一个驱动器来写入 WAL,那么您可以在备用服务器上安全地删除 data_dir/pg_xlog 下的所有内容。
- 使用正常的:pg_ctl start -D /path/to/data_dir/ 启动备用数据库服务器
- 运行:tail -f 查看备用日志并观察以确保它正在重播日志。 如果一切正常,您将在备用服务器查找的每个 WAL 文件上看到一些信息,以及 'success' 消息。 如果由于某种原因它找不到文件,您会看到类似以下的重复消息:'WAL 文件尚未存在。 正在检查触发文件...'(假设您已将 pg_standby 设置为在您的 recovery_command 中查找触发文件)。
至少执行此过程几次,在它重播完所有必要的 WAL 文件(如 .backup 文件中所述)后,将备用服务器带入正常操作模式,这样您就可以连接到它并验证一切是否正常,然后再进行所有这些操作并让它无限期地运行。 一旦您执行几次,它就会变得非常简单。
调整 8.1 中 WAL 更新的频率
人们通常想知道他们的辅助服务器永远不会比主服务器落后多少。 8.2 中引入的 archive_timeout 功能允许这样做。 如果您使用 8.1 的 WAL 复制,您可以使用类似这样的黑客强制执行 16MB 的 WAL 活动,而不会留下任何更改
create table xlog_switch as
select '0123456789ABCDE' from generate_series(1,1000000);
drop table xlog_switch;
如果您将它放入 cron 等中以通过 psql 运行,您甚至可以在没有活动的情况下使日志传送窗口变得尽可能精细。 虽然如果过于频繁地执行此操作,会增加它干扰真实事务的可能性,并且会占用更多磁盘空间;每隔几分钟可能就是您希望执行此操作的频率。 使用 archive_timeout 不会出现此问题,手册建议可以将其设置为几秒钟,如果需要的话。
其他资源
- pg_standby 延迟监控
- 使用 PITR 的简单 HA
- PostgreSQL 8.3 热备复制:包含 Ubuntu 特定的教程
- 使用 pg_standby 实现 Postgresql 的高可用性:涵盖 Debian 的教程,在 8.2 上使用 8.3 pg_standby
- 源材料