Setting up a replication slave is pretty straightforward, yet cumbersome process that needs a lot of attention to detail. Even if at first glance the six steps are simple, together they constitute something that is everything but easy to grasp. What’s Our Solution We decided to fix that. As a result, our very own TwinDB […]

The post How To Setup a Replication Slave With TwinDB Backup Tool appeared first on TwinDB.

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 …