Great news! MySQL 8.0.3 is out and it is a release candidate. In the replication team we have been busy working on interesting new enhancements and also doing some clean up. Some of these new features are out in this release.…

Comparing Oracle MySQL Group Replication and Galera Cluster through a probability perpective seems quite interesting. At commit time both use a group certification process that requires network round trips. The required time for these network roundtrips is what will mainly determined the cost of a transaction. Let us try to compute an estimate of the ...continue reading "Probability perspective on MySQL Group replication and Galera Cluster"

In this blog post, we’ll discuss migrating data from encrypted Amazon MySQL RDS to encrypted Amazon Aurora.

One of my customers wanted to migrate from an encrypted MySQL RDS instance to an encrypted Aurora instance. They have a pretty large database, therefore using mysqldump or a similar tool was not suitable for them. They also wanted to setup replication between old MySQL RDS and new Aurora instances.

Spoiler: this is possible without any logical dump.

At first, I checked Amazon’s documentation on encryption and found nothing about this type of …

In this blog post, we’ll look at some of the MySQL high availability solution options.

In the previous post of this series, we looked at the MySQL high availability (HA) solutions that have been around for a long time. I called these solutions “the elders.” Some of these solutions (like replication) are heavily used today and have been improved from release to release of MySQL.

This post focuses on the MySQL high availability solutions that have appeared over the last five years and gained a fair amount of traction in the community. I chose to include this group only two solutions: Galera and RDS Aurora. I’ll use the term “Galera” generically: it covers Galera Cluster, MariaDB Cluster and Percona …

Actually, Mysqlbinlog tools can’t miner mysql binlog exactly correct.

In this post ,a special environment we got may hexadecimal characters what we don’t need.

Read this PDF: Special-code-rollback.pdf

TL;DR: unless you know what you are doing, you should always have a primary key on your tables when replicating in RBR (and maybe even all the time).

TL;DR2: MariaDB 10.1 has an interesting way to protect against missing a primary key (innodb_force_primary_key) but it could be improved.

A few weeks ago, I was called off hours because replication delay on all the slaves from a replication chain

Introduction : 

In MySQL the replication is logical. And the DB changes were written to mysqlbinlog. This mysqlbinlog is pulled (IO Thread) and applied ( SQL Thread) by the slave servers. Binlog is the key for MySQL Replication.

Binary logging format is of three types.

• Statement
• ROW
• Mixed

ROW based replication benefits the smaller writes ( OLTP ) work load. The events are logged based on how individual table rows are affected. Primary key and Unique keys on tables benefits the efficient writes.

Major Drawbacks in Row Based Replication ( RBR ):

MySQL Binlog troubleshooting becomes harder at times when you have ROW/Mixed binlog formats.

ROW format is claimed to be a better Binlog Format for data consistency and scalability. But ROW based replication tends to have a couple of drawbacks when it was …

As we know, replication is only supported officially between consecutive major MySQL versions, and only from a lower version master to a higher version slave.

This means for example, the following scenario is supported:
5.6 master –> 5.7 slave

while these two scenarios are not supported:
5.5 master –> 5.7 slave
5.7 master –> 5.6 slave

That being said, in some contexts (e.g a MySQL upgrade) it can be valuable to be able to replicate from a master that is using a newer version of MySQL to an older version slave.

This could be used as part of a rollback strategy, and/or be needed in the case of upgrading a master-master replication topology.

The idea of the article is to provide you …

As we know, replication is only supported officially between consecutive major MySQL versions, and only from a lower version master to a higher version slave.

This means for example, the following scenario is supported:
5.6 master –> 5.7 slave

while these two scenarios are not supported:
5.5 master –> 5.7 slave
5.7 master –> 5.6 slave

That being said, in some contexts (e.g a MySQL upgrade) it can be valuable to be able to replicate from a master that is using a newer version of MySQL to an older version slave.

This could be used as part of a rollback strategy, and/or be needed in the case of upgrading a master-master replication topology.

The idea of the article is to provide you …

Continuent are pleased to announce the release of Tungsten Replicator and Tungsten Clustering 5.2.0

This release is one of our most exciting new releases for a while, as it contains some significant new features and lays the groundwork for some additional new functionality in the upcoming 5.3.0 and 6.0 releases due later this year.

In particular, this release includes the following new features:

• New replicator filtering environment to make filtering quicker and easier to use, and more flexible
  • New filter configuration standard for new filters
  • New filter to make replication out of a cluster easier
  • New filters for filtering events and data
• New applier for sending Apache Kafka messages directly from an incoming data stream
• New applier for adding incoming records directly to Elasticsearch for indexing
• New …