A schema change inconsistency with Galera Cluster for MySQL

I recently worked on a case where one node of a Galera cluster had its schema desynchronized with the other nodes. And that was although Total Order Isolation method was in effect to perform the schema changes. Let’s see what happened.


For those of you who are not familiar with how Galera can perform schema changes, here is a short recap:

  • Two methods are available depending on the value of the wsrep_OSU_method setting. Both have benefits and drawbacks, it is not the main topic of this post.
  • With TOI (Total Order Isolation), a DDL statement is performed at the same point in the replication flow on all nodes, giving strong guarantees that the schema is always identical on all nodes.
  • With RSU (Rolling Schema Upgrade), a DDL statement is not replicated to the other nodes. Until the DDL statement has been executed on all nodes, the schema is not consistent everywhere (so you should be careful not to break replication).

You can look at the official document here.

If you read carefully the section on TOI, you will see that “[…] TOI transactions will never fail certification and are guaranteed to be executed.” But also that “The system replicates the TOI query before execution and there is no way to know whether it succeeds or fails. Thus, error checking on TOI queries is switched off.”

Confusing? Not really. It simply means that with TOI, a DDL statement will always pass certification. But if for some reason, the DDL statement fails on one of the nodes, it will not be rolled back on the other nodes. This opens the door for schema inconsistencies between nodes.

A test case

Let’s create a table on a 3-node Percona XtraDB Cluster 5.6 cluster and insert a few rows:

Then on node 3, let’s introduce a schema change on t that can make other schema changes fail:

As the schema change was done on node 3 with RSU, it is not replicated to the other nodes.

Now let’s try another schema change on node 1:

Apparently everything went well and indeed on node 1 and 2, we have the correct schema:

But on node 3, the statement failed so the schema has not been changed:

The error is visible in the error log of node 3:

But of course it is easy to miss. And then a simple INSERT can trigger a shutdown on node3:

will trigger this on node 3:


As on regular MySQL, schema changes are challenging with Galera. Some subtleties can create a lot of troubles if you are not aware of them. So before running DDL statement, make sure you fully understand how TOI and RSU methods work.

Share this post

Comments (8)

  • shawn

    Thanks for share, but i confused about how certification works

    could you introduce some articles?

    July 24, 2014 at 9:50 am
  • Stephane Combaudon


    A good place to start is the official documentation of Galera:

    July 25, 2014 at 4:39 am
  • burn

    I don’t understand. You said “Galera cluster had its schema desynchronized with the other nodes. And that was although Total Order Isolation method was in effect”. But in your example, you disable TOI. So which one is it? Does TOI guarantee consistency or not?

    August 26, 2015 at 9:48 pm
  • Stephane Combaudon

    @burn: right, this is confusing… TOI guarantees that a DDL is executed on all nodes at the same point in time. However Galera cannot check whether the DDL ran successfully on all nodes.

    So if for instance, you first desynchronize the schema under RSU (which is allowed and expected), forget about the change and then change the schema of the same table under TOI, the 2nd DDL may not be executed correctly on all nodes.

    Then you might think that TOI was not able to change the schema properly, while the real issue is somewhere else (schema change under RSU was not performed on all nodes).

    October 6, 2015 at 5:41 am
  • adityaanchuri

    @Stephane: When this happened, was the failed node able to come back up and get the old schema via an SST? I replicated this on a Galera cluster and noticed that the failing node deleted the DB and the table, but the other node kept the DB (even after an SST happened).

    February 23, 2016 at 12:59 am
  • Stephane Combaudon

    @adityaanchuri: in the case demoed in the post, you want to resync the failed node with an SST against a node that has the correct schema.

    February 24, 2016 at 6:14 am
  • Holger Thiel

    If it does not succeed on a few nodes:
    – Does the replication quit or continue?
    – Can you monitor this by the galera status (wsrep…)?

    June 7, 2016 at 5:55 am
  • Chris Bowen

    Is there any way to prevent this?

    I am having an issue where, in my 3 node system, some bad drupal SQL is causing the nodes to hang and eventually fail bringing down the cluster

    TOI is running on all the nodes, but since the failed SQL statement can go to any mysql server because of round robin all of them can fail.

    March 21, 2017 at 4:38 pm

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.