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
