Hi Daniel,

On Mon, Mar 4, 2019 at 6:22 AM Daniel Black <daniel@linux.ibm.com> wrote:

Hi,

I was excited to come across the Galera-4 release notes and blog.

http://galeracluster.com/2019/02/galera-cluster-4-available-for-use-in-the-latest-mariadb-10-4-3-release-candidate/

It was good to see causal read functions that I'd hoped for in
https://jira.mariadb.org/browse/MDEV-10715.

WSREP_LAST_WRITTEN_GTID/WSREP_LAST_SEEN_GTID/ WSREP_SYNC_WAIT_UPTO_GTID
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.

We all agree on this. Most users won't of course do anything with the GTIDs, just relying on that normal and Galera replication works. But for the ones that need the GTIDs it's a bit messy.
 
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.

Good point. I'll make a note about this so that we at least make sure the GTID documentation refers to the corresponding GTID implementation.
 
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).

Codership, together with developers from MariaDB Corporation are working on this. Once they are finished we'll see if we can push it as a bug fix to 10.4.
 
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.
 
The Galera 4 library source code is available here:
https://github.com/MariaDB/galera/tree/mariadb-4.x

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.

It was not intentionally ignored. We think it's an important thing to get corrected and hope we'll see it in 10.4 still.

BR,
Rasmus