Thanks for the detailed explanation... >> >> >> 1. So when the replicator catches up, it will move the object back to >> the correct location. Is that right? > > > The read path will find the object on any primary or any handoff location. > The replicator *will* copy the data files to the primary and delete it from > the handoff once it's successfully in sync. But GETs for the object will be > able to find the object during that entire process. Having data written to > a handoff location does not mean it is unaccessible - quite the opposite - > stable handoff ordering is the mechanism that enables data to be accessible > during failure of primary storage devices.
This is unlike what I've seen in this setup. I have some code that tried to read the object 5 times from Swift with exponential backoff. But it failed with a 404 on all occassions which is why it gave up. I also tried manually using swift command line tool and got back an object "not found" error. The object was found in the *second* handoff node. Not the first. Does that matter. The replicator eventually did transfer the blob to the original node. After that things were just fine... _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
