Note: Comments in MySQL Bug #50413 suggest that innodb_autoinc_lock_mode settings 0 and 1 are equivalent in this respect. I’d also like to know whether this parameter is at all relevant outside statement-based replication (that is, when innodb_autoinc_lock_mode=2 could be safe to use). With the setting 2, InnoDB does not acquire any auto-increment lock within the transaction. With the settings 0 or 1, InnoDB will hold a lock until the end of the current statement. This would suggest that the setting only matters in statement-based replication.
He wants to deprecate and remove the innodb_autoinc_lock_mode system variable, after setting it to 2 by default (MDEV-27844). For that to happen, the dependency on this variable would have to be removed for replication and binary logging.
We have two bugs in replication:
- binlog_format=STATEMENT is not being refused, even if it is unsafe in innodb_autoinc_lock_mode=2.
- binlog_format=MIXED incorrectly uses STATEMENT-level replication for the affected operations