200th blog post!

It’s taken over a year but my blog has now reached its 200th post. As a special celebration, I’m making the 200th posting all about the great event itself. This includes a special photo of me writing the 200th post itself:

To commemorate this achievement I may also be going to the pub later.

David Blunkett resignation statement

David Blunkett has just released the following statement regarding his
resignation

…… … . …. . ….. . . . . …. … .
….. ……. . …… . …. .. . …… ….. . …… .
.. . ……… .. . . ….. … …….. .. …….. .. … .
…. .. …. … .. …. .. . . . ….. .. . … . … ….
.. . …. . . . . . . … . … . . . . . . . . . .. …. . .
… . . .. . ….. … . …. . ….. . . . . …. … . . .
… ……. . …… . …. .. . …… ….. . …… . . .
………. .. . . ….. . …….. .. …….. ….. . .
.. .. …. … .. …. .. . . . ….. .. . … . …

Alter tables with MySQL replication

I couldn’t find anything particularly useful about how to alter MySQL table structure in a situation where replication was being performed so I pretty much had to try something out to see if it worked.

What I found was that MySQL was remarkably clever at replicating changes through from one database to another. I don’t know whether just running a straight ‘ALTER TABLE’ command would work or not but I took the added precaution of running a ‘STOP SLAVE’ command (on the slave) first. Then, once the new column had been added to the master, running ‘START SLAVE’ kicked it off and the database automatically picked up where it had left off by propagating the table alteration and then updating the data.

Replication in MySQL from the manual