Transactional DDL workflow for MySQL

Question

I was a little surprised to discover that DDL statements (alter table, create index etc) implicitly commit the current transaction in MySQL. Coming fr

Answer 1

DDL statements cause an implicit commit and there is nothing you can do about it. There is no way to stop this behaviour.

Which DDL statements have this behaviour changes over time so you need to check for your version.

5.1 http://dev.mysql.com/doc/refman/5.1/en/implicit-commit.html
5.5 http://dev.mysql.com/doc/refman/5.5/en/implicit-commit.html
5.6 http://dev.mysql.com/doc/refman/5.6/en/implicit-commit.html

When we are just extending the schema, new tables/columns/views/procs/etc, that will not affect existing code then automation is OK, just check for errors and fix them.

When they will affect existing code then you need to devise a strategy on a case by case basis. Since there is no rollback you need your own backout plan and you need to test it thoroughly.

Since it is case-by-case there is not a lot that I can offer in the way of help for your particular situation.

Answer 2

One possibility is doing DDL changes in a non-destructive-manner, which would include:

• split logic in DDL/DCL (+1 to reverse all) and DML
• run only the DDL/DCL script adding columns, new tables, ..
• depending on result:
  • on success, apply the DML changes,
  • on fail, apply reverse DDL/DCL script removing the stuff you wanted to add in second step (obviously with some errors "does not exist" depending on how far step 1 got)
• remove what is not needed anymore, drop old columns/tables