maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Sergei Petrunia <psergey@xxxxxxxxxxxx> writes:

> Also, it seems that right now binary logs are not compatible between mysql-5.6
> and mariadb-5.3. When I try read one file with mysqlbinlog of the other I get
> this:
>
>
> mariadb-5.3 reading binlog from mysql-5.6
> #120131  2:43:14 server id 1  end_log_pos 295 	Query	thread_id=2	exec_time=0	error_code=0
> SET TIMESTAMP=1327963394/*!*/;
> BEGIN
> /*!*/;
> ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 62, event_type: 29
> ERROR: Could not read entry at offset 295: Error in log format or read error.

Yes, 29 is ROWS_QUERY_LOG_EVENT, their version of annotate_rows_log_event. I
think you will find the same problem if you try to read with MySQL 5.1 or 5.5.
I believe this only happens if you enable row annotation events on the master;
it seems a general thing that if one enables a new feature on a MySQL master,
it breaks old slaves.

However, when we merge 5.6, we get the new IGNORABLE_LOG_EVENT flag, which
allows a newer master (eg. 5.7) to inform an old slave that it is ok to ignore
a specific event.

When we merge 5.6, I suppose we will just make sure MariaDB 5.6 writes the
MySQL event code on the master, and understands the MariaDB event code on the
slave, so this will be solved.

> Mysql 5.6 reading mariadb-5.3
> ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 48, event_type: -96
> ERROR: Could not read entry at offset 503: Error in log format or read error.
> # at 434
> #120131  2:01:47 server id 1  end_log_pos 503   Query   thread_id=1     exec_time=0     error_code=0
> SET TIMESTAMP=1327960907/*!*/;
> BEGIN

And this is the reverse situation, -96 is our ANNOTATE_ROWS_EVENT, which is
not understood by MySQL. Again, this only happens when row annotation is
explicitly enabled on the master, so one should not do this when having old
slaves connected (whether MySQL or MariaDB).

There is a deeper issue here. It is not possible on the master to simply
filter out the events that an old slave does not understand, as would seem
natural. Because the current slave code gets confused when there are "holes"
in the binlog positions it receives from the master.

In MariaDB 5.5 this will be fixed (if I'm allowed to push MWL#234 ...),
allowing a MariaDB slave to adjust binlog positions correctly if the master
filters out events. But this does not help MySQL slaves of course.

Also, global transaction IDs, which MySQL@Oracle says they are working on,
should fix this, but this is not in 5.6 currently.

Thanks for taking up these subjects, it's good to get them more clearly
understood!

 - Kristian.