Database upgrade - maintenance scheduled

by Gabrys on 25 Feb 2011 12:26


On Monday, 28th February 2011, between 9:00 and 9:30 AM UTC a maintenance of Wikidot service is planned.

We will upgrade database software (to PostgreSQL 9.0) and hardware. The planned down-time is no more than 5 minutes. The upgrade should improve both performance and stability for our backend services.

The new hardware features twice as much SSD disks (in ravishingly fast RAID-0 configuration), twice as much RAM and twice as much CPU power. This is a massive upgrade and we expect the database to literally gain super-powers. The disk read/write speed is astonishing 800/480 MB/s accordingly!

The PostgreSQL upgrade was planned a few months ago and its main purpose is to enable maintenance-free replication. It simplifies administrative tasks (such as altering database schema) that require complex manual procedures when using other replication tools. Also setting up replication and adding more database replicas are simpler tasks. This makes the data safer as the system is less prone to human mistake.

Maintenance and upgrades to Wikidot's backbone are usually transparent to our users, because there are no interface changes or new features introduced, but all these behind-the-scene operations are critical for day-to-day operation, and are reflected in overall Wikidot stability and reliability, which we are very proud of.

The photo comes from Flickr

UPDATE: the upgrade is done. Wikidot was not writable for about 10 minutes. This was not planned and due to our mistake. The problem was the sequences were not replicated so no new records could be saved into the database. Everything should work well now. Just a note: using the new replication, the whole database (including schema, table data, indexes and sequences) is replicated so this scenario should never happen again.

UPDATE2: Due to the upgrade, the "create account" code stopped working. We will fix the problem soon :-).

UPDATE3: Account creation works now. This was due to PostgreSQL change in representing values of bytea type. The solution was to tweak the configuration file of PostgreSQL to work as previously.

Comments: 7

Add a New Comment