This wiki is a XML full dump clone of "Heroes Wiki", the main wiki about the Heroes saga that has been shut down permanently since June 1, 2020. The purpose of this wiki is to keep online an exhaustive and accurate database about the franchise.

User:Admin/Journal

From Heroes Wiki
Revision as of 04:40, 9 August 2007 by imported>Admin (journal entry for server migration)
Jump to navigation Jump to search

Journal of a Wiki Administrator

This page is just a place for me to discuss some of the more interesting topics that come up from time to time administering a wiki like Heroes Wiki.

Hosting

One advantage of owning your own web hosting company is that it's easy to find a place to host a site like Heroes Wiki. Another advantage is that being in charge of the technical operations I'm not constrained by any third-parties and can pretty much do whatever I need to do to make something work. Compare this to other hosting companies where you might be restricted to using a certain version of PHP or MySQL or where you don't have full control over the http server configuration. It's hard to say whether this advantage resulted in any real benefit. If we'd been restricted to MySQL 4.1 or PHP4 for instance we'd have to run a much older version of MediaWiki. Being able to run the latest software did allow us to keep up with the latest MediaWiki features. Once again, probably didn't make much of a difference but it was nice anyway. Up until June 2007 Heroes Wiki was running on the same server as a bunch of other sites we host. As the wiki became more popular I'd notice that we had a harder time keeping up with the traffic (specifically on Monday night and Tuesday following a new episode). This necessitated the addition of APC, a PHP caching module, since the primary load was being caused by PHP needing to interpret each PHP request on the fly. Had I not had control over Apache it might have been impossible or very difficult to get APC added in a timely fashion. Even with this flexibility it was a little tricky since I was running different versions of PHP concurrently on that one server, but it was accomplished relatively quickly and the wiki soon became much more responsive even during periods of high activity. So in the end the flexibility of managing my own server was instrumental in keeping up with the demands of the wiki.

Moving to a new server

Background

By the time June 2007 came around I decided it was time to move Heroes Wiki off of a shared hosting server and onto a more powerful, dedicated server. There were a few reasons for this. For starters it was becoming ever trickier to cleanly maintain separate versions of PHP and MySQL on the same server. Heroes Wiki was using the newer versions of both software and I had to ensure that any changes to either piece of software didn't impact the older versions that were being used by other websites hosted on the same server. A few times, for instance, a PHP update would clobber some config settings used by the older version and a few sites would run into problems. Then adding APC for PHP caching was trickier because I had to perform some steps manually to ensure it was compiled against the version of PHP being used for Heroes Wiki and not the older one being used for the other sites. Secondly the shared hosting server was running an OS that's getting a little old so it was lacking some of the convenient features in the newer releases that would help me add features more quickly. Third, Heroes Wiki is continually growing so I knew that eventually it would outgrow the server (which is a few years old already). By purchasing a new powerful server I could ensure that we'd be set for some time.

Preparation

If I was going to move the wiki onto a new server, it was important to me to minimize the downtime as much as possible. I often see sites that migrate to a new server being down for hours (and sometimes even days!) Perhaps it's because I manage servers for a living, but I find downtime to be distasteful. Fortunately I know to transparently migrate services to new servers since I do it for work every so often. One of the first tasks was to get the database copied over to and running on the new server. Late one night I just switched the wiki into read-only mode and performed a MySQL database dump on the wiki database. This didn't take too long and the wiki was then switched back into read-write mode. Most people wouldn't have even known unless they tried to edit a page during that brief window. Once the dump was imported on the new server I configured MySQL replication so that any changes to the database on the old server would be immediately replicated over to the new server. Ok, database taken care of. So an rsync of the site from the old server established a base copy of the wiki on the new server. Also fortunately I was already utilizing Squid on the front end on the old server and redirecting it to Apache on the same server. This meant that once I wanted to actually perform the switch to the new server all I technically needed to do was repoint Squid to the new Apache server. Squid was primarily responsible for the transparancy of the migration.

Switchover

When the time came for the switchover I pointed Squid to the new server first and then changed DNS for the wiki to point to the new server. This way anyone still using cached DNS info would go to the old server, but Squid would transparently redirect them to the new server. Anyone getting new DNS info would just go right to the new server. For added safety I put the wiki into read-only mode beforehand to give me time to safely perform one last rsync of the site and make the required config changes, but like before this only took a couple minutes at most and the wiki was still accessible the whole time. Clean, professional migration... just what I wanted.