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
March 2008 Update
March 29, 2008
One of the great things about the hosting solution that Onvertigo Bloggers is running on is the ability to make the changes necessary to keep the server running at its greatest efficiency and upgrade resources as they are needed. Since the launch of the service in January we have a spike in traffic and resources. In the month of March it looks like the server will have managed 350,000 hits from 60,000+ unique visitors without flinching. Part of this is because of the resources at our control and part of it was through some optimization. The interesting thing is that Onvertigo Bloggers is still an invitation only community and will remain that way as we get our growth strategy in place. In fact, we might leave it that way anyways
The latest change was managing our database solutions and have officially increased the number of databases serving up information from our blogs to 256. While this solution is maybe “over the top” right now, it may become essential down the road and like any project, looking at the end goals is necessary right from the start. Just the move from 1 database to 16 was an interesting move, but from 16 to 256 was even more interesting. If others want to run WPMU and expect growth, my suggestion is do the 256 from the start
There are many discussions out there on whether a VPS (virtual private server) has the resources to keep up with the demands of a blogging service versus a dedicated physical server. It seems to me that the power of the VPS that I am running could handle plenty of growth and while I could eventually move to a dedicated physical server, I am more likely to run a VPS cluster solution. Maybe move the database to one VPS and the file server to another. It is not something that is required now, but something we can look at down the road. Happy blogging!
Just A Reboot :)
March 17, 2008
As far as I could tell, no one was online, so I initiated a quick reboot of the server after applying some performance changes on the setup. Some of the server changes dealt with apache performance and some changes to the mySQL server setup.
Nothing too amazing, but just a few things to try and fine tune the service.
Trent Adams