Status: Closed (View Workflow)
2019-04-24 7:23:14 139727788889920 [Note] InnoDB: Highest supported file format is Barracuda.
2019-04-24 7:23:14 139727788889920 [Note] InnoDB: Starting crash recovery from checkpoint LSN=63489385105001
2019-04-24 7:23:14 139727788889920 [Note] InnoDB: Ignoring data file 'etl/t_raw_sfdc_acct_history.ibd' with space ID 11877969, since the redo log references etl/t_raw_sfdc_acct_history.ibd with space ID 11878568.
2019-04-24 07:23:14 0x7f14e938d740 InnoDB: Assertion failure in file /home/buildbot/buildbot/build/storage/innobase/log/log0recv.cc line 2467
InnoDB: Failing assertion: type != MLOG_INDEX_LOAD || srv_operation == SRV_OPERATION_NORMAL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
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: about forcing recovery.
190424 7:23:14 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
FYI... the backup seems to complete successfully. the instance does not crash.
MDEV-14545 Backup fails due to MLOG_INDEX_LOAD record
MDEV-16791 mariabackup : allow consistent backup, in presence of concurrent DDL, also without --lock-ddl-per-table