zoukankan      html  css  js  c++  java
  • Xtrabackup 8.0.14 备份MySQL 8.0.22异常

    异常背景

    之前一篇博客介绍到由于MySQLredo日志的调整导致xtrabackup备份失败的文章,参考https://www.cnblogs.com/zhenxing/p/xtrabackup_mysql80.html,这次我们尝试用xtrabackup 8.0.14来备份MySQL 8.0.22再次触发异常BUG,具体原因依旧是MySQL对redo做了进一步调整,导致备份失败

    环境信息

    • ./xtrabackup8 --version
      • ./xtrabackup8 version 8.0.14 based on MySQL server 8.0.21 Linux (x86_64) (revision id: 113f3d7)
    • MySQL 8.0.22

    报错信息

    xtrabackup8 version 8.0.14 based on MySQL server 8.0.21 Linux (x86_64) (revision id: 113f3d7)
    xtrabackup: cd to /data/mysql/data/6630/urman-full-363292028/
    xtrabackup: This target seems to be not prepared yet.
    Number of pools: 1
    xtrabackup: xtrabackup_logfile detected: size=8388608, start_lsn=(17547913)
    xtrabackup: using the following InnoDB configuration for recovery:
    xtrabackup: innodb_data_home_dir = .
    xtrabackup: innodb_data_file_path = ibdata1:1G:autoextend
    xtrabackup: innodb_log_group_home_dir = .
    xtrabackup: innodb_log_files_in_group = 1
    xtrabackup: innodb_log_file_size = 8388608
    xtrabackup: using the following InnoDB configuration for recovery:
    xtrabackup: innodb_data_home_dir = .
    xtrabackup: innodb_data_file_path = ibdata1:1G:autoextend
    xtrabackup: innodb_log_group_home_dir = .
    xtrabackup: innodb_log_files_in_group = 1
    xtrabackup: innodb_log_file_size = 8388608
    xtrabackup: Starting InnoDB instance for recovery.
    xtrabackup: Using 209715200 bytes for buffer pool (set by --use-memory parameter)
    PUNCH HOLE support available
    Mutexes and rw_locks use GCC atomic builtins
    Uses event mutexes
    GCC builtin __atomic_thread_fence() is used for memory barrier
    Compressed tables use zlib 1.2.7
    Number of pools: 1
    Not using CPU crc32 instructions
    Directories to scan './'
    Scanning './'
    Completed space ID check of 5 files.
    Initializing buffer pool, total size = 256.000000M, instances = 1, chunk size =128.000000M
    Completed initialization of buffer pool
    If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
    Starting to parse redo log at lsn = 17547791, whereas checkpoint_lsn = 17547913
    Log scan progressed past the checkpoint LSN 17547791.
    Database was not shutdown normally!
    Starting crash recovery.
    Doing recovery: scanned up to log sequence number 18072402
    Log background threads are being started...
    Applying a batch of 323 redo log records ...
    10%
    20%
    30%
    40%
    50%
    60%
    70%
    80%
    90%
    100%
    Apply batch completed!
    Using undo tablespace './undo_001'.
    Using undo tablespace './undo_002'.
    Opened 2 existing undo tablespaces.
    GTID recovery trx_no: 1817
    Creating shared tablespace for temporary tables
    Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
    File './ibtmp1' size is now 12 MB.
    Scanning temp tablespace dir:'./#innodb_temp/'
    Created 128 and tracked 128 new rollback segment(s) in the temporary tablespace. 128 are now active.
    8.0.21 started; log sequence number 18072402
    Allocated tablespace ID 1 for sys/sys_config, old maximum was 0
    xtrabackup8: Unknown error 3611
    xtrabackup8: Unknown error 3611
    xtrabackup8: Unknown error 3611
    08:27:09 UTC - mysqld got signal 11 ;
    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
    xtrabackup8(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x230b55e]
    xtrabackup8(handle_fatal_signal+0x2eb) [0x11b729b]
    /lib64/libpthread.so.0(+0xf6d0) [0x7fd7318246d0]
    xtrabackup8(dd::get_dd_client(THD*)+0x1) [0x16c8061]
    xtrabackup8(dd_table_open_on_name(THD*, MDL_ticket**, char const*, bool, unsigned long, int*)+0x53a) [0x137306a]
    xtrabackup8() [0xcc9f5e]
    xtrabackup8() [0xccb060]
    xtrabackup8(main+0xca9) [0xc8ad19]
    /lib64/libc.so.6(__libc_start_main+0xf5) [0x7fd72f697445]
    xtrabackup8() [0xcb7bb7]
    Please report a bug at https://jira.percona.com/projects/PXB
    )
    

    percona官方BUG说明链接

    关于xtrabackup及MySQL的是否匹配的注意事项

    1. xtrabackup优先选择最新版的,越新越好
    2. MySQL尽量选择次新版(考虑xtrabackup的更新速度可能不及时,导致最新版的MySQL出来时,xtrabackup没法快速兼容)
    • 但这个需要注意的是MySQL8.0.24是一个一个过渡版本,当前最新为8.0.25,实际上8.0.24存在BUG导致8.0.25直接发布,在这种特殊的情况下,需要优先用8.0.25(可以理解为8.0.24这个版本生产环境不可用)
    转载请说明出处 |QQ:327488733@qq.com
  • 相关阅读:
    Documentum之基础(1)
    tomcat部署项目,war包问题[转]
    AD与LDAP区别
    Microsoft Visual Studio2010--此时无足够的可用内存,无法满足操作的预期要求,可能是由于虚拟地址空间碎片造成的。请稍后重试。
    Oracle 11g服务器安装详细步骤
    Oracle 11g 密码永不过期设置
    oracle 11g dbf数据文件从C盘迁移到D盘
    Swift 简介
    0Day 密码重置dede阿帕奇强制安装
    PS抠图教程_抠图小技巧_常用抠图小技巧_图片结构与配色
  • 原文地址:https://www.cnblogs.com/zhenxing/p/15102332.html
Copyright © 2011-2022 走看看