maria-discuss team mailing list archive
Mailing list archive
MariaDB-10.4 / Galera and GTIDs - aka we now have two different GTID implementations
I was excited to come across the Galera-4 release notes and blog.
It was good to see causal read functions that I'd hoped for in
functions which seemed to mirror existing functions like
MASTER_GTID_WAIT and GTID variables. The reason these are different
names is because a MariaDB GTID is different from a Galera one.
*Having two GTID implementations is insane*. To state the obvious
from a user point of view, we've now got two Global Transaction
Identification implementations. Application and framework writers like
Django/Drupal now have to handle now try to handle consistently with
00000000-0000-0000-0000-000000000000:25 for Galera and 0-1-33 for
MariaDB async gtid replication. This is not just a format
string difference. The an implementation requires a disparate set of
functions to implement when they could of been consolidated. A mixed
topology setup could be hidden from the application implementation if
the same functions where used. There is/was also a option/proposal that
had MariaDB gtid in the protocol save a round trip retrieval of a GTID
- quite useful.
There is also a bunch of documentation that refers to GTID and its
going to absolutely horrible to try to keep the concepts separated as
you try to configure a system.
An issue like MDEV-10715, the most voted for and watched open issue in
JIRA, (and related MDEV-14153), should of had a very priority than this
when the implementation from Codership was been merged. This shoehorned
in implementation from Codership is a very poor fit.
Giving MDEV-10715 a critical priority and a 10.5 target is fiction when
there isn't going to be a new galera wsrep api implementation for a
number of years. An extra field in the protocol is all it would of
taken (comment in MDEV-10715 from 8 months ago).
10.4.3 is out (really an RC?), the galera code got merge in 10.4.2, and
the source code of galera-4 isn't even released.
Hopefully the tight relationship between MariaDB Corporation and
Codership is enough to get this fixed because from an architectural
point of view, because the current implementation shouldn't of been
merged (contractual arrangement or not).
Developers, MariaDB and Codership you've lost track of your user base
because the feedback, that is readily available, is ignored.