Open Stack

The object in the handoff location should get removed once it is successfully copied to the primary locations. Check object-replicator error logs like “Error syncing handoff partition”.

Gerry.


From: Brent Troge [mailto:brenttroge2016 at gmail.com]
Sent: 17 September 2014 16:48
To: John Dickinson
Cc: openstack at lists.openstack.org
Subject: Re: [Openstack] SWIFT - Write Quorum


If an object write is sent to a hand off location, is that object deleted from that hand off location once the primary write location is written to?  In my testing, I forced a new object write to hand off locations. Once I brought the primary locations back online, the object is then written to all primary locations however the object still resides in the handoff location.
Please advise.

Thanks!

On Tue, Sep 9, 2014 at 12:41 PM, Brent Troge <brenttroge2016 at gmail.com<mailto:brenttroge2016 at gmail.com>> wrote:
Thanks John.. I truly appreciate your clear and concise answers.





On Tue, Sep 9, 2014 at 12:09 PM, John Dickinson <me at not.mn<mailto:me at not.mn>> wrote:
Well listings is slightly different than being able to read the data if you already know the object name.

Assuming no failures in the system, the container listings will be up to date before the end-user gets a 2xx response. That is, create a new object, then immediately do a listing, and you'll see the object in that listing.

However, we can pretty safely assume that there will be failures at some point (especially if it's a larger cluster). In that case, the end-user will still get a 2xx response because the data was durably flushed to disk, but the container listing update may fall back to an asynchronous update. In that case, you may or may not get the object in a container listing until container replication has completed. But you'll still be able to read the object directly if you know the name.

--John


On Sep 9, 2014, at 9:15 AM, Brent Troge <brenttroge2016 at gmail.com<mailto:brenttroge2016 at gmail.com>> wrote:

> Thanks..  My understanding is that an object will not be listed within a container until it completes replication throughout the cluster. Thats what I meant by 'listing'
>
> But you corrected that mis-understanding.  Such that, with respect to my 3 write requirement, an object will be available  in each region once I receive a 200 upon file ingest.
>
>
>
>
>
> On Tue, Sep 9, 2014 at 10:02 AM, John Dickinson <me at not.mn<mailto:me at not.mn>> wrote:
> I'm not sure what the question is.
>
> If you are looking to have a successful response after it's written twice in a cluster with 4 replicas, no. Swift's quorum calculation is (replicas DIV 2 + 1). This means that for 4 replicas, you have a quorum size of 3. What I would suggest you look in to is the write_affinity setting so that you can do a full-quorum (at least) write to the local region and then asynchronously replicate to the other region. See http://docs.openstack.org/developer/swift/admin_guide.html#geographically-distributed-clusters and https://swiftstack.com/blog/2012/09/16/globally-distributed-openstack-swift-cluster/.
>
> If you are looking to ensure that there is at least one replica in each region, then yes. The quorum size of three (see above) will ensure that, without any write_affinity settings, you'll have at least one replica in each region and two in another before the client gets a 2xx success response code to the PUT request.
>
> --John
>
>
>
> On Sep 9, 2014, at 6:59 AM, Brent Troge <brenttroge2016 at gmail.com<mailto:brenttroge2016 at gmail.com>> wrote:
>
> >
> >
> > If I configure Swift to use 4 replicas across two regions(two replicas per region), is it possible to only list a newly ingested object if it has written at least twice? The goal is to only list a new object only if it has a presence in each region.
> >
> > west coast
> > region 1 - zone 1
> > region 1 - zone 2
> >
> > east coast
> > region 2  - zone 1( 3?)
> > region 2 -  zone 2( 4?)
> >
> > Thanks!
> >
> >
> > _______________________________________________
> > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> > Post to     : openstack at lists.openstack.org<mailto:openstack at lists.openstack.org>
> > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140917/4c109ec5/attachment.html>