List:Internals« Previous MessageNext Message »
From:Rich Prohaska Date:August 31 2012 5:17pm
Subject:Schema inconsistency after inplace alter table in MySQL 5.6.6-m9
View as plain text  
Hello,

TokuDB supports inplace alter table operations including inplace
column addition. While implementing this feature on MySQL 5.6 we
encountered a schema inconsistency problem that occurs if mysqld
crashes in the right place during an inplace alter table operation
(described below).  We uses the FRM discovery mechanism to resync
MySQL's view of the schema with the TokuDB view of the schema.  We
also implemented FRM discovery in the partition storage engine.  If
MySQL made the FRM rename operation transactional, then there would be
no need to synchronize the schema with the discovery mechanism.

Here are some details. Suppose that one has a simple table:

    create table t (a int primary key);

and one adds a new column to the table:

    alter table t add column b int;

If mysqld crashes after the inplace alter operation is committed and
the table is closed but before the new FRM file is renamed, then when
mysqld comes up after the crash, the table schema described by the FRM
(the old FRM) is inconsistent with the engine's schema since the new
schema was committed.

TokuDB uses FRM discovery to resync the FRM schema with the engine's
view of the schema.

Now, suppose that one has a partitioned table:

    create table t (a int primary key) partition by...

and one adds a new column to the table:

    alter table t add column b int;

If mysqld crashes during the alter table operation, the table schema
described by the old FRM is inconsistent with the engines' schema.  If
the partition storage engine supported FRM discovery, then the
inconsistency could be resolved.  Unfortunately, it does not.

Just for fun, we implemented FRM discovery in the partition storage
engine.  It retrieves the FRM from the engine (if possible) and
returns it.

The problem with inplace alter table operations isthat  the rename of
the FRM schema is not transactional.  Are there any plans to address
this?
Thread
Schema inconsistency after inplace alter table in MySQL 5.6.6-m9Rich Prohaska31 Aug
  • Re: Schema inconsistency after inplace alter table in MySQL 5.6.6-m9Dmitry Lenev12 Sep
    • Re: Schema inconsistency after inplace alter table in MySQL 5.6.6-m9Rich Prohaska12 Sep
      • Re: Schema inconsistency after inplace alter table in MySQL 5.6.6-m9Dmitry Lenev12 Sep