Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL)
Description
In MDEV-17073, marko suggested that innodb_autoinc_lock_mode may only be needed for statement-based replication:
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
Attachments
Issue Links
- blocks
-
MDEV-27844 Set innodb_autoinc_lock_mode=2 by default, and deprecate it
- Stalled
- relates to
-
MDEV-10170 Misleading "Statements writing to a table with an auto-increment column after selecting from another table are unsafe" on DELETE ... SELECT
- Confirmed
-
MDEV-17073 INSERT…ON DUPLICATE KEY UPDATE became more deadlock-prone
- Closed