Tag Archives: MySQL

continuent

Developing Applications for use with Continuent Tungsten and Tungsten Replicator in SDJ

I’ve just had a new article published with the Software Developers Journal talking about how you can write applications to take full advantage of Continuent Tungsten and Tungsten Replicator.

As a developer of an application there really isn’t a problem better than finding that you have to scale up the application and the database that supports it to handle the increased load. The main bottleneck to most expansion is the database server and in many modern environments that replication is based around MySQL. Application servers are easy to add on to the front-end of your environment.

Read: Qt5 – How to Become a Professional Developer- RELEASED | News | Magazine for software developers, programmers and designers – Software Developers Journal (registration/purchase required)


Coalface, continuent, tungsten

Percona Live 2013, MySQL, Continuent and an ever-healthy Ecosystem

I’m sitting here in the lounge at SFO thinking back on the last week, the majority of which has been spent meeting my new workmates and attending the Percona MySQL conference.

For me it has been as much of a family reunion as it has been about seeing the wonderful things going on in MySQL.

Having joined Continuent last month after an ‘absence’ in NoSQL land of almost 2.5 years, joining the MySQL community again just felt like coming home after a long absence. And that’s no bad thing. On a very personal level it was great to see so many of my old friends, many of whom were not only pleased to see me, but pleased to see me working back in the MySQL fold. Evidently many people think this is where I belong.

What was great to see is that the MySQL community is alive and well. Percona may be the drivers behind the annual MySQL conference that we have come to know, but behind the name on the passes and over the doors, nothing has changed in terms of the passion behind the core of the project.

Additionally, it’s great to see that despite all of the potential issues and tragedies that were predicted when Oracle took over the reins of MySQL, as Baron says, they are in fact driving and pushing the project forward. The features in 5.6 are impressive and useful, rather than just a blanket cycling of the numbers. I haven’t had the time to look at 5.7, but I doubt it is just an annual increment either. When I left Oracle, people were predicting MySQL would be dead in two years as an active project at Oracle, but in fact what seems to have happened is that the community has rallied round it and Oracle have seen the value and expertly steered it forward.

It’s also interesting to me – as someone who moved outside the MySQL fold – to note that other databases haven’t really supplanted the core of the MySQL foothold. Robert Hodge’s Keynote discussed that in more depth, and I see no reason to disagree with him.

I’m pleased to see that my good friend Giuseppe had his MySQL Sandbox when application of the year 2013 – not soon enough in my eyes, given that as a solution for running MySQL it has been out there for more years than I care to remember.

I’m also delighted of course that Continuent won Corporate contributor of the year. One of the reasons I joined the company is because I liked what they were doing. Replication in MySQL is unnecessarily hard, particularly when you get more than one master, or want to do clever things with topologies beyond the standard master/slave. I used Federated tables to do it years ago, but Tungsten makes the whole process easier.  What Continuent does is provide an alternative to MySQL native replication which is not only more flexible, but also fundamentally very simple. In my experience, simple ideas are always very powerful, because their simplicity makes them easy to adapt, adopt and add to.

Of course, Continuent aren’t the only company producing alternatives for clustering solutions with MySQL, but to me that shows there is a healthy ecosystem willing to build solutions around the powerful product at the centre. It’s one thing to choose an entirely different database product, but another to use the same product with one or more tools that produces an overall better solution to the problem. *AMP solutions haven’t gone away, we’ve just extended and expanded on top of them. That must mean that MySQL is just as powerful and healthy a core product as it ever was.

That’s my key takeaway from this conference – MySQL is alive and well, and the ecosystem it produced is as organic and thriving as it ever has been, and I’m happy to be back in the middle of that.


Coalface, continuent

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.

Coalface, couchbase, nosql

Moving from MySQL to Couchbase

Before moving to Couchbase and working with NoSQL technology I had for years been a MySQL user. Making that leap from MySQL to NoSQL requires a number of changes, not least of which to the way you structure your data and then query it. 

I’ve tried to distil the first part of that process down into a simpler form and steps in a new blog post oat the Couchbase blog http://blog.couchbase.com/how-move-mysql-couchbase-server-20-part-1


Uncategorized

Moving from MySQL to CouchDB: Part 1

I’ve started a little series on how to migrate your MySQL applications and databases over to CouchDB. Most of the process is about how you think about your data, not about the database itself, the application, or the interface to the database storage. There are some use cases for data storage that lend themselves to the CouchDB document model that provides some advantages over the table-based structure in MySQL.

The first part of the series is Moving from MySQL to CouchDB: Part 1.

Uncategorized

Left MySQL/Joined CouchOne

For many people this will be old news, but I guess It thought I should put up something official.

At the end of September, I left MySQL/Sun/Oracle – that wasn’t an easy decision, mostly because I loved my job. It’s difficult to stop doing something that you enjoy so thoroughly and, over the years, have been so involved in. I did more than just get involved in the docs, I helped out with advice for different departments, worked on areas like DTrace, and of course helped write the documentation and enhanced many of the tools that enabled us to build such brilliant documentation. I managed to work with some amazing people, most of all the rest of my team who worked so hard to produce the manuals and content.

