Problem with xtrabackup

Also, I am wondering why e.g. the file brp_366/postalmap.ibd is missing from the tar file list…

Sorry, attached are the full structure tmp.tar and all files seems to be there. The open-files error is solved as it by standard was 1024 so that should not be an issue anymore.

"ERROR: HT: Error getting free space for path “/backup/urBackup/DB20a/171206-2356/urbackup_backup_scripts/mariadbxtrabackup/brp_366/postalmap.ibd”
postalmap.ibd is the “largest” table right now (just 20000 rows but all the others have below 1000) it that is any hint

“ERROR: Wrong number of embedded meta-data files. Expected 2319 but got 35”
Is this urbackups internal files or is it an error from xtrabackup

tmp.txt (47.4 KB)

No success reproducing this problem yet. Which xtrabackup version are you using?

Version 2.4.8

Could reproduce with that version. Could you try if it is fixed with that client version: https://www.urbackup.org/downloads/Client/2.1.17/UrBackup%20Client%20Linux%202.1.17.sh ?

Yes! It’s working with the 2.1.17 client:

12/11/17 19:31 INFO Transferred 130.014 MB - Average speed: 100.92 MBit/s
12/11/17 19:31 DEBUG Script does not exist urbackup/post_incr_filebackup
12/11/17 19:31 INFO Time taken for backing up client DB20a: 30s
12/11/17 19:31 INFO Backup succeeded

Thanks for quick and great work!

Hi
We are having some trouble with xtrabackup again. /usr/local/share/urbackup/scripts/mariadbxtrabackup > /dev/null manually is running fine without errors.

But the log from urbackup is filled with errors, log is attached

urbackup-DB20a.zip (29.3 KB)

We got this problem after upgrading urBackup server to 2.2.11 on ubuntu 16.04. Client is 2.2.5, Mysql server is 5.7 and xtrabackup is upgraded to 2.4.11.

Does anyone have any idea what could be wrong?

/Jens

Sorry you are having issues. To solve the problem the client (debug) log would be useful.
If possible, could you post it or send it?

This post describes how to change the client to debug logging, where it is stored and where to send it to if posting is not possible: Having problems with UrBackup? Please read before posting

Thanks!

Thanks, attached are the debug log. Pls let me know if there are anything else I could do to help

urbackupclient.zip (42.1 KB)

/Jens

Thanks. Could you redo that with this one: https://ssl.webpack.de/beta.urbackup.org/tmp/UrBackupUpdateLinux(10).sh I added some debug messages…

Here is the debuglog with the 2.2.6 version
urbackupclient.zip (46.1 KB)

Thanks! It may work now with https://ssl.webpack.de/beta.urbackup.org/tmp/UrBackupUpdateLinux(11).sh

Sorry, but I still get errors after upgrading the client:
urbackupclient.zip (241.5 KB)

Ok. How about this one? https://ssl.webpack.de/beta.urbackup.org/tmp/UrBackupUpdateLinux(12).sh

Hi,
Had another go at xtrabackup but still problems. The backup job runs for a while then the client crashes with the following in the kernel log: PipeFile: stdou[12957]: segfault at 7f14e805d000 ip 0000557b7662b1c5 sp 00007f14d3ffeac8 error 6 in urbackupclientbackend[557b7646d000+2f4000]

Attached are the debug log from the client and the serverlog.

Server is Ubuntu 18.04 with UrBackup Server 2.3.8
Client is Ubuntu 16.04 with UrBackup Client 2.3.4
MySQL 5.7.23 and xtrabackup 2.4.15-1

Regards
Jens

urbackup.log (5.7 KB) urbackupclient.log (261.0 KB)

Some fixes went into 2.4.x. Could you try with that?

Also helpfull would be if you get the crash location via gdb. Use a client with debug symbols ( https://www.urbackup.org/downloads/Client/2.4.8/UrBackup%20Client%20Linux%202.4.8-dbg.sh )

Get the pid of the client with pidof urbackupclientbackend.

Then

gdb
attach PID
… wait for crash …
bt

Hi,
Tried 2.4.8 and got the following result in gdb when crashing

(gdb) bt
#0 syscall () at bionic/libc/arch-x86_64/bionic/syscall.S:56
#1 0x00000000009e90a7 in inline_raise (sig=6, value=0x0)

  • at bionic/libc/private/bionic_inline_raise.h:64*
    #2 abort () at bionic/libc/bionic/abort.cpp:45
    #3 0x00000000009c932c in abort_message (
  • format=0xad60ec “terminating with %s exception of type %s: %s”)*
  • at /usr/local/google/buildbot/src/android/ndk-release-r20/external/libcxx/…/…/external/libcxxabi/src/abort_message.cpp:77*
    #4 0x00000000009c941e in demangling_terminate_handler ()
  • at /usr/local/google/buildbot/src/android/ndk-release-r20/external/libcxx/…/…/external/libcxxabi/src/cxa_default_handlers.cpp:62*
    #5 0x00000000009c6c13 in std::__terminate (func=0x3013)
  • at /usr/local/google/buildbot/src/android/ndk-release-r20/external/libcxx/…/…/external/libcxxabi/src/cxa_handlers.cpp:60*
    #6 0x00000000009c687d in __cxa_rethrow ()
  • at /usr/local/google/buildbot/src/android/ndk-release-r20/external/libcxx/…/…/external/libcxxabi/src/cxa_exception.cpp:618*
    #7 0x00000000004244cf in thread_helper_f (t=)
  • at Server.cpp:1470*
    #8 0x0000000000a12abf in __pthread_start (arg=0x7ffff2749d50)
  • at bionic/libc/bionic/pthread_create.cpp:338*
    #9 0x0000000000a52f08 in __start_thread (
  • fn=0xa12aa0 <__pthread_start(void*)>, arg=0x7ffff2749d50)*
    —Type to continue, or q to quit—
  • at bionic/libc/bionic/clone.cpp:53*

Regards
Jens

That’s unfortunately not helpful. At least this one should stop with a message like
“terminating with…” in stdout ? What’s that message?

Hi again, sorry, this was printed just before:

ClientService cmd: #IuXv9dgZztFlSpMWygLPa#2PING RUNNING pc_done=100&status_id=22&speed_bpms=0&total_bytes=0&done_bytes=0&paused_fb=1#token=MIdEPVcGsJ1C4Hw8eW0K
libc: malloc(8386059183675504016) failed: returning null pointer
ERROR: Thread exit with unhandled std::exception std::bad_alloc
terminating with uncaught exception of type std::bad_alloc: std::bad_alloc
libc++abi: terminating with uncaught exception of type std::bad_alloc: std::bad_alloc

Thread 12 “internet client” received signal SIGABRT, Aborted.
[Switching to LWP 12386]
syscall () at bionic/libc/arch-x86_64/bionic/syscall.S:56
56 bionic/libc/arch-x86_64/bionic/syscall.S: No such file or directory.

Maybe you can tell gdb to catch the exception via catch throw before you continue execution via “continue”… then it should show the proper location.

It might also be a different problem…