Comment 3 for bug 1507812

There can be several variants of fix:

1) Do not ignore GTID related options on executing upgrade scripts. But all upgrade sql statements will be executed on slaves too, and this can be not desirable.

2) Force binlog_gtid_simple_recovery = 0 on first start after upgrade. This will work but can lead to lag during first start if there are big amount of binary log records.

3) Tell somehow to the server what exactly binary log file was the last just before the upgrade. In this case we could start usual procedure of searching gtid parameters with binlog_gtid_simple_recovery = 1 but use the passed binlog file as the last binary log for searching process.