Failure to start with "InnoDB: Warning: problems renaming '(name not specified)' to ..."
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
New
|
Undecided
|
Unassigned |
Bug Description
It seems our database attempted to restart when it received the following error:
...
140814 5:18:13 InnoDB: Error creating file './something_
140814 5:18:13 InnoDB: Operating system error number 17 in a file operation.
InnoDB: Error number 17 means 'File exists'.
...
Details are attached or here: http://
After the restart, it attempts a recovery but will crash again:
...
InnoDB: Doing recovery: scanned up to log sequence number 109613855949217
140814 9:53:38 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 140814 9:54:07 InnoDB: Warning: problems renaming '(name not specified)' to 'something_
140814 9:54:27 InnoDB: Warning: problems renaming '(name not specified)' to 'something_
...
140814 10:02:10 InnoDB: Warning: problems renaming '(name not specified)' to 'something_
140814 10:02:10 InnoDB: Assertion failure in thread 140083498571520 in file fil0fil.c line 2312
InnoDB: We intentionally generate a memory trap.
...
After hitting the assertion it dies. The stack trace is attached or here: http://
Previously we had to recover from backup to get back up and running, but maybe this is a bug that should not restart the database when it finds an existing file and just move it aside? Alternatively, is there a way to identify '(name not specified)' and get recovery to complete?
This is on CentOS release 6.2 (Final) with Percona-
description: | updated |
Changed in percona-server: | |
status: | Expired → New |
status: | New → Incomplete |
Changed in percona-server: | |
status: | Incomplete → New |
Thank you for the problem report. Please, upload your my.cnf file content and the entire error log (or at least tail of it since last successful startup before the problem happened) from that instance (if you still have it).
I wonder what happened to that trucker_check table in the something_staging database immediately before the problem.