[MDEV-20720] Galera: Replicate MariaDB GTID to other nodes in the cluster - Jira

Details

Type: Task
Status: Closed (View Workflow)
Priority: Critical
Resolution: Fixed
Fix Version/s: 10.5.1
Component/s: Galera, Replication
Labels:
None

Sprint:
10.2.4-4, 10.2.4-1, 10.3.1-2, 10.2.10, 10.2.11, 10.1.30, 10.2.12

Description

The MariaDB GTID is currently not transferred to other nodes in the cluster. As a result,
receiving nodes simply use the current gtid_domain_id (or wsrep_gitd_domain_id in 10.1)
and server id to tag the incoming transactions along with galera-assigned sequence number.

Attachments

Issue Links

causes

MDEV-6866 Ensure consistency of sequence number in Galera GTID Replication

Closed

MDEV-8458 Galera Cluster replication stream doesn't pass along MariaDB's GTID

Closed

MDEV-10227 MariaDB Galera cluster gtid's falling out of sync inspite of setting wsrep_gtid_mode=ON

Closed

MDEV-13431 wsrep_gtid_mode uses wrong GTID for transaction committed by slave thread

Closed

includes

MDEV-14323 Example mtr test for 2 clusters

Closed

is blocked by

MDEV-9856 wsrep_gtid_mode requires nodes to have the same log_bin path

Closed

relates to

MDEV-7984 Galera doesn't ignore duplicates properly with GTID replication

Closed

MDEV-9107 GTID Slave Pos of untrack domain ids being updated

Closed

MDEV-9315 Xid is only shown for RBR events

Closed

MDEV-14153 Implicitly dropped temporary tables cause GTID drift in Galera cluster

Closed

MDEV-20769 MASTER_GTID_WAIT to work for replicated galera GTIDS

Open

MXS-4819 Failover for async replication between 2 galera cluster

Open

MDEV-9855 log_slave_updates is required for wsrep_gtid_mode

Closed

MDEV-20715 Implement system variable to disallow local GTIDs in Galera

Closed

MXS-2787 Incorrect implementation of Galera replication

Closed

links to

pr1317

(1 is blocked by, 9 relates to, 1 links to)

Activity

Ascending order - Click to sort in descending order

View 29 older comments

Sylvain ARBAUDIE added a comment - 2019-07-12 20:40

Would there be any issue using the galera seqno as the last part of the mariadb gtid ? apart for RSU DDL i mean ?

Sylvain ARBAUDIE added a comment - 2019-07-12 20:40 Would there be any issue using the galera seqno as the last part of the mariadb gtid ? apart for RSU DDL i mean ?

Teemu Ollakka added a comment - 2019-07-15 05:30

There are at least two major issues which need to be resolved in order to use Galera seqno as part of the MariaDB GTID:

Occasionally Galera seqno is generated for a write set which do not commit a transaction, these include (but not limited to) write sets that fail certification and intermediate streaming replication fragments. In order to keep GTID sequences continuous, all of these events should be logged in binlog as dummy events, which could cause excessive clutter under certain workloads.
Master-slave topology where Galera cluster acts as a slave: It is required that the original GTID from the master should be preserved in binlog events. However, as Galera will generate a write set/seqno for the applied transaction, there will be two GTIDs which should be persisted in binlog for each transaction. It is not clear how this could be handled to preserve compatibility with async master/slave replication.

Teemu Ollakka added a comment - 2019-07-15 05:30 There are at least two major issues which need to be resolved in order to use Galera seqno as part of the MariaDB GTID: Occasionally Galera seqno is generated for a write set which do not commit a transaction, these include (but not limited to) write sets that fail certification and intermediate streaming replication fragments. In order to keep GTID sequences continuous, all of these events should be logged in binlog as dummy events, which could cause excessive clutter under certain workloads. Master-slave topology where Galera cluster acts as a slave: It is required that the original GTID from the master should be preserved in binlog events. However, as Galera will generate a write set/seqno for the applied transaction, there will be two GTIDs which should be persisted in binlog for each transaction. It is not clear how this could be handled to preserve compatibility with async master/slave replication.

Geoff Montee (Inactive) added a comment - 2019-10-02 18:56

A feature like ~~MDEV-20715~~ could also improve Galera's support for MariaDB GTIDs. Specifically, it could prevent each node from generating GTIDs for local transactions, which could make it easier for replication slaves to use any cluster node as master, without risking inconsistent GTIDs.

Geoff Montee (Inactive) added a comment - 2019-10-02 18:56 A feature like MDEV-20715 could also improve Galera's support for MariaDB GTIDs. Specifically, it could prevent each node from generating GTIDs for local transactions, which could make it easier for replication slaves to use any cluster node as master, without risking inconsistent GTIDs.

Sachin Setiya (Inactive) added a comment - 2020-01-21 13:07

Okay to push

Sachin Setiya (Inactive) added a comment - 2020-01-21 13:07 Okay to push

Ian Gilfillan added a comment - 2020-03-29 23:21

The pull request linked with this issue is still marked as open, although the task has been closed.

Ian Gilfillan added a comment - 2020-03-29 23:21 The pull request linked with this issue is still marked as open, although the task has been closed.

People

Assignee:: Jan Lindström (Inactive)

Reporter:: Nirbhay Choubey (Inactive)

Votes:: 28 Vote for this issue

Watchers:: 41 Start watching this issue

Dates

Created:: 2016-08-31 15:49

Updated:: 2024-07-07 22:33

Resolved:: 2020-01-29 13:57

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server