The instructions in settings.php and on https://drupal.org/node/310071 show that read-slave databases should be set up this way:

$databases['default']['default'] = array(
  'driver' => 'mysql',
  'database' => 'drupaldb1',
  'username' => 'username',
  'password' => 'secret',
  'host' => 'dbserver1',
);
$databases['default']['slave'][] = array(
  'driver' => 'mysql',
  'database' => 'drupaldb2',
  'username' => 'username',
  'password' => 'secret',
  'host' => 'dbserver2',
);
$databases['default']['slave'][] = array(
  'driver' => 'mysql',
  'database' => 'drupaldb3',
  'username' => 'username',
  'password' => 'secret',
  'host' => 'dbserver3',
);

This lets you have more than one read slave, which gets randomly chosen for each request. However, backup_migrate_destination_db_mysql::destinations() only expects one database per target (i.e., 'default' and 'slave' in the example). This gives "Notice: Undefined index: driver in destinations()" on the Backup and Migrate settings pages and only the default database is selectable as a backup source.

Granted, it seems like a really bad idea to make slave databases a valid destination to restore backups to, but it might make sense to be able to back them up. Either way, the notice needs to disappear.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Feng-Shui’s picture

I'd be in support of not have backup and migrate dealing with salve databases. If you're looking to take a backup you always want to dump the master. If you're running a master/slave MySQL setup (which is the only type supported) and you want to get a dump of a slave DB for other pruposes, I would assume are sufficiently skilled enough to use mysqldump or similar.

Happy to write the patch to solve this if the ronan want's to make a call?

ronan’s picture

Status: Active » Needs work

I'd say the simplest thing to do is to disallow backing up/restoring to the slaves since, as you say, people who want to do that probably have other tools to do so. If you want to write a patch for this that would be great!

gielfeldt’s picture

Status: Needs work » Needs review
FileSize
3.03 KB

Preliminary attempt to handle multiple db definitions. Not tested.

greggmarshall’s picture

I tried applying the patch against 7.x-2.7 and got

error: patch failed: includes/destinations.db.mysql.inc:45
error: includes/destinations.db.mysql.inc: patch does not apply

I tried applying the patch against 7.x-2.x-dev and I was able to back up a site that previously was giving me an error:

Notice: Undefined index: driver in backup_migrate_destination_db_mysql->destinations() (line 51 of /var/www/drupal/sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).

And displayed no source options.

It looks like the patch works for me.

gielfeldt’s picture

I used the 2.x-dev, even though this ticket is about 2.4 ... sorry.

greggmarshall’s picture

Actually I just updated my previous comment when I realized I should have tested the patch against a development version. Your patch works on 2.x-dev for the application I have for it.

greggmarshall’s picture

While the patched version seems to work on our sites that have master/slave configurations, I just copied the patched module back onto a development environment with a single database and get a different error:

Notice: Uninitialized string offset: 0 in backup_migrate_destination_db_mysql->destinations() (line 59 of /var/www/vhosts/dev5.its.ny.gov/web/content/sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).
Notice: Uninitialized string offset: 0 in backup_migrate_destination_db_mysql->destinations() (line 59 of /var/www/vhosts/dev5.its.ny.gov/web/content/sites/all/modules/backup_migrate/includes/destinations.db.mysql.inc).

And I don't get any options in the source pull down.

I suspect the issue might be in the IF statement at line 53, I replaced the $info reference with $infos.

I also used $outer_loop instead of $key on line 63 to select get the if statement to work as I would expect and show Default Database instead of the long identifier that shows up on the master/slave site.

ronan’s picture

Status: Needs review » Needs work

Sounds like you're having issues with single db setups. I'm also concerned that it's adding :0 at the end of all of the non-default db ids. This means that it will break any existing schedules people have set up. It would be nice if this index was only added to database specifications that are part of an array.

greggmarshall’s picture

Issue summary: View changes

I actually now can see a rationale for backing up the slave DB. Backing up the primary DB puts a load that could impact a busy site. But if the slaves are keeping up reasonably, backup up the slave, which might not even be used, would allow the load to be shifted.

Acquia is actually saying Backup and Migrate is not supported on Acquia Cloud because of its impact on the database server.

chiri_iker’s picture

I am not able to restore the database from a saved backup location using "Backup Migrate" module.

"Auto Slave" module in working perfectly, so don't want to change any settings on that, however is there any way backup migrate module can be changed/altered to be compatible with "Auto Slave".

Below is the error -

Warning: PDO::prepare(): SQLSTATE[00000]: No error: PDO constructor was not called in backup_migrate_source_db_mysql->_restore_db_from_file() (line 201 of /var/www/html/drupal_prepaid/sites/all/modules/third-party/backup_migrate/includes/sources.db.mysql.inc).

Thanks in advance :)

couturier’s picture

Version: 7.x-2.4 » 7.x-3.x-dev