maria-developers team mailing list archive
Mailing list archive
Re: MDEV-6877 - binlog_row_image implementation advice
Vicențiu Ciorbaru <vicentiu@xxxxxxxxxxx> writes:
> do have a couple of unknowns still. I don't quite understand what's the use
> for the TABLE_MAP event. My intuition tells me its some sort of id we
> assign to a table name (test.t1 for example) that gets used afterwards in
> the binlog row events.
The Table_map_log_event assigns numerical IDs to the tables used in a
statement. These IDs are then used in one or more following Rows_log_event to
say which table the row operations should be made on.
> the addition. I could not find any other "hidden" logic that we use to
> choose how we log row operations in the binlog. What I would like to know
> is if there are any other pitfalls that I am supposed to watch out for, or
> if there is anything else I may be missing regarding the logging part.
I also cannot think of any. (Though experience shows that there will probably
be a number of pitfalls anyway).
> When it comes to actually doing the replication, I concluded that
> is the place where we begin translating the event from the binlog to an SQL
Right. For row-based replication, it is Rows_log_event::do_apply_event().
> Another concern that I have is how to test the implementation. Right now, I
> run the test, get the binlog file and print it with mysqlbinlog and see if
> the output is what I expect. Do we have something within mysql-test-run
> that automates this?
There are some MTR tests that run mysqlbinlog and checks the output, for
But the usual way to check replication is all the MTR tests in
mysql-test/suite/rpl/t/. They start up a master and a slave server (or more),
make some transactions on the master, check that they replicate as expected to