Bug #82551

Upgrade Wizard Deadlock

Added by SICOR KDL GmbH about 3 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Install Tool
Target version:
-
Start date:
2017-09-25
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
8
PHP Version:
7.1
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Hello,

with newer 8.7.x versions, at least with 8.7.7, we experience a deadlock for these DB changes:

CREATE INDEX `cache_id` ON cf_cache_imagesizes (identifier, expires)
CREATE INDEX `cache_id` ON cf_cache_imagesizes_tags (identifier)
CREATE INDEX `cache_tag` ON cf_cache_imagesizes_tags (tag)

The Error message is three times:
SQL-ERROR: Index column size too large. The maximum column size is 767 bytes.

When executed manually, it is considered a "warning" only:
1071 Specified key was too long; max key length is 767 bytes 1478 InnoDB: ROW_FORMAT=DYNAMIC requires innodb_file_format > Antelope. 1478 InnoDB: assuming ROW_FORMAT=COMPACT.

We are running Debian 9.1 with Maria 10.1 on the server.

Greetings,
Manuel


Related issues

Related to TYPO3 Core - Bug #82080: Indexes too large for some tables with utf8mb4Closed2017-08-11

Actions
Related to TYPO3 Core - Feature #80398: Make default charset and collation for new tables configurableClosed2017-03-22

Actions
#1

Updated by SICOR KDL GmbH about 3 years ago

One of our technicians stayed up last night fixing the problem on the database side by switching Maria from antelope to barracuda.

I still see a need to work on the upgrade wizards though, as I think that a database warning shouldn't deadlock an upgrade wizard entirely. Even worse, it also prevented all other wizards from showing up, so I couldn't continue with the upgrade at all.

#2

Updated by Christian Kuhn about 3 years ago

are you using utf8mb4? the index issue could be related with that.

#3

Updated by SICOR KDL GmbH almost 3 years ago

Christian Kuhn wrote:

are you using utf8mb4? the index issue could be related with that.

Indeed that's part of the problem we have on this particular server (Probably some new i-MSCP default, actually it should create schemes with utf8-general-ci). We're going to dump all schemes and reimport with the proper encoding.

I guess it's okay to close the ticket here, unless you still want to do something to prevent wizard deadlocks in cases where something like that goes wrong.

#4

Updated by Tymoteusz Motylewski over 2 years ago

  • Related to Bug #82080: Indexes too large for some tables with utf8mb4 added
#5

Updated by Tymoteusz Motylewski over 2 years ago

  • Related to Feature #80398: Make default charset and collation for new tables configurable added
#6

Updated by Tymoteusz Motylewski over 2 years ago

I saw similar errors when a db was created with utf8mb4 as default charset.
The error was thrown despite backup I was importing had correct utf8 (not mb4) used in the table create statement.

I've found 2 workarounds:
1) set default charset for db to utf-8.
2) add default row format (DYNAMIC) in the table create statement (and make sure innodb_large_prefix is enabled) https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_large_prefix

Also worth knowing is that since mysql 5.7 or mariadb 10.2, the default row format is dynamic and large_prefix is enabled.

#7

Updated by Gerrit Code Review about 2 years ago

  • Status changed from New to Under Review

Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/56440

#8

Updated by Lienhart Woitok about 2 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#9

Updated by Benni Mack about 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF