ERROR 1118 (42000): Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

Initial attempts

The first attempt to resolve the issue involved converting all columns to TEXT, as their contents are stored off-page. That didn't work: there were too much columns, and even the references consumed too much space.

Next, I considered changing the row format, which can sometimes resolve this issue. Unfortunately, the customer had already set it to DYNAMIC, the best available option for this scenario. No gains there.

InnoDB page size

The obvious fix for running out of space is creating more space. MySQL has an innodb_page_size parameter that defines the tablespace's page size. The data file consists of virtual pages, which are completely overwritten each time a change is made.

MySQL stores two rows in a page, meaning that when you update one, you're effectively saving two. This is an important setting for performance, but in this case, it's relevant for another reason: a row can use at most half of the InnoDB page size.

The innodb_page_size setting is somewhat misleading because its value is stored inside the ibdata1 file, which contains your MySQL data. Once the first page has been written, you can't change the value anymore. All pages inside the file must be the same size.

Thus, changing it means recreating everything, which involves a process like this:

mysqldump --all-databases > backup.sql
systemctl stop mysql
rm -rf /var/lib/mysql/*
mysqld --user mysql --initialize --innodb-page-size=32K
systemctl start mysql
cat backup.sql | mysql

However, on our Percona PXC cluster, I was met with an error:

2025-03-04T13:50:32.929013Z 0 [ERROR] [MY-010872] [InnoDB] InnoDB: Invalid page size=32768.

That was surprising, as the documentation lists 32768 (32K) as a valid option.

The real problem

I spent way too much time debugging this because the error message didn't lead to any useful documentation. It turns out that Percona PXC cluster does not allow changing innodb_page_size. They only accept the default value of 16K, and any other setting will fail.

From (an older) Percona PDF manual:

Only the default 16 KB page size (innodb_page_size=16384) is accepted until the relevant upstream bug is fixed by Codership (see https://github.com/codership/galera/issues/398). All other sizes will report Invalid page size and shut down (the server will not start up).

Newer documentation doesn't seem to mention this anymore, but it still applies.

Watch out with innodb_strict_mode

While researching this issue, I found many Stack Overflow posts suggesting that disabling innodb_strict_mode might help. Be very careful with this!

Disabling strict mode only replaces the critical error with a warning. You'll be able to create the table, but the underlying issue remains: the rows are still too large.

It may not fail immediately, but at some point, an INSERT or UPDATE operation will trigger an error if it exceeds the maximum size. This shifts the failure from a controlled event (such as during deployment) to a random action that a user might perform — not ideal.