大文件树是指大约 20 万个文件，并且一直在增长。但是，在任何给定的小时内更改的文件数量相对较少。
双向我的意思是更改可能发生在任一服务器上并且需要推送到另一台服务器，因此 rsync 似乎不合适。
遥远的意思是服务器都在数据中心，但在地理上彼此相距遥远。目前只有 2 个服务器，但随着时间的推移可能会扩展。
实时地，同步之间有一点延迟是可以的，但是每 1-2 分钟运行一次 cron 似乎是不对的，因为在任何给定的小时内，很小的一部分文件可能会发生变化，更不用说分钟了。
编辑：这是在 VPS 上运行的，所以我可能会限制我可以做的内核级别的事情。此外，VPS 的资源并不丰富，所以我会回避需要大量内存的解决方案（比如 Gluster？）。
完成这项工作的最佳/最“被接受”的方法是什么？这似乎是一个普遍的需求，但我还没有找到一种普遍接受的方法，这令人惊讶。（我正在寻求群众的安全。:)
我遇到过lsyncd在文件系统更改级别触发同步。这看起来很聪明，虽然不是很常见，但我对各种 lsyncd 方法有点困惑。只是将 lsyncd 与 rsync 一起使用，但似乎这对于双向性来说可能很脆弱，因为 rsync 没有内存概念（例如，要知道 A 上已删除的文件是否应在 B 上删除，或者它是否是 B 上的新文件应该复制到 A)。 唇形看起来只是一个lsyncd + rsync的实施，对不对？
然后将 lsyncd 与csync2一起使用，如下所示：https : //icicimov.github.io/blog/devops/File-system-sync-with-Csync2-and-Lsyncd/ ...我倾向于这种方法，但是csync2 有点古怪，但我确实对它进行了成功的测试。我最担心的是我找不到很多社区对此方法的确认。
这里的人似乎很喜欢 Unison，但它似乎不再处于积极开发状态，并且不清楚它是否具有像 lsyncd 这样的自动触发器。
我已经看到Gluster提到过，但也许对我需要的东西来说太过分了？
更新：仅供参考 - 我最终采用了我提到的原始解决方案：lsyncd+csync2。它似乎工作得很好，而且我喜欢让服务器非常松散地连接的架构方法，这样每个服务器都可以无限期地独立运行，而不管它们之间的链接质量如何。
当我最初设置主到主复制时，我使用了：
binlog-ignore-db=mysql
并且一直在手动同步用户帐户和授权。这就是我当时使用的操作指南中的做法。但是有什么理由我不应该删除这一行并允许mysql数据库本身也进行复制？
如果是这样：在我进行更改之前，除了确保两者的所有授权都相同（或者更好地说明，整个 mysql 数据库是相同的）之外，还有什么我应该仔细检查或注意的吗？
我在 2 个 Debian 服务器上设置了 master-master 复制，它们复制了所有内容，包括 mysql 数据库本身（以便新用户等也复制）。这通常非常有效，除了大多数（如果不是全部）对 mysql 的 apt 升级都涉及对 mysql 数据库架构的一些更改，这会导致复制错误停止复制。最终，我总是需要通过跳过每一边的错误语句来手动修复。这总是很耗时，而且我担心我可能会在手动操作时出错（跳过太多语句、错误输入 CHANGE MASTER 详细信息等）。
我可以做些什么来确保将来对 MySQL 的 apt-get 更新能够顺利处理而不会导致复制问题？肯定有一个完善的最佳实践吗？
当我这样做时rsync --dry-run -rv，rsync 会列出除时间戳之外完全相同的文件。
我的理解是，仅使用这些标志（它们并没有真正改变比较行为），rsync 会看到不同的时间戳，检查文件大小（当然，它们是相同的），然后最后对文件，然后将它们标记为更新。如果校验和匹配，即使时间戳不同，文件也不会更新。
我有什么误解？