个人 邮箱 含网站 域名html网页模板 学生html静态网页模板

pg_rewind 是 PostgreSQL 中的一个实用程序，用于将一个数据库集群与另一个数据库集群同步，通常是在故障转移或主服务器和备用服务器角色切换之后。
当旧主服务器需要在故障转移后作为备用服务器重新加入新的主服务器时，它特别有用。

pg_rewind 的工作原理

发生故障转移时，新的主服务器可能会与旧的主服务器（现在成为备用服务器的候选服务器）产生分歧。

pg_rewind 通过仅复制差异（即更改的块）而不是重新同步整个数据库，有效地使旧主服务器的数据文件与新主服务器的数据文件保持同步。

与完全重新同步相比，此过程更快，占用的带宽更少。

使用 pg_rewind 的要求

1. WAL archive或replication slot：旧主服务器必须具有足够的 WAL 日志可用来覆盖自分歧以来的时间段。这可以使用 WAL archive或replication slot来管理。
2. 兼容版本：旧主服务器和新主服务器上的 PostgreSQL 版本必须相同或兼容，pg_rewind 才能工作。
3. clean关闭：在运行pg_rewind之前，应干净地关闭旧主服务器。

Basic Usage of pg_rewind

要使用“pg_rewind”，请遵循以下常规步骤：

1. 停止旧主服务器：确保旧主服务器已clean stop。
2. 运行“pg_rewind”：执行“pg_rewind”命令，指定旧主服务器的数据目录和新主服务器的连接详细信息。

pg_rewind -D data_directory - source-server="connection_string"

• -D data_directory: 旧主服务器的数据目录（现在正准备作为备用服务器）。
• — source-server=”connection_string”:到新的主服务器的连接字符串，它提供同步所需的数据。
• example:

pg_rewind -D /var/lib/postgresql/14/main — source-server=”host=new_primary_host port=5432 user=replication_user dbname=mydb”

在这个范本中:
— /var/lib/postgresql/14/main 是旧主服务器的数据目录
— new_primary_host new_primary_host是新主服务器的主机名。 —5432是PostgreSQL server的端口号 —replication_user` 是具有适当复制权限的用户。

3.启动回滚后的服务器：在 pg_rewind 完成后，你可以将回滚后的服务器以备用模式启动，并进入复制模式。

重要注意事项:

数据丢失：故障转移前未同步的旧主服务器上的任何未复制数据都可能丢失。

• 权限：确保运行“pg_rewind”的用户具有访问旧主服务器和新主服务器所需的权限。
• 备份：在运行“pg_rewind”之前备份关键数据是一种很好的做法，因为如果管理不当，此操作可能会导致数据丢失。

为什么 pg_rewind 需要干净关闭？

为了使 pg_rewind 在 PostgreSQL 中正常运行，通常需要干净关闭旧的主服务器。以下是这很重要的原因：
干净关闭的重要性：

1. 数据一致性：干净关闭可确保所有待处理事务都已完成，并且数据库处于一致状态。这意味着所有数据更改都已完全写入数据文件，并且 WAL（预写日志）已正确刷新。

2. 检查点：在干净关闭期间，PostgreSQL 会执行检查点，这是一个将所有脏页（已修改的页面）从缓冲区缓存写入磁盘并记录特殊 WAL 记录以指示一致时间点的过程。

此检查点对于“pg_rewind”至关重要，因为它标记了可以跟踪更改并向前或向后滚动的状态
3. 避免数据损坏：如果服务器没有干净地关闭，可能会有未正确写入磁盘的不完整或损坏的数据。

在这种情况下，pg_rewind 可能无法准确确定旧主服务器和新主服务器之间的差异，从而导致潜在的数据损坏。

无法进行干净关闭的情况

在某些情况下，可能无法进行干净关闭，例如：

• 突然的硬件故障
• 系统崩溃
• 意外断电

注意：在这些情况下，失效主节点的数据目录可能包含未提交的事务或部分写入的数据，这使得其不能立即安全使用或与 pg_rewind 进行同步。

处理不正常关机

如果旧的主服务器没有干净地关闭，可能需要采取额外的步骤：

1. 手动检查：检查日志和数据文件以评估数据库的状态。
2. 数据恢复：您可能需要使用其他恢复工具或技术，例如从备份中恢复或谨慎使用 pg_resetwal 工具来重置 WAL 并使数据目录再次可用。
3. 风险增加：请注意，在非干净关闭后使用 pg_rewind 可能会带来数据丢失或不一致的风险。

结论

干净关闭可确保 pg_rewind 有一个安全且一致的起点来执行其操作，这使其成为准备将发生故障的主服务器与新的主服务器重新同步时的最佳实践。

如果没有干净关闭，则数据不一致的风险更高，并且该过程可能需要额外的手动干预以确保数据完整性。