Re: Spontaneous corrupted tables on MyISAM with 5.0.x release
Hi Gerald, Michael, Gerald L. Clark wrote: Never put MySQl data files on an NFS exported share. Michael Dykman wrote: This is a bit of a generalization, but file locks are known to be pretty flakey and unreliable under NFS.. any kind of serious load begs races conditions which file locks normally sort out. I have had similar very bad luck using MySQL across NFS. Thanks for the input. I've talked with our Hoster, they told me that, technically, whether the mount points are directly mounted via NFS or whether they're VMware discs doesn't matter: the product operates solely on NFS, they're no real physical drives involved ... thanks, - Markus -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Spontaneous corrupted tables on MyISAM with 5.0.x release
Hi, our scenario (was): server1: 5.0.32-Debian_7etch1-log server2: 5.0.32-Debian_7etch1-log Hardware-wise (attention, Vmware, see below) they're equal: ~1GHz CPU at at minimum 2GB ram. Suddenly about 4 to 6 weeks ago, server1 started getting serious problems with spontaneous corrupted tables, so that in the end our hoster upgrade server1 to 5.0.51-2-log what we're currently running. Unfortunately, things haven't changed a bit. server2 is running different databases/applications, some tables are replicated from server1 to server2, some from server2 to server1. However, server2, as far as I can remember, never had those spontaneous table problems and still hasn't (yet). Both servers are running on VMware (I think ESX is the product our Hoster is using) and the MySQL data files are on a NFS exported share. Those share/fileserver is reported to be some kind of Ueber-Beast-Killer-Maschine. All servers running in Vmware don't contain virtual Vmware hard discs but have NFS mounted root and data, etc. partitions. We're very often, daily!, getting spontaneous corrupted tables on the server with the version which gets us really in trouble. The only pattern so far: 1) it only affects MyISAM tables 2) once converted to InnoDB, no troubles (so far) Unfortunately there are tables we weren't able to convert because they contain an fulltext index. Interestingly, once we converted all (except mentioned) tables in a database, the remaining MyISAM tables won't crash anymore (so far). Besides this, there's no distinct pattern, because we get crashes * on high and low traffic tables * on intensive and non-intensive write tables * on big (range between 100 and 150MB) and small tables It often occurred that a simple REPAIR table statement didn't always helped. Sometimes EXTENDED was required, sometimes an offline repair with the myisamchk had to be done. The tables didn't crash because the whole MySQL server went down, this was while the server was running. We've been running the applications using the databases for years. The were two major changes during the last year: * our moved the MySQL server from a physical machine to Vmware * we upgraded (better, let our Hoster upgrade) from some MySQL4 version to the mentioned versions above. We don't use any fancy stuff, more or less simple SELECT, DELETE, UPDATE, INSERT. No Subselects, no triggers, no stored procedures, no key constraints, etc, no locking, no REPLACE. Our Hoster refers to the following MySQL bugs http://bugs.mysql.com/bug.php?id=28154 http://bugs.mysql.com/bug.php?id=33596 However specially for 33596 I don't see any related information because this issue described there never applied. For 28154: Unfortunately I don't remember seeing this 127 error, however if it ever occurred, then only a long time ago. Recent errors are just corrupted tables once we start seeing problems in our web application. Our thread cache size is 128. Mentioned in #28154 is http://bugs.mysql.com/bug.php?id=29838 . I think that's the reason why our Hoster upgraded to 5.0.51. For what it matters, I just can't believe that MyISAM is to blame completely at fault. If it had that problems I just couldn't believe this was in a stable product. I'm really curious to just to fix the problems but also find out what the cause really is. I would be glad for any help on this matter and I'm happy to provide any information you want. thanks, - Markus -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Corrupted Tables, was:Memory Problems
On Tuesday 15 May 2007 14:36:45 Mathieu Bruneau wrote: Hi, yeah, apparenlty you're running into the 32 bits memory liimt. Note thta some memory is allocated for the OS so you don't even have the full 4GB of ram you can technically adressesed. The 64 bits os would increase this limit to 64gb++ (on 64 bits hardware) Good luck! Ok, changed OS to 64bit. But didn't have any luck at all :-( Upgrade was fine, used a dump to import all the data, and when everything was running, I got following error: May 16 22:47:09 sql mysqld[15259]: 070516 22:47:09 [ERROR] /usr/sbin/mysqld: Got error 134 from storage engine May 16 22:47:09 sql mysqld[15259]: 070516 22:47:09 [ERROR] /usr/sbin/mysqld: Sort aborted So I stopped the database, did a myisamchk and everythind was fine again. For about two minutes. Then these errors occured again. First error 134 (Record was already deleted (or record file crashed)) and after a while the tables could not be accessed anymore: May 16 23:12:03 sql mysqld[15259]: 070516 23:12:03 [ERROR] /usr/sbin/mysqld: Got error 127 from storage engine May 16 23:12:03 sql mysqld[15259]: 070516 23:12:03 [ERROR] /usr/sbin/mysqld: Sort aborted Repairing the tables worked. But it would take just some minutes until the tables got corrupted again. I tried mysql-5.0 from debian etch (5.0.32) ,4.1 from debian sarge (4.1.11) and 5.0 from debian-testing (5.0.38). All the same. Any hints anybody ? Cheers, Christoph mysql show variables; +-+-+ | Variable_name | Value | +-+-+ | back_log| 50 | | basedir | /usr/ | | binlog_cache_size | 32768 | | bulk_insert_buffer_size | 8388608 | | character_set_client| latin1 | | character_set_connection| latin1 | | character_set_database | latin1 | | character_set_results | latin1 | | character_set_server| latin1 | | character_set_system| utf8| | character_sets_dir | /usr/share/mysql/charsets/ | | collation_connection| latin1_swedish_ci | | collation_database | latin1_swedish_ci | | collation_server| latin1_swedish_ci | | concurrent_insert | ON | | connect_timeout | 5 | | datadir | /var/lib/mysql/ | | date_format | %Y-%m-%d| | datetime_format | %Y-%m-%d %H:%i:%s | | default_week_format | 0 | | delay_key_write | ON | | delayed_insert_limit| 100 | | delayed_insert_timeout | 300 | | delayed_queue_size | 1000| | expire_logs_days| 0 | | flush | OFF | | flush_time | 0 | | ft_boolean_syntax | + -()~*:| | | ft_max_word_len | 84 | | ft_min_word_len | 4 | | ft_query_expansion_limit| 20 | | ft_stopword_file| (built-in) | | group_concat_max_len| 1024| | have_archive| YES | | have_bdb| NO | | have_blackhole_engine | NO | | have_compress | YES | | have_crypt | YES | | have_csv| YES | | have_example_engine | NO | | have_geometry | YES | | have_innodb | YES | | have_isam | YES | | have_ndbcluster | DISABLED| | have_openssl| NO | | have_query_cache| YES | | have_raid | YES | | have_rtree_keys | YES | | have_symlink| YES | | init_connect| | | init_file
Re: corrupted tables
How about your disk space? I had a similar problem on a large table and it ended up being caused by filling up the disk. Steve Musumeche CIO, Internet Retail Connection [EMAIL PROTECTED] Octavian Rasnita wrote: From: Steve Edberg [EMAIL PROTECTED] Sometimes I see that some tables from my database get corrupted. Why does this happpen and how can I avoid it? It is not hard to go and use repair table but it seems that in this way some records could be deleted and this is not ok. If I want to have a very secure database, can I use MySQL? I hope the answer won't be that I need to make backups regularily. You'll have to give us some more information...at least: * What MySQL version, OS platform, and file system used for database? I am using MySQL 5, under Fedora Core 4, installed with its default options. * Does this happen at a regular time, or apparently randomly? It happends apparently randomly. Sometimes I just see that the programs are not working. Sometimes I can do some simple queries in the table with problems (like select count(*) from table_name), and the query works fine, but only when trying some more complex queries I can find that the table is corrupt and I need to fix it. Sometimes after fixing the table no records are deleted, but sometimes one or more records are deleted after fixing it. * Does this happen to the same tables all the time, or is that random as well? I found that it happends in more tables, but especially with one of them. That table has more than 2 million records and it is a MyISAM table. Should I use InnoDB instead? (Or another storage system?) That table is updated by a single program which runs continuously a few hours every day, and the program add (just addings and no updates) aproximately 1 records in those few hours... so they are not very very many. But other programs query that table very often. * Is this a precompiled binary from MySQL or did you build it yourself? It is a precompiled version from MySQL. I could see that if you compiled it yourself against some buggy libraries you could have problems; perhaps a cronjob is doing some copy/restore process on the underlying files without shutting mysql down or flushing logs; perhaps a lot of things...more information is needed. I have also seen (in most of the tables if not all) that after using check table table_name for the first time, I receive the message that the table was not closed by a few processes (from 2 to 6 processes). If I use that query a second time, I receive the message that the table is ok, and that message doesn't appear again. It has been my experience (on Windows NT, Solaris and Linux platforms) that MySQL has been one of the more reliable programs out there. Even after system crashes I haven't lost any data; a repair table and index rebuild fixed things. Yes in some cases it is the same for me, but after reparing a table, sometimes it tells me that some records were deleted because before that repair query the number of records reported is bigger. steve Thank you. Octavian -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
corrupted tables
Hi, Sometimes I see that some tables from my database get corrupted. Why does this happpen and how can I avoid it? It is not hard to go and use repair table but it seems that in this way some records could be deleted and this is not ok. If I want to have a very secure database, can I use MySQL? I hope the answer won't be that I need to make backups regularily. Thank you. Octavian -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: corrupted tables
Octavian Rasnita wrote: Hi, Sometimes I see that some tables from my database get corrupted. Why does this happpen and how can I avoid it? It is not hard to go and use repair table but it seems that in this way some records could be deleted and this is not ok. If I want to have a very secure database, can I use MySQL? I hope the answer won't be that I need to make backups regularily. This speaks nothing to the security or reliability of MySQL (or any other crucial/sensitive information), but why wouldn't you want to make regular backups? You could have the most reliable piece of software out there, but that won't help you when a hard drive fails. -- John C. Nichel IV Programmer/System Admin Dot Com Holdings of Buffalo 716.856.9675 [EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: corrupted tables
At 6:56 PM +0200 3/16/07, Octavian Rasnita wrote: Hi, Sometimes I see that some tables from my database get corrupted. Why does this happpen and how can I avoid it? It is not hard to go and use repair table but it seems that in this way some records could be deleted and this is not ok. If I want to have a very secure database, can I use MySQL? I hope the answer won't be that I need to make backups regularily. You'll have to give us some more information...at least: * What MySQL version, OS platform, and file system used for database? * Does this happen at a regular time, or apparently randomly? * Does this happen to the same tables all the time, or is that random as well? * Is this a precompiled binary from MySQL or did you build it yourself? I could see that if you compiled it yourself against some buggy libraries you could have problems; perhaps a cronjob is doing some copy/restore process on the underlying files without shutting mysql down or flushing logs; perhaps a lot of things...more information is needed. It has been my experience (on Windows NT, Solaris and Linux platforms) that MySQL has been one of the more reliable programs out there. Even after system crashes I haven't lost any data; a repair table and index rebuild fixed things. steve -- +--- my people are the people of the dessert, ---+ | Steve Edberghttp://pgfsun.ucdavis.edu/ | | UC Davis Genome Center[EMAIL PROTECTED] | | Bioinformatics programming/database/sysadmin (530)754-9127 | + said t e lawrence, picking up his fork + -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: corrupted tables
From: Steve Edberg [EMAIL PROTECTED] Sometimes I see that some tables from my database get corrupted. Why does this happpen and how can I avoid it? It is not hard to go and use repair table but it seems that in this way some records could be deleted and this is not ok. If I want to have a very secure database, can I use MySQL? I hope the answer won't be that I need to make backups regularily. You'll have to give us some more information...at least: * What MySQL version, OS platform, and file system used for database? I am using MySQL 5, under Fedora Core 4, installed with its default options. * Does this happen at a regular time, or apparently randomly? It happends apparently randomly. Sometimes I just see that the programs are not working. Sometimes I can do some simple queries in the table with problems (like select count(*) from table_name), and the query works fine, but only when trying some more complex queries I can find that the table is corrupt and I need to fix it. Sometimes after fixing the table no records are deleted, but sometimes one or more records are deleted after fixing it. * Does this happen to the same tables all the time, or is that random as well? I found that it happends in more tables, but especially with one of them. That table has more than 2 million records and it is a MyISAM table. Should I use InnoDB instead? (Or another storage system?) That table is updated by a single program which runs continuously a few hours every day, and the program add (just addings and no updates) aproximately 1 records in those few hours... so they are not very very many. But other programs query that table very often. * Is this a precompiled binary from MySQL or did you build it yourself? It is a precompiled version from MySQL. I could see that if you compiled it yourself against some buggy libraries you could have problems; perhaps a cronjob is doing some copy/restore process on the underlying files without shutting mysql down or flushing logs; perhaps a lot of things...more information is needed. I have also seen (in most of the tables if not all) that after using check table table_name for the first time, I receive the message that the table was not closed by a few processes (from 2 to 6 processes). If I use that query a second time, I receive the message that the table is ok, and that message doesn't appear again. It has been my experience (on Windows NT, Solaris and Linux platforms) that MySQL has been one of the more reliable programs out there. Even after system crashes I haven't lost any data; a repair table and index rebuild fixed things. Yes in some cases it is the same for me, but after reparing a table, sometimes it tells me that some records were deleted because before that repair query the number of records reported is bigger. steve Thank you. Octavian -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Mysql 4.0.4 + InnoDB leads to corrupted tables ?
Thank you very much Heikki. Your suggestions are useful. I also noticed that the use on symlinks are somehow deprecated with the last releases of Mysql. Concerning the problem : I lately discovered that the Air Conditioning of the servers room was OFF, thus there where some 40° (we could have grown orchards in there ;-) ). After restoring the AC, MySql and InnoDb are back to businness !! As far as I am concerned everithing is running fast and safe an smooth. Bye Andrea Forghieri Andrea, - Original Message - From: Andrea Forghieri [EMAIL PROTECTED] Newsgroups: mailing.database.mysql Sent: Saturday, October 12, 2002 2:02 AM Subject: Mysql 4.0.4 + InnoDB leads to corrupted tables ? Hi, I recently updated from 4.0.3 do 4.0.4 . everithing was running fast ans smooth (as always). Then I enabled for the first time the InnoDB feature. I was surprised to find out that everithing worked fine from the very beginning. The next day I start having handler error on non-inno tables of other databases ! I ran myisamchk to check and fix the tables : there where the majority of the tables with index probles. I restarted mysql WITHOUT innodb support, everithing was OK again. I restarted mysql WITH innodb and I had the most of the tables (especially the big ones) corrupted again. I decided not use innodb :-( What could be wrong ? this is the first case I hear that InnoDB could corrupt MyISAM tables. ... The only peculiar thing is that the db that (should) make use of innodb tables , has 2 MYISAM tables linked (ln -s) from another DB. Do you access the SAME MyISAM table BOTH from that other database AND from the database to which it is linked? If yes, MySQL does not know that they are actually the same table, and you will get corruption if you update the table in both databases. MySQL caches MyISAM index pages to key_buffer. Could this be the tricky combo ? Try putting a table to only one database. You can refer to a table in another database with databasename.tablename There is really no reason to link a table so that it is 'seen' in two databases. If this symlinking is not the bug, then the next step is to upgrade your Linux kernel. There appear to be lots of file i/o bugs in different Linux hardware/driver/kernel combinations. The following is the configuration of the cpu that runs mysql : OS : Linux (Mandrake 8.2) kernel 2.4.3-20 Mysql : 4.0.4 CPU : Pentium III 800 RAM : 127 Mb Best Regards Andrea Forghieri Emmegi S.p.A. Best regards, Heikki Tuuri Innobase Oy - sql query - 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
Re: Mysql 4.0.4 + InnoDB leads to corrupted tables ?
Andrea, - Original Message - From: Andrea Forghieri [EMAIL PROTECTED] Newsgroups: mailing.database.mysql Sent: Saturday, October 12, 2002 2:02 AM Subject: Mysql 4.0.4 + InnoDB leads to corrupted tables ? Hi, I recently updated from 4.0.3 do 4.0.4 . everithing was running fast ans smooth (as always). Then I enabled for the first time the InnoDB feature. I was surprised to find out that everithing worked fine from the very beginning. The next day I start having handler error on non-inno tables of other databases ! I ran myisamchk to check and fix the tables : there where the majority of the tables with index probles. I restarted mysql WITHOUT innodb support, everithing was OK again. I restarted mysql WITH innodb and I had the most of the tables (especially the big ones) corrupted again. I decided not use innodb :-( What could be wrong ? this is the first case I hear that InnoDB could corrupt MyISAM tables. ... The only peculiar thing is that the db that (should) make use of innodb tables , has 2 MYISAM tables linked (ln -s) from another DB. Do you access the SAME MyISAM table BOTH from that other database AND from the database to which it is linked? If yes, MySQL does not know that they are actually the same table, and you will get corruption if you update the table in both databases. MySQL caches MyISAM index pages to key_buffer. Could this be the tricky combo ? Try putting a table to only one database. You can refer to a table in another database with databasename.tablename There is really no reason to link a table so that it is 'seen' in two databases. If this symlinking is not the bug, then the next step is to upgrade your Linux kernel. There appear to be lots of file i/o bugs in different Linux hardware/driver/kernel combinations. The following is the configuration of the cpu that runs mysql : OS : Linux (Mandrake 8.2) kernel 2.4.3-20 Mysql : 4.0.4 CPU : Pentium III 800 RAM : 127 Mb Best Regards Andrea Forghieri Emmegi S.p.A. Best regards, Heikki Tuuri Innobase Oy --- Order technical MySQL/InnoDB support at https://order.mysql.com/ See http://www.innodb.com for the online manual and latest news on InnoDB sql query - 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
Mysql 4.0.4 + InnoDB leads to corrupted tables ?
Hi, I recently updated from 4.0.3 do 4.0.4 . everithing was running fast ans smooth (as always). Then I enabled for the first time the InnoDB feature. I was surprised to find out that everithing worked fine from the very beginning. The next day I start having handler error on non-inno tables of other databases ! I ran myisamchk to check and fix the tables : there where the majority of the tables with index probles. I restarted mysql WITHOUT innodb support, everithing was OK again. I restarted mysql WITH innodb and I had the most of the tables (especially the big ones) corrupted again. I decided not use innodb :-( What could be wrong ? I set all the variables according to MySQL manual. I did not use extreme memory settings. I created all the requested directories. The only peculiar thing is that the db that (should) make use of innodb tables , has 2 MYISAM tables linked (ln -s) from another DB. Could this be the tricky combo ? The following is the configuration of the cpu that runs mysql : OS : Linux (Mandrake 8.2) kernel 2.4.3-20 Mysql : 4.0.4 CPU : Pentium III 800 RAM : 127 Mb Best Regards Andrea Forghieri Emmegi S.p.A. - 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
Corrupted tables -- for 'no apparent' reason
Hello, We are using mySQL on over 6 servers here, we have been doing so for over 2 years, and we are constaly facing problems with corrupted tables, especially on two of our busiest servers. Tables seem to corrupt out of the blue and we have to shut them down ( the servers ) occassionaly to fix all tables and then bring them up again. This is really not something we want to do, bringing down a server that is, so we were wondering if we are doing something wrong. There must be other users of mySQL using it for far most difficult tasks who maybe faced the same problems once but managed to solve them. We are using mySQL 3.23.41. Tables corruptions occur regardless the server's configuration ( even on a system with PIII@1MhzX2 with 1.5G RAM we get those problems ) so maybe there is something wrong with the startup options we are using for mySQLd. This is how we start mySQLd. --skip-locking -O back_log=1024 -O table_cache=280 -O max_connections=2048 -O wait_timeout=30 -O interactive_timeout=30 -O long_query_time=2 --log-slow-queries=slow.log --big-tables Please reply to [EMAIL PROTECTED] Thank you in advance, Mark Papadakis - 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
Re: Corrupted tables -- for 'no apparent' reason
On Fri, Sep 07, 2001 at 10:29:31AM +0300, Mark Papadakis wrote: Hello, We are using mySQL on over 6 servers here, we have been doing so for over 2 years, and we are constaly facing problems with corrupted tables, especially on two of our busiest servers. Tables seem to corrupt out of the blue and we have to shut them down ( the servers ) occassionaly to fix all tables and then bring them up again. What Operating System? We are using mySQL 3.23.41. Tables corruptions occur regardless the server's configuration ( even on a system with PIII@1MhzX2 with 1.5G RAM we get those problems ) so maybe there is something wrong with the startup options we are using for mySQLd. This clearly shouldn't be happening. What table formats are you using? ISAM? MyISA? InnoDB? Jeremy -- Jeremy D. Zawodny, [EMAIL PROTECTED] Technical Yahoo - Yahoo Finance Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 MySQL 3.23.41-max: up 1 days, processed 18,317,521 queries (186/sec. avg) - 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
Re: Corrupted tables -- for 'no apparent' reason
Mark Papadakis wrote: We are using mySQL on over 6 servers here, we have been doing so for over 2 years, and we are constaly facing problems with corrupted tables, especially on two of our busiest servers. Tables seem to corrupt out of the blue and we have to shut them down ( the servers ) occassionaly to fix all tables and then bring them up again. I have found that sometimes (esp. with older versions of MySQL which is not the case for you) that the only way to either repair or permanently repair a table is to dump/drop/reload the table and data. I had some instances a number of years back where the table would repair and be okay with isamchk but would, at a random time, be corrupted again. Doing the dump, etc. fixed the problem. --Bill - 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
Re: Corrupted tables
I've had some db corruption on a few occasions, and luckily I was running the following in a nightly cron...it has since first install saved my butt on many an occasion. http://www.ocsny.com/main/index.ocs?url=mysqlbackup It doesn't do anything magickal just uses mysqldump and a basic routine to auto discover the databases in your db and print them into straight sql...I have another cron job that runns shortly after that tars the data to tape and then they can be erased from disk... cheers, mikel "Kissandrakis S. George" wrote: Hello I have mysql 3.23.31 on x86 linux Some big tables .ISM get corrupted without any crash or shutdown of mysqld Any suggestions? -- Kissandrakis S. George [[EMAIL PROTECTED]] Network and System Administrator [http://www.phaistosnetworks.gr/] Tel/Fax: (+30 892) 24450/23206 Phaistos Networks S.A. - A DOL Digital Company - 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 - 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
RE: TRUNCATE causes corrupted tables
Hi! No, I can't repeat it on command, sorry. However, I can give a little more info. When inserting, the index file got bigger. It was the data file that was set to 0 bytes, but did not get bigger on inserts. Doing a repair fixed it. I have some tables truncated via scripts, so I turned on mysql's auto repair feature so it can deal with it rather than me. Sincerely, Steven Roussey Network54.com http://network54.com/?pp=e - 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
