[MXS-2776] Binlog filter skipping commit when writing to ColumnStore Created: 2019-11-22  Updated: 2019-12-02  Resolved: 2019-12-02

Status: Closed
Project: MariaDB MaxScale
Component/s: binlogrouter, Filter
Affects Version/s: 2.4.4
Fix Version/s: 2.4.5

Type: Bug Priority: Major
Reporter: Todd Stoffel (Inactive) Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None

Sprint: MXS-SPRINT-95

 Description   

I am using the Binlog Router to replicate InnoDB and ColumnStore data. Both work as expected unless the binlog filter is introduced into the configuration. At this point the ColumnStore replication stops committing to the target table. You'll notice that only when replicating to the ColumnStore table does the binglogfilter add a second line about COMMIT. This does not happen when the target is InnoDB table.

MaxScale logging shows the following:

When replicating to a ColumnsStore table:

2019-11-21 19:18:47   info   : (8) [binlogfilter] [    ] (columnstore) INSERT INTO `columnstore`.`customers` SET `c` = 'Monty'
2019-11-21 19:18:47   info   : (8) [binlogfilter] [SKIP] (columnstore) COMMIT

Result: No replication

When replicating to an InnoDB table:

2019-11-21 19:22:13   info   : (11) [binlogfilter] [    ] (innodb) INSERT INTO `innodb`.`customers` SET `c` = 'Monty'

Result: Successful replication



 Comments   
Comment by Johan Wikman [ 2019-11-25 ]

toddstoffel Please add your config as well.

Comment by markus makela [ 2019-12-02 ]

Using match=(?i)customers|commit should fix it.

Edit: The match parameter is only for the table and database names and thus would not work.

Comment by markus makela [ 2019-12-02 ]

Turns out that an unwanted regex check was done on transaction management statements which would cause it to fail when the match parameter was used.

Generated at Thu Feb 08 04:16:36 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.