MySQL Database Destination?

This was not removed. I'm not sure why yours isn't available for backups. Are you getting any errors?

I'm having the same issue. I reverted back to the 2.x version to get the MySQL destination option. I see that the code is still in the module folder, but it isn't listed on the Destinations page just like in the screenshot above. Not sure how to get it added in.

The same on my site. I'm using Drupal 7.39 and BandM 7.x-3.1 or current 3.0 DEV version.

Same here. Using B&M 7.x-3.1 w/ Drupal Core 7.39. I'm not seeing any errors on my end nor is anything hidden in the markup that would be responsible for hiding the option to create the MySQL destination.

Edit: I meant to also mention that my interface looks exactly like jeff.k's B&M interface.

I looked into this and from what little I can understand, crud.inc has a function named backup_migrate_crud_subtypes() that loops through sources and destinations. In this logic, a dynamic function is called, whereby backup_migrate_backup_migrate_destination_subtypes() gets called (from destinations.inc), which outputs the final set of destinations that it has defined in a few arrays...

MySQL is nowhere to be seen in backup_migrate_backup_migrate_destination_subtypes()'s arrays. Why is this? Shouldn't it be in there?

Following up on the info from Wolf_22 I edited the destinations.inc file to include a subtype for MySQL modeled after the others in the array. It looked like this:

<?php
'mysql' => array(
  'description' => t('Save the backup files to a MySQL Database.'),
  'file' => drupal_get_path('module', 'backup_migrate') .'/includes/destinations.db.mysql.inc',
  'class' => 'backup_migrate_destination_db_mysql',
  'type_name' => t('MySQL Database'),
  'can_create' => TRUE,
  'remote' => TRUE,
),
?>

This added the item into the list and allowed me to create a new Destination. However, when I attempted to run the backup to that destination I got the WSOD. I check my error logs on the server and found this error:

PHP Fatal error: Call to undefined method backup_migrate_destination_db_mysql::calculate_filesize() in /sites/all/modules/backup_migrate/includes/filters.utils.inc on line 191

I then went back to the previous page and the following error box was displayed:

Notice: Undefined property: backup_file::$filters in backup_migrate_filter_utils->add_file_info() (line 184 of /sites/all/modules/backup_migrate/includes/filters.utils.inc).

I'm not much of a developer, so I'm not sure if there are things missing or if I'm doing something wrong. Hopefully this will help provide more insight into getting this issue resolved.

It's been awhile since this entire thread was posted but I decided to look into this again since I can't seem to find any MySQL Database options in my production site that currently uses B&M 7.x-3.1 within an up-to-date 7.50 install...

What I found is this: inside of includes/destinations.inc, I noticed that the entry to MySQL was missing. Using an older 7.x-2.8 installation in another sandbox site that I had laying around, I noticed that the following was still there in includes/destinations.inc:

