Re: [google-appengine] Worst-case scenario for eventual consistency in the HRD?
I think Jeff was actually asking about index lag -- how long before the indexes will be updated, not how long for the data to replicate. I'd like to know this info too. Robert On Mon, Sep 19, 2011 at 20:55, Ikai Lan (Google) ika...@google.com wrote: I'll check for you, but FWIW here are the last numbers for master/slave I heard with regards to replication delay: - most of the time data is replicated within hundreds of milliseconds - when there is something wrong, mean time is 3 minutes, with an upper bound that is roughly 10 minutes If a data center goes offline, that's the window of writes you may lose on master/slave. On HRD you don't lose data. I'll double check with the datastore team to see if we have numbers, but it might not work the same way. When you do a write, a majority of datastore instances have to acknowledge receiving the write and having appended it to the write journal. Thus, if the primary datastore goes offline, application servers make RPCs to the other datastores and use the first response that comes back. The datastores that are running behind still try to catch up in the background and continue to apply writes from the journal. I suppose the number you're looking for here is: what is replication delay if a datastore isn't forced to catch up? -- Ikai Lan Developer Programs Engineer, Google App Engine plus.ikailan.com | twitter.com/ikai On Mon, Sep 19, 2011 at 5:16 PM, Jeff Schnitzer j...@infohazard.org wrote: I know that an index update in the HRD will typically be visible within a couple seconds. That's the average case. What is the worst-case? Assuming something in the datacenter goes wacky, how long might it take for an index to update? Tens of seconds, minutes, hours, days? Thanks, Jeff -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
[google-appengine] Worst-case scenario for eventual consistency in the HRD?
I know that an index update in the HRD will typically be visible within a couple seconds. That's the average case. What is the worst-case? Assuming something in the datacenter goes wacky, how long might it take for an index to update? Tens of seconds, minutes, hours, days? Thanks, Jeff -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
Re: [google-appengine] Worst-case scenario for eventual consistency in the HRD?
I'll check for you, but FWIW here are the last numbers for master/slave I heard with regards to replication delay: - most of the time data is replicated within hundreds of milliseconds - when there is something wrong, mean time is 3 minutes, with an upper bound that is roughly 10 minutes If a data center goes offline, that's the window of writes you may lose on master/slave. On HRD you don't lose data. I'll double check with the datastore team to see if we have numbers, but it might not work the same way. When you do a write, a majority of datastore instances have to acknowledge receiving the write and having appended it to the write journal. Thus, if the primary datastore goes offline, application servers make RPCs to the other datastores and use the first response that comes back. The datastores that are running behind still try to catch up in the background and continue to apply writes from the journal. I suppose the number you're looking for here is: what is replication delay if a datastore isn't forced to catch up? -- Ikai Lan Developer Programs Engineer, Google App Engine plus.ikailan.com | twitter.com/ikai On Mon, Sep 19, 2011 at 5:16 PM, Jeff Schnitzer j...@infohazard.org wrote: I know that an index update in the HRD will typically be visible within a couple seconds. That's the average case. What is the worst-case? Assuming something in the datacenter goes wacky, how long might it take for an index to update? Tens of seconds, minutes, hours, days? Thanks, Jeff -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
