Statements executed in RSU mode produce GTID entries with local UUID

Bug #1692023 reported by Przemek on 2017-05-19
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC
Status tracked in 5.6
5.6
Invalid
Undecided
Unassigned
5.7
Invalid
Undecided
Unassigned

Bug Description

DDL or other statements executed in wsrep_OSU_method = RSU, break cluster's consistency in terms of MySQL's GTID notation as they are add GTID entries with node's own UUID.
In fact, I don't think statements executed in RSU method should create any GTID event at all, as they do not increase the Galera's global transaction counter as well. Also it doesn't make sense to make those statements getting logged in the node's binary log, as it makes it inconsistent with the rest of the cluster (there is never a guarantee an RSU statement will be executed on all nodes, and when).

Here is example binary log from a session where I executed flush hosts first in TOI, and then in RSU method:
mysql> show binlog events in 'mysql1-binlog.000004';
+----------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+----------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| mysql1-binlog.000004 | 4 | Format_desc | 100 | 123 | Server ver: 5.7.17-13-29.20-log, Binlog ver: 4 |
| mysql1-binlog.000004 | 123 | Previous_gtids | 100 | 194 | c101abff-5592-ee19-488d-9da065411b45:10-14 |
| mysql1-binlog.000004 | 194 | Gtid | 100 | 259 | SET @@SESSION.GTID_NEXT= 'c101abff-5592-ee19-488d-9da065411b45:15' |
| mysql1-binlog.000004 | 259 | Query | 100 | 337 | use `test`; flush hosts |
| mysql1-binlog.000004 | 337 | Gtid | 100 | 402 | SET @@SESSION.GTID_NEXT= 'c101abff-5592-ee19-488d-9da065411b45:16' |
| mysql1-binlog.000004 | 402 | Query | 100 | 480 | use `test`; flush hosts |
| mysql1-binlog.000004 | 480 | Gtid | 100 | 545 | SET @@SESSION.GTID_NEXT= 'daf220b6-2c1c-11e7-b427-0242ac110001:1' |
| mysql1-binlog.000004 | 545 | Query | 100 | 623 | use `test`; flush hosts |
| mysql1-binlog.000004 | 623 | Gtid | 100 | 688 | SET @@SESSION.GTID_NEXT= 'daf220b6-2c1c-11e7-b427-0242ac110001:2' |
| mysql1-binlog.000004 | 688 | Query | 100 | 766 | use `test`; flush hosts |
| mysql1-binlog.000004 | 766 | Rotate | 100 | 817 | mysql1-binlog.000005;pos=4 |
+----------------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
11 rows in set (0.00 sec)

Przemek (pmalkowski) wrote :

A workaround to that is to use set sql_log_bin=0; in the session that is supposed to be executed in RSU method.

Krunal Bauskar (krunal-bauskar) wrote :

Let's understand the semantics.

Semantics of RSU claims that action executed are local to the node and so local UUID is incremented and not the shared clustered UUID. Setting wsrep_on=0 will have same effect of incrementing local UUID.

Ideally, for multi-master solution user shouldn't execute local actions but blocking it would be harsh since there are valid use-cases when user need to run something locally.

As per the protocol of GTID (from MySQL) each action (local/remote) should have a GTID associated with it. sql_log_bin comes as rescue as MySQL semantics dictates use use of sql_log_bin controlling write to binary logs.

With those clarification I don't foresee why RSU should change binary logging behavior.

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PXC-1980

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers