Skip to content
John James Jacoby edited this page Sep 20, 2026 · 1 revision

Troubleshooting

Confirm that the drop-in is active

wp eval 'echo get_class( $GLOBALS["wpdb"] );'

The result should identify LudicrousDB rather than the core wpdb class. If it does not, check the drop-in location, ownership, PHP errors, and whether another db.php is already present.

Remove duplicate installations

Keep one LudicrousDB code copy in wp-content/plugins, wp-content/mu-plugins, or wp-content/db-plugins. Multiple copies make upgrades and path resolution unpredictable.

Also confirm which db-config.php is being loaded. Prefer an explicit DB_CONFIG_FILE for unusual layouts.

Diagnose “table does not exist”

Log or inspect the logical dataset selected for the failed query, then verify that the configured physical database contains the exact table. Common causes include:

  • returning a dataset name that was never added;
  • leaving a companion table, such as metadata, on another dataset;
  • doubling the WordPress prefix in a callback;
  • changing a range or modulo rule without migrating existing data;
  • assuming LudicrousDB creates or copies tables.

Prefer $wpdb->table in routing callbacks. It is less brittle than extracting a table name from arbitrary SQL.

Diagnose “table already exists” during an upgrade

Capture the complete CREATE TABLE query and determine which dataset LudicrousDB selected. Check whether the same logical table exists in more than one dataset and whether a plugin upgrade is running once per site or once per network.

A useful report includes current WordPress, PHP, LudicrousDB, and plugin versions; a sanitized db-config.php; the full database error and query; and the expected versus selected dataset.

Investigate connection spikes

Confirm that callbacks return a stable dataset for a given table. Review retry settings, replica health, DNS, connection timeouts, PHP worker counts, and persistent connection behavior. A failed preferred server can multiply connection attempts as traffic rises.

Do not mask the symptom by broadening database permissions. First identify which endpoints are attempted and why.

Share configuration safely

Before posting publicly, replace every database host, username, password, IP address, private domain, token, and connection string. Preserve the shape of the configuration with obvious placeholders such as DB_HOST_REPLICA_1.

If a report may reveal a security vulnerability, use private vulnerability reporting instead of a public issue or discussion. See Support and Security.

Clone this wiki locally