With the introduction of Global Transaction Identifiers(GTID) in MySQL from mysql-5.6 GA a whole lot of different functionality have been developed around it so that GTID could be used in a much simpler and efficient way.

One of the interesting functionality with GTID in use is the function to sync a slave with its
master server using the WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS. This is used to do a timed or an indefinite wait till the servers in contention are in sync with respect to the GTID executed set.

This function is used to address specific use cases in which transactions are applied using SQL/worker thread. In order to give more flexibility to the user a new function of syncing the servers with GTID has been introduced in mysql-5.7.5 called WAIT_FOR_EXECUTED_GTID_SET.

Limitations of WAIT_UNTIL_SQL_THREAD_AFTER_GITDS

The already existing WAIT_UNTIL_SQL_THREAD_AFTER_GITDS functions …

On MySQL-5.7.2, we released a new type of multi-threaded slave (MTS). It is called logical clock based MTS. Because it can parallel apply transactions in the same schema, it has the potential to improve slave throughput on almost any application, regardless of the schema layout. After it was released, we continued to work on the framework to improve it further. Therefore, 5.7.5 includes a few enhancements, in addition to those released as part of previous DMRs. This blog post introduces one of the new features in the latest DMR.

slave_preserve_commit_order

It is a system global variable and can be set dynamically.

• SET GLOBAL slave_perserve_commit_order = {ON|OFF};

Enabling this variable ensures that the order which transactions were committed on the master is preserved on the slave. The replication threads must be stopped before enabling this variable and this variable only affects logical clock based …

 I am happy to announce that slave_transaction_retries is available on multi-threaded slave now. You will no longer see the warning that slave_transaction_retries is not supported by multi-threaded slave since MySQL-5.7.5.

Multi-threaded slave and single-threaded slave share the system variable slave_transaction_retries and they have similar transaction retry logic. So this blog just brings you a little new knowledge and then refresh you with the transaction retry logic.

Transaction Retry In Worker Threads

For multi-threaded slave, Transaction retry is done in worker threads when they are applying their transactions. When a worker thread encounters a temporary error, it needs to read the transaction’s events from relay log by itself and then apply them again.

The only new thing is that worker threads need to read events from relay log by themselves. To support it, coordinator stores relay log position of …

MySQL Group Replication is here and with it comes the need to install and configure the underlying group communication toolkit that supports it: Corosync. Corosync is a well known and reliable Group Communication System that is used in such applications as Pacemaker.

In term of support, we develop MySQL Group Replication based on Corosync version 1.4.6, so this tutorial is based on this version. Regardless of this, no known problems are know to exists when using newer versions, but no extensive testing has been done on those.

Along with Corosync we also encourage the use of NSS to better secure your data that is transmitted in the group.

Installing

To install Corosync, you can rely on your packet manager for most distributions or compile it from source.

==> From the package manager

• Debian distributions

$ sudo apt-get install corosync …

The new addition to the MySQL planet, MySQL Group Replication is now on Labs Release for you to try it! It offers you update everywhere capabilities on any group of normal, out of the box, MySQL servers. Concurrent updates on a setup of several MySQL servers is now possible and this with our trademark: the ease of use.

In fact we ship MySQL Group Replication in such a way that for you to form a group and add new nodes, all that is needed is to configure the servers with your unique group id and just press start. In this post we show you the “behind the scenes” of this process, on how the node catches up with the remaining servers through distributed recovery.

The basics about Distributed Recovery

If we were to summarize what distributed recovery is, we could describe it as the process through which a new server gets missing data from a live node, while paying attention to what happens in the group, eventually catching …

Introduction

The multi master plugin for MySQL is here. MySQL Group Replication ensures virtually synchronous updates on any node in a group of MySQL servers, with conflict handling and failure detection. Distributed recovery is also in the package to ease the process of adding new nodes.

For a better understanding on how things work, we go under the hood in this post and you will have a better understanding about the communication layer functionality and implementation.

Group Communication concepts Figure 1 – Plugin Architecture

As the architecture shown in Figure 1, Group Replication is a classic modular and layered piece of software and the bottom two layers comprise the communication module. But, it is not a regular …

The first preview  release of MySQL Group Replication, a MySQL plugin that brings multi-master update everywhere to MySQL, is available on labs. This plugin ties together concepts and technologies from distributed systems, such as group communication, with traditional database replication. The ultimate result is a seamlessly distributed and replicated database over a set of MySQL servers cooperating together to keep the replicated state strongly consistent.

Introduction

Before diving into the details of MySQL Group Replication, lets first introduce some background concepts and an overview of how things work. These will provide some context to help understand what this is all about and what are the differences between traditional MySQL replication and the one implemented in this new plugin.

…

Both MySQL Connector/Python 2.0.1 and 1.2.3 are now available through the Python Package Index or PyPI. Leaving the previous version available is probably a good idea as you can always go back if needed.

Note that we still have no files hosted at PyPI.

Both MySQL Connector/Python 2.0.1 and 1.2.3 are now available through the Python Package Index or PyPI. Leaving the previous version available is probably a good idea as you can always go back if needed.

Note that we still have no files hosted at PyPI.

In a previous blog post we presented some of the issues with the current optimizer cost model and listed several ideas for improvements. The new 5.7.5 DMR contains the result of our initial work on improving the optimizer’s cost model:

• Cost Model for WHERE Conditions. In previous versions of MySQL, the estimated number of rows from a table that will be joined with the next table only takes into account the conditions used by the access method. This often led to record estimates that were far too high and thus to a very wrong cost estimate for the join. With wrong cost estimates, the join optimizer might not find and choose the best join order. To solve this issue, a cost model that includes the …