Bilginize: Version requirement
Client side global transaction ID injection exists as of mysqlnd_ms version 1.2.0-alpha. Transaction boundaries are detected by monitoring API calls. This is possible as of PHP 5.4.0. Please, see also Transaction handling.
As of MySQL 5.6.5-m8 the MySQL server features built-in global transaction identifiers. The MySQL built-in global transaction ID feature is supported by
PECL/mysqlnd_ms
1.3.0-alpha or later. Neither are client-side transaction boundary monitoring nor any setup activities required if using the server feature.Please note, all MySQL 5.6 production versions do not provide clients with enough information to use GTIDs for enforcing session consistency. In the worst case, the plugin will choose the master only.
Idea and client-side emulation
PECL/mysqlnd_ms
can do client-side transparent global transaction ID injection.
In its most basic form, a global transaction identifier is a counter which is
incremented for every transaction executed on the master. The counter is held
in a table on the master. Slaves replicate the counter table.
In case of a master failure a database administrator can easily identify the most recent slave for promoting it as a new master. The most recent slave has the highest transaction identifier.
Application developers can ask the plugin for the global transaction identifier (GTID) for their last successful write operation. The plugin will return an identifier that refers to an transaction no older than that of the clients last write operation. Then, the GTID can be passed as a parameter to the quality of service (QoS) filter as an option for session consistency. Session consistency ensures read your writes. The filter ensures that all reads are either directed to a master or a slave which has replicated the write referenced by the GTID.
When injection is done
The plugin transparently maintains the GTID table on the master.
In autocommit mode the plugin injects an UPDATE
statement
before executing the users statement for every master use. In manual
transaction mode, the injection is done before the application calls
commit()
to close a transaction. The configuration option
report_error
of the GTID section in the plugins configuration
file is used to control whether a failed injection shall abort the current
operation or be ignored silently (default).
Please note, the PHP version requirements for transaction boundary monitoring and their limits.
Limitations
Client-side global transaction ID injection has shortcomings. The potential
issues are not specific to PECL/mysqlnd_ms
but are rather of general nature.
Using server-side global transaction identifier
Starting with PECL/mysqlnd_ms
1.3.0-alpha
the MySQL 5.6.5-m8 or newer built-in global
transaction identifier feature is supported. Use of the server feature lifts
all of the above listed limitations. Please, see the MySQL Reference Manual
for limitations and preconditions for using server built-in global transaction
identifiers.
Whether to use the client-side emulation or the server built-in functionality is a question not directly related to the plugin, thus it is not discussed in depth. There are no plans to remove the client-side emulation and you can continue to use it, if the server-side solution is no option. This may be the case in heterogenous environments with old MySQL server or, if any of the server-side solution limitations is not acceptable.
From an applications perspective there is hardly a difference in using one or the other approach. The following properties differ.
Bilginize: Global transaction identifiers in distributed systems
Global transaction identifiers can serve multiple purposes in the context of distributed systems, such as a database cluster. Global transaction identifiers can be used for, for example, system wide identification of transactions, global ordering of transactions, heartbeat mechanism and for checking the replication status of replicas.
PECL/mysqlnd_ms
, a clientside driver based software, does focus on using GTIDs for tasks that can be handled at the client, such as checking the replication status of replicas for asynchronous replication setups.