Database Migration Fails for MariaDB >10.6 #3960

Closed
opened 2026-02-05 07:58:22 +03:00 by OVERLORD · 3 comments
Owner

Originally created by @bertineer on GitHub (Aug 10, 2023).

Describe the Bug

On a clean installation of BookStack 23.06.2 the database migration failed:
2019_07_07_112515_add_template_support ........................... 29ms DONE
2019_08_17_140214_add_user_invites_table ......................... 40ms DONE
2019_12_29_120917_add_api_auth ................................... 54ms DONE
2020_08_04_111754_drop_joint_permissions_id ...................... 15ms FAIL

In Connection.php line 760:
SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes (SQL: alter table 'joint_permissions' add primary key ('role_id', 'entity_type', 'entity_id', 'action'))
In Connection.php line 545:
SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes

Steps to Reproduce

On a system with MariaDB >10.6, complete a manual installation via git clone, composer, generate new key, and proceed with migration.

Expected Behaviour

Complete the fresh migration

Screenshots or Additional Context

To successfully run the migration, I needed to manually set the engine in the database configuration by editing app/Config/database.php and changing 'engine' => null, to 'engine' => 'InnoDB', to confirm that this was an issue.

I then cleaned it up a bit and used an env variable:
'engine' => env('DB_ENGINE', null), in app\Config\database.php
DB_ENGINE=innodb in the .env file

This seems to be an issue with MariaDB not defaulting storage engine to InnoDB

Browser Details

115.0.1901.200 (Official build) (64-bit) on Windows 11

Exact BookStack Version

v23.06.2

PHP Version

8.1.21

Hosting Environment

CloudLinux OS 3.10.0-962.3.2.lve1.5.81.el7.x86_64
Apache 2.4.57
PHP 8.1.21
MariaDB 10.6.14-MariaDB-cll-lve-log (collation utf8mb4_general_ci)

Originally created by @bertineer on GitHub (Aug 10, 2023). ### Describe the Bug On a clean installation of BookStack 23.06.2 the database migration failed: `2019_07_07_112515_add_template_support ........................... 29ms DONE` `2019_08_17_140214_add_user_invites_table ......................... 40ms DONE` `2019_12_29_120917_add_api_auth ................................... 54ms DONE` **`2020_08_04_111754_drop_joint_permissions_id ...................... 15ms FAIL`** `In Connection.php line 760:` `SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes (SQL: alter table 'joint_permissions' add primary key ('role_id', 'entity_type', 'entity_id', 'action'))` `In Connection.php line 545:` `SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes` ### Steps to Reproduce On a system with MariaDB >10.6, complete a manual installation via git clone, composer, generate new key, and proceed with migration. ### Expected Behaviour Complete the fresh migration ### Screenshots or Additional Context To successfully run the migration, I needed to manually set the engine in the database configuration by editing **`app/Config/database.php`** and changing `'engine' => null,` to `'engine' => 'InnoDB',` to confirm that this was an issue. I then cleaned it up a bit and used an env variable: `'engine' => env('DB_ENGINE', null),` in **`app\Config\database.php`** `DB_ENGINE=innodb` in the **`.env`** file This seems to be an issue with MariaDB not defaulting storage engine to `InnoDB` ### Browser Details 115.0.1901.200 (Official build) (64-bit) on Windows 11 ### Exact BookStack Version v23.06.2 ### PHP Version 8.1.21 ### Hosting Environment CloudLinux OS 3.10.0-962.3.2.lve1.5.81.el7.x86_64 Apache 2.4.57 PHP 8.1.21 MariaDB 10.6.14-MariaDB-cll-lve-log (collation utf8mb4_general_ci)
OVERLORD added the 🐛 Bug label 2026-02-05 07:58:22 +03:00
Author
Owner

@ssddanbrown commented on GitHub (Aug 10, 2023):

Hi @bertineer, Thanks for reporting.
Do you know if the config for MariaDB was changed in your environment?
As far as I'm aware, MariaDB does default to InnoDB, so just trying to confirm the scenario at play here.

@ssddanbrown commented on GitHub (Aug 10, 2023): Hi @bertineer, Thanks for reporting. Do you know if the config for MariaDB was changed in your environment? As far as I'm aware, MariaDB does default to InnoDB, so just trying to confirm the scenario at play here.
Author
Owner

@bertineer commented on GitHub (Aug 11, 2023):

@ssddanbrown you’re correct, MariaDB does default (since version 10.2) the engine to InnoDB.

I took a look at my.conf and see that the default engine was overwritten to MyISAM:

default-storage-engine = MyISAM

@bertineer commented on GitHub (Aug 11, 2023): @ssddanbrown you’re correct, MariaDB does default (since version 10.2) the engine to InnoDB. I took a look at my.conf and see that the default engine was overwritten to MyISAM: **`default-storage-engine = MyISAM`**
Author
Owner

@bertineer commented on GitHub (Aug 11, 2023):

I would consider this closed, as it was misconfiguration of my environment. I hope this will help others with any future installation issues 🥸

@bertineer commented on GitHub (Aug 11, 2023): I would consider this closed, as it was misconfiguration of my environment. I hope this will help others with any future installation issues 🥸
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#3960