Open Stack

Matthew Booth <mbooth at redhat.com> wrote:

> 
> Based on my current (and still sketchy) understanding, I think we can
> define 3 classes of database node:
> 
> 1. Read/write
> 2. Synchronous read-only
> 3. Asynchronous read-only
> 
> and 3 code annotations:
> 
> * Writer (must use class 1)
> * Reader (prefer class 2, can use 1)
> * Async reader (prefer class 3, can use 2 or 1)
> 
> The use cases for async would presumably be limited. Perhaps certain
> periodic tasks? Would it even be worth it?

Let’s suppose someone runs an openstack setup using a database with async replication.

Can openstack even make use of this outside of these periodic tasks, or is it the case that a stateless call to openstack (e.g. a web service call) can’t be tasked with knowing when it relies upon a previous web service call that may not have been synced?

Let’s suppose that an app has a web service call, and within that scope, it calls a function that does @writer, and then it calls a function that does @reader.   Even that situation, enginefacade could detect that within the new @reader call, we see a context being passed that we know was just used in a @writer - so even then, we could have the @reader upgrade to @writer if we know that reader slaves are async in a certain configuration.

But is that enough?   Or is it the case that a common operation calls upon multiple web service calls that are dependent on each other, with no indication between them to detect this, therefore all of these calls have to assume “I can only read from a slave if its synchronous” ?

I think we really need to know what deployment styles we are targeting here.  If most people use galera synchronous, that can be the primary platform, and the others simply won’t be able to promise very good utilization of async read slaves.

If that all makes sense.  If I read this a week from now I won’t understand what I’m talking about.