The following are the major differences from revision 1 of our clustering plan.
This is the main difference. We're only clustering databases. This means we don't need the backhand redirector machines to look at URIs and redirect requests to the right pool of webslaves. And this also means we can still have premium faster paid servers.
Each webslave will talk directly to the DB it needs to using DBI, rather than doing some HTTP wrapper kludge. The point of the RPC wrapper before was to prevent the cluster master DBs from having five billion connections from a half billion web slaves. But really, MySQL handles insane numbers of connections anyway (if thy're mostly idle, as they will be). If we need to serialize requests later between a smaller number of db connections, we'll just do that, making each machine have a pool of connections they have to share.
Why all idle you say? Well, web slaves continues to grow over time, but we limit the number of users/traffic/load per db cluster. So divide. Each web slave will eventually get a master connection, and the master traffic is fixed, so over time, a smaller number of those connections will be active. When it gets too extreme, we either cluster web slaves or make the DB connection pool. But we can deal with this later. Both solutions are easy enough, but they're boring to care about now.
- talk2
- talktext2
- talkprop2
- log2
- logsec2
- logtext2
- logsubject2
- logprop2
- syncupdates2
- userbio
- talkleft
These tables will replace the tables on the original master server with the
similar names (i.e. without the 2 appended.) userbio is the same.
Currently, a user can conceivably be on either the original master database
or in one of the myriad clusters available. To detect what the case may be,
examine the clusterid element of the user's entry in the user
table. If clusterid == 0 then the user is located on the old
master database and their data needs to be loaded from the old tables; otherwise,
the data is located on cluster #clusterid using the new table names
above.
For future expansion, the element dversion is also added to
the user table. If dversion == 0 then the user is not
on a cluster, i.e. they're on the original master system. dversion == 1
implies that the user is located on a cluster. As more of the user's data is
moved to the clusters, dversion will increase. Note that any dversion >= 1 means
the user is on a cluster. The plan is for higher dversion numbers to indicate
that more per user data is moved from the original setup to the clustering system.
Conversion from dversion 0 to dversion 1 will be a lazy conversion. This involves the READ_ONLY capability code. Basically, the user's READ_ONLY capability bit will be set and then the code will pause for a minute or two to allow any pending transactions to go through. After this, all data will be copied from the old database system into the appropriate cluster. After everything is copied, the data is deleted from the old system and the users's READ_ONLY capability bit is toggled off.