At this stage of the game, I’m still reviewing the XtraBackup applications, so I’m still in a “no risk” state of data loss. I’ve got scripts setup to restore the original data, so I can retest the backup and restore mechanisms of XtraBackup.
During all of my tests there is no active processes to make database changes. I’m entirely focused on screwing things up manually for now, and seeing how the restore process handles what I throw at it.
One of the tests I’ve done, and have successfully completed, was the process of doing a full backup, a couple of incremental backups, then a full restore. The process seems to have worked. I’ve NOT done any data change to see if those new changes have reverted, but that is on the docket.
The next test was more severe, and it failed. I’d run a full backup, then a couple of incrementals, the same as before. I’d go into the instance of MySQL at the CLI and intentionally drop a database. I’d get out of the database, run the restore, but it comes back with an error:
InnoDB: PUNCH HOLE support available
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Uses event mutexes
InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Number of pools: 1
InnoDB: Not using CPU crc32 instructions
InnoDB: Initializing buffer pool, total size = 100M, instances = 1, chunk size = 100M
InnoDB: Completed initialization of buffer pool
InnoDB: page_cleaner coordinator priority: -20
InnoDB: Log file ./ib_logfile1 is of different size 268435456 bytes than other log files 8388608 bytes!
InnoDB: Plugin initialization aborted with error Generic error
xtrabackup: innodb_init(): Error occured.
Looking at when this happens, this seems to be when it is trying to restore the FULL backup part. It’s not even looked at the incrementals.
I didn’t write the script that does the backup and restore process. (Found here: [url]https://www.percona.com/forums/questions-discussions/percona-xtrabackup/10772-[/url][script]-automatic-backups-incremental-full-and-restore ).
I don’t know if the script is passing the correct arguments or if its missing something to force the restore.
I’m writing my own script that is going to work similar to this, but, instead it’ll deal with revision numbers based on the number of FULL backups that have been performed, and not include any dates and times. I’ll also be adding functionality so that the restore process stops at a particular incremental number. But before I get past that, I need to know why a FULL backup won’t proceed after a database drop.
Thanks for taking the time to read my wall of text. :]