data corruption

I was updating a database and my database got corrupted ( I'm not sure what coused this) but ever since then I have been having lots of mysql problems. The onl way I can stop mysql is by doing a kill, mysqld stop fails. I was able to restore to a backed up database but now I can not add new items.

Data corruption issue

I'm experiencing data corruption with the latest version of MySQL: ares% mysql -V mysql Ver 11.15 Distrib 3.23.47, for pc-linux-gnu (i686) Compiled with: ares% gcc --version 2.95.4 I'm running MySQL as: /usr/local/libexec/mysqld --datadir=/home/mysql -O key_buffer_size=160M -O rec

Re: data corruption

Use mysqladmin shutdown to stop the server. You should have run myisamchk to fix the tables. When you copied the tables from backup you probably changed the user and permissions. Ransom wrote: > I was updating a database and my database got corrupted ( I'm not sure > what coused this) but eve

data corruption Update

I decided just to creat a new database and import my old data using a csv but I found another problem, I can now no longer create new datadases and I can not add any data to any of the databases stored on this machine. I was searching the logs and found this: 010708 0:37:02 Aborted connection 19

Very Strange data corruption

Query: insert into MIS.simcard(ID,ShipID,Service_Provider,SN,v1,v2,f1,d1,puk1,puk2,pin1,pin 2,TwoStage,Status,DateAssigned,DateDisabled,UserID) VALUES('NULL', '6889927707', '1', '8988169214000421398', '881621456175', '', '', '881693156175', '62982149', '', '', '', '1307', '1', '1085508771',

Data corruption on deletes

I have a table with several keys. When I try to delete anything from this table, I get data corruption and have to repair it with myisamchk. Selects, updates work fine. Here's the create table statement: CREATE TABLE `postsearch` ( `postId` int(11) NOT NULL default '0', `w

data corruption with mysqldump

Hello I send you this message from the Mediawiki mailing list. It explains clearly that mysqldump has an incorrect behavior which may lead to data destruction (I got this problem) Could you please do something to fix it ? Thanks Francois Colonna -BEGIN of MESSAGE- Sylvain Machefert

Re: Very Strange data corruption

Set the fieldtype to 'bigint' It's the limit on int "Jeff McKeon" <[EMAIL PROTECTED]> 05/25/2004 02:29 PM To: <[EMAIL PROTECTED]> cc: Subject:Very Strange data corruption Query: insert into MIS.simcard(ID,ShipID

RE: Very Strange data corruption

From: Jeff McKeon [mailto:[EMAIL PROTECTED] > Query: > > insert into > MIS.simcard(ID,ShipID,Service_Provider,SN,v1,v2,f1,d1,puk1,puk > 2,pin1,pin > 2,TwoStage,Status,DateAssigned,DateDisabled,UserID) > VALUES('NULL', '6889927707', '1', '8988169214000421398', > '881621456175', > '', '', '88169

Re: Very Strange data corruption

05/25/2004 02:29 Subject: Very Strange data corruption

RE: Very Strange data corruption

or all the explanations.. Jeff > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 25, 2004 2:41 PM > To: Jeff McKeon > Cc: [EMAIL PROTECTED] > Subject: Re: Very Strange data corruption > > > > Jeff, > > You are try

Re: Very Strange data corruption

MySQL really should throw an exception/error rather than just quietly trim your data and accept it. When your data is critical, and your business depends on it, you can't have bad data quietly going into the database. David. Mike Johnson wrote: From: Jeff McKeon [mailto:[EMAIL PROTECTED] Que

RE: Very Strange data corruption

From: David Griffiths [mailto:[EMAIL PROTECTED] > MySQL really should throw an exception/error rather than just quietly > trim your data and accept it. When your data is critical, and your > business depends on it, you can't have bad data quietly going > into the > database. Someone correct m

RE: Very Strange data corruption

> -Original Message- > From: David Griffiths [mailto:[EMAIL PROTECTED] > MySQL really should throw an exception/error rather than just quietly > trim your data and accept it. When your data is critical, and your > business depends on it, you can't have bad data quietly going > into th

Re: Very Strange data corruption

David Griffiths wrote: MySQL really should throw an exception/error rather than just quietly trim your data and accept it. When your data is critical, and your business depends on it, you can't have bad data quietly going into the database. David. Mike Johnson wrote: A value is not valid just

Re: Very Strange data corruption

It's best practice to write unit tests for all your code, with calculated data to show what you expect. That data then gets compared to what is actually generated and if there is a discrepency, then you have a bug somewhere. But the reason modern databases have foreign keys, primary keys, not-

Re: Very Strange data corruption

David Brodbeck wrote: The client software ought to be range-checking the data before sending it to the database. If the client isn't even doing that kind of minimal-effort check, how likely is it to be checking for exceptions? That's not to say that an error or exception is a bad idea, but MySQL

Re: Very Strange data corruption

The client software ought to be range-checking the data before sending it to the database. If the client isn't even doing that kind of minimal-effort check, how likely is it to be checking for exceptions? Not sure what you code in, but in Java, you *HAVE* to catch SQLExceptions (or throw them

Re: Very Strange data corruption

David Griffiths wrote: I'm not sure what the sql standard says on the matter, but Oracle, DB2 and Postgres would through an exception. In fact, there is a page on MySQL "gotachs" to document MySQL behaviour when it differs significnatly from other databases (like the first datetime field in a t

Re: Very Strange data corruption

[EMAIL PROTECTED] cc: Subject:Re: Very Strange data corruption It's best practice to write unit tests for all your code, with calculated data to show what you expect. That data then gets compared to what is actually generated and if there is a discrepency, then you have

Re: Very Strange data corruption

David Griffiths wrote: But the reason modern databases have foreign keys, primary keys, not-nulls, check constraints and data-metadata (char(5), INT, BIGINT, etc) is to prevent bad data from going in.. If no exception is thrown because you are trying to put a BIGINT into an INT, then why throw o

RE: Very Strange data corruption

From: Steve Meyers [mailto:[EMAIL PROTECTED] > David Griffiths wrote: > > I'm not sure what the sql standard says on the matter, but > Oracle, DB2 > > and Postgres would through an exception. In fact, there is > a page on > > MySQL "gotachs" to document MySQL behaviour when it differs > > sig

Re: Very Strange data corruption

This comes up frequently. MySQL's behavior is explained in the manual . It begins: | To be able to support easy handling of non-transactional tables, all | columns in MySQL have default values. | | If you insert an ``incorrect'' value i

Re: Very Strange data corruption

Michael Stassen wrote: This comes up frequently. MySQL's behavior is explained in the manual . It begins: That's interesting, and I guess one just has to accept it as part of the mysql philosphy. I don't agree, as I don't like the data

Re: Data corruption on deletes

Hardware? OS and version? MySql version? Size of data file? Size of index file? Filesystem type? Jim Nachlin wrote: I have a table with several keys. When I try to delete anything from this table, I get data corruption and have to repair it with myisamchk. Selects, updates work fine. Here&#

Re: Data corruption on deletes

n't open file: 'postsearch.MYI'. (errno: 144) So now I am repairing again. Thanks for your interest, Jim I have a table with several keys. When I try to delete anything from this table, I get data corruption and have to repair it with myisamchk. Selects, updates work fine.

Re: Data corruption on deletes

as although the DB seemed to be working afterwards, mysql> describe postsearch; ERROR 1016: Can't open file: 'postsearch.MYI'. (errno: 144) So now I am repairing again. Thanks for your interest, Jim I have a table with several keys. When I try to delete anything from this

(U) RE: Very Strange data corruption

CLASSIFICATION: UNCLASSIFIED who knows -Original Message- From: Mike Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 12:26 PM To: David Griffiths; [EMAIL PROTECTED] Subject: RE: Very Strange data corruption From: David Griffiths [mailto:[EMAIL PROTECTED] > MySQL rea

Data corruption following a power failure.

Hi. I've noticed that when a server running MySQL crashes and comes back to life, the MyISAM tables typically need to be repaired to account for the fact that they were not flushed when the server went down. However, I've also noticed that when the database is recovered from a crash, the tables

Re: Data corruption following a power failure.

Andrew Iles wrote: Is this the true behavior or does it just appear to work this way? And if so, is there any way to force MySQL to automatically save data to disk in a way that is chronologically correct? This would make it much easier for me to recover from an unexpected crash. What os/vers

Data corruption and server crash issues in replicated setup

Hi all, Starting Wednesday night, we observed several weird errors indicative of data corruption shortly before a CPU spike and complete crash on our master db server (opera.oursite.com). opera.oursite.com had crashed twice with signal 11 in recent weeks, but we had never observed any data

FLUSH TABLES WITH READ LOCK data corruption (the followup)

CSI drives and ECC memory. I've never experienced any data corruption outside of the FLUSH TABLES WITH READ LOCK problem. System: Linux *.fr 2.4.19 #3 SMP Fri Aug 9 15:18:06 CEST 2002 i686 unknown Architecture: i686 Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc /usr/

Inserting blob in database with gbk charset may cause error or data corruption

From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Inserting blob in database with gbk charset may cause error or data corruption Description: When mysql's sql statement lexer (sql/sql_lex.cpp)) analyzes a sql string, it uses the my_ismbchar macro on the default charset structu

Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

This is a follow-up to my previous post. I have been narrowing down what is causing this bug. It is a timing issue of a replication ignored table with an auto-increment primary key values leaking over into a non-ignored table with inserts immediately after the ignore table has had rows inserted.

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

Two additional notes: 1. Using the "replicate-wild-ignore-table" option in my.cnf produces the same results. 2. If the my.cnf "replicate-ignore-table=db.log" setting on the master is removed and mysql restarted so "db.log" is no longer ignored in replication, this bug goes away and correct res

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

Great investigation Hank, congratulations. I will try this tomorrow morning(11:20pm now) and let you know if I can reproduce it on my environments. Thanks! Claudio 2011/6/15 Hank > Two additional notes: > > 1. Using the "replicate-wild-ignore-table" option in my.cnf produces the > same res

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

Oops... big typo in above steps... add the following line: replicate-ignore-table=db.log to the SLAVE my.cnf, and restart the SLAVE server. The master does not need to be restarted or changed. Just the SLAVE. Sorry about that. -Hank Eskin On Wed, Jun 15, 2011 at 5:19 PM, Claudio Nanni wro

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

No worries! I think I would have figured that out! I'll feedback you tomorrow. Thanks again Claudio 2011/6/15 Hank > Oops... big typo in above steps... add the following line: > > replicate-ignore-table=db.log > > to the SLAVE my.cnf, and restart the SLAVE server. > > The master does not ne

Re: Found serious replication data-corruption bug in 5.5.8/5.5.11 (auto-increment in primary key)

Sveta Smirnova at Mysql just confirmed this bug in 5.5.13: http://bugs.mysql.com/45670 On Wed, Jun 15, 2011 at 5:38 PM, Claudio Nanni wrote: > No worries! > > I think I would have figured that out! > > I'll feedback you tomorrow. > > Thanks again > > Claudio > > 2011/6/15 Hank > >> Oops... big