...
      'file' => drupal_get_path('module', 'backup_migrate') .'/includes/destinations.db.inc',
      'class' => 'backup_migrate_destination_db',
      'can_create' => FALSE,
    ),
    'mysql' => array(
      'type_name' => t('MySQL Database'),
      'description' => t('Import the backup directly into another MySQL database. Database destinations can also be used as a source to backup from.'),
      'file' => drupal_get_path('module', 'backup_migrate') .'/includes/destinations.db.mysql.inc',
      'class' => 'backup_migrate_destination_db_mysql',
      'can_create' => TRUE,
    ),
    'ftp' => array(
      'description' => t('Save the backup files to any a directory on an FTP server.'),
      'file' => drupal_get_path('module', 'backup_migrate') .'/includes/destinations.ftp.inc',
      'class' => 'backup_migrate_destination_ftp',
      'type_name' => t('FTP Directory'),
      'can_create' => TRUE,
    ),
    's3' => array(
      'description' => t('Save the backup files to a bucket on your <a href="@link">Amazon S3 account</a>.', array('@link' => url('http://aws.amazon.com/s3/'))),
      'file' => drupal_get_path('module', 'backup_migrate') .'/includes/destinations.s3.inc',
      'class' => 'backup_migrate_destination_s3',
...

So, in similar fashion as efruin, I decided to take the mysql definition and apply it to the includes/destinations.inc file of the newer version I was using in a production site. When I did this, I finally began to see the MySQL options become available: the MySQL destination type was there along with preexisting entries corresponding to older MySQL destinations that I had in the past... Pretty strange.

...but when I tried to create a new destination using the MySQL type, I began to see oddities:

Underneath "Other Destinations" is where the option to create a new MySQL Database destination is (using the definition changes I mentioned above). After clicking on that to create a new destination, I noticed that the first text field for "Database type" is somewhat nebulous in terms of what it's expecting... Thinking that it must be something like "MySQL," I used that but later discovered that it has to be "mysql". Every field after that is pretty straightforward, but once I had this new MySQL Database destination created, I tried to use it only to wind up with a WSOD and the following errors in the log (in chronological order):

1. Notice: Undefined index: scheme in backup_migrate_location->glue_url() (line 388 of /sites/all/modules/backup_migrate/includes/locations.inc).
2. Notice: Undefined index: host in backup_migrate_location->glue_url() (line 392 of /sites/all/modules/backup_migrate/includes/locations.inc).
3. Notice: Undefined index: scheme in backup_migrate_location->glue_url() (line 388 of /sites/all/modules/backup_migrate/includes/locations.inc).
4. Notice: Undefined index: host in backup_migrate_location->glue_url() (line 392 of /sites/all/modules/backup_migrate/includes/locations.inc).
5. Notice: Undefined property: backup_file::$filters in backup_migrate_filter_utils->add_file_info() (line 184 of /sites/all/modules/backup_migrate/includes/filters.utils.inc).

The moral of the story here is that it almost looks like someone has been working on this but after adding the MySQL Database definition above, you get to see where they've left off. ;.)

I guess we're forced to do manual dump file imports until this gets finished, right? Has anyone else had any different experiences with MySQL Database Destinations using B&M 7.x-3.1? Is it available to you out-of-the-box or did you have to do something to it to make it work as expected?

Had some more time to look into this... (Been awhile, I know.)

I think the issue boils down to how $op is being set and or used inside of /includes/destinations.inc inside of the function "backup_migrate_get_destinations()": $op appears to contain a value that gets evaluated against $destination->$supported_ops array to see if a match is found from $op.

(See backup_migrate_get_destinations() and look for the condition in it where if($destinations->op($op)) is performed.)

Long story short, $destinations->op($op) never returns a true for the destinations that should be for manually backing up to a MySQL backup destination because, for whatever reasons, the supported_ops array inside the $destinations object never contains a match for $op when it's put through $destinations->op($op). If we can isolate where and why supported_ops lacks the value "manual backup", we can probably get the MySQL manual backups to work again. Can someone verify this so that I know I'm not crazy?

I'll try to see if I'm correct by looking into where supported_ops gets set, etc. to see if there might be some logic somewhere that needs looking into. If I find anything else, I'll post back.

Well, I can at least add destinations now and see them in the manual (Quick & Advanced) backup screens. I'm still working on getting the actual backup to work, though. Hopefully, it's a start...

Here's what I did:

Inside includes/destinations.inc, add the following items to the 2nd $out array assignment (the one containing non-file based values) in backup_migrate_backup_migrate_destination_subtypes():

    'db' => array(
      'type_name' => t('Database'),
      'description' => t('Import the backup directly into another database. Database destinations can also be used as a source to backup from.'),
      'file' => drupal_get_path('module', 'backup_migrate') .'/includes/destinations.db.inc',
      'class' => 'backup_migrate_destination_db',
      'can_create' => FALSE,
    ),
    'mysql' => array(
      'type_name' => t('MySQL Database'),
      'description' => t('Import the backup directly into another MySQL database. Database destinations can also be used as a source to backup from.'),
      'file' => drupal_get_path('module', 'backup_migrate') .'/includes/destinations.db.mysql.inc',
      'class' => 'backup_migrate_destination_db_mysql',
      'can_create' => TRUE,
    ),

Inside includes/destinations.db.inc, add the following $form['scheme'] elements in edit_form():

	$form['scheme']['#default_value'] = 'mysql';
	$form['scheme']['#type'] = 'hidden';
	$form['scheme']['#attributes'] = array('readonly' => 'readonly');
        /* Note: You'll want to apply a default_value for the machine name, too. I haven't done this yet. */

Doing this at least allows for the *selection* of a MySQL database in destinations but it's not working due to lost logic for the MySQL backup processing (from what I can tell, it was in the 2.x branch but apparently lost when everything went into the 3.x--I'm not sure why).

Hopefully this helps. If I can get the actual backup to work, I'll post it on here.

After diving into the code some more, I was able to get the majority of backup routines to run straight through without major failure. The problem is that the generated temporary files I'm seeing are not being restored into the destination. I'm not sure why this is but one thing that's very confusing about how they've designed their classes is how the instantiated object corresponding to backups seems to keep both the source and the destination in one single object without very clear distinguishing factors that separate the two abstractions. Adding to this, their comments are not very informative, leaving someone outside the box to go using things like debug_backtrace() all over the place just to figure out why things are set the way they are...

Long story short, I think the reason you don't see the MySQL destinations as an option is because they did some major refactoring between the 2.x and 3.x releases whereby at some point, they got overwhelmed in the 3.x version and gave up in order to focus efforts on their D8 rewrite. Can't blame them.

Since they're apparently rewriting for D8, let's just hope that they provide logic for backing up to MySQL database destinations in that version while everyone else "gets by" with their standard flat-file backups in the 3.x version...

Updating the version. Comment #11 is correct that resources are very limited for the 7.x branch. Most of the effort is being devoted to the port to D8.

We've had no response in two years on this issue, and being in the 7.x branch, I will archive unless someone new would like to re-open. As stated earlier, this shouldn't be an issue across all sites.