加载中

Some weeks ago I had to migrate some independent MySQL servers (some standard MySQL masters, and some just standalone) to a Percona XtraDB Cluster of 3 nodes.

So the easiest way would be to configure each node to become also an asynchronous slave of one of the production servers.

几周前,我将一些独立的 MySQL 服务器(其中一部分是主节点,一部分是独立主机)移植到一个三节点的 Percona XtraDB Cluster 中。

最简单的方法就是配置每个节点成为其中某个产品服务器的异步从节点。

Like illustrated here:

But in this case there was one major issue, the tables where MyISAM and this is not really recommended with Galera replication even if it’s now supported.


如下图所画:

但是在这种情况下有一个主要的问题, 那就是MyISAM表,它不被推荐使用Galera复制,即使它现在被支持。

Preparing the slaves would then become a loop :

for each production server
   restoring the dump on the node that will be the dedicated slave
   convert the table in InnoDB
   configure and start the replication 
   finally perform SST on the other nodes....

So in this case that should have be done 3 times… that could take some time ! And then, if the single production servers where more than 3 ?

准备从节点(在每个从节点上执行) :

for each production server
   恢复dump文件到将用于专用从节点的服务器
   在InnoDB中转换表
   配置和启动当前节点
   在其他节点上执行SST

在当前例子中我们需要循环3次,这会花费一些时间。但是如果超过3个节点,怎么办呢?

So I decided to use a wonderful feature of MariaDB 10: Multi-source replication.

MariaDB’s multi-source-replication doesn’t have any conflict resolution. The assumption is that there are no conflicts in data between the different masters. Which is the case here, all standalone servers handle different schemas.

所以我决定用一下MariaDB 10的多主复制功能Multi-source replication 

(补充一下MariaDB和多主复制:

MariaDB基于事务的Maria存储引擎,替换了MySQL的MyISAM存储引擎,它使用了Percona的 XtraDB,InnoDB的变体,分支的开发者希望提供访问即将到来的MySQL 5.4 InnoDB性能。这个版本还包括了 PrimeBase XT (PBXT) 和 FederatedX 存储引擎。

Multi-source replication means that one server has many masters from which it replicates. This is a new feature in MariaDB 10.0 release.

你可以把你的数据分在很多个主数据库上,然后通过这个功能备份到一个从数据库上。这对分析数据是非常有用的。

MariaDB 10的多主复制功能没有提供任何数据冲突的解决办法,这样做是因为每个server独自处理不同的schema,互不影响,所以不同的master库间也不会产生数据冲突。这里所提的案例就是这种情况。

(注释:我到现在都觉得schema的中文翻译很奇怪,所以常见的term还是不要翻译好了,你懂)

I configured the MariaDB server to be slave of all production servers, changed the table engine to InnoDB on it and chose one node of the PXC to be the async slave of that MariaDB server. It worked like a charm and the migration of production to Percona XtraDB Cluster became very easy.

我把 MariaDB 配置成所有产品的从属服务器, 把它上边的表引擎换成了 InnoDB 并且选了一个 PXC 节点同步那个从属 MariaDB 服务器。 它运行的还不错并且往 Percona XtraDB 集群迁移产品的话也会变得简单。


Thank you MariaDB’s team for this feature.

When a sever (a node) is member of a Percona XtraDB Cluster is also standard slave (standard asynchronous replication of MySQL), it can spread in the cluster all statements received from the master if log_slave_updates is enabled.

感谢MariaDB团队开发的这个特性。


当一个服务器(节点)是Percona XtraDB Cluster的一员,它是同样标准的从站(标准异步复制的MySQL),如果 log_slave_updates 属性是打开的,它能够在集群中传播从主机接收的所有状态。

返回顶部
顶部