Add Slave_pos for Using_Gtid in SHOW SLAVE STATUS only if Master GTID
mode is set
Possible output values are:
Default
Using_gtid: No
or
Using_gtid: Slave_pos
MXS-1266:
blr_slave_gtid_request() the file in slave registration request is
checked whether it exists or not and GTID file info could e set instead.
Also addded:
blr_handle_simple_select_stmt(): only mariadb10_gtid_domain is checked
for SELECT @@GLOBAL.gtid_domain_id slave request
blr_start_master_registration(): only router->mariadb10_compat is
checked before sending SELECT @@GLOBAL.gtid_domain_id to master
blr_file_create calls mxs_mkdir_all()
MASTER_USE_GTID=Slave_pos is now handled by CHANGE MASTER TO
If mariadb10_master_gtid is On
MASTER_LOG_FILE is no longer required, only MASTER_USE_GTID=Slave_pos
Slave_pos must be set before to empty value or request value:
set @@global.gtid_slave_pos = '0-10116-194';
Files are saved in GTID repo at creation time: this allows to show
files without transactions via SHOW [FULL] BINARY LOGS
The FULL keywords add domain_id and server id to the output as file
prefix: 0/10122/mysql-bin.000080
Standalone events in transaction (no COMMIT event) are now handled:
the GTID is saved to gtid_maps storage.
Transaction detection assumes there is only one query_event after GTID
event with MARIADB_FL_STANDALONE flag set.
Saving GTID components into gtid_maps storage will allow to create a
hiearchical binlog cache dir.
Empty GTID for master registration can be specified with SET
@@global.gtid_slave_pos = ‘’
MariaDB GTID Master registration:
creating missing binlog files (with 4 byes) between current one and the
filename coming from ROTATE_EVENT.
blr_slave_binlog_dump() is also checking possible empty files.
New option ‘mariadb10_master_gtid’ in use.
Only MariaDB 10 Slaves with GTID request can register if the option is
set.
When receiving a Master reply to a GTID request and the GTID_LIST is
seen, an IGNORABLE event could be written at the end of file if
GTID_LIST next_pos is beyond that EOF
The “mariadb_gtid” parameter is no longer available:
“mariadb10_slave_gtid” is the new one.
Another parameter “mariadb10_master_gtid” enable GTID registration.
The latter set to On forces option “mariadb10_slave_gtid” to be On
When log messages are written with both address and port information, IPv6
addresses can cause confusion if the normal address:port formatting is
used. The RFC 3986 suggests that all IPv6 addresses are expressed as a
bracket enclosed address optionally followed by the port that is separate
from the address by a colon.
In practice, the "all interfaces" address and port number 3306 can be
written in IPv4 numbers-and-dots notation as 0.0.0.0:3306 and in IPv6
notation as [::]:3306. Using the latter format in log messages keeps the
output consistent with all types of addresses.
The details of the standard can be found at the following addresses:
https://www.ietf.org/rfc/rfc3986.txthttps://www.rfc-editor.org/std/std66.txt
Both the listeners and servers now support IPv6 addresses.
The namedserverfilter does not yet use the new structures and needs to be
fixed in a following commit.
MariaDB 10 GTID is detected and stored only if transaction_safety
option is on.
SELECT @@gtid_current_pos and “maxadmin show service $service_name” can
return it
The highwater and lowwater callbacks were never registered for the client
DCBs in the binlogrouter.
The DCB hangup callbacks were never called by the core and were replaced
with fake hangup events in an earlier version.