嗨，每次我需要设置二进制复制时，我都会遵循本教程，事实上，我正在使用第二种方法，称为：“仅通过快速主重启启动复制”，可在此处找到： https ://wiki.postgresql.org /wiki/Binary_Replication_Tutorial
那很好用。
在测试环境中，我尝试使用 tar 代替此 rsync：
rsync -av --exclude pg_xlog --exclude postgresql.conf --exclude postgresql.pid \
data/* 192.168.0.2:/var/lib/postgresql/data/
像这样：
tar -cz data >data.tar.gz
使用数据生成 .tar 文件并在从站上解压缩，这对数据库有多糟糕？
在日志中，slave 显示它已成功连接到 master。
假设复制数据目录一开始是空的（它应该是空的，或者你可能做错了什么），这些命令基本上是等价的。两者都读取所有数据并对其进行处理。
tar 将在服务器上使用更多的 CPU，因为它将运行 gzip，只要有一个空闲的 CPU，它可能会用完一个 CPU。它还会消耗更多的 IO 容量，因为它会将 .tgz 文件写入磁盘而不是直接通过网络流式传输（但您可以将 tar 命令更改为通过 ssh 流式传输）
这些都不应该有太大的不同，除非你已经处于边缘。
考虑到您对 rsync 慢了多少的评论：我发现 rsync 有点慢，但不是很慢。我想知道你是否有功能失调的实施。我听说过（模糊地）rsync 的版本以导致上下文交换风暴的方式与 Linux 内核的版本交互。无论如何，如果 tar 快得多，那么它自然会在服务器上施加更高的 IO 负载，因为它会在更短的时间内读取所有数据，这可能会在发生时干扰服务器操作。另一方面，无论 rsync 正在做什么使其变慢，也可能正在消耗数据库想要使用的资源。
不幸的是，当您遇到与内核版本交互的一种工具的实现等问题时，您遇到的问题实际上只能通过实验来解决。
如果您担心正确性，rsync（当像您展示的那样使用并且在一个空的目标目录上使用时）和 tar 都应该保持您的数据完整性，这只是哪个性能更好的问题，并且对生产的性能影响最小服务器通过与它竞争资源。我更喜欢 tar，因为 rsync 邀请人们尝试做一些聪明的事情，这些事情会将他们的数据置于危险之中。