We recently ran a script against a mysql to convert all tables to use innodb. Unfortunately, this also included the system tables. The server will no longer start.
I didn't figure it would probably matter in this case, but also tried the
innodb_force_recovery in the config file and restarting. Same error.
Is there any way to get back to myisam from this dumb conversion on the system tables?
Dump we're receiving
Thread pointer: 0x92eb40
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...
000000014009A9A1 mysqld.exe!ha_resolve_by_name()[handler.cc:135]
0000000140119F6F mysqld.exe!open_binary_frm()[table.cc:897]
000000014011C12B mysqld.exe!open_table_def()[table.cc:644]
0000000140078204 mysqld.exe!get_table_share()[sql_base.cc:379]
000000014007829D mysqld.exe!get_table_share_with_create()[sql_base.cc:478]
000000014007A9B3 mysqld.exe!open_unireg_entry()[sql_base.cc:3874]
000000014007E0C1 mysqld.exe!open_table()[sql_base.cc:2931]
000000014007ED61 mysqld.exe!open_tables()[sql_base.cc:4630]
000000014007F258 mysqld.exe!open_and_lock_tables_derived()[sql_base.cc:5041]
000000014003643C mysqld.exe!plugin_load()[sql_plugin.cc:1417]
000000014003772A mysqld.exe!plugin_init()[sql_plugin.cc:1252]
000000014001DB5E mysqld.exe!init_server_components()[mysqld.cc:4021]
000000014001E315 mysqld.exe!win_main()[mysqld.cc:4490]
000000014001E6AF mysqld.exe!mysql_service()[mysqld.cc:4666]
00000001402EBAB7 mysqld.exe!_callthreadstart()[thread.c:295]
00000001402EBB85 mysqld.exe!_threadstart()[thread.c:275]
0000000076C7A4BD kernel32.dll!BaseThreadInitThunk()
0000000077076461 ntdll.dll!RtlUserThreadStart()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0000000000000000): =
Connection ID (thread ID): 0
Status: NOT_KILLED
Yeah, that is bad news. The mysql tables should not be converted from MyISAM; MySQL cannot work if they are.
Plan A: If you have any sort of dump, reload at least the database mysql from that dump. Then we can discuss how to get your tables loaded or whatever.
Plan B: Install a new copy of MySQL; it will have 'correct' in mysql (but won't have your GRANTs, etc.) Then we can discuss how (and whether) you can get your tables reloaded/rebuilt.
What dump(s) do you have? Recent? Old? In MyISAM? In InnoDB? What was the value of innodb_file_per_table? What version are you coming from / going to? (There, I am thinking about "transportable tablespaces".)
Won't help at the moment, but you should review the other gotchas in the conversion: http://mysql.rjweb.org/doc.php/myisam2innodb .
Related
Due to NDA I've difficulties providing an actual sample, that also makes filing a bug report quite useless.
It is a completely normal table, no specialities and 7 simple indexes on 1-2 columns each.
The Problem I have is that I have to regularly transfer a table between two Mysql 8.0.19 Servers (latest Percona stable they provide for Docker) and mysql crashes on signal 11 (segfault) every single time.
I've done this the same for a year without the issue and the table barely changed, crashing started recently.
I have this issue on 4 servers, 3 of them using Docker, one 1 normal Debian APT package
What I have tried:
1) I rebuilt the entire table to ensure the IBD file has no internal corruption.
2) I tried to split the table into multiple parts, in these cases the segfault crash only happens one part. Though I do not have the time to further reduce it to a single row.
06:55:37 UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
Thread pointer: 0x7fee7cde6100
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 = 7ff03c0f4d80 thread_stack 0x46000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x559950e1380e]
/usr/sbin/mysqld(handle_fatal_signal+0x351) [0x55994ff2e641]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0) [0x7ff04770e0e0]
/usr/sbin/mysqld(lob::z_index_page_t::get_n_index_entries() const+0x8) [0x5599512a10f8]
/usr/sbin/mysqld(lob::z_index_page_t::import(unsigned long)+0x18) [0x5599512a1628]
/usr/sbin/mysqld(PageConverter::update_page(buf_block_t*, unsigned long&)+0x3e1) [0x559950ff8051]
/usr/sbin/mysqld(PageConverter::operator()(unsigned long, buf_block_t*)+0x322) [0x559950ff86a2]
/usr/sbin/mysqld(fil_tablespace_iterate(dict_table_t*, unsigned long, PageCallback&)+0x9ef) [0x55995122027f]
/usr/sbin/mysqld(row_import_for_mysql(dict_table_t*, dd::Table*, row_prebuilt_t*)+0xdc6) [0x559950ff9ad6]
/usr/sbin/mysqld(ha_innobase::discard_or_import_tablespace(bool, dd::Table*)+0x422) [0x559950ecf742]
/usr/sbin/mysqld(Sql_cmd_discard_import_tablespace::mysql_discard_or_import_tablespace(THD*, TABLE_LIST*)+0x1bc) [0x55994fe787cc]
/usr/sbin/mysqld(mysql_execute_command(THD*, bool)+0x2645) [0x55994fe07b15]
/usr/sbin/mysqld(mysql_parse(THD*, Parser_state*)+0x360) [0x55994fe0ae70]
/usr/sbin/mysqld(dispatch_command(THD*, COM_DATA const*, enum_server_command)+0x1e93) [0x55994fe0d203]
/usr/sbin/mysqld(do_command(THD*)+0x168) [0x55994fe0deb8]
/usr/sbin/mysqld(+0xfcc9c8) [0x55994ff1f9c8]
/usr/sbin/mysqld(+0x23fdeb5) [0x559951350eb5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x74a4) [0x7ff0477044a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7ff04578fd0f]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
My main questions:
1)
Given that I have an exported IBD file (created as in manual with a flush and CFG file) and create the new table using 1:1 the same syntax as from "SHOW CREATE TABLE": Is there no way to access it like an MyIsam table ?
2)
Given that MyIsam is heading to 'deprecated' I am reluctant using it for this purpose, it would probably be much easier using it.
Is there any idea for how long it will be available still ?
Like I said in the beginning I have limitations, I can't provide a reproduceable case and finding the row which causes this is too time demanding.
Update
Uncompressing the table solved the segmentation faults, I hope it won't happen with the larger tables.
In this case I just list 30GB storage, that was an acceptable solution.
In case a Mysql developer reads this: the compression of blobs seems to have a serious bug somewhere.
In a word - no.
InnoDB pages contain a header, and the node ID is encoded in each page header. If this doesn't match what is in the master tablespace, created when the node was initialized, it won't work. IMPORT TABLESPACE rewrites the headers of each page in the imported tablespace.
What you're asking for simply isn't possible with InnoDB.
I have a mysql (Percona) 5.7 instance with over 1Million tables.
When I start the database, it can take more than an hour to start.
Errorlog doesn't show anything, but when I trace mysqld_safe, I found out that MySQL is getting a stat on every file in the DB.
Any idea why this may happen?
Also, please no suggestion to fix my schema, this is a blackbox.
Thanks
This turned out to be 2 issues (other than millions of tables)!
When MySQL start, and a crash recovery is needed, as of 5.7.17, it needs to traverse your datadir to build it's dictionary. This will be lifted in future releases(8.0), as MySQL will have it's own catalog, and will not rely on datadir content anymore. Doc states that this isn't done anymore. It's true and false. It doesn't read the 1st page of ibd files, but It does a file stat. Filed Bug
Once it finished (1), it starts a new process, "Executing 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' to get a list of tables using the deprecated partition engine.". That of course open all the files again. Use disable-partition-engine-check if you think you don't need it. Doc
All this can be observed using sysdig. very powerful handy dtrace like tool.
sysdig proc.name=mysqld | grep "open fd="
Ok, now, it's time to reduce the number of files.
I am a newbie to Mysql/Mac OS. Yesterday I turned my laptop (Yosemite 10.10.5) on and found that mysql workbench 6.3 was complaining when retrieving data from one of my tables:
Error Code: 1932. Table 'mydb.mytable' doesn't exist in engine
I cant think why this would suddenly start happening. The ibd file is 2.4GB but I guess that makes no difference.
The table is stored in INNODB format.
All I need to do is get the data, even if its in a text file or something, I dont care about relinking the data back into MySQL. At this stage all I care about is the data.
I've tried various things:
innodb_force_recovery (values from 0-6) (same error occurred)
PERCONA innodb recovery tool (i couldnt get it to compile)
deleting and recreating tablespaces (same error occurred)
http://www.chriscalender.com/tag/innodb-error-tablespace-id-in-file/ - but this does not give me the error he says it should, hence he thinks I should be able to dump my table (which I cant) as the same error occurs.
I'm at my wits end. Is there any way to get my data back? Any advice much appreciated.
Sometimes tables in the mySQL database crash after a server restart or after a lost connection to the database.
This have happen several times for the last 3-4 weeks.
This is how the error message looks like:
145 - Table './xxx/sessions' is marked as crashed and should be
repaired select value from sessions where sesskey =
'60fa1fab3a3d285cfb7bc1c93bb85f64' and expiry > '1395226673'
[TEP STOP]
So far it’s have been the tables "sessions" and "whos_online" that have crashed. If I repair the tables in phpmyadmin it will work fine again
After the last crash I changed "sessions" from MyISAM to InnoDB. The table "whos_online" still use MyISAM.
I use osCommerce 2.2 rc2a and I'm looking for any thoughts and suggestions in this matter.
One solution might be to change both these tables to InnoDB, since it supposed to be self-healing. Is that a good or bad idea?
Another one would be to have them in MyISAM and do something like this with the php-file that echo the error message:
if $error contain "is marked as crashed and should be repaired"
run a table repair script
Would that be a good or bad idea?
Here’s my server specs
Database: MySQL 5.5.36-cll
PHP Version: 5.3.15
At first you should address the issue that tables become corrupted in the first place. InnoDB tries to repair broken files, but it cannot do magic. Repeated unsafe shutdowns or other accidents may seriously corrupt your database!
If you only have a small website, all variants are good. MyISAM is a little faster (sometimes), while InnoDB provides some extended features. If the server is strong enough, you will likely encounter no issues. I would stick with InnoDB in most cases as it accounts for consistent data and throws errors if files are broken, unlike MYISAM tables which are used and then sometimes throw errors in production...
But if something severely breaks, it requires more effort to get MySQL with InnoDB back up running if it does not automatically. There exist different InnoDB recovery modes which are only available from the shell of your server and require modifying the config file, starting the server by hand, reading its output and maybe doing some other actions. If you do not have any clue of these issues, you might want to stick with MyISAM instead. The server always starts, and if the table is utterly broken, you might need to import a backup. But this is more easily than editing config files and reading database outputs etc.
sometimes i get an error like "table is marked as corrupt and shld be repaired". that DB (tables) is using MyISAM. recently that keeps happening. what could be the causes? most recently i am executing a batch insert
INSERT INTO table (..., ..., ...) VALUES (...), (...), (...) ...
and it just hung. or took very long to complete it seems hung to me. the next day, when i checked the table was marked as corrupt again. when i try to use mysqlcheck -r it said all tables OK when it reached that "corrupt" table it hung there again...
so, what can i do to prevent this. and what could be the causes. the DB is hosted 3rd party, how can i debug this?
is InnoDB a more reliable engine to use? i heard MyISAM is faster but others say InnoDB can be fast also but it takes abit more to optimize it. can i conclude that InnoDB is something more reliable but abit slower overall even with optimization?
If your tables get corrupt, you can use the repair table command to fix them:
REPAIR TABLE table;
If you run myisamchk while the server is still running (and inserts/selects are hitting the table), it could be what is corrupting your tables. Most of the corruption issues I run into are when trying to do things outside the server (copying the files, etc) while it is still running.
InnoDB is slower for read only databases, because it has features (ACID compliant, row level locking) that MyISAM leaves out. However, if you are doing a mixture of reads and writes, depending on the mixture, then InnoDB can offer serious performance improvements, because it doesn't have to lock the entire table to do a write. You also don't run into corruption issues.
Go with InnoDB.
ok, so the problem was the company's db exceeded the storage space allowed by the hosting company. so apparently noone told the company they exceeded the usage ... lousy host i guess.
btw, theres no way mysql could have known abt this?