Replication 当发生网络故障和驱动器故障等问题时，保持系统的一致性，同样翻译自官方文档。 Replication 复制 由于每一个副本在swift中功能独立，客户端通常只需要一个简单多数的节
Replication 当发生网络故障和驱动器故障等问题时，保持系统的一致性，同样翻译自官方文档。
Replication 复制
由于每一个副本在swift中功能独立，客户端通常只需要一个简单多数的节点响应为操作成功，短暂的故障像是网络，虚节点快速造成副本产生分歧。这些不同最终通过异步，端到端的replicator进程来进行响应。replicator进程遍历本地的文件系统，同时以平衡的方式执行在物理磁盘上。
复制使用推进模式，记录和文件只是拷贝从本地到远端的副本。这很重要因为在节点上的数据可能不属于那些（在切换和环改变的模式下），replicator不能知道应该引入的在其他地方存在集群的数据。这是所有节点的责任去包含数据来确保数据到达属于的地方。副本放置由ring处理。
在系统中每一个文件或者记录的删除被记录成一个墓碑。，以便于删除可以再创建的时候复制。这些墓碑通过复制进程清除在一段时间后被称作一致性窗口。与复制持续和从集群中移除节点的短暂故障的时间有关。墓碑
清除应该与replcation管理来到达副本集中。
如果replicator检测一个远端的驱动器故障，它将会使用ring的"get_more_nodes"结构来选择交换节点进行同步。replicator可以维护需要的复制级别来面对磁盘故障。尽管有些副本或许不再一个立即可用的位置。replicator不会维护需要的复制级别在其他的故障（整个节点故障）因为大多数的故障时短暂的。
复制是一个很活跃的开发领域，在速度很正确性上有潜在的提供的能力。
有两种主要的replicator类型-db replicator,可以复制账户和容器，object replicator 可以复制对象数据。
DB Replication
db复制执行的第一步是一个低消耗的哈希比较用来找出是否两个符文已经匹配过了。在常规的操作下。这个检查可以非常快核实系统中多数的数据库已经同步。如果哈希值不同，replicator通过共享最后一次的同步点之后增加的记录对数据库进行同步。
这个同步点是一个高水印标记的用来记录在哪两个数据库进行了同步，然后存储在每个数据库中作为一个远程数据库id和记录id的元组。数据库id在数据库所有副本中是唯一的，记录id是递增的整数。毕竟新的记录已经推送到远端的数据库上，整个本地数据库同步表被推送，因此远端数据可知道现在于任何本地数据库之前的同步的数据库进行了同步了。
如果一个副本被发现完全的丢失了，整个本地数据库文件使用rsync(1)传送到对等的节点的远端数据库，授予一个新的唯一的id。
实际上，DB复制可以处理上百个数据库可以设定没并发每秒的值（取决于可以用的CPU和磁盘的数量）并且必须执行DB是事务的约束。
Object Replication 对象复制
最初的对象复制的实现 简单执行了rsync推送数据从本地虚节点到所有它所期望的远端的服务器。尽管在小规模下执行的很充分，复制时间飙升一旦目录结构不再保存在RAM中。我们现在使用这个种方式的改进版本，将每一个后缀目录的内容的哈希值保存到每一个虚节点的哈希文件中，当目录后缀的内容被修改时，它的哈希值无效。
对象复制进程独缺这些哈希文件，计算出实效的哈希，然后传送这些哈希到每一个远端的有虚节点的服务器，只是有不同哈希值的后缀目录在远端服务器被rsync。在推送文件到远端服务器之后，复制进程修改它重新计算rsync的后缀目录的哈希值。
对象复制的性能通常被要遍历的未缓存目录的数量所限制，通常作为失效后缀目录哈希值的结果。在我们运行的系统中使用写卷和虚几点计数，它被设计以便于2%的哈希空间在一个节点上将失效每天，已经在实验中给予我们可以接受的复制速度。
