本番データベース（MySQL / InnoDB）でバリアを使用する必要がありますか？

Question

barrierを有効にしてジャーナリングファイルシステム（EXT3）を使用している場合でも、これはより安全で推奨されますか？

例えば

mount -o barrier=1 /dev/sda /mntpnt

参照：

Eelke · Answer

はい、常に安全です。実際に腐敗する可能性は低いと思いました。ファイルシステムが破損した場合、修復が成功する可能性が非常に高くなります。 InnoDBなどのACID準拠データベースも、fsync /バリアを実行して、コミットされた変更がディスクに永続的に保存されるようにします。

運用環境では、冗長PSUまたはUPSを使用した高品質のサーバーを使用する必要があるため、ジャーナルが実際に必要になる可能性はかなり小さいことを忘れないでください。

それを有効にしない理由はパフォーマンスかもしれません。もちろん、これは書き込みパフォーマンスにのみ影響します。ただし、これらの種類のものはハードウェアに大きく依存するため、測定する必要があります。たとえば、RAIDコントローラーでバッテリーバックアップ式書き込みキャッシュを使用して実行している場合、コントローラーのライトバックキャッシュのため、パフォーマンスのペナルティはゼロと同じになります。

したがって、全体として、私はリスクが非常に小さいと信じていますが、それは何が問題になっているのかによって異なります。個人的には、これを正当化できるほどリスクが高い場合は、2番目のサーバーへのレプリケーションを検討していると思います。もちろん、すでに定期的なバックアップを作成しています。

ところで：fsyncは常にすべてのファイルを同期するため、ext3では非効率です！ ACID準拠のデータベースは多くのfsyncを実行する傾向があるため、可能であればext4を使用することをお勧めします。

RolandoMySQLDBA · Answer

あなたの質問はこれに向いています：MySQLデータのパフォーマンスや一貫性に対する私の懸念はありますか？

一貫性が最も重要な場合は、InnoDBのACID設定を維持します。

innodb_flush_log_at_trx_commit は1にする必要があります。パフォーマンスを向上させるために0または2に設定できますが、クラッシュした場合にデータが失われる可能性があります。

innodb_flush_method を使用して、MySQLがフラッシュデータを処理する方法を強化できます。何に設定するかわからない場合は、デフォルト設定のままにします。

sync_binlog を1に設定して、トランザクションがコミット時にバイナリログに記録されるようにすることができます。

ext3ジャーナリングとバリアに与えたリンクによると、これはアルゴリズムです：

ログブロックがジャーナルに書き込まれます。
バリア操作を行います。
コミットレコードが書き込まれます。
別のバリアが実行されます。
メタデータの書き込みは、後で開始されます。

わーい!!!これは、ディスクレベルでのACIDコンプライアンスのように感じられます。

クラウドサーバー上でVMWareを実行し、それからVMWareサーバーを作成することを想像してみてください。クラウドを実行するクラウドは、確かにパフォーマンスに挑戦します。これは、ext3バリアと、sync_binlog = 1およびinnodb_flush_log_at_trx_commit = 1に設定されたInnoDBにより、基本的にパフォーマンスの面で得られるものです。これは、InnoDBとext3の観点から、個別かつ集合的に最も安全で最も遅いアプローチです。

これを補正するには、InnoDBのパフォーマンスチューニングに集中する必要がある場合があります。

まず、sync_binlogを0のままにします。

次に、より多くのCPUとコアを使用するようにInnoDBを構成します。また、より大きなInnoDBログファイルが役立ちます。

このようなチューニングに関する過去のリンクの一部を以下に示します。

MySQL 5.1以前の場合は、MySQL 5.5またはPercona Server 5.5にアップグレードする必要があります。

mnagaraj · Answer

はい、電力損失保護を確実にするためにバリアが必要です。停電時にデータベースを完全に消去できます。リスクに見合う価値はありません。

バリアを無効にできるのは、ディスクにバッテリーバックアップ式のキャッシュがある場合のみです。