Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
Description
"Inspired" by https://github.com/github/gh-mysql-tools/tree/master/rewind and a great talk by Shlomi on how they used the flashback functionality to unwind some changes in the database I thought I'd try this myself.
$ ./mysqlbinlog.mariadb --version # from MariaDB-server-10.3.15-1.el7.centos.x86_64
|
./mysqlbinlog.mariadb Ver 3.4 for Linux at x86_64
|
When running it I see the following:
$ sudo ./mysqlbinlog.mariadb -vvv --flashback /data/instance1/log/binlog.040693
|
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
|
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
|
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
|
DELIMITER /*!*/;
|
#191004 13:37:23 server id 1 end_log_pos 124 CRC32 0x719035f9 Start: binlog v 4, server v 8.0.17 created 191004 13:37:23
|
BINLOG '
|
8y6XXQ+IevEMeAAAAHwAAAAAAAQAOC4wLjE3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
|
AAAAAAAAAAAAAAAAAAAAAAAAEwANAAgAAAAABAAEAAAAYAAEGggAAAAICAgCAAAACgoKKioAEjQA
|
CgH5NZBx
|
'/*!*/;
|
#191004 13:37:23 server id 1 end_log_pos 235 CRC32 0x6d2310ff Ignorable
|
# Ignorable event type 35 (MySQL Previous_gtids)
|
#191004 13:37:23 server id 1 end_log_pos 325 CRC32 0x2e4d4aec Ignorable
|
# Ignorable event type 33 (MySQL Gtid)
|
#191004 13:37:23 server id 1 end_log_pos 525 CRC32 0x306e76f3 Ignorable
|
# Ignorable event type 29 (MySQL Rows_query)
|
#191004 13:37:23 server id 1 end_log_pos 583 CRC32 0xc7217d67 Table_map: `db`.`table756` mapped to number 756
|
# Number of rows: 1
|
#191004 13:37:23 server id 1 end_log_pos 748 CRC32 0x14d12fe3 Ignorable
|
# Ignorable event type 33 (MySQL Gtid)
|
#191004 13:37:23 server id 1 end_log_pos 3044 CRC32 0xb7c3f7d3 Ignorable
|
# Ignorable event type 29 (MySQL Rows_query)
|
#191004 13:37:23 server id 1 end_log_pos 3121 CRC32 0x677bb299 Table_map: `db`.`table757` mapped to number 757
|
 |
Error row length: 0
|
$
|
So this fails. Clearly it's not entirely unexpected reading from a MySQL 8.0 binlog but even so it would be good to provide better debugging information when such an error occurs.
e.g.
- which event type was not liked
- what were you expecting to see, what did you see?
- adding the "binlog pos" when reporting such an error would also be good as the other tools can be used to look at the event and maybe determine what's wrong.
The current error message is terse to put it mildly...
I understand this may not be seen as a really important thing to do. Right now there is no such functionality in "upstream" MySQL so I was trying out the MariaDB version to see if it might work. The failure is ok but the error reporting of the issue could be improved and maybe adding a bit more detail would be helpful.