我们使用两台由WAN隔开的服务器来复制大约1TB的数据。
在主站方面，我们有一台服务器，将Gluster卷导出到许多其他写入数据的服务器上。
在从属方面，我们有一台Gluster卷作为只读共享导出到灾难恢复服务器。
随着时间的推移，奴隶已经变得与主人的同步200gb的调，应该在那里的文件没有和已被删除的文件。 这似乎没有很大的一致性。
什么是最简单的方法来强制群集校验和从属的每个文件，并在需要重新复制？
文档build议：
说明：GlusterFS地理复制没有完全同步数据，但地理复制状态仍显示正常。
解决scheme：您可以通过擦除索引并重新启动GlusterFS Geo-replication来强制执行数据的完全同步。 重新启动后，GlusterFS地理复制开始同步所有的数据，也就是所有的文件将通过校验和进行比较，这可能是一个冗长的资源高利用率操作，主要是大数据集（但是，实际的数据丢失将不会发生）。 如果错误仍然存在，请联系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 这个索引closures失败，而连接仍然存在，文档没有提到这个要求。
有什么build议么？
你的奴隶变得不同步，因为GlusterFS地理复制并不意味着多个变化的数据池（分布式FS），而是灾难恢复（只读备份）。
简而言之，地理复制是主/从模式，其中只有主站点推送写入/更改，并且任何更改都会周期性地同步到远程只读从站。
要有一个真正的分布式复制文件系统，你必须使用GlusterFS的“复制卷”function。 缺点是，对于当前的复制scheme，写入操作必须是同步的：这意味着如果要在WAN链接之间进行复制，则即使本地LAN写入也将与WANpath一样慢。 为了克服这个限制，“ 新风格复制 ”被认为是包含的，但似乎还没有实现（至less在稳定的企业分布）。
回到目前的情况，你是在一个经典的“脑裂情景”，我不知道你能做什么：你的主人和奴隶对底层卷有不同的看法，他们可能积累了不同的，不兼容的变化文件。 我认为你必须（或多或less）手动检查它们…