[MDEV-14793] Document innodb-lock-schedule-algorithm details Created: 2017-12-28  Updated: 2018-02-08  Resolved: 2018-02-08

Status: Closed
Project: MariaDB Server
Component/s: Documentation
Affects Version/s: N/A
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Ian Gilfillan Assignee: Ian Gilfillan
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-12837 WSREP: BF lock wait long Closed

 Description   

Ian Gilfillan Can you document that innodb-lock-schedule-algorithm is read-only variables (i.e. it can't be changed dynamically) and that VATS method is not supported on Galera.

Here what documentation should mention:

10.1, default is FCFS and InnoDB will refuse to start if VATS is used with galera.
>=10.2 default is VATS and in galera it will be changed to FCFS.



 Comments   
Comment by Ian Gilfillan [ 2017-12-28 ]

jplindst will setting innodb-lock-schedule-algorithm details to FCFS be sufficient for people currently running 10.2 (before 10.2.12 is released), or should people avoid upgrading altogether if running Galera?

Comment by Daniel Black [ 2018-02-02 ]

in https://github.com/MariaDB/server/commit/da3a3a68df34c7fef387ce890d3925166edeef2c#diff-bbb9322fe6d0355bb459fe6df3a5126c it can't be set to vats and will fail in wsrep_on_check and revert to FCFS with warning.

Comment by Ian Gilfillan [ 2018-02-02 ]

Thanks danblack I think this is documented in https://mariadb.com/kb/en/library/xtradbinnodb-server-system-variables/#innodb_lock_schedule_algorithm (have added that it produces a warning), but am waiting for clarity from jplindst or anyone else on running 10.2 Galera before this fix.

Comment by Jan Lindström (Inactive) [ 2018-02-05 ]

greenman Yes setting innodb-lock-schedule-algorithm=FCFS is sufficient.

Comment by Ian Gilfillan [ 2018-02-08 ]

Noted in the docs:
https://mariadb.com/kb/en/library/upgrading-from-mariadb-101-to-mariadb-102/#galera

Comment by Ian Gilfillan [ 2018-02-08 ]

Accidentally changed to "not a bug" when closing

Generated at Thu Feb 08 08:16:19 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.