Confirm
358
edits
Changes
no edit summary
The particulars of shard selection/lookup are not defined in this proposal. :rfkelly likes the consistent-hashing-plus-vbucket approach taken by couchbase, but it could be as simple as a lookup table. We assume that the proxy implements this appropriately and efficiently.
Moving the shard-handling into a separate proxy process gives us a number of advantages:
* Application code is greatly simplified.
* Same code paths can be used for testing with a single-database setup.
* Reduces total number of connections and connection-related overheads.
* Proxy can do centralized health monitoring of the individual servers.
== Intra-Tier Redundancy ==
We don't want a single-point-of-failure, so we'll have to have multiple instances of the webapp talking to multiple instances of the proxy. These are connected via loadbalancing, virtual IPs, and whatever Ops black magic is required to make single-machine failures in each tier be a non-event:
+--------------+ +------------------+
| Web App Tier | | Shard Proxy Tier | +---------------------------+
| | | | +---->| MySQL Server for Shard #1 |
| +---------+ | | +-------------+ | | +---------------------------+
| | Web App | |--->| | Shard Proxy | |--+
| +---------+ | | +-------------+ | | +---------------------------+
| +---------+ | | +-------------+ | +---->| MySQL Server for Shard #2 |
| | Web App | | | | Shard Proxy | | +---------------------------+
| +---------+ | | +-------------+ |
+--------------+ +------------------+
