Bug #83431 RBR slave's "BEGIN" binlog query event doesn't carry a session database name
Submitted: 18 Oct 2016 18:53 Modified: 23 Nov 2016 10:16
Reporter: Teng Li Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Row Based Replication ( RBR ) Severity:S1 (Critical)
Version:5.6.27.75, 5.6.34 OS:CentOS
Assigned to: CPU Architecture:Any
Tags: binlog event, query event, replication, session database

[18 Oct 2016 18:53] Teng Li
Description:
Under Row-based replication, the slave's "BEGIN" query binlog event doesn't carry a session database name.
The master doesn't have this problem. It always happens on the slave.

The query log event should alway carry a session database name when the following query is performed:

use database1;
begin;
insert into t1 values XXX;
commit;

The BEGIN query event pointer (log_event *ev) should have ev->db that is equal to "database1"

However, this information (ev->db) is not available in all the RBR slaves.

How to repeat:
Set up a RBR master and slave replication. 

On master run:

use database1;
begin;
insert into t1 values XXX;
commit;

Let the slave replicate. 

Use GDB to launch "mysqlbinlog" (mysqlbinlog.cc) with the slave's binlog, in GDB, try to print the "BEGIN" query event's session database (ev->db).

It's empty, which is unexpected.
[20 Oct 2016 11:23] Andrii Nikitin
This is rather 'not a bug' - there is no reason to set 'current database' for serialized activity of many clients.
This is why current database is replicated with every DML command. 
In other words - many clients do change own database and no need to involve replication into that until real commands get replicated.
[20 Oct 2016 23:57] Santosh Praneeth Banda
@ Andrii Nikitin, There is clearly a behavior change with RBR. If the clients do set session database, the master's BEGIN event has the database information while the slaves after executing the same log are missing database name in BEGIN event.
[23 Nov 2016 10:16] Umesh Shastry
Hello Teng Li,

Thank you for the bug report and feedback.
Verifying based on my internal discussion with Development.

Thanks,
Umesh