我们使用两台由 WAN 隔开的服务器来复制大约 1TB 的数据。
在主端，我们有一台单独的服务器，该服务器具有一个 Gluster 卷，该卷导出到许多其他写入数据的服务器。
在从属端，我们有一台服务器，其中的 Gluster 卷作为只读共享导出到灾难恢复服务器。
随着时间的推移，从服务器与主服务器的同步度已达到 200gb，应该存在的文件不见了，而删除的文件却存在了。这似乎不太一致。
强制集群对从属设备上的每个文件进行校验并在需要时重新复制的最简单的方法是什么？
文档表明：
描述：GlusterFS 地理复制未完全同步数据，但地理复制状态仍显示正常。
解决方案：您可以通过擦除索引并重新启动 GlusterFS Geo-replication 来强制完全同步数据。重新启动后，GlusterFS Geo-replication 开始同步所有数据，也就是说，所有文件将通过校验和进行比较，这可能是一个耗时/资源利用率高的操作，主要是针对大型数据集（但是，不会发生实际数据丢失）。如果错误情况仍然存在，请联系 Gluster 支持。
但没有提到这个索引可能在哪里。
# gluster volume geo-replication share gluk1::share stop
Stopping geo-replication session between share & gluk1::share has been successful
# gluster volume set share geo-replication.indexing off
volume set: failed: geo-replication.indexing cannot be disabled while geo-replication sessions exist
当连接仍然存在并且文档中没有提到此要求时，此索引关闭会失败。
有什么建议么？
答案1
您的从属服务器不同步，因为 GlusterFS 地理复制不是适用于多个变化的数据池（分布式 FS），而不是用于灾难恢复（只读备份）。
简而言之，地理复制是一种主/从模型，其中仅限主站点推送写入/更改，并且任何更改都会定期同步到远程只读奴隶。
要拥有真正的分布式复制文件系统，您必须使用 GlusterFS 的“复制卷”功能。缺点是，使用当前复制方案，写入必须同步：这意味着如果您在 WAN 链路之间进行复制，即使是本地 LAN 内写入也会与 WAN 路径一样慢。为了克服这个限制，“新式复制“正在考虑纳入，但似乎尚未实施（至少在稳定的企业分布上）。
回到您当前的情况，您处于典型的“裂脑场景”，我不确定您能做什么：您的主服务器和从服务器对底层卷有不同的看法，并且它们可能对同一文件积累了不同的、不兼容的更改。我认为您必须（或多或少）手动查看它们...