In 8.0.1, we introduced per-channel replication filters. This allows user to specify different replication filter rules for different slave replication channels. Therefore, the slave will be able to filter out (or transform) the execution of selected replicated changes on a per-source basis when using multi-source replication.…
On the same day last year, I wrote a post about replication filters in MySQL Multi Source Replication and whether we can set the filters per replication channel or not (Bug #80843). My feature request – as well as some others – has been implemented in MySQL 8.0.1. Thanks Oracle for the implementation. (Full list of changes can be checked out here)
In this post, I’ll demonstrate how to set replication filters per
channel in MySQL Multi Source Replication.
Setting up and configuring Multi Source …[Read more]
A basic MySQL or MariaDB replication arrangement uses a simple method to perform replication. Any changes to schema or data on the master are recorded in its binary log. The slave regularly asks the master for any new entries to its binary log, based on position numbers in that log. The slave will record any new entries the master sends it in a relay log and then execute them on its copy of the databases. This system works well with a straightforward master-slave configuration, when there is only one master and one or more slaves.
With recent releases of MySQL and MariaDB, a slave can have multiple sources for replication. This may seem absurd at first until you consider one of the inherent points of replication: load balancing. Slaves are typically used for Read load balancing—to spread traffic related to SELECT statements among several servers. With multi-source replication, Writes can also be load balanced. For a large organization with …[Read more]
Multi-Source Replication is one of the awesome
features in MySQL 5.7 which allows the slave to get the
replication streams from multiple masters by having a replication
channel for each master.
But what about the replication filters? Can we set replication filters per channel in the multi-source replication?
In brief, replication filtering is a way used to eliminate part
of the master’s events (not) to be replicated to the slaves (Also
known as Partial Replication). This can be done on either master
--binlog-ignore-db options) or slaves (using
--replicate-* options) while it is not recommended
on the master anyway at least to provide Point in Time Recovery
MySQL 5.7 comes with a new set of features and multi-source replication is one of them. In few words this means that one slave can replicate from different masters simultaneously.
During the last couple of months I’ve been playing a lot with this trying to analyze its potential in a real case that I’ve been facing while working with a customer.
This was motivated because my customer is already using multi-sourced slaves with Tungsten Replicator and I wanted to do a side-by-side comparison between Tungsten Replicator and Multi-source Replication in MySQL 5.7
Consider the following scenario:[Read more]
The other day I was discussing new features of MySQL 5.7 with a Percona Support customer. After that conversation, I thought it would be a good idea to compile list of important features of MySQL 5.7. The latest MySQL 5.7.6 release candidate (RC) is out and is packed with nice features. Here’s a list of some MySQL 5.7 key features.
- One of the top features in MySQL 5.7 is multi-source replication. With multi-source replication you can point multiple master server’s to slave so limitation of slave having only one master is lift off. There is nice blog post written by my colleague on multi-source replication you will find useful.
MySQL replication isn’t perfect and sometimes our data gets out of sync, either by a failure in replication or human intervention. We are all familiar with Percona Toolkit’s pt-table-checksum and pt-table-sync to help us check and fix data inconsistencies – but imagine the following scenario where we mix regular replication with the Tungsten Replicator:
We have regular replication going from master (db1) to 4 slaves (db2, db3, db4 and db5), but also we find that db3 is also master of db4 and db5 using Tungsten replication for 1 database called test. This setup is currently working this way because it was deployed some time ago when multi-source replication was not possible using regular MySQL replication. This is now a working feature in …[Read more]
Recently Oracle announced several new features for the latest available development version of MySQL that is 5.7.2 at the time of writing this article. Most of them are performance and replication related that show us how incredible the new release will be.
In this post I’m going to try to explain in some easy steps how the new multi-source replication works and how we can configure it for our own tests. It is important to mention that this is a development release, so it is not production ready. Therefore this post is intend to people that want to test the new feature and see how it works with their application, always in a staging environment.
What is multi-source replication?
First, we need to have clear that multi-master and multi-source replication are not the same. Multi-Master replication is the usual circular replication where you can write on any server and data gets replicated …[Read more]