Comments on: KISS KISS KISS

By: Mark Callaghan

Mark Callaghan — Wed, 04 Mar 2009 00:22:15 +0000

This is great advice, although perhaps bad for me. Overly complex deployments create more interesting problems to solve. One other point that relates to scalability is that many (most?) systems have a lot of spare capacity waiting to be discovered as soon as they deploy the user_stats patch from Percona/Google. With that in place it is common to find a lot of unexpected load and then query logging or SHOW PROCESSLIST sampling can be used to find the problem queries.

By: benpi

benpi — Sun, 01 Mar 2009 18:27:14 +0000

@peter: you made a case for design “robust simplicity” there

@Matthew
I’m not sure to understand the worklog implicit consequences very well, so unsure about the functionality coverage; but it seems to be a very useful proposal even for what it explicitly states.

The worklog’s description wording focuses on addressing serializability and isolation problems with concurrent accesses while performing DDL, through proper locking. Is deferring the release of metadata locks up to an explicit commit/rollback enough to get rid of DDL auto commits (ie. does this implicitly means that the schema changes can actually be rolled back, or is it just a first step)?

By: peter

peter — Sun, 01 Mar 2009 17:11:14 +0000

benpi,

Right. You can do MySQL/hardware/OS upgrades this way, schema changes or table maintainance virtually without downtime. Transactional DDL would be nice though so far it can’t be solved on just storage engine lawyer (hence can’t be added just to XtraDB).

By: Matthew Montgomery

Matthew Montgomery — Sun, 01 Mar 2009 15:07:38 +0000

@benpi

There is a worklog in progress and targeted at 6.0 covering transactional DDL locking.
http://forge.mysql.com/worklog/task.php?id=4284

High and low level descriptions of this worklog briefly discuss ROLLBACK and SAVEPOINT handling.

Please review this worklog and comment on it if it is missing the sort of functionality you are expecting.

By: Arjen Lentz

Arjen Lentz — Sun, 01 Mar 2009 13:52:37 +0000

Complexity often causes trouble. But simplicity should not be confused with “lack of good design” – and I’m not saying “proper design” as dogma rarely helps. It’s very important to learn why some “rules” (guidelines) exist, so you know when to break them! This is what we teach in our classes, and it’s oh so useful.

Another thing to steer clear of is marketing hype… a company plugging the latest and greatest fancy technology or tool.

By: benpi

benpi — Sun, 01 Mar 2009 12:41:48 +0000

Thanks for this post; having a top notch expert writing we can point to will help fighting those “overdesigning hubris” moments we all have, for sure

“Master-Master which you typically want for high availability and online schema changes.”

Ahh, thanks for this tip, I never thought to address this problem that way. I guess you mean something like, along the lines: remove one master from being accessed by applications, stop slave on the remaining, busy one, make schema change on the non busy server, when everything is done, exchange the roles of the servers (ex. non-busy become worker) and wait for the other server to catch up schema changes. Is it this?

By the way, something that makes planning such a solution very useful with MySQL, despite complexity (and even when the schema change is expected to be fast and resources friendly, without large index creations) is the problem with InnoDB schema changes being not ACID compliant. This dangerous lack of feature is often overlooked in my small experience; I remember a Zarafa (a MySQL based Exchange like) upgrade which, after quite a few schema changes bundled in a theoretical transaction, did failed to had a constraint (because of database content) and desperately tried to rollback the whole changeset (bummer! all corporate emails made inaccessible!). So for now we have to circumvent this problem with some infrastructure complexity. Having rollbackable ALTERs, like PostgreSQL already supports, would be quite an improvement for MySQL/InnoDB. Is this totally impossible? are there plans like this for XtraDB (wouldn’t that be a killer feature)?

By: James Byers

James Byers — Sun, 01 Mar 2009 08:33:25 +0000

This is great advice for startups. The key is to evolve from simplicity to complexity based on proven rather than imagined needs. Few startups warrant complex distributed database systems; this engineering time is better spent building something their customers want.

Aside from advice on exotic MySQL configurations, there seems to be a new column-oriented or distributed key-value database project launching every month. I’m afraid this will be the exotic configuration of the next few years, where startups spend lots of time building systems that will scale to the billions of records they’ll never have to store.