DB Backups getting stuck on options table

[AndrewParticipant]

Hi,

I’m managing a site that is having problems with backups — UpdraftPlus is stalling out completely while trying to back up the wp_options table in the database. The table is about 130MB, and I’ve analyzed/optimized/repaired it and everything seems fine with the table. I tried changing the engine from InnoDB to MyISAM (just in case that might help), but still no luck.

The progress indicator just gets stuck here:
Creating database backup (table: wp_cah86qt2sv_options)

Log file is pasted below.

This site is on a Cloudways server, and it has a similar config (with their default timeouts, etc) to dozens of my other clients… so I don’t think it’s simply a matter of increasing timeout settings.

It had been working fine for months, and this problem started about five days ago.

Any ideas why it’s getting stuck here?

Thanks,
Andrew

0000.004 (0) Opened log file at time: Thu, 26 Apr 2018 15:12:47 +0000 on https://preppykitchen.com
0000.005 (0) UpdraftPlus WordPress backup plugin (https://updraftplus.com): 2.14.7.24 WP: 4.9.5 PHP: 7.0.29-1~dotdeb+8.1 (fpm-fcgi, Linux 114206.cloudwaysapps.com 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64) MySQL: 5.5.60 WPLANG: en_US Server: Apache/2.4.10 (Debian) safe_mode: 0 max_execution_time: 900 memory_limit: 268435456 (used: 12.4M | 6M) multisite: N openssl: OpenSSL 1.0.1t 3 May 2016 mcrypt: Y LANG: ZipArchive::addFile: Y
0000.005 (0) Free space on disk containing Updraft’s temporary directory: 24660.4 MB
0000.007 (0) Tasks: Backup files: 0 (schedule: daily) Backup DB: 1 (schedule: daily)
0000.014 (0) Requesting semaphore lock (d) (apparently not via scheduler)
0000.015 (0) Semaphore (d, wp_cah86qt2sv_options) was stuck, set lock time to 2018-04-26 15:12:47
0000.018 (0) Semaphore (d, wp_cah86qt2sv_options) reset to 1
0000.020 (0) Set semaphore last lock (d) time to 2018-04-26 15:12:47
0000.020 (0) Semaphore lock (d) complete
0000.028 (0) Backup run: resumption=0, nonce=171455918bb0, begun at=1524755567 (0s ago), job type=backup
0000.029 (0) Scheduling a resumption (1) after 600 seconds (1524756167) in case this run gets aborted
0000.081 (0) This backup run is not intended for files – skipping
0000.082 (0) Beginning creation of database dump (WordPress DB)
0000.125 (0) Testing: /usr/bin/mysqldump
0000.165 (0) Output: /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;\n/*!40103 SET TIME_ZONE=’+00:00′ */;\n/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;\n/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;\n/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE=’NO_AUTO_VALUE_ON_ZERO’ */;\n/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;\nDROP TABLE IF EXISTS wp_cah86qt2sv_options;\n/*!40101 SET @saved_cs_client = @@character_set_client */;\n/*!40101 SET character_set_client = u (truncated – 1264 bytes total)
0000.189 (0) Working binary mysqldump found: /usr/bin/mysqldump
0000.196 (0) Table wp_cah86qt2sv_options: Total expected rows (approximate): 1022

[AndrewParticipant]

Ah! I think I fixed it.

I found about 150 entries in the options table that were _vp_ai_ping_123345 (various numbers). Looks like those were leftover from VaultPress test failures. I deleted those rows and the database size dropped down to about 1.5 megabytes (from 130)… and I was able to complete the DB backup via UDP.

[Bryle CroduaModerator]

Hi Andrew,

Great – I’m glad you were able to resolve the issue.

Regards,
Bryle

[Author]

Posts