Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.1.34
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.
Attachments
Issue Links
- relates to
-
MDEV-17369 Document how to reset gtid_current_pos
- Closed
-
MDEV-17370 Create method to purge a specific domain from gtid_binlog_pos
- Closed
-
MDEV-17853 Document that gtid_binlog_pos can lag behind gtid_current_pos after RESET MASTER
- Closed
-
MDEV-17867 Make RESET MASTER throw GTID-related warning if gtid_slave_pos is set
- Open
-
MDEV-17156 Local transactions on a Slave don't update GTID's gtid_current_pos after RESET MASTER on Slave (master_use_gtid value is not relevant)
- Closed