2

I thought I would give back to all those people who help me when I have a problem. This might be something old, but I did not find it anywhere so here goes:

We recently upgraded our production DBs from percona 5.1 to 5.5. Parallel to this we have been using innobackupex for our backups, which has never let us down... Until now.

We were adding a node from a backup, when during the recovery phase we ran into this error:

InnoDB: Failing assertion: len % DATA_NEW_ORDER_NULL_TYPE_BUF_SIZE <= 1

Our backups were made with:

nice -n 19 innobackupex-1.5.1 --stream=tar ./ --user XXXX --password 'YYYYY' \
  --ibbackup xtrabackup_55 | \
  nice -n 19 /usr/bin/pigz - | \
  ssh -p 32231 ***@backup.****.com \
    'cat - > /var/backup/db/#{Time.now.strftime("%Y-%m-%d")}.tar.gz'

and recovered with:

innobackupex-1.5.1 --apply-log . --ibbackup xtrabackup

The problem was that our backups had been made with the switch --ibbackup xtrabackup. This was fine for mysql/percona 5.1 but does not work on mysql/percona 5.5 due to the fact that current transactions are not commited/rollbacked at the time of the backup.

1

Luckily there is a small fix for this if you do not have the luxury of stopping traffic on the DB. By using --ibbackup xtrabackup_55 the recovery recognizes the pending transactions and handles them accordingly.

Our script now looks like this:

nice -n 19 innobackupex-1.5.1 --stream=tar ./ --user XXXX --password 'YYYYY' \
  --ibbackup xtrabackup_55 | \
  nice -n 19 /usr/bin/pigz - | \
  ssh -p 32231 ***@backup.****.com \
    'cat - > /var/backup/db/#{Time.now.strftime("%Y-%m-%d")}.tar.gz'

and

innobackupex-1.5.1 --apply-log . --ibbackup xtrabackup_55

respectively.

Just thought I would share this tidbit, due to the fact that looking for a solution cost me approx. 3,5 hours.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.