Joining Continuent

I’ve just completed my first month here at Continuent, strangely back into the MySQL ecosystem which I have been working in for some time before I joined CouchOne, and then Couchbase, two and half years ago. Making the move back to MySQL is both an experience, and somehow, comfortable…

Continuent produce technology that makes for easier replication between MySQL servers and, more importantly, more flexible solutions when you need to scale out by providing connector and management functionality for your MySQL cluster. That means that you can easily backup, add slaves, and create complex replication scenarios such as multi-master, and even multiple-site, multiple-master topologies. This functionality is split over two products, Continuent Tungsten, which is the cluster management product, and the open source Tungsten Replicator, which provides the basic replication functionality.

Those who know me well will know that I am no fan of the native MySQL replication, and that’s almost entirely because of the complexities of first of all getting it to work, followed by keeping it working, and ultimately because of the variability of the replication in the first place. There’s no reliable way to know if the replication stream has successfully been applied to the slaves or, from a client perspective, how far behind slaves are so that you can make an educated guess about which slave you should be talking to. Let’s not even get into the complexities of having to handle the read/write splitting required to make the master/slave relationship work in the first place.

Continuent solves this problem by using the binary log stream from MySQL, but handling the transfer and application of those bin log entries. Using this method enables Continuent to monitor and manage the replication process. Continuent knows when a statement has been applied to a slave, and it can work to ensure that the application of the changes is applied. With Continuent Tungsten, we go a stage further and provide a connector that sits between your application servers and your MySQL servers. Because Continuent Tungsten handles the replication, it knows the cluster topology, and can redirect queries to the master or the slave, and handle failures by directing the client queries to working slaves. Like all good software, it’s simple, but very very effective, and ergo very powerful.

So what am I doing at Continuent? Building out the documentation and helping users to help themselves, in combination with working with the developers to make sure that the software is as easy, intuitive, and foolproof to use as possible. In the short term, that means ensuring we have the core documentation required to get Continuent working for you.

If there’s more information you need, or something you specifically want in the documentation, let me know.

UC2009: On the Starting Blocks

Despite an annoying 3 hour flight delay from Heathrow (and no, I wasn’t connecting there, I was leaving from there), I’m here in San Francisco and Santa Clara again ready for the MySQL User Conference 2009.I obviously have my four presentations to get through, and there will be plenty of other stuff going on at the conference both in terms of other presentations, the show floor, the booths, and the Birds of a Feather sessions (which are terrific fun). But mostly, I see the UC2009 as the best opportunity to meet up with both other MySQL/Sun people, our customers, and the community at large and talk about the thing we are all passionate about – MySQL and the technologies surrounding it. And I don’t care if that sounds goofy. Nothing beats talking to face to face with like minded individuals, and one thing that MySQL – and Sun – seems to engender is an extreme passion about the products we deliver that I don’t always see in other products or companies. That means the talk is always interesting and intelligent, and, when it needs to be, good fun.To anybody attending, welcome to the fun and enjoy the experience. To those not coming, you really are missing something.

MySQL Conf 2009 Preview: Scalability and HA Tutorial

Like most people, and with just over a week to go before the conference, I’m putting the finishing touchs on my various presentations. First up for me, on Monday afternoon, is my tutorial: Scale Up, Scale Out, and High Availability: Solutions and Combinations. What will be doing? Very simply: Looking at every potential solution for maximum scalability and availability for your database environment. If you are attending, be prepared to:

  • Expand your mind as we think about scaling up.
  • Expand your horizons as we think about scaling out.
  • Divide and conquer, as we think about high-availability.

We’re not not hands on in this session – but I will expect you to be brains on!

Diarizing – what goes around, comes around

OK, so I’ve just written about my love of Moleskines and it occurs to me that today’s bloggers (myself included) are just continuing a long tradition for some people to share their experiences. I write my memories in my Moleskines, not on a day to day basis, but whenever anything significant is happening in my life, or when I’m traveling about the world for business or pleasure, and for me that’s a vital part of me recording my memories, despite my otherwise excellent recollection skills. Hundreds of years ago Samuel Pepys and many others did the same thing – diarized what was going on in their lives and the world around them, and it became part of the content that records our world history. I know not every blog is that interesting (my own including), but as the title says, what goes around, comes around – we are just carrying on the tradition of those great diarists that came before us.

I love my Moleskine

Not remotely related to computing at all, but I’ve just been updating my diaries, and I use Moleskine. I go everywhere with a Moleskine of some description (they’ve recently released some really tiny notebooks, which make it easier to carry your life around with you). Despite having computers, organization tools, and email, there is something decidedly comforting about writing, by hand, into a physical notebook. Of course, you write in pencil so that the contents don’t smudge, and somehow that just feels even better.

