MySQL Bugs: #74071: 69097 has been fixed in 5.6.21 but not documented

Bug #74071	69097 has been fixed in 5.6.21 but not documented
Submitted:	25 Sep 2014 12:33	Modified:	30 Sep 2014 10:59
Reporter:	Laurynas Biveinis (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Documentation	Severity:	S3 (Non-critical)
Version:	5.6.21	OS:	Any
Assigned to:	David Moss	CPU Architecture:	Any

Description:
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-21.html does not mention bug 69097, option simplified-binlog-gtid-recovery, nor any other similar bug. But it appears to be fixed there with rev 6110.

How to repeat:
Inspect bug 69097, commit 6110, MySQL 5.6.21 behaviour.

Suggested fix:
Document bug 69097 fix for 5.6.

Hello Laurynas,

Thank you for the report.

Thanks,
Umesh

// from bzr log

[ushastry@ushastry mysql-5.6]$ bzr log -r6110
------------------------------------------------------------
revno: 6110
committer: Bill Qu <bill.qu@Oracle.com>
branch nick: mysql-5.6
timestamp: Fri 2014-08-08 10:12:49 +0800
message:
  BUG#16741603: MYSQLD SCANS ALL BINARY LOGS ON CRASH RECOVERY
  
  Mysql server iterates backwards through binary logs, looking for
  the last binary log that contains a Previous_gtids_log_event for
  gathering the set of gtid_executed, and iterates forwards through
  binary logs, looking for the first binary log that contains both
  Previous_gtids_log_event and gtid_log_event for gathering the set
  of gtid_purged on crash recovery. Mysql server also iterates
  forwards through binary logs, looking for the first binary log
  that contains both Previous_gtids_log_event and gtid_log_event
  for gathering the set of gtid_purged when purging binary logs.
  This may take very long time if the mysql server has many binary
  logs and almost all of them are out of filesystem cache.
  
  To fix the problem, introduce an option
  'simplified-binlog-gtid-recovery', whose default value is false.
  If the option is enabled, we do this: In the first scan (where
  it iterates over binary logs from the newest to the oldest):
  If the last binary log does not contain any GTID event, do not
  read any more binary logs, and set GTID_EXECUTED = '' and
  GTID_PURGED = ''. Otherwise, initialize GTID_EXECUTED as usual.
  Then, in the second scan (where it iterates from the oldest to
  the newest): If the first binary log does not contain any GTID
  event, do not read any more binary logs, and set GTID_PURGED = ''.

Thanks for your feedback, indeed this was missing from the page you linked to. The following has been added with commit 4352:
The new variable simplified_binlog_gtid_recovery can be used to change the way binary log files are searched for previous GTIDs during recovery, speeding up the process when a large number of binary log files exist.