How is it possible for seo_cache database tables to disappear?

Twice now I have had seo_cache table disappear, which breaks the catalog. In neither case did I make any database or file changes between when it was working and when it stopped working. There are no other known issues with the database. Any ideas on how this could happen?

This references an issue similar to
http://www.zen-cart.com/showthread.php?89625-1146-Tables-error-after-installing-ultimate-SEO-URLs
However, in that thread this issue is more that the table gets named improperly.

divinelighting:

Twice now I have had seo_cache table disappear, which breaks the catalog. In neither case did I make any database or file changes between when it was working and when it stopped working. There are no other known issues with the database. Any ideas on how this could happen?

A check is done for each request to the store to see if the plugin is properly installed (and does not currently include a check for the "seo_cache" table). If the plugin detects something is broken, it attempts (among other things) to remove and re-install the "seo_cache" table. The only way the re-install is triggered is if the plugin settings have not been installed or accessing the database fails (intermittent connect, read, or write issues).

The "seo_cache" table can disappear if for some reason on your host the script stops running during this process (hosting issue), your user does not have permission to create tables (database permissions issue), or your database becomes unavailable during the uninstall / install process (hosting issue).

As a stop gap, you can disable removal and creation of "TABLE_SEO_CACHE" in seo.install.php. Intermittent database access issues may cause you other problems down the road - and the default settings for your plugin will be used instead of your configured ones when these are encountered. But at least the "seo_cache" table should not disappear.

Thanks lhungil for that wisdom. I have nightly directadmin backups where presumably there are moments of database inaccessibility. Should I be taking other safeguards during the backup process?

I have never used directadmin, so not sure if there is an impact there.

I do know there are applications one can use to perform "hot" or at least "warm" backups of MySQL databases. A few off the top of my head are (not an exhaustive list):

• Commercial Offerings from Oracle (Enterprise MySQL).
• Percona XtraBackup. Free with commercial support.
• Replication partner. Set up a database slave and run the backups against the slave.
• Filesystems supporting snapshots (such as LVM2). Flush db + snapshot + mysqlhotcopy (works on MyISAM tables - the default engine used in most Zen Cart installations).

Additionally, if you are using a hosting company, most keep backups of the database for you. You may want to check.

If your db user has full permission to the database, in the short term, you can get away with commenting out the lines to install / uninstall the 'seo_cache' table once the table has been created. If the problem is a temporary db loss, you might have one or two requests generate errors, but at least you would not have the whole site become broken.

Also see this post if you are using Zen cart 1.3 in a newer hosting environment (MySQL >= 5.1). Thanks to divinelighting for the reminder.

This specific change does not apply to newer versions of "Ultimate SEO URLs" on Zen Cart 1.5.