是否有可能由于操作系统崩溃或mysql本身崩溃或某些例如 SCSI无法丢失存储在其中的所有数据table（让我们说百万 的1KB行）。换句话说，MyISAM 后端的最坏情况是什么？ 也可以不丢失数据但是它们已损坏？ Thx，Andy
解决方案>是否可能由于操作系统崩溃或mysql本身崩溃或某些例如 > SCSI无法丢失表中存储的所有数据（让我们说百万行的1KB行）。
您的计算机系统始终可能会着火，并且即使它已断电，也会丢失所有数据。同样的核攻击 也可能占用你所有的备份。你和你所有的员工。 或者整件事情都可能被盗。 管理粉碎一个部门，包含数据的部门/> 文件inode，或者更糟糕的是，包含数据文件，索引 文件和表定义inode的扇区可以很好地杀死一个表。 我有过硬盘控制器的经验，有时候在写入之前会在扇区中翻转一些比特。花了好几周 来发现这个。
>换句话说，MyISAM 后端的最坏情况是什么？可能是数据和硬件完全丢失。
>也可以不丢失数据，但让他们损坏？我称之为丢失。但是，是的，有可能最终得到一堆好的数据，而且你还没有意识到这一点，直到事情变得更糟糕。
Gordon Burditt写道： >> ;是否有可能由于操作系统崩溃或mysql本身崩溃或某些例如SCSI失败而丢失存储在表中的所有数据（让我们说百万行的1KB行）。
管理只粉碎一个扇区，包含数据的扇区 文件inode，或更糟糕的是，包含数据文件的扇区，索引 文件，和表定义inode，可以很好地杀死一个表。 我有过硬盘控制器的经验，有时候是 在写入之前翻转扇区中的一些位。发现这个花了几周 。
>>换句话说，MyISAM最糟糕的情况是什么后端？可能是数据和硬件完全丢失。
好吧，让''缩小到mysql错误导致它崩溃。或者说更好地适用于所有情况，其中InnxDB的trx'的功能可以轻松地处理恢复（到最后提交的trx）。 我想知道是否有可能由于MyISAM的内部结构 后端而失去整个表格甚至恢复工具都会放弃。 会使用ext3帮助吗？ 提前Thx，Andy
alf写道： Gordon Burditt写道： >>是否可能由于操作系统崩溃或mysql本身崩溃或某些例如 SCSI无法丢失表中存储的所有数据（让我们说1百万行的数百万）。
管理只粉碎一个扇区，该扇区包含数据文件inode，或者更糟糕的是，包含数据文件的扇区，索引文件，和表定义inode，可以很好地杀死一个表。我有一个硬盘控制器的经验，有时在写入之前翻转扇区中的一些位。花了几周时间才发现这个。
>>换句话说，MyISAM的最坏情况是什么后端？可能是数据和硬件完全丢失。
好吧，让我们把它缩小到mysql的bug导致它崩溃。或者说更好地适用于所有情况，其中InnxDB的trx'的功能可以轻松地处理恢复（到最后提交的trx）。 我想知道是否有可能由于MyISAM的内部结构 后端而失去整个表格甚至恢复工具都会放弃。 会使用ext3帮助吗？ 提前Thx，Andy
正如戈登所说 - 一切皆有可能。 我不明白为什么ext3会有所帮助。它对表格的内部 格式一无所知，这是数据库崩溃中最有可能被搞砸的原因。我认为几乎不可能将恢复到数据库中的一致点，除非你对文件的内部格式有详细的了解。即便如此，如果您的系统非常繁忙，也可能无法获得。 最好的策略是定期备份数据库。 - ================== 删除x来自我的电子邮件地址 Jerry Stuckle JDS计算机培训公司 js ******* @ attglobal ==================
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
解决方案 >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 millionof 1KB rows).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.
>In other words what is the worst case scenario for MyISAMbackend?Probably, total loss of data and hardware.
>Also is it possible to not to lose data but get them corrupted?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 Burditt wrote: >>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 millionof 1KB rows).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.
>>In other words what is the worst case scenario for MyISAMbackend?Probably, total loss of data and hardware.
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 wrote: Gordon Burditt wrote: >>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 millionof 1KB rows).Managing to smash just one sector, the sector containing the datafile inode, or worse, the sector containing the data file, indexfile, AND table definition inodes, could pretty well kill a table.I have had the experience of a hard disk controller that sometimesflipped some bits in the sectors before writing them. It took weeksto discover this.
>>In other words what is the worst case scenario for MyISAMbackend?Probably, total loss of data and hardware.
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
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 screwed 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. js*******@attglobal ==================
更多推荐
MyISAM引擎：崩溃情况下的最坏情况（mysql,O / S,硬件,等等）
发布评论