MySQL 8.0.14 is out and it contains some new and very interesting replication enhancements. As always, we are very pleased to share with you the details about the exciting new features in this release.

This blog post will provide you a summary of the features and subsequent blog posts will dive into the mechanics and details of each one. Without further ado, here is the list:

• Binary Log Encryption at Rest. The binary and relay logs can now be encrypted when stored on disk. Encryption is opt-in and can be enabled through the system variable binlog_encryption. With this new feature the user shall be able to instruct the server to encrypt the data stored in the binary log files on disk. And therefore, to protect against attackers that would otherwise, in the event of securing access to the filesystem, get access to the the data in the binary log files.
• Server Version in the Binary Log. Additional metadata was added to the binary log that stores the server version that generated the log entry as well as the server version that originally executed the transaction that generated the changes captured. This helps both MySQL developers and DBAs to better orchestrate cross-version replication as well as troubleshoot and handle issues within that context.
• Different Consistency Criteria for Group Replication. This new feature introduces infrastructure to specify the consistency criteria for read-write and read-only transactions in group replication. It allows users to execute seamlessly transactions in different servers in the group with a stronger consistency criterion than just eventual consistency. Transactions can now be instructed to synchronize on read and/or on writes. As a consequence, some transactions can specify a stronger read consistency, e.g., read all changes that have happened beforehand in the system. Some transactions can be instructed to commit in the local server only after all members in the group have executed and are ready to commit the transaction as well.
• Consistent Primary on Fail-over. This new feature makes the promoted primary disallow accesses to the data in it until its replication backlog is fully applied. Therefore, it prevents the application from transiently read stale data form the new primary during the time it is applying the replicated transactions that are still in the relay log.
• More Efficient Group Communication System Interaction. This new feature enhances performance of group replication in some cases. It simplifies the code path between the MySQL Group Replication plugin and the group communication system (GCS) layer. In low latency networks, where the network communication latency is small enough to make the latency spent in the interaction between GR and GCS more noticeable, the effect of this becomes more visible.
• IPv6 Support for Group Replication. This feature allows users to deploy group replication in IPv6 networks.
• binlog-row-event-max-size is now a system variable. This feature makes the command line option binlog-row-event-max-size a read-only system variable. Therefore, user can configure it with SET PERSIST_ONLY. And, as with any other variable, the user can read its value through an SQL interface instead of looking at configuration files.

Finally, I am happy to summarize these wonderful features that enable the user to deploy MySQL replication  in a larger set of use cases. In fact, some of these features are quite compelling for our users, such as binary log encryption at rest, or transaction consistency options for group replication or even IPv6 support for group replication as well. Give 8.0.14 a try and let us know what you think!

Enjoy!