Professional Web Applications Themes

MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever) - MySQL

Hi, is it possible that due to OS crash or mysql itself crash or some e.g. SCSI failure to lose all the data stored in the table (let's say million of 1KB rows). In other words what is the worst case scenario for MyISAM backend? Also is it possible to not to lose data but get them corrupted? Thx, Andy...

  1. #1

    Default MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    Hi,

    is it possible that due to OS crash or mysql itself crash or some e.g.
    SCSI failure to lose all the data stored in the table (let's say million
    of 1KB rows). In other words what is the worst case scenario for MyISAM
    backend?


    Also is it possible to not to lose data but get them corrupted?


    Thx, Andy
    alf Guest

  2. #2

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    >is it possible that due to OS crash or mysql itself crash or some e.g. 

    It is always possible that your computer system will catch fire and
    lose all data EVEN IF IT'S POWERED OFF. And the same nuclear attack
    might take up all your backups, too. And you and all your employees.
    Or the whole thing could just be stolen.

    Managing to smash just one sector, the sector containing the data
    file inode, or worse, the sector containing the data file, index
    file, AND table definition inodes, could pretty well kill a table.
    I have had the experience of a hard disk controller that sometimes
    flipped some bits in the sectors before writing them. It took weeks
    to discover this.
     

    Probably, total loss of data and hardware.
     

    I call that 'lost'. But yes, it is possible to end up with a bunch
    of data that's bad and you don't realize it until things have gotten
    much worse.

    Gordon Guest

  3. #3

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    Gordon Burditt wrote: 
    >
    > Managing to smash just one sector, the sector containing the data
    > file inode, or worse, the sector containing the data file, index
    > file, AND table definition inodes, could pretty well kill a table.
    > I have had the experience of a hard disk controller that sometimes
    > flipped some bits in the sectors before writing them. It took weeks
    > to discover this.
    >

    >
    >
    > Probably, total loss of data and hardware.
    >[/ref]

    well, let's narrow it down to the mysql bug causing it to crash. Or
    better to the all situations where trx's capabilities of InnoDB can
    easily take care of a recovery (to the last committed trx).

    I wonder if there is a possibility due to internal structure of MyISAM
    backend to lose entire table where even recovery tools give up.

    Would using ext3 help?


    Thx in advance, Andy
    alf Guest

  4. #4

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    alf wrote: 
    >>
    >>
    >> Managing to smash just one sector, the sector containing the data
    >> file inode, or worse, the sector containing the data file, index
    >> file, AND table definition inodes, could pretty well kill a table.
    >> I have had the experience of a hard disk controller that sometimes
    >> flipped some bits in the sectors before writing them. It took weeks
    >> to discover this.
    >>
    >> 
    >>
    >>
    >>
    >> Probably, total loss of data and hardware.
    >>[/ref]
    >
    > well, let's narrow it down to the mysql bug causing it to crash. Or
    > better to the all situations where trx's capabilities of InnoDB can
    > easily take care of a recovery (to the last committed trx).
    >
    > I wonder if there is a possibility due to internal structure of MyISAM
    > backend to lose entire table where even recovery tools give up.
    >
    > Would using ext3 help?
    >
    >
    > Thx in advance, Andy[/ref]

    As Gordon said - anything's possible.

    I don't see why ext3 would help. It knows nothing about the internal
    format of the tables, and that's what is most likely to get ed up
    in a database crash. I would think it would be almost impossible to
    recover to a consistent point in the database unless you have a very
    detailed knowledge of the internal format of the files. And even then
    it might be impossible if your system is very busy.

    The best strategy is to keep regular backups of the database.

    --
    ==================
    Remove the "x" from my email address
    Jerry Stuckle
    JDS Computer Training Corp.
    net
    ==================
    Jerry Guest

  5. #5

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S, hardware, whatever)

    Gordon Burditt wrote: 
    >
    > It is always possible that your computer system will catch fire and
    > lose all data EVEN IF IT'S POWERED OFF. And the same nuclear attack
    > might take up all your backups, too. And you and all your employees.
    > Or the whole thing could just be stolen.
    >
    > Managing to smash just one sector, the sector containing the data
    > file inode, or worse, the sector containing the data file, index
    > file, AND table definition inodes, could pretty well kill a table.
    > I have had the experience of a hard disk controller that sometimes
    > flipped some bits in the sectors before writing them. It took weeks
    > to discover this.[/ref]

    I spent weeks on a similar problem too - turned out to be bad RAM. The
    only filesystem that I know of which can handle such hardware failures
    is Sun's ZFS:
    http://blogs.sun.com/bonwick/entry/zfs_end_to_end_data
     
    >
    > Probably, total loss of data and hardware.

    >
    > I call that 'lost'. But yes, it is possible to end up with a bunch
    > of data that's bad and you don't realize it until things have gotten
    > much worse.[/ref]

    toby Guest

  6. #6

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    Jerry Stuckle wrote:
     


    only to not to get the file system corrupted.


     


    Well, mysql recovery procedures does have that knowledge. There are
    different levels of disaster. My assumption is that the file system
    survives.

     

    in my case it is a bit different. There are millions of rows which get
    inserted, live for a few minutes or hours and then they get deleted. the
    backup is not even feasible. While I can afford some (1-5%) data loss
    due to crash, I still must not lose entire table. Wonder if mysql
    recovery procedures can ensure that.

    --
    alf
    alf Guest

  7. #7

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    alf wrote: 
    >
    >
    >
    > only to not to get the file system corrupted.
    >
    >[/ref]

    That doesn't mean the tables themselves can't be corrupted. For instance
    if MySQL crashes in the middle of large write operation. Nothing the
    file system can do to prevent that from happening. And you would have
    to know exactly where to stop the file system restore to recover the
    data - which would require a good knowledge of MySQL table structure.
     
    >
    >
    >
    > Well, mysql recovery procedures does have that knowledge. There are
    > different levels of disaster. My assumption is that the file system
    > survives.
    >[/ref]

    Yes, it does. That's its job, after all. But if the tables themselves
    are corrupted, nothing the file system will do will help that. And if
    MySQL can't recover the data because of this, which file system you use
    doesn't make any difference. 
    >
    > in my case it is a bit different. There are millions of rows which get
    > inserted, live for a few minutes or hours and then they get deleted. the
    > backup is not even feasible. While I can afford some (1-5%) data loss
    > due to crash, I still must not lose entire table. Wonder if mysql
    > recovery procedures can ensure that.
    >[/ref]

    Backups are ALWAYS feasible. And critical if you want to keep your data
    safe. There is no replacement.

    You can get some help by using INNODB tables and enabling the binary
    log. That will allow MySQL to recover from the last good backup by
    rolling the logs forward. There should be little or no loss of data.

    But you still need the backups. There's no way to feasibly roll forward
    a year's worth of data, for instance.

    --
    ==================
    Remove the "x" from my email address
    Jerry Stuckle
    JDS Computer Training Corp.
    net
    ==================
    Jerry Guest

  8. #8

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    Jerry Stuckle wrote:
     

    I understand that.

     

    Not sure I agree. ext3 enables a quick recovery because there is a
    trxlog of the file system itself. In ext2 you can lose files. So there
    is a small step froward.

     

    In my case backups get outdated every minute or so. There is a lot of
    data coming into DB and leaving it. Also losing the data from last
    minute or so is not as critical (as opposed to banking systems).
    Critical is losing like 5%. I know the system is just different.

     


    For some other reasons INNODB is not an option. My job is to find out
    if crashing the mysql or the actual hardware the mysql is running on can
    lead that significant amount of data (more then 5%) is lost. From what
    I understand from here it is.

    Thx a lot, A.








    alf Guest

  9. #9

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    alf wrote: 
    >
    >
    > I understand that.
    >

    >
    >
    > Not sure I agree. ext3 enables a quick recovery because there is a
    > trxlog of the file system itself. In ext2 you can lose files. So there
    > is a small step froward.
    >[/ref]

    So? If the file itself is corrupted, all it will do is recover a
    corrupted file. What's the gain there?
     
    >
    >
    > In my case backups get outdated every minute or so. There is a lot of
    > data coming into DB and leaving it. Also losing the data from last
    > minute or so is not as critical (as opposed to banking systems).
    > Critical is losing like 5%. I know the system is just different.
    >[/ref]

    Without backups or logs/journals, I don't think ANY RDB can provide the
    recovery you want.
     
    >
    >
    >
    > For some other reasons INNODB is not an option. My job is to find out if
    > crashing the mysql or the actual hardware the mysql is running on can
    > lead that significant amount of data (more then 5%) is lost. From what
    > I understand from here it is.
    >
    > Thx a lot, A.
    >
    >[/ref]

    You have a problem. The file system will be able to recover a file, but
    it won't be able to fix a corrupted file. And without backups and
    logs/journals, neither MySQL nor any other RDB will be able to guarantee
    even 1% recovery - much less 95%.

    Let's say MySQL starts to completely rewrite a 100Mb table. 10 bytes
    into it, MySQL crashes. Your file system will see a 10 byte file and
    recover that much. The other 99.99999MB will be lost. And without a
    backup and binary logs, MySQL will not be able to recover.

    Sure, you might be able to roll forward the file system journal. But
    you'll have to know *exactly* where to stop or your database will be
    inconsistent. And even if you do figure out *exactly* where to stop,
    the database may still not be consistent.

    You have the wrong answer to your problem. The RDB must do the
    logging/journaling. For MySQL that means INNODB. MSSQL, Oracle, DB2,
    etc. all have their versions of logging/journaling, also. And they
    still require a backup to start.

    --
    ==================
    Remove the "x" from my email address
    Jerry Stuckle
    JDS Computer Training Corp.
    net
    ==================
    Jerry Guest

  10. #10

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S, hardware, whatever)

    Jerry Stuckle <net> wrote: 
    >
    > So? If the file itself is corrupted, all it will do is recover a
    > corrupted file. What's the gain there?[/ref]

    The gain is, that you have a chance to recover at all. With no files,
    there is *no* way to recover.

    However, thats not a real problem. MySQL never touches the datafile
    itself once it is created. Only exception: REPAIR TABLE. This will
    recreate the datafile (as new file with extension .TMD) and then
    rename files.

    DELETE just marks a record as deleted (1 bit). INSERT writes a new
    record at the end of the datafile (or into a hole, if one exists).
    UPDATE is done either in place or as INSERT + DELETE.

    Most file operations on MyISAM tables are easier, faster and less
    risky, if the table uses fixed length records. Then there is no need to
    collapse adjacent unused records into one, UPDATE can be done in place,
    there will be no fragmentation and such.

    The MyISAM engine is quite simple. Data and index are held in separate
    files. Data is structured in records. Whenever a record is modified,
    it's written to disk immediately (however the operation system might
    cache this). MyISAM never touches records without need. So if mysqld
    goes down while in normal operation, only those records can be damaged
    that were in use by active UPDATE, DELETE or INSERT operations.

    There are two exceptions: REPAIR TABLE and OPTIMIZE TABLE. Both
    recreate the datafile with new name and then switch by renaming.
    There is still no chance to lose *both* files.

    Indexes are different, though. Indexes are organized in pages and
    heavily cached. You can even instruct mysqld to never flush modified
    index pages to disk (except at shutdown or cache restructuring).
    However indexes can be rebuilt from scratch, without losing data.
    The only thing lost is the time needed for recovery.


    HTH, XL
    --
    Axel Schwenke, Senior Software Developer, MySQL AB

    Online User Manual: http://dev.mysql.com/doc/refman/5.0/en/
    MySQL User Forums: http://forums.mysql.com/
    Axel Guest

  11. Moderated Post

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    Removed by Administrator
    Jerry Guest
    Moderated Post

  12. Moderated Post

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S, hardware, whatever)

    Removed by Administrator
    Axel Guest
    Moderated Post

  13. #13

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S, hardware, whatever)

    Axel Schwenke wrote: 
    > >
    > > But the caching is all too important. It's not unusual to have hundreds
    > > of MB of disk cache in a busy system. That's a lot of data which can be
    > > lost.[/ref]
    >
    > Sure. But this problem was out of scope. We didn't talk about what
    > happens if the whole machine goes down, only what happens if mysqld
    > crashes.
    >
    > Having the whole system crashing is also hard for "real" database
    > engines. I remember several passages in the InnoDB manual about
    > certain operating systems ignoring O_DIRECT for the tx log. Also
    > there may be "hidden" caches in disk controllers and in the disks.[/ref]

    Indeed. Some references here:
    http://groups.google.com/group/comp.unix.solaris/msg/4817a85b71816f98
     

    toby Guest

  14. Moderated Post

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    Removed by Administrator
    Jerry Guest
    Moderated Post

  15. #15

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S, hardware, whatever)


    Jerry Stuckle wrote: 
    > >
    > >
    > > Agreed. But Alf worried he could lose whole tables aka files.
    > >
    > > 
    > >
    > >
    > > Sorry, I didn't express myself clear here: MyISAM never touches the
    > > metadata for a data file. The file itself is created with CREATE TABLE.
    > > Later on there is data appended to the file or some block inside the
    > > file is modified. But the file itself stays there and there is
    > > virtually no chance to lose it. So indeed there is no gain from using
    > > a filesystem with metadata journaling (in fact most "journaling"
    > > filesystems use the journal only for metadata).
    > >
    > > 
    > >
    > > ...
    > > 
    > >
    > >
    > > What do you call "rewrite"?
    > >
    > > Of cource MySQL writes modified data. MySQL never reads an otherwise
    > > unmodified record and rewrites it somewhere else.
    > >[/ref]
    >
    > Just what you are calling it. It reads in a block of data and writes it
    > back out to disk.[/ref]

    Note the words "otherwise unmodified" - i.e. not affected by current
    operation.
     
    > >
    > >
    > > Agreed. But then again I don't know how *exactly* MyISAM does those
    > > nonatomic writes. ...
    > >[/ref]
    >
    > Part of it is MyISAM. But part of it is the OS, also. For instance,
    > what happens if the row spans two physical blocks of data which are not
    > contiguous? In that case the OS has to write the first block, seek to
    > the next one and write that one.
    >
    > There isn't anything Monty can do about that, unfortunately.
    >[/ref]

    MyISAM doesn't claim to be transactional.
     
    >
    > Actually, you would lose all data which wasn't written to the disk.[/ref]

    Axel means, data *already* written which is not being changed, i.e.
    other records.
     
    > Agreed it's a problem. Most databases handle this with a log/journal
    > which writes directly to the file system and doesn't return until the
    > record is written. Once that is done, the real data is written
    > asynchronously to the tables.[/ref]

    Yes, but how is this relevant to MyISAM?
     
    >
    >
    > --
    > ==================
    > Remove the "x" from my email address
    > Jerry Stuckle
    > JDS Computer Training Corp.
    > net
    > ==================[/ref]

    toby Guest

  16. #16

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    toby wrote: 
    >>
    >>Just what you are calling it. It reads in a block of data and writes it
    >>back out to disk.[/ref]
    >
    >
    > Note the words "otherwise unmodified" - i.e. not affected by current
    > operation.
    >[/ref]

    Depends on your definition of "otherwise unmodified". That sounds like
    something different than "unmodified", doesn't it? "Otherwise
    unmodified" indicates *something* has changed.

    Now - if you just say "MySQL never reads an unmodified record and
    rewrites it somewhere else", I will agree.
     
    >>
    >>Part of it is MyISAM. But part of it is the OS, also. For instance,
    >>what happens if the row spans two physical blocks of data which are not
    >>contiguous? In that case the OS has to write the first block, seek to
    >>the next one and write that one.
    >>
    >>There isn't anything Monty can do about that, unfortunately.
    >>[/ref]
    >
    >
    > MyISAM doesn't claim to be transactional.
    >[/ref]

    Nope, and I never said it did. But this has nothing to do with
    transactions. It has to do with a single row - or even a single column
    in one row - being corrupted.

    Transactional has to do with multiple operations (generally including
    modification of the data) in which all or none must complete. That's
    not the case here.
     
    >>
    >>Actually, you would lose all data which wasn't written to the disk.[/ref]
    >
    >
    > Axel means, data *already* written which is not being changed, i.e.
    > other records.
    >[/ref]

    Could be. But that's not what he said. He said "not written to...".

    Now - if he means data which was not overwritten (or in the progress of
    being overwritten), then I will agree.
     
    >>
    >>Agreed it's a problem. Most databases handle this with a log/journal
    >>which writes directly to the file system and doesn't return until the
    >>record is written. Once that is done, the real data is written
    >>asynchronously to the tables.[/ref]
    >
    >
    > Yes, but how is this relevant to MyISAM?
    >[/ref]

    It goes back to the crux of the original poster's problem. He wants to
    use an access method which is not crash-safe and is trying to ensure the
    integrity of his data - or at least a major portion of it.
     
    >>
    >>[/ref][/ref]



    --
    ==================
    Remove the "x" from my email address
    Jerry Stuckle
    JDS Computer Training Corp.
    net
    ==================
    Jerry Guest

  17. #17

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S, hardware, whatever)

    >> > Agreed. But Alf worried he could lose whole tables aka files. [/ref][/ref]

    Ok, I assume here we are talking about a mysqld crash, NOT an OS crash,
    a power failure, or a hardware crash, or a hardware malfunction such
    as a disk controller that writes on the wrong sectors or writes random
    crap to the correct sectors.

    WHY did mysqld crash? One plausible scenario is that it has gone
    completely bonkers, e.g. because of a buffer-overflow virus attack
    or coding error. Scribbled-on code can do anything. It's even more
    likely to do something bad if the buffer-overflow was intentional.

    So, you have to assume that mysqld can do anything a rogue user-level
    process running with the same privileges will do: such as deleting
    all the tables, or interpreting SELECT * FROM ... as DELETE FROM
    .... Bye, bye, data. Any time you write data, there is a chance
    of writing crap instead (buggy daemon code, buggy OS, buggy hardware,
    etc.). Any time you write data, there is a chance of its being
    written in the wrong place.

    The worst case is considerably less ugly if you assume that mysqld
    crashes because someone did a kill -9 on the daemon (it suddenly
    stops with correct behavior up to the stopping point) and it is
    otherwise bug-free.

    The worst case is still very bad but the average case is a lot less
    ugly if you assume a "clean" interruption of power: writes to the
    hard disk just stop at an arbitrary point. (I have one system where
    a particular disk partition usually acquires an unreadable sector
    if the system crashes due to power interruption, even though 99% of
    the time it's sitting there not accessing the disk, read or write).

     [/ref][/ref]

    I believe this is incorrect. OPTIMIZE TABLE and ALTER TABLE (under
    some cirstances, such as actually changing the schema) will also
    do this. But these aren't used very often.

    Now consider what happens when you attempt doing this WITH INSUFFICIENT
    DISK SPACE for temporarily having two copies. I believe I have
    managed to lose a table this way, although it was a scratch table
    and not particularly important anyway. And this scenario has usually
    "failed cleanly", although it usually leaves the partition out of
    disk space so nothing much else works.

    As far as I know there are very few places where MySQL chops a file and
    then attempts to re-write it, and these are places where it's re-creating
    the file from scratch, with the data already stored in another file
    (REPAIR TABLE, OPTIMIZE TABLE, ALTER TABLE, DROP TABLE/CREATE TABLE).
    It won't do that for things like mass UPDATE. It may leave some more
    unused space in the data file which may be usable later when data is
    INSERTed.
     [/ref][/ref]

    Writing on a file changes the change-time metadata for the file.
    Writing on a file to extend it likely changes the list of blocks
    used by a file (if it is extended by enough to add more blocks).
     [/ref][/ref]

    I don't think this is true for operations that copy rows of tables.
    But that won't corrupt the source table.
     
    >>
    >> Just what you are calling it. It reads in a block of data and writes it
    >> back out to disk.[/ref]
    >
    >Note the words "otherwise unmodified" - i.e. not affected by current
    >operation.

    >>
    >> Part of it is MyISAM. But part of it is the OS, also. For instance,
    >> what happens if the row spans two physical blocks of data which are not
    >> contiguous? In that case the OS has to write the first block, seek to
    >> the next one and write that one.
    >>
    >> There isn't anything Monty can do about that, unfortunately.
    >>[/ref]
    >
    >MyISAM doesn't claim to be transactional.

    >>
    >> Actually, you would lose all data which wasn't written to the disk.[/ref]
    >
    >Axel means, data *already* written which is not being changed, i.e.
    >other records.

    >> Agreed it's a problem. Most databases handle this with a log/journal
    >> which writes directly to the file system and doesn't return until the
    >> record is written. Once that is done, the real data is written
    >> asynchronously to the tables.[/ref]
    >
    >Yes, but how is this relevant to MyISAM?[/ref]
    Gordon Guest

  18. #18

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S, hardware, whatever)


    Jerry Stuckle wrote: 
    > >
    > >
    > > Note the words "otherwise unmodified" - i.e. not affected by current
    > > operation.
    > >[/ref]
    >
    > Depends on your definition of "otherwise unmodified". That sounds like
    > something different than "unmodified", doesn't it? "Otherwise
    > unmodified" indicates *something* has changed.
    >
    > Now - if you just say "MySQL never reads an unmodified record and
    > rewrites it somewhere else", I will agree.[/ref]

    I think that's exactly what Axel meant, yes.
     
    > >
    > >
    > > MyISAM doesn't claim to be transactional.
    > >[/ref]
    >
    > Nope, and I never said it did. But this has nothing to do with
    > transactions. It has to do with a single row - or even a single column
    > in one row - being corrupted.
    >
    > Transactional has to do with multiple operations (generally including
    > modification of the data) in which all or none must complete. That's
    > not the case here.[/ref]

    The problem you describe is solved by transactional engines.
     
    > >
    > >
    > > Axel means, data *already* written which is not being changed, i.e.
    > > other records.
    > >[/ref]
    >
    > Could be. But that's not what he said. He said "not written to...".
    >
    > Now - if he means data which was not overwritten (or in the progress of
    > being overwritten), then I will agree.[/ref]

    Again, I think that's what he meant.
     
    > >
    > >
    > > Yes, but how is this relevant to MyISAM?
    > >[/ref]
    >
    > It goes back to the crux of the original poster's problem. He wants to
    > use an access method which is not crash-safe and is trying to ensure the
    > integrity of his data - or at least a major portion of it.[/ref]

    I guess you/Axel have covered some of the points where this just isn't
    possible. OP really ought to consider a different engine, no?
     [/ref]
    >
    >
    >
    > --
    > ==================
    > Remove the "x" from my email address
    > Jerry Stuckle
    > JDS Computer Training Corp.
    > net
    > ==================[/ref]

    toby Guest

  19. #19

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S,hardware, whatever)

    toby wrote: 
    >>
    >>Depends on your definition of "otherwise unmodified". That sounds like
    >>something different than "unmodified", doesn't it? "Otherwise
    >>unmodified" indicates *something* has changed.
    >>
    >>Now - if you just say "MySQL never reads an unmodified record and
    >>rewrites it somewhere else", I will agree.[/ref]
    >
    >
    > I think that's exactly what Axel meant, yes.
    >

    >>
    >>Nope, and I never said it did. But this has nothing to do with
    >>transactions. It has to do with a single row - or even a single column
    >>in one row - being corrupted.
    >>
    >>Transactional has to do with multiple operations (generally including
    >>modification of the data) in which all or none must complete. That's
    >>not the case here.[/ref]
    >
    >
    > The problem you describe is solved by transactional engines.
    >[/ref]

    Yes, it is solved by by "transactional engines". But you don't
    necessarily need to explicitly use transactions for it. For instance,
    INNODB can protect against that, even if you are using autocommit
    (effectively otherwise negating transactional operations).
     
    >>
    >>Could be. But that's not what he said. He said "not written to...".
    >>
    >>Now - if he means data which was not overwritten (or in the progress of
    >>being overwritten), then I will agree.[/ref]
    >
    >
    > Again, I think that's what he meant.
    >[/ref]

    It could be. I can only go by what he said. And sometimes English is
    not the best language, especially when discussing technical topics.
     
    >>
    >>It goes back to the crux of the original poster's problem. He wants to
    >>use an access method which is not crash-safe and is trying to ensure the
    >>integrity of his data - or at least a major portion of it.[/ref]
    >
    >
    > I guess you/Axel have covered some of the points where this just isn't
    > possible. OP really ought to consider a different engine, no?
    >[/ref]

    I agree completely.

    Of course, with the additional integrity comes additional overhead.
    TANSTAAFL.
     
    >>
    >>
    >>--
    >>==================
    >>Remove the "x" from my email address
    >>Jerry Stuckle
    >>JDS Computer Training Corp.
    >>net
    >>==================[/ref]
    >
    >[/ref]


    --
    ==================
    Remove the "x" from my email address
    Jerry Stuckle
    JDS Computer Training Corp.
    net
    ==================
    Jerry Guest

  20. #20

    Default Re: MyISAM engine: worst case scenario in case of crash (mysql, O/S, hardware, whatever)


    Jerry Stuckle wrote: 
    > >
    > >
    > > I think that's exactly what Axel meant, yes.
    > >
    > > 
    > >
    > >
    > > The problem you describe is solved by transactional engines.
    > >[/ref]
    >
    > Yes, it is solved by by "transactional engines". But you don't
    > necessarily need to explicitly use transactions for it. For instance,
    > INNODB can protect against that, even if you are using autocommit
    > (effectively otherwise negating transactional operations).[/ref]

    An Autocommited statement is no different from any other transaction,
    so it benefits from the same machinery, yes.
     
    > >
    > >
    > > Again, I think that's what he meant.
    > >[/ref]
    >
    > It could be. I can only go by what he said. And sometimes English is
    > not the best language, especially when discussing technical topics.[/ref]

    You apparently had more trouble deciphering his intended meaning than I
    did.
     
    > >
    > >
    > > I guess you/Axel have covered some of the points where this just isn't
    > > possible. OP really ought to consider a different engine, no?
    > >[/ref]
    >
    > I agree completely.
    >
    > Of course, with the additional integrity comes additional overhead.
    > TANSTAAFL.[/ref]

    Well, each of the engines has a different sweet spot (BDB, Solid, PBXT,
    Falcon) and we don't even know if the OP has a performance problem. I
    think he only mentioned an integrity problem?
     
    > >
    > >[/ref]
    >
    >
    > --
    > ==================
    > Remove the "x" from my email address
    > Jerry Stuckle
    > JDS Computer Training Corp.
    > net
    > ==================[/ref]

    toby Guest

Page 1 of 6 123 ... LastLast

Similar Threads

  1. mysql question : CASE
    By maraguida@gmail.com in forum MySQL
    Replies: 1
    Last Post: January 4th, 07:28 PM
  2. Is there a way to convert lower case text to upper case text in PHP?
    By tanas@ing.com.au in forum PHP Development
    Replies: 3
    Last Post: December 11th, 06:12 AM
  3. #23026 [Com]: Make Zend case-sensitive (classes, functions, remove case-insensitive)
    By nvivo at mandic dot com dot br in forum PHP Development
    Replies: 0
    Last Post: October 19th, 12:17 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139