Hyperdb redirects to wp-admin/install.php with no read servers up

[archon810]

Hi folks. Apologies if the dev team doesn't consider ​HyperDB core WP (I do, since it's used by Wordpress.com and is developed by core WP people).

Either way, I also filed this ​here, though none of the developers seem to be active on that support forum (hence this bug report to bring attention to it). If you choose to close this bug here, I at least appreciate if at least one of the core devs takes a look at the above url and comments there (matt, andy, ryan, mdawaffe, vnsavage).

I'm enabling hyperdb on a high-traffic website but during my testing found pretty shocking behavior in my opinion when a certain situation occurs.

Basically, when all db read servers are down, rather than showing the standard "Error establishing a database connection" page as you would expect, anyone visiting the site is immediately redirected to wp-admin/install.php. No matter if you're logged in or not, that's where you end up.

I kind of understand why it happens, but I'm terrified to think that rather than get a descriptive DB error page, users will be instead directed to a page that shows up during the very first WP install. Moreover, I'm not sure what would happen if they got to that page and the read server came back up in the meantime, then they submitted the form.

Is there a way to get hyperdb to error out when no read servers are available instead of having users deal with this unfriendly and potentially dangerous behavior?

To test, just set all read servers to 0 in the config or just shut down mysql on the hosts with read > 0.

[vnsavage]

Hi,

Thanks for the report. In general you can use the plugins trac: ​http://plugins.trac.wordpress.org/ which would probably get you an answer faster.

HyperDB is meant to be as flexible as possible, allowing the usage of both multiple database servers per site and multiple database servers per table. In certain cases, the inability to connect to a certain table might be acceptable and could be handled in the code. For example, if we have a logging table that is on a separate dataset, for some users might not be acceptable to kill the whole site if the database servers for this dataset die.

The solution we have added for this case, which still keeps HyperDB flexible is a callback called "db_connection_error" which is called when HyperDB couldn't connect to a certain dataset. If you want to replicate the behavior without HyperDB and get the "Error establishing a database connection" when you can't connect to servers for a dataset, you can use the following code in db-config.php:

function wpdb_connection_error( $host, $port, $op, $tbl, $ds, $dbhname, $wpdb ) {
	dead_db();
}
$wpdb->add_callback( 'wpdb_connection_error', 'db_connection_error' );

Closing the ticket as "wontfix".

--
Iliya Polihronov

[archon810]

@vnsavage, I didn't know about a separate Trac for plugins, but in my defense I did start a post on HyperDB's plugin page.

Thanks for the fix - it makes sense to have a behavior like that, but considering my experience, I highly urge you to at least document this in the FAQ section of the plugin (​http://wordpress.org/extend/plugins/hyperdb/faq/). It is something that is pretty crucial to realize when jumping head first with this plugin and potentially very jarring for any big site in case their db goes down.

[vnsavage]

Yeah, that makes sense. I documented this behavior in the FAQ section.