Too easy to backup wrong datadir with multiple instances

If you have a valid datadir that is referenced in /etc/my.cnf and another instance you specify by socket, you can silently back up the wrong directory when you forget to pass --defaults-file:

# innobackupex --socket=/s/56master/data/mysql.sock --stream=tar . > /dev/null

<SNIP>

140716 19:05:51 innobackupex: Starting to backup non-InnoDB tables and files
innobackupex: in subdirectories of '/var/lib/mysql'
innobackupex: Backing up files '/var/lib/mysql/test/*.{frm,isl,MYD,MYI,MAD,MAI,MRG,TRG,TRN,ARM,ARZ,CSM,CSV,opt,par}' (28 files)

# mysql -S/s/56master/data/mysql.sock -e'select @@datadir'
/s/56master/data/

A straight forward fix would be to compare $orig_datadir/ to @@datadir that you SELECT over the socket:

For percona-xtrabackup-2.2.3-4982.el6.x86_64:

@@ -1899,6 +1899,13 @@
     my $buffer_pool_filename = get_option(\%config, $option_defaults_group,
                                           'innodb_buffer_pool_filename');

+ # Validate datadir for current socket before doing any heavy lifting
+ my ($datadir_var) = eval { $mysql{dbh}->selectrow_array("SELECT \@\@datadir") };
+ if ( "$orig_datadir/" ne "$datadir_var" ) {
+ print STDERR "$prefix Error: $orig_datadir incorrect for this unix socket\n";
+ exit 1;
+ }
+
     detect_mysql_capabilities_for_backup(\%mysql);

     #

For percona-xtrabackup-2.1.9-744.rhel6.x86_64 it is quite similar @@ -1916,6 +1916,22 @@

If this is not acceptable or conflicts with goals in https://blueprints.launchpad.net/percona-xtrabackup/+spec/read-server-options-with-show-variables it might be ok to create a view and then search for it:

     my $buffer_pool_filename = get_option(\%config, $option_defaults_group,
                                           'innodb_buffer_pool_filename');

+ # Validate datadir for current socket before doing any heavy lifting
+ use Digest::MD5 qw(md5_hex);
+ my $test_view = md5_hex("$now $prefix $orig_datadir"); # Avoid replication race
+ print STDERR "\n";
+ print STDERR "$now $prefix Creating a test view to validate that datadir is $orig_datadir\n";
+ mysql_query(\%mysql, "CREATE VIEW mysql.xtrabackup_$test_view AS SELECT 'xtrabackup_test_view'");
+ if (!-f "$orig_datadir/mysql/xtrabackup_$test_view.frm" ) {
+ print STDERR "$now $prefix Dropping test view\n";
+ mysql_query(\%mysql, "DROP VIEW mysql.xtrabackup_$test_view");
+ print STDERR "Detected $orig_datadir to be incorrect for this unix socket\n";
+ exit 1;
+ } else {
+ print STDERR "$now $prefix Datadir validated, dropping test view\n";
+ mysql_query(\%mysql, "DROP VIEW mysql.xtrabackup_$test_view");
+ }
+
     detect_mysql_capabilities_for_backup(\%mysql);

     #

At least one problem with the heavy handed approach is that there is a race condition if the slave runs a backup at the same second but server_id does not seem to be available via xtrabackup --print-param. Perhaps it could be extended to toggle the session variable for sql_log_bin/wsrep_on to avoid this. Another potential problem is that a "read only" tool uses DDL.