I am trying to import a 15 MB mySQL DB in phpMyAdmin but I get an error. How can I fix this?

November 23, 2016 3.2k views
MySQL Ubuntu 16.04
eightysix
By:
eightysix

This is the error I get:

#1118 - 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.

I searched the error and found some people talking about adding this to /etc/mysql/my.cnf

innodb_log_file_size = 512M

I did that and restarted Apache but I still get the error. I've also updated my php.ini file with:

memory_limit = 600M

I'm running a 1GB / 30GB Disk Ubuntu droplet. Is there something I am missing?

6 comments
  • xMudrii November 23, 2016

    That doesn't sound like a problem with phpMyAdmin.
    If you created database in advance before importing, make sure that it's the same engine (InnoDB, MyISAM) as original one.

  • ryanpq MOD November 23, 2016

    When changing your my.cnf you'll need to restart the MySQL service, restarting apache will have no effect:

    service mysql restart
  • eightysix November 23, 2016

    @ryanpq That's probably my issue but when I run the restart I get this:

    Job for mysql.service failed because the control process exited with error code. See "systemctl status mysql.service" and "journalctl -xe" for details.

    When I run systemctl status mysql.service I see this:

    Nov 23 20:08:29 lamp-1gb-tor1-01 systemd[1]: Stopped MySQL Community Server.
Nov 23 20:08:29 lamp-1gb-tor1-01 systemd[1]: Starting MySQL Community Server...
Nov 23 20:08:29 lamp-1gb-tor1-01 mysqld[8026]: mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 23!
Nov 23 20:08:29 lamp-1gb-tor1-01 mysqld[8026]: mysqld: [ERROR] Fatal error in defaults handling. Program aborted!

    What is the preceding group that is being referred to?

  • eightysix November 23, 2016

    @ryanpq Ok, I found out what groups are and added this to my.cnf:

    [mysqld]
innodb_log_file_size = 512M

    This allowed me to restart mySQL successfully, however, I am still getting the error.

  • ryanpq MOD November 23, 2016

    The specific error you ran into isn't one I've encountered before myself but doing some searching led me to this Stackoverflow thread which included an answer that worked for another user who encountered the "Row size too large" error you're seeing.

  • eightysix November 23, 2016

    I tried adding this to my.cnf:

    innodb_file_per_table
innodb_file_format = Barracuda

    I also altered the table to use ROW_FORMAT = COMPRESSED.

    Unfortunately this did not work. I exported a copy of my DB without any content (just the structure) and tried importing that. When I tried that, I got the same error regarding row size. I only have a single table but it has 163 columns. I don't understand why the error is regarding row size when I'm not even importing any rows!

    I've set most of them to be TINYTEXT, thinking that would use less memory than VARCHAR, but that doesn't seem to matter.

Log In to Comment
1 Answer
trevorweir November 24, 2016

I believe that the error is trying to say that when you add up the sizes of your 163 fields, they are larger than the 8126 that your current configuration is allowed.

You are actually attempting to create a row definition or place holder for the data which will have 163 different columns/fields whose total data width is larger than 8126.

Since you are maxing out at 8126, you might look at changing your innodb page size which is usually about double the row max. It's currently at 16K. I have heard that it can be changed to 32 or even 64K.
Or alternately, you can vertically split the table by putting the most important used data in table A and the least used important data in table A1 then linking them in reports and elsewhere via a primary->foreign key.
If you just copy paste the create table statement here, it may be obvious to others here as to why the estimated width is larger than the allowed 8K.

On this page: https://dev.mysql.com/doc/refman/8.0/en/innodb-restrictions.html

I see this example which might visually prove to be helpful to you:
mysql> CREATE TABLE t (a VARCHAR(8000), b VARCHAR(10000),
-> c VARCHAR(10000), d VARCHAR(10000), e VARCHAR(10000),
-> f VARCHAR(10000), g VARCHAR(10000)) ENGINE=InnoDB;
ERROR 1118 (42000): Row size too large. The maximum row size for the
used table type, not counting BLOBs, is 65535. You have to change some
columns to TEXT or BLOBs

Reply
  • eightysix November 24, 2016

    @trevorweir Thanks for your input! I found a work-around by importing my largest table in batches, though it was tedious and time consuming splitting it all up.

    Seeing as this worked but attempting to upload the SQL in one big file didn't, I'm pretty sure now that the issue is with my server and not the database itself, though as you mentioned, it could be optimized using foreign keys. It would just require a lot more development time that my team isn't really able to invest in at this point.

    Now that I have the table structure, I've started importing the content. It seems to be taking a while though (it is about 14MB) and I'm starting to think I may need to resize my droplet (it is only 1GB right now).

    I also want to try increasing the innodb_page_size like you suggested. Is there any risk in doing that?

    • eightysix November 24, 2016

      So I tried innodb_page_size = 32K and I wasn't able to restart mysql. It just kept failing.

      Nov 24 20:34:32 systemd[1]: Stopped MySQL Community Server.
Nov 24 20:34:32 systemd[1]: Starting MySQL Community Server...
Nov 24 20:34:33 systemd[1]: mysql.service: Main process exited, code=exited, status=1/FAILURE

      I've resized my droplet to be 2GB of memory but the import is still taking forever. I wonder... do I require a "High Memory" droplet? The DB is about 14MB and we'll be updating it daily.

Have another answer? Share your knowledge.

Related Questions