-
Bug
-
Resolution: Fixed
-
Low
-
6.3.4, 6.6.10, 6.13.5
-
7
-
Severity 2 - Major
-
4
-
Background
When Confluence starts up, it verifies schemas for all tables with active objects (AO), and modifies / adds fields if required. For example, if a new version of a plugin is installed, and this plugin introduces a new field in AO class, the corresponding table will be updated and new column will be created.
The problem
For MySQL, migration procedure has a bug and updates several tables on every boot like this:
[[SQLAction{statement='ALTER TABLE AO_BAF3AA_AOINLINE_TASK CHANGE COLUMN BODY BODY LONGTEXT DEFAULT NULL', undoAction=null}]]
[[SQLAction{statement='ALTER TABLE AO_88BB94_BATCH_NOTIFICATION CHANGE COLUMN PAYLOAD PAYLOAD LONGTEXT NOT NULL', undoAction=null}]]
[[SQLAction{statement='ALTER TABLE AO_21D670_WHITELIST_RULES CHANGE COLUMN EXPRESSION EXPRESSION LONGTEXT NOT NULL', undoAction=null}]]
...etc...
It is not a serious issue for Confluence with one node (it only increases boot time), but in case of 2+ nodes it could lead Confluence to deadlock. Example:
- The first node is executing slow query (which takes a lot of time) on AO_BAF3AA_AOINLINE_TASK table
- The second node is being restarted and is trying to modify AO_BAF3AA_AOINLINE_TASK. But this operation is blocked while the first node does not finish all SQL queries on AO_BAF3AA_AOINLINE_TASK
- The first node tries to run more SQL queries on AO_BAF3AA_AOINLINE_TASK, but all of them are blocked by DDL operation on the second node.
As a result, all threads could be blocked.
Expected behaviour
Confluence should not run any DDL operations on boot if tables do not require changes.
Technical details
It happens in SchemaGenerator.migrate
- incorporates
-
-
- Closed
-
- is related to
-
-
- Closed
-
- mentioned in
-
Page Failed to load
-
Page Failed to load
-
Page Failed to load
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-