I have 3 node xtradb cluster (node.a , node.b, node.c) – all running the latest 5.6 version.
I also have a standard mysql 5.5 (server.d) which serves as a mysql replication master to node.a(which is a mysql.slave) in the cluster.
When i start standard mysql replication on node.a(mysql.slave) in the cluster , replication starts successfully replicating data from
master server.d but after replication starts i notice that any data that gets written to node.b or node.c does not get written to node.a
but any data that gets written to node.a does get written to both node.b and node.c
I can provide conf files if needed - but wanted to see if anyone has experienced similar issues with mysql.standard
replication into a single node apart of a xtradb cluster?
[COLOR=#252C2F] So after doing a lot of investigation and finding a very very hidden forum post on a google code page i found that the reason i was having issues was the “replicate-do-db=” variables i had on my slave node that was replicating from a production system.
This was only allowing those particular tables to be replicated by galera (isn’t galera supposed to be independent of MySQL???)
Anyway having here at least means that if someone else runs into the problem they will be able to fix it them self
** I am using “replicate-do-table” on PXC node.a slave to Mysql.Standard Master server.d **
I think it’s a mistake for Galera to obey the standard replication filters, it makes architectures that use both Galera and asynchronous replication have inter-dependent configuration, and it makes the cluster fail in non-obvious ways.
For example, I very rarely would want to limit replication filtering within my cluster, but I very well may want to replicate only certain DBs into my cluster on a single async replication stream (i.e., on a single node). However, woe to you if you add any ‘replicate-do’ filters to a configuration on one of your nodes.
If Galera needs replication filters internally (which I’m somewhat dubious of), they should be wsrep_% settings, and be completely independent of async replication.