标签：osi 执行 通过 sql fat sql数据库 visio mysql数据库 ges
在生产环境中使用的是xtrabackup，对mysql进行备份，每天0点开始备份，周日是全量备份，其他时间是基于周日做的增量备份，通过脚本实现，每天备份完成后会发送短信，突然有一天，备份全部失败，手动执行也无法备份，报错的日志如下：
/usr/bin/xtrabackup version 2.4.8 based on MySQL server 5.7.13 Linux (x86_64) (revision id: 97330f7) incremental backup from 70857650633 is enabled. xtrabackup: uses posix_fadvise(). xtrabackup: cd to /usr/local/mysql/mysqldata/data1 xtrabackup: open files limit requested 8192, set to 1048576 xtrabackup: using the following InnoDB configuration: xtrabackup: innodb_data_home_dir = . xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend xtrabackup: innodb_log_group_home_dir = ./ xtrabackup: innodb_log_files_in_group = 2 xtrabackup: innodb_log_file_size = 536870912 InnoDB: Number of pools: 1 23:04:07 UTC - xtrabackup got signal 11 ; This could be because you hit a bug or data is corrupted. This error can also be caused by malfunctioning hardware. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. 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 0x10000 /usr/bin/xtrabackup(my_print_stacktrace+0x35)[0xd19635] /usr/bin/xtrabackup(handle_fatal_signal+0x273)[0xbccf03] /lib64/libpthread.so.0[0x383920f7e0] /usr/bin/xtrabackup(_Z8log_initv+0x24f)[0x7f0bcf] /usr/bin/xtrabackup(_Z22xtrabackup_backup_funcv+0x44c)[0x7424ac] /usr/bin/xtrabackup(main+0x9a1)[0x747e21] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3838a1ed1d] /usr/bin/xtrabackup[0x7354e9] Please report a bug at https://bugs.launchpad.net/percona-xtrabackup
在这种情况下，通过手动重启mysql数据库，就能解决。
标签：osi 执行 通过 sql fat sql数据库 visio mysql数据库 ges
原文地址：https://www.cnblogs.com/bobo137950263/p/11675245.html
