Today, I worked on a ticket for a customer with a Craft 4.x CMS that created a MySQL table with a staggering 270 columns.\nMost of them were of type TEXT, but it also contained about 50 VARCHAR columns of varying lengths.\nAttempting to import the table resulted in a Row Size Too Large error.
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.\nThe 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.
The obvious fix for running out of space is creating more space.\nMySQL has an innodb_page_size parameter that defines the tablespace's page size.\nThe 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.\nThis 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.
\nThe 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.\nAll pages inside the file must be the same size.
Thus, changing it means recreating everything, which involves a process like this:
\nmysqldump --all-databases > backup.sql\nsystemctl stop mysql\nrm -rf /var/lib/mysql/*\nmysqld --user mysql --initialize --innodb-page-size=32K\nsystemctl start mysql\ncat backup.sql | mysql\nHowever, on our Percona PXC cluster, I was met with an error:
\n2025-03-04T13:50:32.929013Z 0 [ERROR] [MY-010872] [InnoDB] InnoDB: Invalid page size=32768.\nThat was surprising, as the documentation lists 32768 (32K) as a valid option.
I spent way too much time debugging this because the error message didn't lead to any useful documentation.\nIt turns out that Percona PXC cluster does not allow changing innodb_page_size.\nThey only accept the default value of 16K, and any other setting will fail.
From (an older) Percona PDF manual:
\n\n\nOnly 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).\nAll other sizes will report Invalid page size and shut down (the server will not start up).
\n
Newer documentation doesn't seem to mention this anymore, but it still applies.
\ninnodb_strict_modeWhile 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.
\nIt 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.