This blog explains how relay log recovery happens in a scenario where an applier thread (SQL_Thread) is starting for the first time and its starting position is not available for relay log recovery operations. If you are using GTIDs with MASTER_AUTO_POSITION then the following is more or less irrelevant since we then employ a more resilient repositioning scheme.…
As part of MySQL replication all data changes that happen on the master server are recorded into a binary log so that they can be sent to slave and replayed there.…
MySQL Fabric is a new product and some folks are running into issues when trying to deploy test instances that grow beyond a single server.
The Fabric documentation has an example GRANT statement illustrating the simple localhost use case:
CREATE USER 'fabric'@'localhost' IDENTIFIED BY 'secret';
GRANT ALL ON *.
In MySQL 5.6 we introduced
GTID_MODE as a new server option. A global transaction identifier (GTID) is a unique identifier created and associated with each transaction when it is committed on the server of origin (master). This identifier is unique not only to the server on which it originated, but is unique across all servers in a given replication setup.…
making it faster, more flexible and easier to use. In MySQL 5.6 we added
support for Global Transaction Identifiers (GTID), which was a huge leap in the
direction of easing the failover process hiding the details about
replication logs and positions.…
In MySQL Replication, users can filter statements either at master (using –binlog-* startup options) or at the slave (using –replicate-* startup options). Prior to MySQL-5.7.3, users could set these filtering rules either through command line parameters or by using my.cnf file.…