[GH-ISSUE #1287] Migration 20201130224000 causes Mysql Row Size too large errors #896

New issue

Closed

opened 2026-03-03 02:04:28 +03:00 by kerem · 1 comment

kerem commented

2026-03-03 02:04:28 +03:00

Owner

Originally created by @tgrecojr on GitHub (Dec 29, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1287

Subject of the issue

Upgrading to the latest Bitwarden Docker (sha256:0f967fc9bfd40b137e6d7171bb945f03f4ab7d26a98775f69730387c3b8e344b) won't allow the server to start because running migration 20201130224000 causes the following MySQL error:

BitwardenRS Logs:

[2020-12-29 13:13:42.009][bitwarden_rs::util][WARN] Can't connect to database, retrying: DieselMigError.
[CAUSE] QueryError(
DatabaseError(
__Unknown,
"Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs",
),
)

MySQL Logs:

2020-12-29 13:29:26 185927 [ERROR] InnoDB: Cannot add field security_stamp in table bitwarden.users because after adding it, the row size is 8810 which is greater than maximum allowed size (8126 bytes) for a record on index leaf page.

Your environment

Bitwarden_rs version:
Install method: docker: bitwardenrs/server-mysql:latest
Clients used: N/A
Reverse proxy and version: N/A
Version of mysql/postgresql: 10.5.8-MariaDB-1:10.5.8+maria~focal
Other relevant information:

Steps to reproduce

Pull the latest docker image and start. Server performs migrations and fails.

Expected behaviour

Server should start and all migrations should succeed

Actual behaviour

Migration failed with MySQL error: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

Relevant logs

),
Running migration 20201130224000,
Executing migration script 20201130224000/up.sql,
[2020-12-29 13:20:54.225][bitwarden_rs::util][WARN] Can't connect to database, retrying: DieselMigError.,
[CAUSE] QueryError(,
DatabaseError(,
__Unknown,,
"Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs",,
),,
),

Originally created by @tgrecojr on GitHub (Dec 29, 2020). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1287 ### Subject of the issue Upgrading to the latest Bitwarden Docker (sha256:0f967fc9bfd40b137e6d7171bb945f03f4ab7d26a98775f69730387c3b8e344b) won't allow the server to start because running migration 20201130224000 causes the following MySQL error: BitwardenRS Logs: [2020-12-29 13:13:42.009][bitwarden_rs::util][WARN] Can't connect to database, retrying: DieselMigError. [CAUSE] QueryError( DatabaseError( __Unknown, "Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs", ), ) MySQL Logs: 2020-12-29 13:29:26 185927 [ERROR] InnoDB: Cannot add field `security_stamp` in table `bitwarden`.`users` because after adding it, the row size is 8810 which is greater than maximum allowed size (8126 bytes) for a record on index leaf page. ### Your environment * Bitwarden_rs version: * Install method: docker: bitwardenrs/server-mysql:latest * Clients used: N/A * Reverse proxy and version: N/A * Version of mysql/postgresql: 10.5.8-MariaDB-1:10.5.8+maria~focal * Other relevant information: ### Steps to reproduce Pull the latest docker image and start. Server performs migrations and fails. ### Expected behaviour Server should start and all migrations should succeed ### Actual behaviour Migration failed with MySQL error: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs ### Relevant logs ), Running migration 20201130224000, Executing migration script 20201130224000/up.sql, [2020-12-29 13:20:54.225][bitwarden_rs::util][WARN] Can't connect to database, retrying: DieselMigError., [CAUSE] QueryError(, DatabaseError(, __Unknown,, "Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs",, ),, ), 2020-12-29 13:29:26 185927 [ERROR] InnoDB: Cannot add field `security_stamp` in table `bitwarden`.`users` because after adding it, the row size is 8810 which is greater than maximum allowed size (8126 bytes) for a record on index leaf page.

kerem closed this issue

2026-03-03 02:04:28 +03:00

kerem commented

2026-03-03 02:04:29 +03:00

Author

Owner

@tgrecojr commented on GitHub (Dec 29, 2020):

I am going to close this issue because I was able to solve my own problem. Putting the solution here just in case someone else comes across this. My particular problem is that my MySQL database was created prior to 10.2 and the underlying BW tables were of type 'Compact'. Moving these to 'Dynamic' solved the issue.

Find the tables using this query:

SELECT NAME, ROW_FORMAT FROM information_schema.INNODB_SYS_TABLES WHERE ROW_FORMAT IN('Redundant', 'Compact') AND NAME NOT IN('SYS_DATAFILES', 'SYS_FOREIGN', 'SYS_FOREIGN_COLS', 'SYS_TABLESPACES', 'SYS_VIRTUAL', 'SYS_ZIP_DICT', 'SYS_ZIP_DICT_COLS');

Then issue an alter table statement:

ALTER TABLE ROW_FORMAT=DYNAMIC;

If you want to put it all together:

select concat('ALTER TABLE ',SUBSTRING_INDEX(name,'/',-1), ' ROW_FORMAT=DYNAMIC;') FROM information_schema.INNODB_SYS_TABLES WHERE ROW_FORMAT IN('Redundant', 'Compact') AND NAME NOT IN('SYS_DATAFILES', 'SYS_FOREIGN', 'SYS_FOREIGN_COLS', 'SYS_TABLESPACES', 'SYS_VIRTUAL', 'SYS_ZIP_DICT', 'SYS_ZIP_DICT_COLS');

After altering the tables, I was able to do the upgrade and the migrations succeeded.

@tgrecojr commented on GitHub (Dec 29, 2020): I am going to close this issue because I was able to solve my own problem. Putting the solution here just in case someone else comes across this. My particular problem is that my MySQL database was created prior to 10.2 and the underlying BW tables were of type 'Compact'. Moving these to 'Dynamic' solved the issue. Find the tables using this query: SELECT NAME, ROW_FORMAT FROM information_schema.INNODB_SYS_TABLES WHERE ROW_FORMAT IN('Redundant', 'Compact') AND NAME NOT IN('SYS_DATAFILES', 'SYS_FOREIGN', 'SYS_FOREIGN_COLS', 'SYS_TABLESPACES', 'SYS_VIRTUAL', 'SYS_ZIP_DICT', 'SYS_ZIP_DICT_COLS'); Then issue an alter table statement: ALTER TABLE <table> ROW_FORMAT=DYNAMIC; If you want to put it all together: select concat('ALTER TABLE ',SUBSTRING_INDEX(name,'/',-1), ' ROW_FORMAT=DYNAMIC;') FROM information_schema.INNODB_SYS_TABLES WHERE ROW_FORMAT IN('Redundant', 'Compact') AND NAME NOT IN('SYS_DATAFILES', 'SYS_FOREIGN', 'SYS_FOREIGN_COLS', 'SYS_TABLESPACES', 'SYS_VIRTUAL', 'SYS_ZIP_DICT', 'SYS_ZIP_DICT_COLS'); After altering the tables, I was able to do the upgrade and the migrations succeeded.