<<Resent, because of attachment problem.>> At 09:52 17-4-2002, Michael Widenius shared with all of us:
Melvyn> Hi Monty / list, Melvyn> I still didn't change anything with the software, and now other tables, Melvyn> also with FT indexes are crashing - these tables have never had any Melvyn> problems at AIX. Also - the replica (2 servers are in replication with Melvyn> eachother) doesn't expose this error. Hardware, OS etc. is exactly the Melvyn> same. Built from a make clean && make, on the exact same source tree. I'm Melvyn> totally baffeled. First, this email list is dedicated for repeatable bug reports. In the future, please use [EMAIL PROTECTED] instead of this list when you have general problems with MySQL. For me - it IS repeatable, just don't know how - exactly, but found a clue: 020416 18:27:25 Error reading packet from server: Lost connection to MySQL server during query (read_errno 0,server_errno=2013) 020416 18:27:25 Slave: Failed reading log event, reconnecting to retry, log 'rep_log.003' position 186510180 020416 18:27:25 Slave: reconnected to master '[EMAIL PROTECTED]:3306',replication resumed in log 'rep_log.003' at position 186510180 020416 18:27:59 read_next_with_key: Got error 126 when reading table ./forum/hardware I think I solved that problem, by upping the openfiles as per your suggestion. (You can of course also get in direct contact with the MySQL developers by buying support from https://order.mysql.com ...) When this persists on AIX, I'll definitely do that. <cut> Melvyn> Didn't find any fields in table 'babbelbox' Have you checked your 'hostname'.err file for errors ? The above error normally means that you have not given MySQL enough file descriptors. This is a common problem on BSD and is fully documented in the online manual, under openbsd. Upped it and restarted mysql. Melvyn> Here's the strange part: mysql> CHECK TABLE hardware; Melvyn> +----------------+-------+----------+----------------------------+ Melvyn> | Table | Op | Msg_type | Msg_text | Melvyn> +----------------+-------+----------+----------------------------+ Melvyn> | forum.hardware | check | warning | Table is marked as crashed | Melvyn> | forum.hardware | check | error | Found 16426 keys of 16428 | Melvyn> | forum.hardware | check | error | Corrupt | Melvyn> +----------------+-------+----------+----------------------------+ Melvyn> 3 rows in set (1.33 sec) The above shows the symptoms, but not the reason for the crash :( When you have problems that mysqld hangs, or becomes unresponsible you should definitely look at the following MySQL entries: not applicable. MySQL keeps running - even the slave, which is kindof strange. Melvyn> I have a few more tables to go. Melvyn> Is there enough room, to roughly upload the binary versions of these index Melvyn> files, or doesn't this help you? Melvyn> I can upload the 'before' and 'after' version, so you're able to determin Melvyn> the difference. If you have something that we can use to repeat the problem, we are interested in looking at this! In this case it's enough to have the original tables + a set of commands to get corrupted tables. Before and after tables will not help us :( I don't get the checksum errors anymore - after I changed the table def. However - myisamchk is not doing a good job with the large keys (restored them by LOAD TABLE hardware FROM MASTER which produced the correct size), plus keys become corrupted when a replication packet is not received correctly, plus: mysql> SHOW VARIABLES LIKE '%ft%'; Empty set (0.07 sec) The myisamchck is certainly reproducable, as is the missing ft_ variables, resulting in no way to set ft_min_word_len. Should I re-report those bugs, so they are easier to process for you? Today I think I found something interesting: Some tables kept crashing, with incorrect keyfiles. Verifying the CREATE TABLE statement, there's was 1 correlation: The tables all had a second index on the primary key (for what reason? I don't know - legacy probably - I think the primary key, was dual-fielded at some point). Combining that with the other table that kept crashing there seems to be a problem, with the situation, where one field is indexed more than one time. The first table to crash, did so at a point, where openfiles could never have been a problem, since it was like 6:30 in the morning and no visiting spider anywhere which could have upped the number of open tables. Best regards, Melvyn Sopacua WebMaster IDG.nl _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If it applies, where it applies - this email is a personal contribution and does not reflect the views of my employer IDG.nl. \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\ --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
