maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

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.

Yes.
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
> Log_event::do_apply_event
> is the place where we begin translating the event from the binlog to an SQL
> statement.

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
example mysqlbinlog.test.

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
the slave.

 - Kristian.