主页 / dba / 问题 / 327495
Accepted
Luciano Andress Martini
Asked: 2023-05-25 05:56:08 +0800 CST

使用 rsync -u 的副本的 Postgresql rsync 同步

  • 772

使用 rsync 参数 -u 同步 PostgreSQL 复制是否安全？

例如，如果我的复制由于连接问题（例如 WAL 存档已被删除）而丢失了很长时间，我总是需要将我数据库的所有文件再次从主服务器同步到副本。

所以我正在使用类似（或几乎类似）的东西（在奴隶内部）：

systemctl stop postgresql@11-slave 
psql -h 10.0.0.MASTER -Atc "select pg_start_backup('clone', true);"
rsync -avz [email protected]:/var/lib/postgresql/11/main /var/lib/postgresql/11/  
systemctl start postgresql@11-slave 
psql -h 10.0.0.MASTER -Atc "select pg_stop_backup('clone', true);"

上面的解决方案工作得很好，并且经过多次测试，没有任何数据丢失。

但我很想尝试使用更快（危险？）的方法来恢复复制，例如：

systemctl stop postgresql@11-slave 
psql -h 10.0.0.MASTER -Atc "select pg_start_backup('clone', true);"
rsync -uavz [email protected]:/var/lib/postgresql/11/main/ /var/lib/postgresql/11/  
systemctl start postgresql@11-slave 
psql -h 10.0.0.MASTER -Atc "select pg_stop_backup('clone', true);"

在 rsync（更新）上使用参数 -u 而不是重新复制所有文件是否安全，或者当我的复制发生问题时我应该继续复制所有文件吗？

postgresql

1 个回答

  1. Best Answer

    我认为那不会rsync -u给你买任何东西。唯一可能在备用数据库上具有较晚时间戳的相关文件是控制文件，它很小。

    我认为这是过早优化的经典案例。如果有的话，它可能会伤害你。如果某人或某事不小心触及了备用文件上的文件，给它一个较晚的时间戳（修改或不修改内容），您将错误地不复制该文件，这很可能导致数据损坏。

    你没有问过这个问题，但是你修复备用服务器的方法已经过时了，因为它使用“独有的备份 API”并且依赖于backup_label在主服务器的数据目录上创建。在 PostgreSQL v15 中删除了这种备份方法，因为在备份模式处于活动状态时主服务器崩溃很可能会使主服务器处于无法在没有手动干预的情况下重新启动的情况。您可以更改您的程序以使用“非独占备份API”，但它会变得相当复杂。

    我建议您采取通常的措施来可靠地防止备用服务器“退出”：要么在备用restore_command服务器上设置以使其能够从 WAL 存档中恢复，要么使用复制槽并监视复制。

    • 1

相关问题