Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Duplicate
-
None
Description
Hi,
the GTID of the last transaction is exposed via the last_gtid session variable ([1]). This needs a round-trip to the server, which could be unwanted in some situations.
[1]: https://mariadb.com/kb/en/mariadb/gtid/#last_gtid
Upstream MySQL implements a way to get the GTID of the last transaction at the protocol level in the OK packet. ([2], [3] and [4]). I think this would be a good feature in MariaDB Server.
[2]: https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_session_track_gtids
[3]: https://dev.mysql.com/doc/refman/5.7/en/mysql-session-track-get-first.html
[4]: https://dev.mysql.com/doc/refman/5.7/en/mysql-session-track-get-next.html
Please also consider this improvement on the upstream implementation: Request transaction GTID in OK packet on COMMIT (without needing a round-trip) - [5].
[5]: https://bugs.mysql.com/bug.php?id=84748
Many thanks,
JFG
Attachments
Issue Links
- blocks
-
MXS-1778 Consistent reads by the utlization of GTID in OK packet.
-
- Closed
-
- duplicates
-
-
- Closed
-
-
MDEV-15477 SESSION_SYSVARS_TRACKER does not track last_gtid
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
Thanks for looking into that Vladislav.
I am not familiar with batching: will this work in all cases (all drivers: Java Perl, ..., including with prepare statement) ?
"semicolon" batching , i.e commands separated by ";" , might require some special parameters to enable, and the way to enable it could be driver specific.
e.g allowMultiQueries=true in JDBC. Server-side prepared statements I believe are not supported, client-side prepared statements will work in JDBC, not sure about anything else.
BEGIN NOT ATOMIC should work just fine in 10.1 not requiring special parameters for enabling it. I'm unsure how prepared statements work with it. I did not read anything about not supporting, but did not try either.
It shouldn't be difficult to report gtid in the session tracker framework.
In fact, there is even a reserved value SESSION_GTIDS_TRACKER for this.
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 10.3 [ 22126 ] |
| Priority | Minor [ 4 ] | Major [ 3 ] |
| Priority | Major [ 3 ] | Minor [ 4 ] |
| Priority | Minor [ 4 ] | Critical [ 2 ] |
| Assignee | Vicentiu Ciorbaru [ cvicentiu ] |
| Link |
This issue duplicates |
| Link |
This issue relates to |
| Assignee | Vicentiu Ciorbaru [ cvicentiu ] | Oleksandr Byelkin [ sanja ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Link |
This issue duplicates |
| Status | In Progress [ 3 ] | Stalled [ 10000 ] |
functionality will be implemeted in MDEV-15477
https://jira.mariadb.org/browse/MDEV-15477
| Fix Version/s | 10.3.6 [ 23003 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Resolution | Duplicate [ 3 ] | |
| Status | Stalled [ 10000 ] | Closed [ 6 ] |
| Comment | [ I don't see this fix mentioned on https://mariadb.com/kb/en/library/mariadb-1036-changelog/. Was it really fixed or added? ] |
| Workflow | MariaDB v3 [ 79457 ] | MariaDB v4 [ 133115 ] |
Out of curiosity, about the the round trips. There is batching via semicolon "UPDATE... ;SELECT @@session_var" and also MariaDB specific BEGIN NOT ATOMIC, that does not need semicolon batching to be enabled. Would not work for some reason?