As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 521597 - personas database needs to move off of C01
: personas database needs to move off of C01
11/03/2009 @ 7pm
Product: Graveyard
Classification: Graveyard
Component: Server Operations (show other bugs)
: other
: All Other
: -- normal (vote)
: ---
Assigned To: Dave Miller [:justdave] (
: matthew zeier [:mrz]
Depends on:
  Show dependency treegraph
Reported: 2009-10-10 14:12 PDT by Dave Miller [:justdave] (
Modified: 2015-03-12 08:17 PDT (History)
2 users (show)
justdave: needs‑downtime+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Dave Miller [:justdave] ( 2009-10-10 14:12:29 PDT
The personas database is currently in the C01 cluster.  With the amount of attention marketing is giving this site lately, it really should have higher than a C-level SLA on it, not to mention being in a cluster with some measure of redundancy in place.

I'm not quite sure where to move it to, however...  In theory if we promote it to A-level it gets its own cluster with redundancy, which means a minimum of 3 new hardware machines to support it.  The database portion of personas doesn't use a lot of horsepower, though, so it might make sense to combine it with another A-level cluster.  The question then becomes which one?

The choices:  sfx, sumo, bouncer, amo, bugs

All of those sound like sites we wouldn't want to risk if personas gets buried...  and all of those are also pretty heavy DB users, making them a bad choice.  Maybe we should make a generic A01 cluster that can collect low-intensity sites that need the redundance?
Comment 1 User image matthew zeier [:mrz] 2009-10-10 15:25:34 PDT
I commented to justdave offline but will include it here.

I think you need to better understand how the db is used before knowing where to move it.  It's minimal access and primarily used for adding new Personas.  Traffic to this db is light (you should even be able to grab status off the current db server).

I'd argue that it doesn't need a dedicated master/slave cluster.

zandr should offer more insight.
Comment 2 User image Dave Miller [:justdave] ( 2009-10-10 20:00:56 PDT
I think I said that in my initial description, that it doesn't use a lot of horsepower, and probably ought to be combined with something else.  I'm just suggesting that we probably want the redundancy for it.
Comment 3 User image Dave Miller [:justdave] ( 2009-10-12 21:31:39 PDT
The winning idea at the moment seems to be to add a slave to the SFX cluster so that it's redundant, and then move this database there.
Comment 4 User image Dave Miller [:justdave] ( 2009-11-03 18:47:02 PST
OK, the plan continues to be to move it to the SFX cluster.  Still don't have the second slave there, but it'll still be better than where it is now (c01), and we can get the extra slave added later.

zandr/Toby: Need to know everywhere the database config is stored so we can get the configs fixed to point at the new DB while we're at it.
Comment 5 User image Dave Miller [:justdave] ( 2009-11-03 19:54:29 PST
ok, for future reference:


server/lib/personas_constants.php:6:if (!defined('PERSONAS_HOST')) { define('PERSONAS_HOST', ''); }

Everyplace else appears to pull it from one of those two places.

This is all done.

Note You need to log in before you can comment on or make changes to this bug.