1

このようなオプションをオンにするリスクは、トランザクションの最後のN秒を失うよりも実際に高いというのは本当ですか？

私がこの質問をしている理由を説明しましょう。DBサーバーがトランザクションTを処理し、その結果として一連のインデックスページを変更したと想像してください。これらのインデックスページのいくつかはすでにディスクにフラッシュされていますが、他のいくつかはフラッシュされていません。ただし、Tによって行われたすべての操作は、まだディスク上のトランザクションログにフラッシュされていません。そして今、私たちは電源を切ります。

したがって、DBサーバーを再起動して回復しようとすると、トランザクションログにT操作は表示されません。ただし、Tによって変更された一部のインデックスページは電源障害の前にフラッシュされたため、一部のインデックスは実際にはこれらの操作を反映しています。つまり、結果として、Tは部分的に適用されます。おそらく、一貫性のないインデックス構造につながるような方法で適用されます（たとえば、テーブルXのプライマリインデックスはTによる変更を反映しませんが、そのセカンダリインデックスの一部は反映します）。

したがって、トランザクションログのフラッシュを遅らせると、このようなことが本当に可能になるのではないかと思います。そうでない場合は、データベースサーバーが実際にこれを防ぐために何をしますか（MySQL 5.5 w / InnoDBが私にとって最も興味深いケースです）。

4

4 に答える 4

1

Quoraでこの質問に対する完全な回答を得ました：

「チェックポイント（ダーティページフラッシュ）fsyncトランザクションログも、あなたが言及した状況を回避するためです。バックグラウンドスレッドタイマーだけがログフラッシュのソースではありません。ページ内のLSNが発生するため、これは非常に多くの警告を発生させることに注意してください。トランザクションログLSNの前に。

一般に、最後のデータが本当に必要ない限り、トランザクションログのフラッシュを無効にしてInnoDBを実行しても安全です（複製されたセットアップを実行する場合は、マスターにないデータ、つまりスレーブに存在する可能性のあるデータを処理する必要があります） 。」

于 2013-02-28T14:57:59.700 に答える
0

数年前のPerconaLive会議からのこのPDFには、まともな記事があります（55ページを参照）。

簡単な答え：値0は、COMMITでフラッシュまたは同期されないため、耐久性はまったくありません。少なくとも値が2の場合は、COMMITでフラッシュします。しかし、それでも、同期するのは1秒ごとであるため、許容できない妥協案であることがよくあります。

于 2013-02-21T01:40:41.737 に答える
0 
innodb_flush_log_at_trx_commit    
1  every commit log buffer flashed, synced,     no data loss
2  every commit log buffer flashed, not synced, data loss in OS crash or power loss
0  every second log buffer flashed, synced,     data loss on mysql crash, OS crash or power loss

innodb_flush_log_at_trx_commit=0データが重要でなく、ハードウェアが限られている場合は使用できると思います。しかし、お金のために、innodb_flush_log_at_trx_commit=1データを失わないようにするために銀行またはセキュリティソリューションを使用する必要があります。

于 2014-01-15T22:28:23.340 に答える
0

簡単な答え-安全ですが、OSまたはMySQLがクラッシュした場合、コミットされたトランザクションを最大1秒失う可能性があります。

アプリケーションに受け入れられるかどうかを判断するのはあなた次第です（たとえば、金融ソフトウェアはデータの損失を許容しませんが、コメントが失われた場合でもブログは存続します）。

于 2014-02-10T21:39:30.153 に答える