[MDEV-21638] Replication filters seems to be incoherent between DDL and tables usages Created: 2020-02-03 Updated: 2020-03-07 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Richard DEMONGEOT | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | replication | ||
| Environment: |
Debian, with MariaDB 10.3.21 pacakge (source : MariaDB) |
||
| Description |
|
Hello, I've seen an inconsistency on the replication filter flow. Host A : Host B : MariaDB 10.3 B is a slave of A, with a replication filter "Replicate_Ignore_DB" set to X. Scenario : This scenario breaks the replication with error "Table Y.test does not exists". Alternatively : Once again, DDL (truncate table) were ignored, while insertions were played on the replication. In my opinion, it should be more coherent to do the same for DDL and insert/update. Option 1: Ignore both of them. (will break some sub-obtimal use cases where users are logged on the wrong database); Best regards, |
| Comments |
| Comment by VAROQUI Stephane [ 2020-02-03 ] |
|
Hi, As documented. replicate_wild_do_table The workaround is to add an extra filter replicate_wild_do_table="Y.%" can fixe your issue . That the replication stopped when mixing row events and statement ddl is indeed questionable
Thanks |
| Comment by Richard DEMONGEOT [ 2020-02-03 ] |
|
Hello, Trying with Replicate_wild_ignore_table="A.%" and seems to works. Thans Stephane for this work arround Regards, |