For this next blog in our Continuent MySQL Use Case series, we’re diving into a sub-series on the topic of ‘multi-master MySQL’.

We’ll cover three (3) multi-master MySQL use cases as part of this sub-series focusing first on e-commerce to start with, and then following up with use cases from financial services and telecommunications.

Multi-master replication for MySQL typically means that a user can write to any master node knowing that the write will be eventually consistent for all nodes in the cluster; unlike regular MySQL replication, where writes have to be applied to the sole master to ensure that it will be synched to all the slaves.

The First Multi-master Customer

The first Continuent multi-master customer is a leading fashion e-commerce company with sites servicing customers across the globe.

More specifically, it has four multi-brand online stores and several online flagship stores …

MySQL 8.0.19 introduces Binlogless replicas with commit ordering which means you can deploy asynchronous replicas without binary logs enabled, and commit transactions in the same order they are replicated in. Yes, you can disable binlog (skip-log-bin) and the logging of changes done by the applier (log-slave-updates=FALSE) while at the same preserve commit order (slave-preserve-commit-order=TRUE).…

Tweet Share

In a follow-up to the work presented on MySQL 8.0.18  where we introduced privilege checks for slave applier threads, in this post we present a new feature to further increase your ability to securely replicate your data: you can now restrict replication streams to row based events only.…

Tweet Share

Here comes another MySQL release, and together with it, a set of new replication features. As usual, we would like to summarize them. And, also as usual, follow up blogs will provide further details.

• Configure Replication Applier to Require Row-based Replication only.

… Tweet Share

In a MySQL 5.7 master-slave setup that uses the default semisynchronous replication setting for rpl_semi_sync_master_wait_point, a crash of the master and failover to the slave is considered to be lossless. However, when the crashed master comes back, you may find that it has transactions that are not present in the current master (which was previously a slave). This behavior may be puzzling, given that semisynchronous replication is supposed to be lossless, but this is actually an expected behavior in MySQL. Why exactly this happens is explained in full detail in the …

Overview

Over the past few days we have been working with a number of customers on the best way to handle Triggers within their MySQL environment when combined with Tungsten Replicator. We looked at situations where Tungsten Replicator was either part of a Tungsten Clustering installation or a standalone replication pipeline.

This blog dives head first into the minefield of Triggers and Replication.

Summary and Recommendations

The conclusion was that there is no easy one-answer-fits-all solution – It really depends on the complexity of your environment and the amount of flexibility you have in being able to adjust. Our top level summary and recommendations are as follows:

If using Tungsten Clustering and you need to use Triggers:

• Switch to …

The latest MySQL 8.0 release is out. That is MySQL 8.0.18.  We have some new replication enhancements and some work done on replication internals in this release that we would like to highlight and celebrate with our users. Here is a quick summary.…

Tweet Share

For optimal compatibility and performance, all members of a group should run the same version of MySQL Server and therefore of Group Replication. However, in some situations, it may be required to that a group contains servers running different versions. For example, during a rolling upgrade.…

Tweet Share

MySQL 8.0.17 is out. In addition to fixing a few bugs here and there, we also have a couple of new replication features that I would like to present. Thence, allow me to give you a quick summary. As usual, there shall be follow-up blog posts providing details, so stay tuned.…

Tweet Google Plus Share

Background The Skinny

Performing schema changes often requires extended downtime for applications. This is due to MySQL needing to rebuild tables for common schema change operations. Tools like pt-online-schema-change have been written to try to overcome the downtime associated with schema changes, however they are complex and put a high load on the database. Amazon’s Aurora improves some schema changes operations, but still requires a table rebuild for common operations like adding a column using before or after, or simply to add a column with a default value. Rebuilding a table with millions of rows can take hours and prevent writes to that table the entire time.

How Can Tungsten Clustering Keep Applications Running? How Does It All Work?

…