Migration of database colums failed –> website not avaiable

Recently WP Statistics asked for 3 different kinds of updates. It went without problems on 2 websites. On a 3rd website I started with “migration of visitor data column”. The migration started, the counter went up, but stopped at a certain point in time. Unfortunately the process didn’t run safely in the background. After a while I noticed, that the website was no longer accessible. It always redirects to <domain>/wp-admin/install.php and shows the installer interface 😱. I looked into phpMyAdmin and saw an error message stating basically that too many database queries has been issued and access to the database has been denied. That’s why the installer was shown. I deactivated WP statistics via ftp and after a while the website was available again. I activated WP Statistics again – the same problem occurred. I de-installed WP statistics and installed it again, but the same problem occurred again! It seems that WP Statistics does not clean the database properly when it is de-installed. Any advice what to do now? I could manually delete all WP statistics related database tables (as far as I can tell from the name). But usually it doesn’t feel good to manually manipulate the database. So – what can I do? Thank you. Christian Hi @cortlieb , We’re sorry about this experience. We’ve identified the root cause, the background migration process can overwhelm the database on certain hosting configurations, which is what caused your site to become inaccessible. This problem is often related to hosting resource limits. Before applying the fix below, we strongly recommend checking the following with your hosting provider to prevent it from happening again: PHP Memory Limit: Should be at least 256M . You can check this in Tools > Site Health > Info > Server once your site is back up. If it’s lower, ask your host to increase it or add define('WP_MEMORY_LIMIT', '256M'); to your wp-config.php . PHP Max Execution Time: Should be at least 120 seconds. MySQL Max Connections: On shared hosting this can be very low. The migration runs many database queries in quick succession. Ask your host if there is a limit on simultaneous database connections or queries per second, and if so, whether it can be increased. WP-Cron: The migration relies on WordPress cron. Some hosts disable or throttle WP-Cron. Ask your host to confirm cron is enabled and not rate-limited. To restore your site, please follow these steps using phpMyAdmin: Log in to your hosting control panel and open phpMyAdmin Select your WordPress database Go to the SQL tab and run the following queries one by one: -- Step 1: Remove all queued migration batch data DELETE FROM wp_options WHERE option_name LIKE 'wp_statistics_visitor_columns_migrator_batch_%'; DELETE FROM wp_options WHERE option_name LIKE 'wp_statistics_update_visitors_source_channel_batch_%'; -- Step 2: Remove process locks DELETE FROM wp_options WHERE option_name LIKE '%wp_statistics_visitor_columns_migrator_process_lock%'; DELETE FROM wp_options WHERE option_name LIKE '%wp_statistics_update_visitors_source_channel_process_lock%'; -- Step 3: Remove status flags DELETE FROM wp_options WHERE option_name IN ( 'wp_statistics_update_visitors_source_channel_status', 'wp_statistics_visitor_columns_migrator_status' ); -- Step 4: Reset migration tracking DELETE FROM wp_options WHERE option_name = 'wp_statistics_jobs'; Note: If your table prefix is not the default wp_ , replace wp_options with your actual prefix (e.g. xyz_options ). You can check this in your wp-config.php file under $table_prefix . If you previously deactivated WP Statistics via FTP, you can now reactivate it from Plugins > Installed Plugins in your admin. The migration will no longer auto-run. The migration prompt may reappear in the admin area. Please do not start it again until you’ve confirmed the hosting resources above are adequate, or until we release an update with improved handling for large databases. We’ve escalated this matter to our development team and we will follow up with you once a permanent fix is available. We understand how critical site availability is and we take this seriously. Please let us know if this resolves the issue or if you need any further assistance. Hi @gandomi ; thank you for your reply! Some data from hosting: – PHP Memory Limit: 512 M – PHP Max Execution Time: 3600 s – MySQL Max Connections: 2048 (you didn’t gave a limit, but this doesn’t sound like “very low” to me) – WP-Cron: enabled I executed the database commands you gave. Afterwards I neglected your recommendation to not run the migration again, mainly because I was under the impression that the hosting requirements seems to be fulfilled. Unfortunately I ran into the same issues (as described in my 1st post) again. This time it seems to be even more tricky, since cron-tasks reproduced the issue, when I was under impression, it was solved already by deactivation the plugin again. I removed the cron-tasks, cleaned the database and removed the plugin completely. I think the only way is to wait for the “update with improved handling for large databases.”. Any idea when it will be available? BR Christian This reply was modified 3 months, 1 week ago by cortlieb . This reply was modified 3 months, 1 week ago by cortlieb . Reason: typos, wrong wording Hi Christian, Thank you for the detailed follow-up and for sharing your hosting specs. You’re right, your server resources are more than sufficient, so that’s not the cause here. Before we rule out everything on your end, could you check whether there might be a plugin conflict on that specific site? Since the migration worked fine on your other 2 websites, something unique to this site’s setup may be interfering with the migration process. To help us investigate, could you share: A list of active plugins on the affected site (especially any that interact with the database, caching, or cron, e.g., object caching plugins, database optimization tools, or security plugins) The approximate size of your visitors table on this site. This information will help us narrow down whether something specific to this site is causing the migration to behave differently. Best regards Hi @gandomi, Sorry, I was busy with other stuff, hence the late reply. Here is a list of the installed Plugins. - Add to Calendar Button - Advanced Custom Fields PRO - Borlabs Cookie - Bulk Page Creator - Custom Post Type UI - diwima JagdGast - Editor Plus - Health Check & Troubleshooting - ManageWP - Worker - The Icon Block - UpdraftPlus – Sichern/Wiederherstellen - W3 Total Cache - WP Map Block by aBlocks - WP Migrate Lite - WP STAGING WordPress Backup Plugin - Backup Duplicator - WPBakery Page Builder - WPCode Lite - Yoast Duplicate Post - Yoast SEO I'm not sure about the visitors - table. It says 14.399 data sets. Is that the information you are looking for?