Brian Aker wrote:
Hi!
In working on replication I end up in our transaction code. Today DDL
causes whatever transaction that is in play to commit.
Is this really a good behavior?
No. If an engine supports transactional DDL, there is no reason to
artificially inhibit this in the kernel.
I am looking at cleaning up the API so that an engine will be able to do
transactional DDL (assuming it can handle it). This piece of behavior is
going to cause this to become... messy.
Your statement is confusing. *What* will become messy? The replication
code? The handler code? Something else?
Should we toss an error on DDL if the engine does support it
transactionally?
Did you mean "does *not* support it transactionally"?
> Current behavior good enough/would break too much to
change?
Current behaviour is a known limitation of MySQL, but there is no reason
not to try and fix this. For DDL to be transactional, the .frm files
need to go bye-bye (since these introduce a need for 2 phase commit).
If InnoDB, or PBXT, is used as the data dictionary, then perhaps it will
be possible to wrap DDL transactions in the engine's transactional
behaviour.
What is the proper behavior?
IMHO, the behaviour of whether the DDL is transactional is not
important. Of much more importance is the ability to do the DDL changes
online...
I will point out, as well, that in sharded environments, transactional
DDL will only be within the shard, so it's usefulness in this type of
environment is a little questionable. Online DDL operations, however,
are much more useful...
My 2 cents and all that,
-jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
