[MXS-1728] Please document ignorable events in MaxBinlogCheck Created: 2018-03-20 Updated: 2019-09-04 Resolved: 2019-09-04 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | binlogrouter, Documentation |
| Affects Version/s: | None |
| Fix Version/s: | N/A |
| Type: | Task | Priority: | Major |
| Reporter: | Michaël de groot | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||
| Description |
|
Hi, Please document how to make binlog events with Maxbinlogcheck in the documentation: Thanks! |
| Comments |
| Comment by Michaël de groot [ 2018-03-20 ] |
|
Please see 2 related issues. This is very useful to do point in time recovery with. |
| Comment by Johan Wikman [ 2019-09-04 ] |
|
Current binlog router will be deprecated and replaced with new functionality in 2.5. |
| Comment by Michaël de groot [ 2019-09-04 ] |
|
Will the use case Massimiliano and me concluded ignorable still be supported in the new version? We came to ignorable events for this purpose; Imagine a human error like this: "UPDATE bankaccount SET balance=100000000000000;" - oops, I forgot the WHERE clause. Binlog server runs as slave to production machine. There are no slaves to the binlog server, it just collects binlogs. When Point in Time recovery is needed, a backup is restored to a node. The node then connects to binlogserver as a slave to get the transactions with the benefit of parallel replication, recovering the transactions signficantly faster then when feeding them to the restored backup with mysqlbinlog. While the backup is restoring, or at least before the restored backups starts to run as a slave, the DBA can inspect the binary logs and find the faulty transaction. The DBA can then mark the faulty transaction as ignorable, and the server will ignore the event. The tool to make a transaction ignorable is the maxbinlogchk tool, though it's name doesn't entirely fit the functionality anymore. Thanks, |