Description:
http://dev.mysql.com/doc/refman/5.5/en/binary-log-setting.html
(and other versions)
The section here:
Note
Each MySQL Server can set its own and only its own binary logging format...
Should likely be clarified with an example, i.e. setting rbr for a session on an sbr host with multiple levels of sbr will cause the "Error executing row event: 'Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT.'" error. The "unexpected results, or even cause replication to fail altogether." wording is unclear.
In the following case, this is, as far as I have seen in many years of experience, completely untrue.
"In addition to switching the logging format manually, a slave server may switch the format automatically. This happens when the server is running in either STATEMENT or MIXED format and encounters an event in the binary log that is written in ROW logging format. In that case, the slave switches to row-based replication temporarily for that event, and switches back to the previous format afterward."
Maybe it was a planned feature that was never implemented? a slave in statement format, receiving a row event, will always throw the error mentioned above. It does not, in any configuration I've encountered, automatically change. That capability would be incredibly useful, but it does not exist at least up to 5.5. If there's some way it's possible, please tell me, and update the documentation!
How to repeat:
three hosts, host1 --sbr--> host2 --sbr--> host3
create table x (int not null primary key) engine=innodb;
set session binlog_format=ROW;
insert into x values (1);
-- same with insert...select or other dml constructs. replication (sql thread) will fail on host2 with the error mentioned above.
Suggested fix:
Update documentation to avoid the misleading statements (or implement the feature!)
