私のデバイスには、ディスクオンモジュールまたはコンパクトフラッシュストレージを使用する TinyCore (3.6) Linux ディストリビューションがインストールされています。
ファイルシステムはext2です。
このデバイスには LAMP スタックがあり、400 を超えるテーブル (myisam) を含む MySQL データベースを操作しています。書き込み操作は 15 分ごとに体系的に発生します。
これらのテーブルは、セットアップのニーズに応じて、Web アプリケーションによって生成されます。
現在、電力不足のため、このデバイスが突然シャットダウンすることがあります。
MySQL が何らかの書き込み操作 (つまりupdate、、 )を実行している場合、一部のデータとインデックス ファイルが破損する可能性があります。deleteinsert
確かに大した問題ではありませんが、repair table操作を実行することはそれほど悪いことではありません。残念ながら一部のデータが失われたとしても (私の場合は許容範囲内です)、テーブルは修復され、アプリケーションは実行を継続できます。
問題は、突然のシャットダウンが発生すると、多くの場合、いくつかの MySQL テーブル ファイル (FRM または MYI または MYD) が「入力/出力エラー」状態になり、MySQL フロントエンドがそれらのテーブルに対して「ストレージ エンジン エラー 5」(I/O エラー) を報告することです。データベースを使用するアプリケーションは、明らかに正しく実行できません。
このようなイベント (ある程度は避けられないと思います) を防ぐのではなく、上記のシナリオから生じるファイル I/O エラー状況から正しく、可能であれば自動的に回復する方法について考えたいと思います。
何か案は？
編集： 残念ながら、ext3 に切り替えることはできません。ext3 はソリッド ステート メモリの書き込みサイクルに大きな影響を与えるため、ext2 を使い続ける必要があります。
答え1
CFを使用している場合、使用できない可能性がありますDM-マルチパスまたはその他の高可用性機能が必要な場合は、寿命を延ばすために、少なくともそれらのファイルシステムを「noatime」オプションでマウントする必要があります (独自のスクリプトなどで atimes に依存しない場合)。
それ以外では、最も堅牢なプラットフォームのようには思えません。