Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Fix
-
5.5.37-galera
-
None
-
None
-
debian wheezy
3x master/master galera cluster
Description
Reproduction step:
my.cnf
|
...
|
[server]
|
wsrep_replicate_myisam=ON
|
replicate_wild_ignore_table=a_local_database.% ...
|
...
|
node1> CREATE TABLE `a_local_database`.`a_table` ( `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY, `data` varchar(64) NOT NULL ) ENGINE='MyISAM' COLLATE 'utf8_bin'; |
|
|
node2> CREATE TABLE `a_local_database`.`a_table` ( `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY, `data` varchar(64) NOT NULL ) ENGINE='MyISAM' COLLATE 'utf8_bin'; |
Error in query (1050): Table 'a_table' already exists |
|
|
node1> INSERT INTO `a_local_database`.`a_table` VALUES(null,'node1'); |
1 row inserted
|
|
|
node2> SELECT * from `a_local_database`.`a_table`; |
+----+-------+ |
| id | data |
|
+----+-------+ |
| 1 | node1 |
|
+----+-------+ |
1 row in set (0.00 sec) |
======
As a general comment, precedence of replication filters should be explained in the documentation.
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
Reproduction step: my.cnf ... [server] wsrep_replicate_myisam=ON replicate_wild_ignore_table=a_local_database.% ... ... node1> CREATE TABLE `a_local_database`.`a_table` ( `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY, `data` varchar(64) NOT NULL ) ENGINE='MyISAM' COLLATE 'utf8_bin'; node2> CREATE TABLE `a_local_database`.`a_table` ( `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY, `data` varchar(64) NOT NULL ) ENGINE='MyISAM' COLLATE 'utf8_bin'; Error in query (1050): Table 'a_table' already exists node1> INSERT INTO `a_local_database`.`a_table` VALUES(null,'node1'); 1 row inserted node2> SELECT * from `a_local_database`.`a_table`; +----+-------+ | id | data | +----+-------+ | 1 | node1 | +----+-------+ 1 row in set (0.00 sec) ====== As a general comment, precedence of replication filters should be explained in the documentation. |
Reproduction step: {noformat} my.cnf ... [server] wsrep_replicate_myisam=ON replicate_wild_ignore_table=a_local_database.% ... ... {noformat} {code:sql} node1> CREATE TABLE `a_local_database`.`a_table` ( `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY, `data` varchar(64) NOT NULL ) ENGINE='MyISAM' COLLATE 'utf8_bin'; node2> CREATE TABLE `a_local_database`.`a_table` ( `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY, `data` varchar(64) NOT NULL ) ENGINE='MyISAM' COLLATE 'utf8_bin'; Error in query (1050): Table 'a_table' already exists node1> INSERT INTO `a_local_database`.`a_table` VALUES(null,'node1'); 1 row inserted node2> SELECT * from `a_local_database`.`a_table`; +----+-------+ | id | data | +----+-------+ | 1 | node1 | +----+-------+ 1 row in set (0.00 sec) {code} ====== As a general comment, precedence of replication filters should be explained in the documentation. |
| Assignee | Nirbhay Choubey [ nirbhay_c ] | |
| Labels | MariaDB_5.5 galera replication | galera replication |
| Workflow | defaullt [ 40501 ] | MariaDB v2 [ 43037 ] |
"replicate_wild_ignore_table" affects replication slave thread which is not used in Galera replication.
Also, a similar feature (if implemented & used) will certainly bring data inconsistency across galera
nodes, which is undesirable. I will updates the docs.
Hi doekia, I looked futher into the replication filter support and it turned out that
except for DML updates for InnoDB tables, replicate-wild-[do|ignore]-table is
currently not support. So unfortunately, it cannot be used for MyISAM tables.
Added a note in the Galera limitations page :
https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/
Its a limitation for MyISAM engine. Closing it as won't fix as replication of MyISAM tables is still considered 'experimental' in Galera.
| Resolution | Won't Fix [ 2 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
| Workflow | MariaDB v2 [ 43037 ] | MariaDB v3 [ 64582 ] |
| Link | This issue relates to MDEV-16841 [ MDEV-16841 ] |
| Workflow | MariaDB v3 [ 64582 ] | MariaDB v4 [ 147882 ] |
I'm not sure these replication filters are expected to have any effect on Galera replication, but nirbhay_c will be able to say for sure.
And indeed, if they don't work with Galera, it should be documented, I failed to find anything.