MySQL on Solaris Best Practices Presentation

A couple of weeks ago I was at the MySQL European Customer Conference in London, where I was presenting my talk on deploying MySQL on Solaris best practices. You can download a copy of the presentation here: MySQL on Solaris Best Practices. I cover both choosing the best release version, using tricks like mtmalloc (the threaded malloc library) before moving on to UFS and ZFS tricks, using DTrace and MySQL Cluster and Sun Cluster.

MySQL Documentation Myths

There are a few myths surrounding the MySQL documentation and how it works, and I thought I’d try and dispel some of those myths if I can. If you have any more questions or misunderstandings you want clarified, let me know. Myth:

MySQL Documentation is written by the developers.


MySQL Documentation is written by a dedicated team of writers with help and input from the developers. There are four main writers, Paul DuBois, Tony Bedford, Jon Stephens, and MC Brown (me!), plus our Team Lead, Stefan Hinz. All the documentation staff are employed full time for the sole purpose of writing documentation. Sure, some of us get involved in other things too, but that’s basically the nature of the job. Some of us simply cannot help ourselves.


Docs team members are just writers and have no technical expertise.


It’s tempting to come back with a rude response to this one, but it is a comment I heard from someone at a conference. The reality is that all of us have some technical background, unsurprisingly often with MySQL. Some of us have expertise elsewhere too. Speaking only for myself, go look at for more info. If you want details, feel free to ask, but know that this myth is definitely busted.


The documentation is updated very rarely.


Our main tree, mysqldoc, is publicly available, and if you want to go view the commits to that tree, please feel free. It doesn’t take much to see that we commit to that tree all day, and every time we change something, the documentation gets rebuilt. How frequently? Well, on a typical day we will generate 10-15 new versions of each reference manual. It’s actually difficult to rebuild more frequently than that due to the sheer size of the documentation. If you want to check the build date of the documentation, check the intro/preface of each document. The build and build date information is included there.


The MySQL documentation is small and unused.


You’d be amazed how many people need to be told RTFM, but a surprising number of people who criticize the MySQL documentation have actually never read it, or, they looked at it years ago and haven’t bothered to look recently because they couldn’t find what they were looking for before.The reality is that our documentation is over 2000 pages per reference manual, which means over 10,000 pages now just for MySQL. There are hundreds more pages on the GUI tools, Workbench, Cluster/NDBAPI, and the Enterprise Monitor.As to the popularity, the hits to the online pages of our manual exceed the hits to every other section of the MySQL website by a significant factor. For the downloadable formats we get an average of 200,000 downloads in all the various formats each month, with occasional spikes up to 800,000. For the online manuals, the documentation pages make up about 45% of all the traffic on Or to say it another way, we account for almost half of all the web traffic that MySQL receives, including downloads. In short, we have no shortage of interested readers.


Docs team don’t read comments


Actually, we all get an email each time you post a comment and all of us will read it, determine whether it is suitable, useful, or (occasionally) spam, and either ignore it, delete it, or comment on it accordingly. Often that will happen within minutes of your leaving the comment. If there’s a non-standard reply to your comment, you’ll get that too. Now, we are aware that the comments system has it’s faults. For one, we have one comment system for all the different versions of the manual, which means comments can be confusing and even misleading. We’re fixing that. We’re also trying to address the problem that some comments are really tips, while others are just plain comments and observations. Any other comments or criticisms, let us know. We may not be unaware of the problem, but if we know your pain we can do something about it.


Docs team don’t accept bugs or corrections


You can report a bug or correction to us using the standard, or drop us an email to


Docs are ‘closed source’


The docs are not closed source – you can download the DocBook XML and the files and tools required to build them (well, beyond the XML parsers, Perl, and other bits and pieces). You can get hold of the repos (via SVN), on the Tech Resources page. That said, we don’t allow anybody to commit changes, but see the response above for information on how to provide changes and fixes. Again this is something we are working to improve on.


MySQL Documentation is not distributable


This mostly comes out of the fuss around Debian dropping the man pages from their MySQL distributions You can see the description why here: MySQL Documentation and Debian/Ubuntu. The short answer is that it is a mis-understanding in our license for the documentation, which is not released under the same license as MySQL. You can provide documentation if you provide MySQL, but not on it’s own. The reason for this is that our documentation is updated so regularly that we want to ensure that we only get genuine, up to date, versions of our documentation out there. Trust me, do a search for MySQL and some term and you will find versions of the manual that are months, or even years out of date, which is no help to anybody. It’s about trying to make our documentation readable and usable and not misleading.

OK that’s enough myths busted today, but if you hear any more, or just have additional questions, feel free to ask.