Group Replication now interacts with the Group Communication Engine more efficiently

MySQL 8.0.14 comes with a plethora of new features. Some of the new Group Replication features have userfacing options, some impact user-facing options, and others stay completely under the hood. This post will present one of the under-the-hood changes in MySQL 8.0.14: the way the Group Replication layer interacts with the underlying Group Communication Engine layer, XCom.…

Group Replication: Preventing stale reads on primary fail-over!

This is a follow up post about the new consistency option of Group Replication group_replication_consistency. We recommend that you first read this post to get an overview of scenarios that can be addressed with this solution.

A group replication cluster will automatically detect failures and adjust the view of the members that are active, i.e., the membership configuration.…

Group Replication – Consistency Levels

The MySQL Group Replication (GR) feature is a multi-primary update anywhere or single-primary replication plugin for MySQL with built-in conflict detection and resolution, automatic distributed recovery, and group membership.

Its goal it is to make high-availability (HA) simple with off-the-shelf hardware, not only to new applications but also existing ones – that was one of the motivations of the single-primary mode.…

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).…

Extending replication instrumentation: an insight on transaction retries

MySQL 8.0.13 improves replication lag monitoring by extending the instrumentation for transaction transient errors. These temporary errors, which include lock timeouts caused by client transactions executing concurrently as the slave is replicating, do not stop the applier thread: instead, they cause a transaction to retry.…