Skip to main content

I’m attempting a MySQL restore (made with XtraBackup if that matters) but I can’t get over this error:

 

Description: Restoring Percona Xtrabackup database a~XXXXXXXXX~] failed. Reason:e~Failed to fetch destination MySQL data directory.~]
Source: XXXXXXXX, Process: MySqlRestore

 

MySqlBrowseAgent.log
MySqlBrowseAgent::SendValidateServerResponse() - verifyUser failed err=eConfig File:g /etc/my.cnf] does not exist]

MySqlRestore.log

111627 1b40b 06/13 10:42:37 280447 GetMySqlInfo::DeleteConfFile() - GetMySqlInfo object not init'ed

 

It happens whether or not I use UNIX user impersonation (mysql user if that matters).

Config file obviosly exists and is owned by mysql:mysql

 

 


Any ideas?

Hi @FQueiroloCeibal 

Looks like you have an empty space character at the beginning of path /etc/my.cnf.

 

Can you remove it in your instance configuration and try again?

 

Thanks,

Sunil-

 


Thanks @Sunil , that was correct.

I’m now facing a new setback, similar:

128683 1f6ab 06/13 11:55:02 ### MySqlBrowseAgent::SendValidateServerResponse() - verifyUser failed err=eMySQL MEB directory: o /usr/bin] is not valid]

 

 


Are you using MySQL Enterprise Backup?

In that case you need to provide this directory with a path where MEB utility is installed.

But you’re saying you’re trying to restore from XtraBackup. So, please check if you have selected MEB instead of XtraBackup option in the instance properties. Either case /usr/bin doesn’t sound right.

 

Thanks,

Sunil-


I’m not the DBA so I didn’t installed it haha but it’s there:

 

 


Strange. Not sure why it’s looking for MEB file under this path. Can you just create an empty file named 

mysqlbackup under /usr/bin and retry. This file won’t be used during the actual restore but should let the validation pass.

 

Thanks,

Sunil-

 


Ok, that worked!

 

Error changed, now on MySqlRestore.log I get:

10172 27cf 06/13 12:44:40 280467 GetMySqlInfoExt::DropDB() - DropDB failed : XXXXXX]
10172 27cf 06/13 12:44:40 280467 GetMySqlInfoExt::DropDB() - Database XXXXXX] does not exist. Ignoring the failure to drop db.
10172 27cf 06/13 12:44:40 280467 GetMySqlInfo::getDataDir() - Empty datadir returned from MySqlInstance::getMySqlDataDir().
10172 27cf 06/13 12:44:40 280467 MySqlRestore::OnBufferPlFsHdr() - GetMySqlInfo::getDataDir failed.

10172 27cf 06/13 12:44:40 280467 MySqlRestore::cleanUp() - Cleaning up...
10172 27cf 06/13 12:44:40 280467 GetMySqlInfo::DeleteConfFile() - Removing [/opt/commvault/Base/Temp/galaxy_bkp_mycnf_164_1718293479_10172_10172_280467.cnf] file

10172 27cf 06/13 12:44:40 280467 GetMySqlInfo::RemoveDirectoryWithFiles(807) - Directory - [/opt/commvault/iDataAgent/jobResults/XXXXXX] does not exist.
10172 27cf 06/13 12:44:40 280467 FclRestore::terminateOnFatalError(10225) - Sending FSR_MSG_STOP
10172 27cf 06/13 12:44:40 280467 Sending FAILED complete message to JM, 280467
10172 27cf 06/13 12:44:41 280467 FsRestoreUnixObject::closeObject(6602) - Error 2] while updating file times for XXXXXX]
10172 27cf 06/13 12:44:41 280467 FsRestoreFile::closeObject(8000) - Error 1] while closing crm_remoto] (base class)
10172 27cf 06/13 12:44:41 280467 FclRestore::readPipeline(6081) - Removing file XXXXXXon error


@Sunil MySqlBrowseAgent.log succesfully finds the MySql datadir:

But for some reason it’s not correcty tunneled to the restore process?


Not sure why this is happening. Can you just open Instance properties, edit and save it without any changes?

This will ensure we have all required information synced up in the database.

 

Thanks,

Sunil-


@Sunil no matter what I do, I keep getting the same error.

I even check editing and saving from the java console but I get the same result


At this point, I ran out of ideas. We need to troubleshoot further with all logs. Could you create a support ticket? 

 

Thanks,

Sunil-


Reply