I'll try to keep this to the point.

System: OPenVZ VPS, debian 6, 512 MB RAM, 50 GB HDD (25GB free)

I have a mysqldump dump file (3GB), that was created when the innodb database was working fine.

After purging, removing mysql and any related files/folders mariadb was installed (Actually this process has been repeated several times). Next the dump file created earlier was imported (mysql -u user -p < sql.sql)

Immediately after importing the dump, I tried to take a backup using xtrabackup, it complained of corruption and crashed.

Output of check table tableName.

| Table                        | Op    | Msg_type | Msg_text                                          |
| db.table                     | check | Warning  | InnoDB: Index "product_id" is marked as corrupted |
| db.table                     | check | error    | Corrupt                                           |

Now comes the weird part. In The mysql-error log the page, the ascii page dump has strange sentences that should not be part of my VPS let alone the database or the table :

Part of the InnoDB: Page dump in ascii and hex (16384 bytes):

A fun three-picture set of the Okavango Delta in four sizes each  Okavango Jigsaw publish                                                      open                                                

                       3@ me      < l                Z  N    Z  N       Cute Puppies is a slider with 6 different pictures of super cute puppies. 3 pictures are easy, and 3 puppy pictures are a bit harder. Have fun!  Cute Puppies publish                                                      open              

The table in question has 3 columns - INT | INT | VARCHAR(50)

A cat trans.sql | grep "super cute puppies" confirmed that the unexpected sentences were not in my DB dump.

Anybody knows why my table is corrupt ? I have even tried to do a import from an older backup with similar results. And what about those strange sentences in the page dump ??

Lastly this all began after my VPS went offline for a couple of days (SSH brute force attacks, migration to new datacenter)


Edit: Before: Mysql 5.5 | After: 5.5.42-MariaDB

I thought Repair table was not for innodb..

btw can there be a unconfigurable limit to a mysql table size for the VPS ?

Edit: The unexpected sentences were part of a website that is also hosted by the same host. Found this after googling. Not sure what it means.

  • Try REPAIR TABLE. What versions are you using (before and after)? 512MB is super-tiny, your settings in my.cnf need to be especially small. However, too small may cause troubles. Try to increase the RAM.
    – Rick James
    Commented Apr 1, 2015 at 17:18
  • Most "limits" are listed here. A table is limited to 64 terabytes, possibly more. I don't think a cloud/VM service can limit the table size without recompiling MySQL. It probably can limit disk space, which indirectly limits various sizes.
    – Rick James
    Commented Apr 1, 2015 at 18:48

1 Answer 1


I've been having the exact same issues on my OpenVZ VPS's recently. Both running Debian 7 (official OpenVZ template), both with MySQL 5.6.23 from the Dotdeb repository. Random InnoDB corrupted tables, with the dump in the error log showing strange data that is definitely not part of any of my own databases, nor any files stored in my container.

Both started only recently (within the past month or so), one server was running fine for over a year prior, the other was a brand new VPS with fresh install of Debian.

My KVM VPS's running the exact same configurations have been fine thus far.

I'm sorry I can't offer a solution, but now I at least know that this is most likely not something that I caused. It has been extremely frustrating trying to figure out what is happening.

I'll let my host know that you have been having the exact same problems. Perhaps with this info they can figure out what the heck is going on. If they and I can get to the bottom of this I'll definitely let you know.

  • The unexpected sentences are part of a website that is also hosted by the same host. Found this after googling.. I ended up taking drastic action: reinstalled the VPS and migrated to postgresql.
    – gyaani_guy
    Commented Apr 25, 2015 at 10:00
  • Yes, my host thinks it's a problem with a recent OpenVZ kernel update (the timing coincides with that start of both of our issues), perhaps a mis-mapping of inodes causing other peoples' data in the error logs. My host has also seen other examples of OpenVZ and InnoDB not playing nicely over the years. I'm separating my 1GB OpenVZ web + MySQL VPS into a 512 MB OpenVZ web server and a 512 MB KVM MySQL server. Commented Apr 27, 2015 at 3:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.