Database error when upgrading to 9.0.0

Hi @nothin7,

That looks like an issue with upgrading the plugin database tables. Could be the database is partially upgraded because of some other database issue. As a result every request to the site is probably reattempting the database upgrade.

Please share the following info:

Log into phpMyAdmin and let us know the exact list of currently existing SolSec plugin tables. These tables can be recognized because their names all start with “wp_itsec_” There used to be 11 tables and as of plugin release 9.0.0 (after database upgrade) 14 tables should exist.

If the SolSec plugin UI is functioning/visible also follow the steps below. Add the line below to the wp-config.php file (if not already):

define('ITSEC_DEBUG', true);

This will add a new?Debug?(sub)menu option to the Security menu option. Log into the WordPress backend and navigate to:

Security > Debug

In the?Settings?section of the Debug page select?global?from the dropdown list. Then click on the?Load button.

Look for the “build” setting and it’s value. It should be 4128. If it’s still 4127 or less the database upgrade did not complete.

+++ To prevent any confusion, I’m not SolidWP +++

Apologies. Updated wrong topic.

• This reply was modified 12 months ago by nlpro.

Hi @nlpro,

Thanks for your response. Not sure if your “Updated wrong topic” comment refers to the one you changed to that or both comments, but a random database issue seems unlikely since it’s happening on all of my sites, not just one. Anyone, I checked one, my build is 4128, and I have all 14 tables:

wp_itsec_bans
wp_itsec_dashboard_events
wp_itsec_dashboard_lockouts
wp_itsec_distributed_storage
wp_itsec_fingerprints
wp_itsec_firewall_rules
wp_itsec_geolocation_cache
wp_itsec_lockouts
wp_itsec_logs
wp_itsec_mutexes
wp_itsec_opaque_tokens
wp_itsec_temp
wp_itsec_user_groups
wp_itsec_vulnerabilities

Hi @nothin7,

I accidentally entered a post for another topic in here but I was able to change the content of that post in time ?? Apologies for the confusion.

Based on your feedback I probably need to change my theory. Looks like the database upgrade completed just fine. It also means you probably only get the error once in an env. It doesn’t repeat over an over again in the PHP log?

Might be the error is the result of a concurrent (simultaneous) request (2 requests, both triggering the database upgrade simultaneously). If so it’s nothing to worry about.

Hi @nothin7,

I hope the information provided by nlpro helped resolve the issue. Tracking notifications on this forum can become tricky over time, and since we haven’t received a response, I’ll mark this post resolved.

If you still require further assistance, feel free to open a new support topic, and we’d be happy to assist.

Thank you!

The error doesn’t repeat for the same site, but it did happen for all 100+ sites a single time, right when I updated. The chance of some database fluke happening that many times is infinitesimally small. Anyway, my sites appear to be loading fine, just wanted to let you know.

Hi @nothin7,

Ah ok, I see.

I’ve been looking into this error on the internet and it seems to be an index related MySQL database specific issue. So there is nothing wrong with the alter table statement. Just to be sure, could you provide the output of the following MySQL statement:

SHOW CREATE TABLE wp_itsec_geolocation_cache;

There is something related to the PRIMARY KEY of this table I want to check in one of your error envs.

Sure, here’s the exact output on two sites I tried:

CREATE TABLE wp_itsec_geolocation_cache (
location_id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
location_host varchar(40) NOT NULL,
location_lat decimal(10,8) NOT NULL,
location_long decimal(11,8) NOT NULL,
location_label varchar(255) NOT NULL,
location_credit varchar(255) NOT NULL,
location_time datetime NOT NULL,
location_meta text NOT NULL,
PRIMARY KEY (location_id),
UNIQUE KEY location_host (location_host),
KEY location_time (location_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

Hi @nothin7,

The PRIMARY KEY part, as well as the rest of the table definition looks just fine. Even the new column (location_meta) is there. So I am confident all is fine.