Migration 20201130224000 causes Mysql Row Size too large errors #1524

Closed
opened 2025-10-09 17:18:11 +03:00 by OVERLORD · 1 comment
Owner

Originally created by @tgrecojr on GitHub.

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.

Originally created by @tgrecojr on GitHub. ### 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.
Author
Owner

@tgrecojr commented on GitHub:

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: 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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#1524