maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Peter Laursen <peter_laursen@xxxxxxxxxx> 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.