after mysql.5.6.28 upgrade to 8.0.23, percona-xtrabackup-8.0.23 could not be used with mysql 8.0.23
Description
Environment
operating system:Red Hat Enterprise Linux Server release 7.4 (Maipo)
pre-upgrade mysql version:oracle mysql 5.6.28
upgraded version:oracle mysql 8.0.23
backup command:/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup --defaults-file=/data/3309/my.cnf --user=root --password=--host=127.0.0.1 --port=3309 --backup --target-dir=/data/mysql/dump --parallel=2 &>/tmp/mysql5.6_backup_`date +%F`.log
prepare command:/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup --prepare --target-dir=/data/mysql/dump &>/tmp/apply5.6_`date +%F`.log
Smart Checklist
Activity
Jira Bot September 4, 2021 at 12:56 PM
Hello @zhouke,
It's been 52 days since this issue went into Incomplete and we haven't heard
from you on this.
At this point, our policy is to Close this issue, to keep things from getting
too cluttered. If you have more information about this issue and wish to
reopen it, please reply with a comment containing "jira-bot=reopen".
Jira Bot August 27, 2021 at 11:57 AM
Hello @zhouke,
It's jira-bot again. Your bug report is important to us, but we haven't heard
from you since the previous notification. If we don't hear from you on
this in 7 days, the issue will be automatically closed.
Jira Bot August 12, 2021 at 10:56 AM
Hello @zhouke,
I'm jira-bot, Percona's automated helper script. Your bug report is important
to us but we've been unable to reproduce it, and asked you for more
information. If we haven't heard from you on this in 3 more weeks, the issue
will be automatically closed.
Lalit Choudhary July 14, 2021 at 10:41 AM
Hi @zhouke
Thank you for the report.
I do not see the describe issue when using xtrabackup 8.0.23 with MySQL 8.0.23 version.
If you still able to reproduce is send us reproducible steps.
My Test:
mysql version:
Server version: 8.0.23 MySQL Community Server - GPL
./bin/xtrabackup --version
./bin/xtrabackup version 8.0.23-16 based on MySQL server 8.0.23 Linux (x86_64) (revision id: 934bc8f)
started sysbench read-write load:
bin/xtrabackup --defaults-file=/home/lalit/sandboxes/msb_8_0_23/my.sandbox.cnf --user=msandbox --password=msandbox --socket=/tmp/mysql_sandbox8023.sock --backup --target-dir=~/backup
210714 16:07:05 Executing UNLOCK INSTANCE
210714 16:07:05 All tables unlocked
210714 16:07:05 [00] Copying ib_buffer_pool to /home/lalit/backup/ib_buffer_pool
210714 16:07:05 [00] ...done
210714 16:07:05 Backup created in directory '/home/lalit/backup/'
MySQL binlog position: filename 'binlog.000003', position '7101'
210714 16:07:05 [00] Writing /home/lalit/backup/backup-my.cnf
210714 16:07:05 [00] ...done
210714 16:07:05 [00] Writing /home/lalit/backup/xtrabackup_info
210714 16:07:05 [00] ...done
xtrabackup: Transaction log of lsn (26848048) to (54261543) was copied.
210714 16:07:06 completed OK!Lalit Choudhary July 13, 2021 at 3:21 PMEdited
Details
Assignee
Lalit ChoudharyLalit ChoudharyReporter
zhoukezhoukeAffects versions
Priority
Medium
Details
Details
Assignee
Reporter
Affects versions
Priority
MediumSmart Checklist
Open Smart Checklist
Smart Checklist
Open Smart Checklist
Smart Checklist
after I Upgrade mysql from 5.6.28 to 8.0.23,i used percona-xtrabackup-8.0.23-16 to backup mysql8.0.23's data, but an error occurred when use the --prepare command with percona-xtrabackup-8.0.23-16,the error message is
InnoDB: Assertion failure: os0file.cc:2907
InnoDB: thread 140477846411648InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.percona.com/projects/PXB.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
07:03:37 UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x46000
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x23d14ce]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup(handle_fatal_signal+0x2f3) [0x1205733]
/lib64/libpthread.so.0(+0xf630) [0x7fc38be11630]
/lib64/libc.so.6(gsignal+0x37) [0x7fc389c0a3d7]
/lib64/libc.so.6(abort+0x148) [0x7fc389c0bac8]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0xb2) [0x1686402]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup(os_file_flush_func(int)+0x93) [0x155b483]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup(os_file_set_size(char const*, pfs_os_file_t, unsigned long, unsigned long, bool, bool)+0x728) [0x1564638]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup() [0xca525a]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup() [0xca559b]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup(srv_start(bool, unsigned long)+0x1a70) [0x16314a0]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup() [0xcecd8b]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup() [0xceeba9]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup(main+0xca9) [0xcab749]
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7fc389bf6555]
/tmp/percona-xtrabackup-8.0.23-16-Linux-x86_64.glibc2.12-minimal/bin/xtrabackup() [0xcda599]
I want to sure if there is a bug that percona-xtrabackup-8.0.23-16 could't be used with mysql8.0.23 version ,if this mysql 8.0.23 version was upgraded from other versions