Not the answer you need?
Register and ask your own question!

v.2.3.x exits with the error (though the backup succeeds).

hakoarhakoar EntrantCurrent User Role Beginner
When I run the xtrabackup with following options, the exit code will not be "0" even when the backup succeeds?:
--safe-slave-backup --slave-info
"
Not checking slave open temp tables for --safe-slave-backup because host is not a slave
Failed to get master binlog coordinates from SHOW SLAVE STATUS
This means that the server is not a replication slave. Ignoring the --slave-info option
"
The source may or may not be a slave server and thus the exit code should be "0" when the backup has completed successfully.
This was working right with earlier versions?

Comments

  • trompxtrompx Entrant Current User Role Beginner
    I have the exact same problem, the exit code is 1 when I make the backup on the master with --salve-info while it should just ignore it as it is written and return 0. I did not have this problem before but I built a new image and it looks like the apt version has changed something.
  • scott.nemesscott.nemes MySQL Sage Current User Role Patron
    Hi hakoar/trompx;

    It does look like that is a bug (labeled as for PXC only, but appears to just be Xtrabackup in general):
    https://bugs.launchpad.net/percona-x...p/+bug/1513520

    So if you have not done so already, I would visit the bug page and mark that it affects you.

    -Scott
  • trompxtrompx Entrant Current User Role Beginner
    Hello Scott,

    Thanks for the fast answer. That bug does not really affect me as I can just set the --salve-info if the server is a slave and not if it is a master.
    However, since I reinstalled xtrabackup with apt-get percona-xtrabackup, my backup/restore stream process to S3 is broken.

    The backup still works with something like :
    $INNOBACKUPEXFULL --defaults-file=$MYCNF --encrypt=AES256 --encrypt-key-file=${keyfile} --stream=xbstream --compress --user=$MYSQL_BACKUP_USER --password=$MYSQL_BACKUP_PASS --socket=$MYSQL_SOCKET $SLAVE_INFO ./ 2> ${LOGFILE} | pv | ${S3GOF3R} put -b $S3_BUCKET -k $S3_BACKUP_NAME/${timestamp}.xbcrypt

    However, the restore :
    ${S3GOF3R} get -b $S3_BUCKET -k $BACKUP_PATH | xbcrypt --encrypt-algo=AES256 --decrypt --encrypt-key-file=${keyfile} | xbstream -x -C ${FOLDER_PATH}
    now fails with error : "xbcrypt:xb_crypt_read_chunk: wrong chunk magic at offset 0x0."

    I did not check what was the previous xtrabackup version when everything was working (installed maybe a month ago), was it the 2.2.12 ?
    I would like to reinstall it from source or any other install procedure that allows me to specify a specific version.

    Thank you.
  • trompxtrompx Entrant Current User Role Beginner
    I managed to rollback the version with apt-get install percona-xtrabackup=2.1.8-1

    When backing up, the size of the backup was changing from version 2.3.2 to 2.1.8

    - 2.3.2-1 : 1.9MB on S3
    ​When backing up with pv
    1.53MB 0:00:01 [1.52MB/s] [ <=>
    1.93MB 0:00:01 [1.23MB/s] [ <=>
    duration: 3.419386364s

    - 2.1.8-1 : 3.5MB on S3
    When backing up with pv
    1.53MB 0:00:01 [1.43MB/s] [ <=>
    1.53MB 0:00:02 [ 0B/s] [ <=>
    3.51MB 0:00:03 [1.99MB/s] [ <=>
    3.51MB 0:00:03 [ 959kB/s] [ <=>
    duration: 6.257668918s

    I don't know if some extra files are copied with the old version but at least the restore process is working now again.
    I would be interested to make this work with 2.3.2 as the size on S3 seems to be better.
Sign In or Register to comment.

MySQL, InnoDB, MariaDB and MongoDB are trademarks of their respective owners.
Copyright ©2005 - 2020 Percona LLC. All rights reserved.