The impetus to leave came from an opportunity to work with another excellent team on a different database, namely CouchDB. CouchDB reminds me of my early database work working on freeform text databases, with a nice open and easy structure, but with ways of getting standardized information out.

I’ve joined CouchOne as Vice President of Documentation. The core of that is building an entirely new suite of documentation, starting from the ground up with everything from the build environment for the docs, to the content itself. Longer term there are lots of other things we are working on, but it will hang off that core reference documentation.

Uncategorized

Reorganizing the documentation

Those of you that know the documentation well will be aware of the old page we used to have for the MySQL documentation. It was huge, and over the years we’d done a number of things to try and improve the layout and make it easier to find what you wanted. We had in-age links to jump to the different documentation types, and the old topic table that allowed you to jump to specific parts of the documentation.

The problem was that the more documentation that we produced (and there are over a thousand docs in various formats now), the bigger the page got. When we added the individual topic guides, for example, we trebled the size of the page by adding the links for each individual topic guide.

Ultimately that makes it increasingly difficult for you guys to find what you are looking for, despite the quick links and other elements.

We’ve now changed all this and split the single, big, monolithic page of *every* piece of documentation that we create, and instead spread the documentation out over a number of pages. The actual documentation itself remains the same, and we still have the same range of documentation (in fact, it’s increased slightly as I’ve been able to squeeze in a few more formats and topic guide docs), but everything is still there.

The key is the new sub-navigation bar that the Web team have provided us with:

The pages have been split out as follows:

  • MySQL Manual — the full, complete reference manuals
  • Workbench — the Workbench manuals
  • Expert Guides — the standalone guides for some of our more detailed products and system such as the Falcon storage engine and the MySQL Test Framework
  • Topic Guides — the topic reference, with the topic table at the top providing direct links into the 5.1 manual or standalone guides, and the full list of downloadable standalone guides.
  • MySQL Cluster — the full cluster manuals, including the guide to the MySQL Cluster API (NDBAPI)
  • Other docs — other documentation, not already mentioned, including the sample databases (Sakila, World, Employee), the help tables you can import into MySQL, and printed material and links elsewhere.
  • MySQL Uni — a page about the MySQL University, which is run by the documentation team, and which provides links to the MySQL Uni pages on Forge
  • About — information about the documentation team, who we are, and some statistics on the documentation we produce
  • Archives — archives of older manuals

We are aware of a few issues with some of the links to some documentation, and I’m working right now to address those problems, but all the documentation should be there and available. If it isn’t, please report a Bug.

Uncategorized

Adding Workflows to the Installation Guides

One of the elements that I have wanted to add to the installation chapter for some time has been some flowcharts to make understanding the steps required to successfully complete an installation on various platforms.

The Windows one is the most interesting, because not only do we have the installer, but we also have the MySQL Server Instance Config Wizard which has its own sequence of steps to configure an instance of the server.

I’m still working out and refining the examples and the graphics, but here is an example of the config wizard output:
win-msi-remove-autosvg

Hopefully the full suite of images will be in the documentation shortly – all comments and input welcome.

Uncategorized

Rebuilding the installation chapter

We have lots of things on the go right now (over and above the normal process of keeping things up to date), and one of the main projects for me is to do a complete rebuild of the installation chapter (Installing and Upgrading MySQL). I’ll be starting with the 5.1 manual, then the 5.4 manual. Any future manuals should be based on these so we should be up to date for future generations.

What I’m doing:

  • Re-structuring the chapter to make it easier to follow on a platform basis. The old structure mixed content for different binary and source types, and different platforms, across a number of sections, making it very difficult to follow the instructions for your chosen platform.
  • Make some things generic. There are sections which are generic and apply to all (or at least many) different installation types.
  • Make some things more specific. Equally, there are some things that need to be spelled out more uniquely.
  • Remove some old, old, advice. We have notes in there going back 10 years or more. Among the favorite examples I’ve found is a piece of advice that says ‘If your machine has more than 16MB of RAM…’. These things are not helpful in the manual, and may just serve to confuse some people.
  • Remove some older platforms. Some of the platforms and advice go back and predate MySQL 5.1, and even MySQL 5.0 and 4.1. In many cases the OS information is for a system either no longer actively developed or supported (FreeBSD 3.x, or Solaris 2.5, for example). Again, we want to remove some ambiguous and potentially confusing information and advice here for platforms which we simply can no longer monitor.
  • Make it easier to keep up to date. The problem with the old organic structure is that knowing where to add new content, improvements, extensions, etc. becomes harder and harder. by merging and unifying the structure we will improve this, and in turn, improve the ability to find information.

In practice that means for at least the next month or so you will see a number of improvements and restructuring in the installation chapter for 5.1 and later manuals.

I already have a list of about 35 items that need to be addressed, over and above the list above, but feel free to provide any additional suggestions and I’ll see what I can do to fit them in.