Database Redundancy
April 26, 2008
We are happy to use Media Temple as our main server as it gives the easy ability to upgrade and downgrade resources as they are needed. With the service getting an increasing amount of pageviews and some of the process and memory intensive upgrades we are planning, it makes sense to have the system in place. The system is currently running with dedicated 1 gig of RAM and in a position to be a real work horse.
Offloading backups is done onto another service and that is working really well. Data integrity and backups are the cornerstone of confidence both for myself and the users of this service. We are always trying to get better. That is why we have another server with SliceHost that we are using to implement our next strategy with database redundancy. This will be done with a master/slave database relationship.
Essentially, the master database server still deals with all the entries, comments and other posts that are made on the service or “writes of new data”. The slave database server just syncs itself with the master so that it always has an up-to-date version of all data. This allows us to load balance the database between the two servers as requests from the general public viewing sites can be setup to come from either database server.
This is the setup that we are going to implement by using a dedicated “database only” server on Slicehost. This setup will also allow us to make backups off the slave database server without disrupting anyone on the service as all writes still will go to the master database server. Summing up, this allows us to backup the data more frequently 
Another thing we are considering will be creating a duel master redundancy plan so if the master (all “writes”) database server does go down, the slave server can take over as the master and when the original database server comes back online it adjusts to become the slave. Little more complicated, but worth it.
The interesting thing to me as the system administrator and the one paying for all of this is that implementing this system will actually make the monthly costs go down! Instead of having to have 1 large server to have the resources to cover the bottlenecks, it is cheaper to have several smaller servers working on specific tasks. That is why we will stick with our Media Temple server (which we can downgrade) and use smaller Slicehost servers to more than pick up the slack!
Some might ask if this is a little “overboard” for such a small service that is in “beta” right now and not entirely public. Believe me, once we release the rest of the service plans we have coming up, it is
Comments
No Responses to “Database Redundancy”
Got something to say?
Trent Adams
After playing around with “slicehost”, we decided that it might be an easier transition to start up our replication on another Media Temple server. While slicehost is a great host and a small amount cheaper, our administration, support, security and consistency with another (dv) server is the better fit. It will take a bit more time before we implement our solutions, but we are looking forward to the changes!
Quicker than expected we have this working now with our database redundancy now on another (dv) server at Media Temple. It is working great!