Raise max_allowed_packet for rebuilds
If wp sss rebuild succeeds on small sites but fails partway through on a larger catalogue with “Error establishing a database connection” – and your database server is fine straight after – the cause is almost always MySQL/MariaDB’s max_allowed_packet being set too low. The fix is a one-line config change plus a restart.
The Readiness Status section on the Main tab warns you about this automatically when the value is below 64MB.
Symptom
You see the rebuild emit a chunk of “Query N completed” lines, then suddenly:
Error: Error establishing a database connection.wp post list --post_type=product or wp option get siteurl work fine seconds later, and your MariaDB error log (or sudo journalctl -u mariadb -n 100) shows nothing or, at most, a single warning like:
[Warning] Aborted connection NNNN to db: 'yourdb' user: 'yourdb' host: 'localhost'
(Got an error reading communication packets)That Got an error reading communication packets line is the giveaway. MariaDB rejected a single oversized statement, the client (PHP) closed the connection, and the next WP-CLI invocation reported it as “Error establishing a database connection” – the server itself never went down.
“Error establishing a database connection” sounds like the server crashed, but it did not. MariaDB stayed up and rejected one oversized packet; the connection that carried it was dropped. That is why wp option get siteurl works a second later. Do not go hunting for a down database.
Why it happens
The rebuild builds a few wide INSERT … SELECT statements that pull every row of wp_posts plus their meta and taxonomy assignments into the search table in one go. With a catalogue of a few thousand products, term assignments, and any configured meta columns or taxonomy combinations, the total statement can easily run to 30 – 60MB. MariaDB’s default max_allowed_packet on Ubuntu 22.04 ships as 16MB, which is plenty for everyday WordPress traffic but not enough for the rebuild.
You won’t see the issue on a small dev site with a few hundred products – only when the SELECT result blows past whatever your max_allowed_packet happens to be set to.
Check the current value
sudo mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"You’ll see something like:
+--------------------+----------+
| Variable_name | Value |
+--------------------+----------+
| max_allowed_packet | 16777216 |
+--------------------+----------+16777216 bytes is 16MB. Anything below 64MB will trigger the warning in Settings → Super Speedy Search → Main tab → Readiness Status.
You can also grep the config files:
grep -E "^[^#]*max_allowed_packet" /etc/mysql/mariadb.conf.d/*.cnf /etc/mysql/conf.d/*.cnf /etc/mysql/my.cnf 2>/dev/nullIf the grep returns nothing, the setting isn’t explicitly configured and MariaDB is using its built-in default.
Raise it
The simplest fix is a one-liner that replaces an existing setting if there is one, otherwise drop into the file and add the line under [mariadbd]:
sudo sed -i 's/^\s*max_allowed_packet.*/max_allowed_packet = 128M/' \
/etc/mysql/mariadb.conf.d/50-server.cnfIf grep returned nothing earlier, edit the file manually:
sudo nano /etc/mysql/mariadb.conf.d/50-server.cnfFind the [mariadbd] section (or [mysqld] on older configs) and add:
max_allowed_packet = 128MSave and exit.
Restart and verify
sudo systemctl restart mariadb
sudo mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"You should see 134217728 (128M). Then re-run:
wp sss rebuild all forceIt should complete cleanly. If you still see the error after the restart, double-check the value with the SHOW VARIABLES query – some hosts have multiple config files and the change might have landed in one MariaDB doesn’t read.
Recommended values
| Catalogue size | Recommended max_allowed_packet |
|---|---|
| Under 1,000 products | 64M is plenty |
| 1,000 – 10,000 products | 128M, safe headroom |
| 10,000+ products, or many meta-conditional weights | 256M |
64MB is the minimum we recommend and the threshold for the in-plugin Readiness warning. Going higher than 256MB rarely buys anything and just wastes per-connection memory.
The setting only applies to new connections, so the systemctl restart is essential – SET GLOBAL max_allowed_packet = … from a SQL prompt does not survive a restart and does not affect connections already open.
Do not rely on SET GLOBAL max_allowed_packet = … at a SQL prompt. It is not read by connections already open, and it is wiped on the next MariaDB restart. The only durable fix is the config file plus a systemctl restart.
Why not bump it permanently in the plugin?
A plugin can’t change a MariaDB configuration variable from PHP – SET SESSION max_allowed_packet is read-only for the client and the value MariaDB uses for incoming packets is server-wide. The only place to set it is the MariaDB config file. The rebuild does set a few server variables it can change at session level (notably group_concat_max_len, which is a per-session setting), but max_allowed_packet is not one of them.
Comments