[MDEV-17368] RESET MASTER doesn't completely reset gtid_current_pos Created: 2018-10-03  Updated: 2020-08-25  Resolved: 2018-10-04

Status: Closed
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.1.34
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: Andrei Elkin
Resolution: Not a Bug Votes: 0
Labels: binlog, gtid

Issue Links:
Relates
relates to MDEV-17369 Document how to reset gtid_current_pos Closed
relates to MDEV-17370 Create method to purge a specific dom... Closed
relates to MDEV-17853 Document that gtid_binlog_pos can lag... Closed
relates to MDEV-17867 Make RESET MASTER throw GTID-related ... Open
relates to MDEV-17156 Local transactions on a Slave don't u... Closed

 Description   

RESET MASTER mostly resets gtid_current_pos, but it doesn't seem to reset it entirely:

MariaDB [(none)]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
| 1-1-29,3-1-99971          | 1-1-29,3-1-99971         |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)
 
 
 
MariaDB [(none)]> RESET MASTER;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
| 3-2-54                    |                          |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)

I don't know where this leftover GTID is from and why it wasn't deleted. It obviously came from another server, since this specific server does not have server_id=2:

MariaDB [(none)]> SELECT @@global.server_id;
 
+--------------------+
 
| @@global.server_id |
 
+--------------------+
 
|                  1 |
 
+--------------------+
 
1 row in set (0.00 sec)

This server is not currently a slave and it is not currently in a Galera Cluster, so it's not like it could have replicated this transaction after I executed RESET MASTER:

MariaDB [(none)]> SHOW SLAVE STATUS\G
 
Empty set (0.00 sec)
 
 
 
MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep%';
 
+--------------------------+----------------------+
 
| Variable_name            | Value                |
 
+--------------------------+----------------------+
 
| wsrep_cluster_conf_id    | 18446744073709551615 |
 
| wsrep_cluster_size       | 0                    |
 
| wsrep_cluster_state_uuid |                      |
 
| wsrep_cluster_status     | Disconnected         |
 
| wsrep_connected          | OFF                  |
 
| wsrep_local_bf_aborts    | 0                    |
 
| wsrep_local_index        | 18446744073709551615 |
 
| wsrep_provider_name      |                      |
 
| wsrep_provider_vendor    |                      |
 
| wsrep_provider_version   |                      |
 
| wsrep_ready              | OFF                  |
 
| wsrep_thread_count       | 0                    |
 
+--------------------------+----------------------+
 
12 rows in set (0.00 sec)

It seems as though there is a bug in RESET MASTER that prevents it from completely resetting gtid_current_pos.

 Comments   
Comment by Geoff Montee (Inactive) [ 2018-10-04 ]

What's also interesting is that no matter how many times I execute RESET MASTER, this GTID doesn't go away:

MariaDB [(none)]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
| 3-1-55                    | 3-1-55                   |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)
 
 
 
MariaDB [(none)]> RESET MASTER;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [(none)]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
| 3-2-54                    |                          |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)
 
 
 
MariaDB [(none)]> RESET MASTER;
 
Query OK, 0 rows affected (0.01 sec)
 
 
 
MariaDB [(none)]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
| 3-2-54                    |                          |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)

And it even seems possible to make gtid_current_pos and gtid_binlog_pos get out of sync:

MariaDB [(none)]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
| 3-2-54                    |                          |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)
 
 
 
MariaDB [(none)]> USE db1;
 
Reading table information for completion of table and column names
 
You can turn off this feature to get a quicker startup with -A
 
 
 
Database changed
 
MariaDB [db1]> INSERT INTO test_table VALUES (1000000, 100);
 
Query OK, 1 row affected (0.01 sec)
 
 
 
MariaDB [db1]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
| 3-2-54                    | 3-1-1                    |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)
 
 
 
MariaDB [db1]> INSERT INTO test_table VALUES (1000001, 100);
 
Query OK, 1 row affected (0.01 sec)
 
 
 
MariaDB [db1]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
| 3-2-54                    | 3-1-2                    |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)
 
 
 
MariaDB [db1]> RESET MASTER;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [db1]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
| 3-2-54                    |                          |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)

Comment by Geoff Montee (Inactive) [ 2018-10-04 ]

I figured it out. mysql.gtid_slave_pos had some GTIDs leftover from when the server was a slave. I fixed it with:

MariaDB [(none)]> SET GLOBAL gtid_slave_pos='';
 
Query OK, 0 rows affected (0.01 sec)
 
 
 
MariaDB [(none)]> SELECT @@global.gtid_current_pos, @@global.gtid_binlog_pos;
 
+---------------------------+--------------------------+
 
| @@global.gtid_current_pos | @@global.gtid_binlog_pos |
 
+---------------------------+--------------------------+
 
|                           |                          |
 
+---------------------------+--------------------------+
 
1 row in set (0.00 sec)

Generated at Thu Feb 08 08:35:56 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.