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-l...
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