Confirm
358
edits
Changes
no edit summary
+--------------+ +------------------+
| Web App Tier | | Shard Proxy Tier | +---------------------+ | | | | +-->| Master for Shard #N | | +---------+ | | +-------------+ | | +----------+----------+ | | Web App | |--->| | Shard Proxy | |-----+ | (replication) | +---------+ | | +-------------+ | | +----------V---------------+ | +---------+ | | +-------------+ | +-->| Hot Standby for Shard #N | | | Web App | | | | Shard Proxy | | +--------------------------+
| +---------+ | | +-------------+ |
+--------------+ +------------------+
Note that we're '''not''' doing this to the MySQL servers. There's too many of them and we already have a custom redundancy scheme from the hot standby.
With multiple Shard Proxy processes, we run into the problem of shared state. They must all agree on the current mapping of userids to shards, of shards to database machines, and which database machines are master versus standby. They'll operate as a ZooKeeper (or similar) cluster to store this state in a consistent and highly-available fashion:
+----------------------------------------------+
| Shard Proxy Tier |
| |
| +------------------+ +-----------------+ |
| | Shard Proxy: | | Shard Proxy: | |
| | ZooKeeper Node <+----+> ZooKeeper Node | |
| | Proxy Process | | Proxy Process | |
| +----|-------------+ +----|------------+ |
| | | |
| +-----------+-----------+ |
+-------------------|--------------------------+
V
...................
: MySQL Instances :
:.................:
