External storage
From Wikitech
(Difference between revisions)
(Add Cage/Rack info to highlight possible unnecessary los of power to all in one set from a single rack or cage failure) |
|||
| Line 6: | Line 6: | ||
{| class="mw_metadata" | {| class="mw_metadata" | ||
| − | !'''Cluster'''!!'''Master'''!!'''Slaves''' | + | !'''Cluster'''!!'''Master'''!!'''Slaves'''!!'''Cage/Rack''' |
|- | |- | ||
!cluster1 | !cluster1 | ||
|[[srv30]] | |[[srv30]] | ||
|[[srv28]],[[srv29]] | |[[srv28]],[[srv29]] | ||
| + | |Core2,Core4,Core2 | ||
|- | |- | ||
!cluster2 | !cluster2 | ||
|[[srv27]] | |[[srv27]] | ||
|[[srv25]],[[srv24]] | |[[srv25]],[[srv24]] | ||
| + | !'''all Core2''' | ||
|- | |- | ||
!cluster3 | !cluster3 | ||
|[[srv34]] | |[[srv34]] | ||
|[[srv33]],[[srv32]],[[srv36]] | |[[srv33]],[[srv32]],[[srv36]] | ||
| + | |Core5,Core5,Core5,Sec2 | ||
|- | |- | ||
!cluster4 | !cluster4 | ||
|[[srv73]] | |[[srv73]] | ||
|[[srv72]],[[srv71]] | |[[srv72]],[[srv71]] | ||
| + | !'''all Sec2''' | ||
|- | |- | ||
!cluster5 | !cluster5 | ||
|[[srv76]] | |[[srv76]] | ||
|[[srv75]],[[srv74]] | |[[srv75]],[[srv74]] | ||
| + | |'''Sec2,unknown,Sec2''' | ||
|} | |} | ||
Revision as of 17:41, 31 May 2006
The external storage database cluster are MySQL servers storing page revision text. The main database only stores a link of the form DB://clusterx/blob_id, where x is the number of the cluster and blob_id is the key to the blob table.
External storage clusters are replicated, there's a master and several slaves. For clusters that are not written to, a failure of the master is not critical.
There are currently 5 external storage clusters in Tampa:
| Cluster | Master | Slaves | Cage/Rack |
|---|---|---|---|
| cluster1 | srv30 | srv28,srv29 | Core2,Core4,Core2 |
| cluster2 | srv27 | srv25,srv24 | all Core2 |
| cluster3 | srv34 | srv33,srv32,srv36 | Core5,Core5,Core5,Sec2 |
| cluster4 | srv73 | srv72,srv71 | all Sec2 |
| cluster5 | srv76 | srv75,srv74 | Sec2,unknown,Sec2 |
Currently, clusters 4 and 5 are used for storage of new revisions' text blobs, using a round robin load balancing.
Cluster3 has 4 nodes because it stores the text of many current revisions and has a high read load.
