[BUG] real_db_name isn't found

[DerFels]

Describe the bug
I created a a backup using mydumper 0.12.1 and tried to restore it using myloader 0.12.1 but it fails instantly with It was not possible to process file: <some-file-name>.sql.gz (2) because real_db_name isn't found

To Reproduce
Command executed:
/usr/bin/mydumper --kill-long-queries -t 8 -v 1 -G -E -R --less-locking -c -o /backup
myloader -d backup -v 3 -t 5 -h 127.0.0.1 -u root -p <some-pw> -s <some-db>

What mydumper and myloader version has been used?
myloader 0.12.1

Expected behavior
I expect the restore function to work :)

Log
If applicable, add the --verbose 3 / -v 3 and --logfile / -L to the execution of the command and upload the file.

** Message: 08:23:05.915: Server version reported as: 5.7.35-38
** (myloader:20): CRITICAL **: 08:23:05.937: It was not possible to process file: example_planner.soccer_entry-schema.sql.gz (2) because real_db_name isn't found

Backup
If applicable, add the list of content of the database path, an ls -l will be enough

Environment (please complete the following information):

• OS version: Ubuntu 20.04
• MyDumper version: 0.12.1

Additional context
The restore environment lives inside docker-compose

[davidducos]

Does example_planner-schema-create.sql.gz file exists? if not, then it will always going to fail.

[DerFels]

Hi,
yes the file exists and is in the correct folder. The backup script has always worked with version 0.11 but we wanted to update to the latest version.
We use a little bash script to iterate over all the .sql.gz, copy them into their seperate folders and then restore+drop them one after another

for db in $(ls -1|grep sql|awk 'FS="." {print $1}'|sort -u); do

  echo " Restoring ${db} now!"

  mkdir -p ${db} && mv ${db}.*.sql.gz ${db} && cp metadata ${db}/

  myloader \
    -d ${db} \
    -v 3 \
    -t 5 \
    -h 127.0.0.1 \
    -u root \
    -p ${MYSQL_ROOT_PASSWORD} \
    -s $db


  echo " Restore OK, dropping ${db} now!"

  mysql \
    -h 127.0.0.1 \
    -u root \
    -p${MYSQL_ROOT_PASSWORD} \
    -e "drop database ${db};"



done

[davidducos]

Hi @DerFels
I found what your issue is:

root@ubuntu-focal:~/issue_650/mydumper/dump# mkdir percona
root@ubuntu-focal:~/issue_650/mydumper/dump# mv percona.*.sql.gz percona/
root@ubuntu-focal:~/issue_650/mydumper/dump# mv metadata percona
root@ubuntu-focal:~/issue_650/mydumper/dump# ls -l
total 400
drwxr-xr-x 2 root root 12288 Apr 25 12:46 percona
-rw-r--r-- 1 root root   109 Apr 25 12:36 percona-schema-create.sql.gz

The -schema-create.sql file is being left behind. That is the file that add the database name to the list that we use to determine the real_db_name. Why don't you use: -s, --source-db Database to restore? as there is no need to move the files. BTW, you can use --regex with myloader too...

[davidducos]

Please, let me know if you need further help, so we can close this 2 issues.

[DerFels]

Thank you David! :)
You were correct, the whole moving of files screwed the restore process up.
The restoring process works perfectly now.

myloader \
    -d . \
    -v 3 \
    -t 5 \
    -h ${MYSQL_IP} \
    -u root \
    -p ${MYSQL_ROOT_PASSWORD} \
    -s $db

You can close both tickets.