Category Archives: Binary Log

Automatic provisioning in Group Replication

With the release of version 8.0.17 of MySQL, we bring to you the brand new Clone plugin. Allowing you to get physical snapshots of data stored in InnoDB, this new plugin is an ideal addition to your Group Replication setup.

When joining a new server into a running replication group, a manual offline provisioning procedure was required in most cases as a tool to execute this step in the context of distributed recovery was missing.…

MySQL 8.0.16 Replication Enhancements

MySQL 8.0.16 has been released last Thursday. In it, you can find some new replication features. Here is a quick summary. Follow-up blog posts will provide details about these features.

  • Large Messages Fragmentation Layer for Group Replication. Tiago Vale’s work, introduces message fragmentation to the Group Communication Framework.

Server version in the binary log

Replication topologies, whether master-slave or group replication setups, may be composed of servers using different MySQL versions.

In MySQL 8.0.14, each transaction’s immediate and original server versions are now visible in the binary log as session variables. These two new variables, fully managed by the replication infrastructure, are used to support cross-version replication by transmitting the MySQL server release numbers associated with each transaction through the replication topology:

  • original_server_version stores the MySQL Server release number of the server where a transaction was originally committed (for example, 80014 for a MySQL 8.0.14 server instance).

How to manually decrypt an encrypted binary log file

The encrypted binary log file format introduced in MySQL version 8.0.14 was designed to allow a “manual” decryption of the file data when the value of the key that encrypted its file password is known.

Each encrypted binary (or relay) log file is composed by an encrypted binary log file header and the encrypted binary log content (the file data).…

Reading the log positions of a snapshot consistently

MySQL 8.0.11 introduced a new performance schema table named log_status, which provides consistent information about MySQL server instance log positions from replication and transactional storage engines.

Used in conjunction with other MySQL 8.0 feature (the backup lock), this new feature will allow backup tools to take backup with minimal impact in DML throughput, but ensuring consistent snapshot with respect to GTIDs, replication, binary logs and transactional storage engine logs.…

Taking advantage of new transaction length metadata

MySQL 8.0.2 introduced a small yet powerful per transaction metadata information containing the transaction length in binary logs.

MySQL binary logs are being used for many other things than MySQL replication or backup/recovery: replicate to Hadoop; replicate to other databases, such as Oracle; capture data change (CDC) and extract-transform-load (ETL); record change notification for cache invalidation; change tracking for differential backups; etc.…

MySQL 8.0.3: Binary logging and Replication chains are now enabled by default

MySQL 8.0.3 release candidate is out with amazing new replication features, along with changes in couple of replication default options. Thanks to our users for their constant feedback and valuable inputs, MySQL is changing defaults whenever possible to remove configuration overhead for practical deployment of MySQL server.…