Bug #68386 | Master scans all binlogs when slave reconnects with auto positioning | ||
---|---|---|---|
Submitted: | 15 Feb 2013 1:03 | Modified: | 3 Apr 2013 14:50 |
Reporter: | Santosh Praneeth Banda | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S2 (Serious) |
Version: | mysql 5.6.10 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | auto_positioning, GTID |
[15 Feb 2013 1:03]
Santosh Praneeth Banda
[15 Feb 2013 1:08]
Yoshinori Matsunobu
This is serious since usually tens or hundreds of GBs of binary logs exist on master, and most of older binary logs are not cached in filesystem cache. And i/o thread disconnect/reconnect is not uncommon. Reading 100+GB binlogs every i/o thread reconnects is painful.
[20 Feb 2013 13:49]
Mark Callaghan
This should be more than a feature request. This probably prevents anyone from using gtid if they have one or both of: 1) many slaves per master 2) 100+ gb of binlogs per master
[20 Feb 2013 18:59]
Santosh Praneeth Banda
Change the severity level.
[21 Feb 2013 9:15]
Luis Soares
Thanks for bringing up this issue. We are aware of the problem and we are working on a fix.
[1 Mar 2013 14:34]
MySQL Verification Team
A fix was pushed in the 5.6 tree, so we close this bug.
[3 Apr 2013 14:50]
Jon Stephens
Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release. If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at http://dev.mysql.com/doc/en/installing-source.html
[3 Apr 2013 14:51]
Jon Stephens
Fixed in 5.6+. Documented as follows in the 5.6.11 and 5.7.1 changelogs: When using GTIDs and binary log auto-positioning, the master had to scan all binary logs whenever the slave reconnected (due to reasons such as I/O thread failure or a change of master) before it could send any events to slave. Now, the master starts from the oldest binary log that contains any GTID not found on the slave. Closed.