OK.. In a sunny day scenario, in my 4 replica configuration, and with a region 1 write affinity, I do see the 3rd copy in the r1 hand off location deleted upon async replication to zone 1 and zone 2 within region 2.
In a rainy day scenario with no region 2 storage servers available upon new file upload, i do not see the region 1 hand off object deleted upon region 2 restore and subsequent sync. Am I missing something within my configuration? On Wed, Sep 17, 2014 at 11:25 AM, Drudy, Gerry <gerry.dr...@hp.com> wrote: > 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:brenttroge2...@gmail.com] > *Sent:* 17 September 2014 16:48 > *To:* John Dickinson > *Cc:* openstack@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 <brenttroge2...@gmail.com> > wrote: > > Thanks John.. I truly appreciate your clear and concise answers. > > > > > > > > > > > > On Tue, Sep 9, 2014 at 12:09 PM, John Dickinson <m...@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 <brenttroge2...@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 <m...@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 <brenttroge2...@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@lists.openstack.org > > > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > > > > > > > > >
_______________________________________________ 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
