james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Cheng <c...@joecheng.com>
Subject Re: Innodb better?
Date Tue, 28 Jun 2005 14:28:38 GMT
Stefano Bagnara wrote:

>>However, MyISAM tables can corrupt if the mysql process is 
>>merely killed during a write, or the power is cut off.  Any 
>>decent logging/journaling[1] persistence strategy will 
>>protect you from these--there's no reason in the year 2005 
>>for this to be a point of failure at all.  InnoDB for example 
>>should not suffer from this problem, if it does then the 
>>MySQL folks *really* have no clue what they are doing.
>I think here there are too many people talking about theory and interpreting
>sentences to easily.
That may be--database administration is neither my job nor hobby and I 
don't claim to be an expert at anything.

The difference between MyISAM and InnoDB seems (in theory!) analogous to 
the difference between FAT and NTFS (or ext2 and ext3), in that the 
former is non-journalled and the latter is.  In my personal experience I 
have lost a lot of data to non-journalled filesystems (power outages, 
faulty power supply, or simply frozen computer).  That is why I was so 
alarmed when it sounded like people were casually dismissing InnoDB as a 
default choice.

However, last night I found out that MySQL offers a "binary log" that 
you can use with MyISAM that, for data recovery purposes, should let you 
(manually) recover from a crash as long as you have a backup from when 
the log began.  Although I couldn't figure out whether this 
functionality is enabled by default.

There may also be reasons why MyISAM is inherently more robust than say 
FAT--for example I found it surprising that myisamchk is so successful 
most of the time (according to most articles about it I could find).

>I personally ran multiple MySQL, from 1GB to 80GB databases, for 5 years
>having millions of updates per day and never lost data. After few hardware
>crash mysql at run said "myisam table corrupted, run myisamchk for a manual
>repair" (or something similar) I simply ran myisamchk and repaired the table
>before restart: it worked fine.
While that's great to hear, I would be wary of relying too heavily on 
anecdotal evidence when talking about data loss issues.  That sounds to 
me like saying "I've never worn seatbelts for the last 20 years and I've 
always been fine."

>Have you ever restarted an Oracle machine after an hardware crash? It happen
>once to me and I had to call an Oracle DBA because the DB was not restarting
>automatically. For sure maybe I've had luck with MySQL and lesser with
>Oracle but here is my practice.
>IMHO No transaction support doesn't mean more probability of data
>corruption: When the application does not use transaction you don't know
>wether is safer a transactional db or a not transactional one.
To be precise, I'm not talking about transactional vs. not 
transactional.  I am talking about journaling vs. non-journaling.  
You're right that the former does not mean increased crash safety, but 
the latter certainly should.  I agree with you that a non-transactional 
application could end up in an inconsistent state in any case.

>And about your sentence about MySQL folks, I would consider that MySQL is
>the MOST installed DB around, it simply works and it is FAST.
I said *if* InnoDB is a journaling database that doesn't protect you 
against crashes, then they don't know what they're doing.  The very 
point of journaling is to protect against this exact problem.

>James does not use transaction and if you look at source code you will find
>plenty of cases where after a SOFT restart it will resend the same message
>twice or after an HARD kill it will loose messages so I think that we should
>not give so much importance to the non transactionality of mysql.
Again, I'm not talking about the transactionality aspect and losing 
in-flight messages (although perhaps now we should!).  I am talking 
about journaling and whether arbitrary amounts of data can be lost in a 
database failure, and whether this problem can be avoided by simply 
defaulting to InnoDB.

It may very well be that MyISAM is not actually susceptible to data loss 
during a crash, but if so, I would feel a lot more comfortable knowing 
the technical reason for that.

>I will try InnoDB because of the row level locking: I think this feature
>could improve james spooling performance but I'm not sure.
Cool... I would also be interesting in hearing how bad the real-world 
performance impact on the rest of JAMES is.

>PS: it is REALLY easy to setup a slave mysql server that replicate your
>original server for better availability.
Yes, it's also very easy to tell James to use InnoDB.  I'm just assuming 
that most users will run James in whatever mode is the default.

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message