Bug #73744 rbr_exec_mode is not documented

Submitted: 27 Aug 2014 16:24 Modified: 10 Oct 2014 16:06
Reporter: Jaime Crespo (OCA) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Documentation Severity:S3 (Non-critical)
Version:5.7 OS:Any
Assigned to: David Moss CPU Architecture:Any

[27 Aug 2014 16:24] Jaime Crespo
Description:
rbr_exec_mode, present as a global and session variable on MySQL 5.7.4 is not documented on the release notes nor on http://dev.mysql.com/doc/refman/5.7/en/mysqld-option-tables.html (and equivalent places). I run into this when doing a diff between the configuration options of 5.6 and 5.7: http://dbahire.com/changes-in-configuration-of-global-variables-between-mysql-5-6-20-and-m... 

How to repeat:
Search for rbr_exec_mode on the release notes for MySQL 5.7 or its server variables reference. 

There are mentions of the IDEMPOTENT mode (here for NDB http://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#sysvar_slave_exec_mo... and http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-0.html for mysqlbinlog) but I only found the variable rbr_exec_mode documented on this developer blog: http://geek.rohitkalhans.com/2013/05/mysqlbinlog-idemmpotent-mode.html

Suggested fix:
Check when it was really added, add an entry on the release notes and document its usage on the server variables reference.
[27 Aug 2014 18:27] MySQL Verification Team
Thank you for the bug report.
[10 Oct 2014 16:06] David Moss
Thanks for your feedback, this is now documented as follows:
rbr_exec_mode

This variable switches the server between IDEMPOTENT mode and STRICT mode. IDEMPOTENT mode causes suppression of duplicate-key and no-key-found errors. This mode is useful when replaying a row-based binary log on a server that causes conflicts with existing data. mysqlbinlog uses this mode when you set the --idempotent option by writing the following to the output:

SET SESSION RBR_EXEC_MODE=IDEMPOTENT;

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.038 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.