swift搭建时使用演练疑问

搭建了一套openstak环境，在测试使用swift时有如下问题想不通，请教各位：

三台主机环境：
1.proxy server
2.swift0
3.swift1

描述：
swift0和swift1做为两个节点的存储正常运行时，在proxy server端使用swift upload myfiles test.txt上传文件，可同时上传到swift0和swift1中。
模拟把swift0主机关掉后。swift1仍可以使用的。通过swift list myfiles可以查看上传的test.txt文件。


如果此时在proxy server上:swift upload myfiles test2.txt上传另一个文件test2.txt（这时只上传到swift1上）。

我模拟把swift0主机重新开启，想尝试把test2.txt文件同步过去，但是尝试多种方法仍达不到效果(重新检查ring,平衡ring,分发ring文件等)。


问题：
1.请问我这种想法，能实现吗？（swift0主机宕后，swift1可以接受新的文件上传，待swift0恢复后，同步swift1，实现swift0、swift1内容同步）

2.如果上面不能实现，请问新扩展的swift节点如何与其它结节同步的呢?

备份几份，两个节点可能不够，当发生故障的时候，
  如果replicator检测到远程驱动器发生故障，它将使用环的get_more_nodes接口来选择一个替代节点进行同步。

1.请问我这种想法，能实现吗？（swift0主机宕后，swift1可以接受新的文件上传，待swift0恢复后，同步swift1，实现swift0、swift1内容同步）
这个应该可以实现，关键是冗余了几份



#################################################################
Replication   复制

Since each replica in swift functions independently, and clients generally require only a simple majority of nodes responding to consider an operation successful, transient failures like network partitions can quickly cause replicas to diverge. These differences are eventually reconciled by asynchronous, peer-to-peer replicator processes. The replicator processes traverse their local filesystems, concurrently performing operations in a manner that balances load across physical disks.

       由于每个副本在Swift中独立地运行，并且客户端通常只需要一个简单的主节点响应就可以认为操作成功，如网络等瞬时故障虚节点会快速导致副本出现分歧。这些不同最终由异步、对等网络的replicator进程来调解。replicator进程遍历它们的本地文件，在物理磁盘上以平衡负载的方式并发地执行操作。

Replication uses a push model, with records and files generally only being copied from local to remote replicas. This is important because data on the node may not belong there (as in the case of handoffs and ring changes), and a replicator can’t know what data exists elsewhere in the cluster that it should pull in. It’s the duty of any node that contains data to ensure that data gets to where it belongs. Replica placement is handled by the ring.

       复制使用推模型（推模型的简单实现是通过循环的方式将任务发送到服务器上），记录和文件通常只是从本地拷贝到远程副本。这一点非常重要，因为节点上的数据可能不属于那儿（当在传送数据而环改变的情况下），并且replicator不知道在集群的其它位置上它应该拉什么数据。这是任何一个含有数据的节点职责，确保数据到达它所应该到达的位置。副本的位置由环来处理。

Every deleted record or file in the system is marked by a tombstone, so that deletions can be replicated alongside creations. These tombstones are cleaned up by the replication process after a period of time referred to as the consistency window, which is related to replication duration and how long transient failures can remove a node from the cluster. Tombstone cleanup must be tied to replication to reach replica convergence.

       文件系统中每个被删除的记录或文件被标记为墓碑，因此删除可以在创建的时候被复制。在一段称为一致性窗口的时间后，墓碑文件被replication进程清除，与复制的持续时间和将节点从集群移除瞬时故障的持续时间有关。tombstone的清除应该绑定replication和对应的replica，不应该出现有的replica中的tombstone删除掉了，而有的却没有删除掉。

If a replicator detects that a remote drive is has failed, it will use the ring’s “get_more_nodes” interface to choose an alternate node to synchronize with. The replicator can generally maintain desired levels of replication in the face of hardware failures, though some replicas may not be in an immediately usable location.

       如果replicator检测到远程驱动器发生故障，它将使用环的get_more_nodes接口来选择一个替代节点进行同步。在面临硬件故障时，复制器通常可以维护所需的复制级别，即使有一些副本可能不在一个直接可用的位置。

Replication is an area of active development, and likely rife with potential improvements to speed and correctness.

       复制是一个活跃的开发领域，在速度和正确性上具有提升的潜力。

There are two major classes of replicator - the db replicator, which replicates accounts and containers, and the object replicator, which replicates object data.

       有两种主要的replicator类型——用来复制账号和容器的db复制器，以及用来复制对象数据的对象复制器。