我有一个数据中心A，该中心每毫秒更改100GB的文件。我需要将文件复制并放置在数据中心B中。万一数据中心A发生故障，我需要在文件B中使用该文件。由于文件每毫秒发生变化，r-sync可以在250英里远的数据中心处理它吗？是否有可能获得损坏的文件？当我们将其称为数据中心B中的完成文件时，它会不断更新？
答案 0 :(得分：1)
rsync是一个相对简单的文件复制工具，具有一些非常高级的功能。这对于更改频率较低的文件和目录结构非常有用。
如果一个具有100GB数据的文件每毫秒更改一次，则潜在的数据更改率为每秒100TB。实际上，我希望更改率会小得多。
尽管可以恢复数据传输并可能部分重用现有数据，但不会在该时间间隔进行rsync进行连续复制。 rsync在文件级别上工作，不像块级复制工具那样常用。但是，有一个--inplace选项。这可能能够为您提供所需的文件同步。 https://superuser.com/questions/576035/does-rsync-inplace-write-to-the-entire-file-or-just-to-the-parts-that-need-to
就距离而言，如果考虑光速，那么250英里可能会导致至少2ms的额外延迟。实际上，这更多是由于电缆，路由器和交换机。
rsync本身可能不是正确的解决方案。这个问题似乎与物理，链接速度和业务要求有关，而不是其他任何问题。最好知道确切的更改率，并知道是否允许您在还原点上留有空白。这种级别的可靠性可能需要更复杂的解决方案，例如日志传送，存储快照，存储复制或后端的某种形式的分布式存储。
答案 1 :(得分：0)
不，rsync可能不是根据您的描述使数据保持同步的正确方法。
如果没有维护和提取信息的手段，100Gb的数据对任何人都毫无用处。这意味着结构化的元素，例如记录和索引。 Rsync对这种结构一无所知，因此无法确保对文件的写入将从一个有效状态转换为另一有效状态。如果要在文件的任一端同时更新并通过rsync复制文件，则肯定不能保证任何一致性。
Rsync可能是正确的解决方案，但是根据您在此处所说的内容无法分辨。
如果您正在谈论为故障转移目的配置数据库的实时复制，那么最好的方法是在DBMS层上使用事务复制。如果失败，请考虑使用类似drbd的块复制，但是请记住，您必须在复制的副本上应用数据库崩溃恢复，然后该副本才能在远程端使用。