On previous posts about Group Replication consistency we:

1. introduced consistency levels;
2. explained how to configure the primary failover consistency;
3. presented how to configure transaction consistency levels to achieve the consistency required by your applications.

In blog 3. we presented the consistency levels: EVENTUAL, BEFORE, AFTER and BEFORE_AND_AFTER; their scopes: SESSION, GLOBAL; and their context: whether they only impact the ongoing transaction or all concurrent transactions.…

Tweet Google …

This was not on the radar. I have never been proficient in Galera clusters and related technologies, and thus I hadn’t given much thought to Percona Xtradb Cluster (PXC), until Alkin approached me at FOSDEM, and proposed to extend dbdeployer features to support PXC. He mentioned that many support engineers at Percona use dbdeployer) on a daily basis and that the addition of PXC would be welcome.

I could not follow up much during the conference, but we agreed on …

• Replication used to replicate data from the Master node to a slave node[Replica].
• By default Replication is asynchronous.
• It uses binary logs for reading data from the Master node and relay log on slave[Replica].
• Depending on the configuration, you can replicate all databases, selected databases, or even selected tables within a database.

Replication Methods:

• File-based Replication:

The traditional method is based on replicating events from the master’s binary log, and requires the log files and positions in them to be synchronized between master and slave.

• GTID Replication:

The newer method based on global transaction identifiers (GTIDs) is transactional and therefore does not require working with log files or positions within …

Some months ago, Shlomi Noach published a series about Service Discovery.  In his posts, Shlomi describes many ways for an application to find the master.  He also gives detail on how these solutions cope with failing-over to a slave, including their integration with Orchestrator.

This is a great series, and I recommend its reading for everybody implementing master failover, with or without

Recently we had encountered a strange issue with replication and temp directory(tmpdir) change while working for one major client.

All the servers under this were running with Percona flavor of MySQL versioned 5.6.38 hosted on a Debian 8(Jessie)

The MySQL architecture setup  is as follows one master with 5 direct slaves under it

Through this blog, we will take you through the issue we had faced and how we fixed ultimately.

Client Request:

There was a simple request from our client to add a column and index to a 16GB production table since the table had foreign keys, to avoid complications we decided to go with online DDL instead of pt-online-schema.

When we started to alter, it got failed due to insufficient space in “tmpdir”.MySQL by default would be using “/tmp” for temp table creating, sorting and other temp operation, Since we had only 5.7G left on the “/” …

This is a follow-up post in the MySQL Master Replication Crash Safety series.  In the two previous posts, we explored the consequence of reducing durability on masters (including setting sync_binlog to a value different than 1) when slaves are using legacy file+position replication.  In this post, we cover GTID replication.  This introduces a new inconsistency scenario with a potential

As you may have noticed by now, we are continuously improving and enhancing the experience of managing a MySQL server. Furthermore, we have also released tools, such as MySQL shell, that make advanced and distributed setups like creating, deploying, and running clusters of InnoDB instances, seamless to the end user.…

Tweet Google Plus Share

We are less than 48h before the more and more popular pre-FOSDEM MySQL Day !

Unfortunately one of our speaker won’t be able to deliver his talk. Indeed, Giuseppe had ton cancel is talk on containers (Automating MySQL operations with containers) but he will be present during the day and during the Community Dinner, so if you have questions, I’m sure he will gladly answer them.

So we have replace this great speaker by another great one: Shlomi Noach !

Shlomi will present a very new session: Un-split brain (aka Move Back in Time) MySQL.

Here is the updated …

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

…

As we showed on the introduction post, in MySQL 8.0.14 Group Replication was once again improved. Now the developer can specify which is the consistency level of all group transactions or even of a single transaction.

Note that this is about consistency in terms of the global synchronization of transactions in the group.…