Setting InnoDB for tables breaks mysqlcluster/ndb replication

[Michael Renz]

Updating towards folsom breaks mysqlcluster/ndb replication because tables are created/altered to use InnoDB.

Neither MySQL replication or drbd/corosync are solutions, as the production cluster(s) span multiple node groups and datacenters and relies heavily on automated monitoring and orchestration.

This is a major bug as far as we are concerned as it will require manual intervention, major downtime and a partial re-architecture to resolve.

[Monty Taylor (mordred)]

I think if we add a nova config (because we clearly need another one) that will set the mysql engine used that is by default set to innodb, then it would allow us to force a default to innodb without removing your ability to override that.

[Michael Renz (mrenz)]

I agree. Anything besides a complete override.

I put this in openstack-core because we verified it in Nova, and suspect (but have not yet verified it) in other projects, keystone etc...

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/14718

[Stuart Stent (stuart-stent)]

Has this been Abandoned? This would help us a great deal in a production environment.

[Stuart Stent (stuart-stent)]

Has this been Abandoned? we really need this

[Michael Renz (mrenz)]

Doubleplus on this one. This really needs to get fixed. I don't know why I should be forced to use an active-backup database when I can easily set up an active-active database.

[Michael Renz (mrenz)]

Any word on this?

[Viktor Křivák (viktor-krivak)]

Can I ask where is the problem, when fixing this? I do some research and simply change engine to ndb isn't enough. Ndb doesn't support foreign keys. It mostly ignore it when table is created, but adding foreign key in table alter fail during bug in mysql. That is why you need also disable foreign keys. At this moment I usually manually edit migration files in nova, but I think it is possible to make patch from this modification. Problem is this patch affected all migration back in history and it is kind a ugly. Is there rules (best practices) describe when I can do that?

[Jay Pipes (jaypipes)]

I have pinged Monty on this to see if he is still doing anything with this bug. IMHO, Nova has not supported NdbCluster for at least 4 release cycles now, as we rely heavily on foreign key relations. I am not confident that there is any support in the community to fix this particular issue at this time, and would recommend setting the status to Won't Fix.