Issues
- xbstream does long post-processing after receiving all dataPXB-3470Satya Bodapati
- Optimize deleted files handling with reduced lockPXB-3468
- Missing 'posix_fadvise(file, 0, 0, POSIX_FADV_SEQUENTIAL)' when reading the redo log filesPXB-3467Resolved issue: PXB-3467Satya Bodapati
- test for attachementsPXB-3466
- --defaults-file is ignored by xtrabackup in --prepare modePXB-3465
- Bash process substitution for --defaults-file and --defaults-extra-file args doesn't work anymorePXB-3464
- Wrong default value of innodb_flush_methodPXB-3463
- Allow supplying the MySQL password in an environment variablePXB-3462
- Remove version check from PXB 8.4PXB-3461Satya Bodapati
- Backup fails with Vault related errorPXB-3460
- Xtrabackup failing to take backup on Mysql server where keyring is enabledPXB-3459
- Parameterize "PERCONA_SCHEMA.xtrabackup_history"PXB-3455
- [DOCS] - add an index 8.0PXB-3454Resolved issue: PXB-3454patrick.birch
- SST timeouts when mysqld takes more than 5 minutes to startPXB-3434
- Restore fails if non-defaults variables are usedPXB-3458
- Xtrabackup can not backup replicaPXB-3433Aaditya Dubey
- Assertion failure: log0recv.cc:4340:log.m_files.find(recovered_lsn) != log.m_files.end()PXB-3431
- Error when using Smart memory.PXB-3430Aaditya Dubey
- Error when using Smart memory.PXB-3429Resolved issue: PXB-3429
- Parallelize incremental delta apply in incremental backup preparePXB-3427Satya Bodapati
- On a busy server Xtrabackup crashes when using LZ4 as compression and KMIP encryption is usedPXB-3426Satya Bodapati
- When running XtraBackup on unsupported MySQL 9 version, it shows a message to use 9.1 version that doesn't existsPXB-3423
- xtrabackup got signal if --databases= very longPXB-3421
- xtrabackup got signal 11PXB-3420Resolved issue: PXB-3420
- xtrabackup fails with 'got signal 6' errorPXB-3412Resolved issue: PXB-3412
- Benchmark the performance of reduced lock featurePXB-3411Resolved issue: PXB-3411Satya Bodapati
- PXB 84 Creating Backup on replica failsPXB-3399Resolved issue: PXB-3399Satya Bodapati
- Merge mysql-9.1.0PXB-3396Resolved issue: PXB-3396aibek.bukabayev
- Verify latest version of PXB works with the newly created PS versionPXB-3395Resolved issue: PXB-3395mohit.joshi
- Verify PXB 8.0.35 works with PS 8.0.40PXB-3394Resolved issue: PXB-3394mohit.joshi
- General tablespaces are not handled properly when located in external data directoryPXB-3393Resolved issue: PXB-3393aibek.bukabayev
- xtrabackup doesn't pick up --innodb-log-group-home-dir config parameterPXB-3392
- Release PXB 8.0.35-32 (Q2 2024)PXB-3384Resolved issue: PXB-3384aibek.bukabayev
- Allow Xbcloud to respect AWS_CONFIG_FILE and AWS_PROFILE env variable configured using AWS RolesAnywherePXB-3382
- Implement check to fail early if number of open file handles is not same as number of files in datadirPXB-3381Resolved issue: PXB-3381Satya Bodapati
- Test new approach to handle duplicate filesPXB-3378Resolved issue: PXB-3378aibek.bukabayev
- Slave (replica) backup fails (8.4)PXB-3377Resolved issue: PXB-3377
- fut0lst.ic:82:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATAPXB-3372Satya Bodapati
- xtrabackup --stream does not exit on successPXB-3369Aaditya Dubey
- Fix jenkins test failuresPXB-3368Resolved issue: PXB-3368Satya Bodapati
- Documentation bug for xtrabackup 8.4.0PXB-3363Resolved issue: PXB-3363patrick.birch
- In which version does xtrabackup start to support PUNCH HOLE of mysql5.7?PXB-3362Resolved issue: PXB-3362
- percona-release setup pxb84-lts fails due to directory namingPXB-3361Resolved issue: PXB-3361Vadim Yalovets
- PXC concurrent backups - metadata lock hang with xtrabackup_historyPXB-3359aibek.bukabayev
- Allow for snapshots/incremental backups for myrocks enginePXB-3358Resolved issue: PXB-3358
- Document that xtrabackup --decompress requires the zstd to be installedPXB-3357Resolved issue: PXB-3357alina.derkach
- 话题 黄焕杰 8月26日 10:01 2024-08-25T19:40:26.473458+08:00 0 [Note] [MY-012550] [InnoDB] Doing recovery: scanned up to log sequence number 6309043033825 InnoDB: Assertion failure: log0files_capacity.cc:555:file_size <= LOG_FILE_MAX_SIZE InnoDB: thread 140659171PXB-3356Resolved issue: PXB-3356
- Implement snapshot/checkpoint based backups for MyRocksPXB-3355
- when restore backup with --move-back, with rocksdb engine, xtrabackup using copy insteadPXB-3353Resolved issue: PXB-3353
- Fix jenkins test failuresPXB-3352Resolved issue: PXB-3352Satya Bodapati
50 of
xbstream does long post-processing after receiving all data
General
Escalation
General
Escalation
Description
Environment
None
Attachments
3
blocks
Details
Details
Assignee
Satya Bodapati
Satya BodapatiReporter
Kamil Holubicki
Kamil HolubickiNeeds QA
Yes
Affects versions
Priority
Smart Checklist
Smart Checklist
Created last week
Updated last week
Activity
Show:
Kamil Holubickilast week
I created xbstream coredump: /bigdisk/kamil.holubicki/xbstream.coredump
symbol-file /home/kamil.holubicki/pxb-debug/usr/lib/debug/usr/bin/xbstream-8.0.35-32.1.el9.x86_64.debug
When we stream a backup containing huge tables, xbstream after receiving it spends a significant amount of time on post-processing.
Why it is a problem: PXC uses PXB for SST. On Joiner node there is a mechanism that prevents SST transfer to be stuck. It monitors if the receive directory size grows. If its size does not change for
sst-idle-timeout
(default 120 sec), SST script considers the transfer as stuck and cancels SST.Side note: in PXC it seems possible to monitor not only receive directory size, but also xbstream activity, but such a solution seems to be not perfect workaround (how much CPU consumption should we consider as “doing something” and how much as “waiting for data when the network is stuck”?). If we could avoid this “silent” time in PXB, or let the outside world know in any way, that streaming is still in progress, that would be a better solution.
Steps to reproduce:
Create a large database. I’ve attached create_manga_db.sql
Stuff the database tables with data. I’ve attached manga-insert.sh script (modify db connection parameters). It will take some time, but it will result in ca. 500GB database and a few huge tables (more than 100GB)
Do a backup (I used pxb 8.0.35)
./xtrabackup --defaults-file=/home/kamil.holubicki/sandboxes/msb_8_0_41/my.sandbox.cnf --backup --compress=lz4 --stream=xbstream --target-dir /home/kamil.holubicki/backup-1 -umsandbox -pmsandbox -H127.0.0.1 -P8041 > /home/kamil.holubicki/backup-1.stream
restore the backup
mkdir -p /bigdisk/kamil.holubicki/decompressed cd /bigdisk/kamil.holubicki/decompressed cat ../backup-1.stream | /home/kamil.holubicki/pxb-8.0.35/bin/xbstream -x --decompress --decompress-threads=4 --parallel=4
In another terminal observe the directory size
while sleep 1; do du -b -s decompressed; du -b -s -h decompressed; done
Once a directory size stops to grow, check that xbstream process is still active. In my test (highram2 server) it is ca 3:45min). Then xbstream finishes.
Note 1: There is stream file already prepared (to avoid 1, 2, 3). Its location is /bigdisk/kamil.holubicki/backup-1.stream
I attached to xbstream with gdb during the “silence” and here is the callstack:
#0 0x00007f8b1d4fdb6c in read () from /lib64/libc.so.6 #1 0x0000000000414910 in read (__nbytes=10485760, __buf=0x7f8b0ca04b10, __fd=3) at /usr/include/bits/unistd.h:38 #2 my_read (fd=3, Buffer=0x7f8b0ca04b10 ".Q\234^", Count=10485760, MyFlags=MyFlags@entry=0) at /usr/src/debug/percona-xtrabackup-80-8.0.35-32.1.el9.x86_64/mysys/my_read.cc:87 #3 0x00000000004197d8 in datafile_read (cursor=0x7f8b18bf5930) at /usr/src/debug/percona-xtrabackup-80-8.0.35-32.1.el9.x86_64/storage/innobase/xtrabackup/src/file_utils.cc:266 #4 restore_sparseness (buffer_size=10485760, error=0x7f8b18bf52c0 "\300\211\001\024\213\177", src_file_path=0x7f8b18bf54c0 "manga_data/manga_reading_status.ibd") at /usr/src/debug/percona-xtrabackup-80-8.0.35-32.1.el9.x86_64/storage/innobase/xtrabackup/src/file_utils.cc:316 #5 extract_worker_thread_func (ctxt=...) at /usr/src/debug/percona-xtrabackup-80-8.0.35-32.1.el9.x86_64/storage/innobase/xtrabackup/src/xbstream.cc:595 #6 0x00007f8b1d8dbad4 in execute_native_thread_routine () from /lib64/libstdc++.so.6 #7 0x00007f8b1d489d32 in start_thread () from /lib64/libc.so.6 #8 0x00007f8b1d50edc0 in clone3 () from /lib64/libc.so.6
Indeed, it seems we are reading the whole idb (huge) file, which takes time.
This behavior was introduced to pxb by commit 079ea2bb.
Note 2: It is probably possible to reproduce the issue with just one huge table.
Note 3: Having a compressed backup is necessary, because the problematic branch is executed only for that case.