Peter Laursen <peter_laursen@webyog.com> writes:
MyISAM is/used to be completely 'transaction-agnosstic'. But GTIDs seem to confict with non-transactional storage engines (as far as I can understand). MySQL/Oracle have "solved" (!) this by not allowing updates to tables using transactional engines and non-transactional storage engines in same transaction.
However to me it is nonsense that transactions apply (have any effect at all) for non-transactional storage engines. As a consequence I consider this solution (what must have been enforced in the server layer and not the storeage engine layer) by Oracle 'a dirty hack' (unless somewone can explain me why it it necessary).
Yes, MySQL/Oracle introduced a lot of limitations with their GTID implementation in 5.6. But these are specific to their choice of design of GTID. It is not intrinsic to the concept of global transaction ID. The whole motivation for doing GTID differently in MariaDB is exactly to avoid all these limitations and other problems that come with the MySQL 5.6 design. Your observation with limitations on non-transactional engines is one example. (IIRC, originally _any_ update to non-transactional tables was disallowed in MySSQL 5.6 GTID). In MariDB 10.0 GTID, I tried hard to make it work without any limitations compared to not using GTID. So in MariaDB there is no need to explicitly enable any gtid_mode=ON or enforce_gtid_consistency=ON options. GTID is available automatically after upgrade to 10.0, and can be used or not as and when desired. So yes, there are others that consider Oracle's design of GTID 'a dirty hack', but MariaDB 10.0 GTID is not affected by that design. Hope this helps, - Kristian.