First, as a preliminary condition, the slave checks whether
statement-based replication is enabled. If so, and the statement
occurs within a stored function, the slave executes the
statement and exits. If row-based replication is enabled, the
slave does not know whether a statement occurred within a stored
function on the master, so this condition does not apply.

Note

For statement-based replication, replication events represent
statements (all changes making up a given event are associated
with a single SQL statement); for row-based replication, each
event represents a change in a single table row (thus a single
statement such as UPDATE mytable SET mycol =
1 may yield many row-based events). When viewed in
terms of events, the process of checking table options is the
same for both row-based and statement-based replication.

Statement-based replication stops if a single SQL statement
operates on both a table that is included by a
--replicate-do-table or
--replicate-wild-do-table
option, and another table that is ignored by a
--replicate-ignore-table or
--replicate-wild-ignore-table
option. The slave must either execute or ignore the complete
statement (which forms a replication event), and it cannot
logically do this. This also applies to row-based replication
for DDL statements, because DDL statements are always logged
as statements, without regard to the logging format in effect.
The only type of statement that can update both an included
and an ignored table and still be replicated successfully is a
DML statement that has been logged with
binlog_format=ROW.