Notes from Dean Jacobs's talk

12 use cases for how data is managed in clsutered appservers that they think cover the space well --> just need c/o stores for each type?

Read-mostly:  primary copy in shared backing store, relaxed consistency

Three binary options:

  1. replicated or partitioned  ( partitioned: Server-server comm is still cheaper and faster than server-DB comm).  If it's replicated with a high update rate and strong consistency, should just use the DB.
  2. copied from backing store (catalog data), or computed from it (dynamic pages).  Computed from backing store means hard to push updates "through" the view; but possible to recompute, so you know the appserver can't have the primary copy of the real data.  Backing store could be DB, another service, etc.
  3. Lifetime of data: working set (customer acct while logged into system) vs materialized (catalogs, stock prices)

RMW data: primary copy may be in appserver(!), strong consistency requirements.  Eg session state - nearly every read is accompanied by a write. Many reasons to keep this data out of the DB despite strong consistency requirements.

  1. Location of primary: backing store vs appserver (with primary/secondary, since this is the primary)

Hybrid - 1 case.  Primary managed by appserver, everyone has a replica, update from anywhere, read-mostly.  Can use pessimistic locking or master that coordinates updates from slaves.  Haven't found a use for this in practice; included for completeness.  Usually there's a better way to do this.

Some words about ROC:  minimizing recovery time isn't really needed if you can fail over, and non-Internet-facing enterprise apps don't tend to see large spikes (which would make recovery time more important).  Hence, ROC isn't as relevant for cluster apps.  (Of course, if your overall capacity is affected by failover, and you care about this, recovery time becomes relevant to performability/goodput.)

To execute failiover, need fencing.  ie, shorten the time till when it's safe to migrate, to avoid split-brain syndrome.  What he really wants is to be able to put a tight bound on the time till safe failover.