maria-developers team mailing list archive

[Rasmus Johansson <rasmus@xxxxxxxxxxx>]

Hi Daniel,

On Mon, Mar 4, 2019 at 6:22 AM Daniel Black <daniel@xxxxxxxxxxxxx> 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