MySQL事物系列:2:事物の実現
1958 ワード
1:物事の隔離性は鍵によって実現される.物事の持続性と物事の原子性はredo logによって実現される.物事の一致性はundo logによって実現される.
redo logは、コミットされた変更のページ操作を復元します.
undo logはローにロールバックして特定のバージョンを記録します.
redoは通常物理ログであり、ページの変更操作を記録する.undoは論理ログであり、各行の記録に基づいて記録される.
2:redo
redo REDOログは、物事の持続性、すなわち、物事ACIDのDを実現するために使用されます.メモリ内のredo log bufferとディスク上のredo log fileは永続的です.
InnoDBは事物の記憶エンジンであり,Force Log at Commitメカニズムにより事物の持続性を実現する.すなわち、物事がコミットされると、その物事のすべてのログをREDOログファイルに書き込んで永続化する必要があります.物事のCOMMIT操作が完了してから完了します.
3:undo
undo logは、物事のロールバックやMVCCを助ける機能です.redo logは順番に書かれており、データベースの実行時にredo logのファイルを読み込む必要はありません.undo logはランダムな読み書きが必要です.
4:fsync
各ログがREDOログ・ファイルに書き込まれるようにするには、REDOログ・バッファがREDOログ・ファイルに書き込まれるたびに、InnoDBストレージ・エンジンがfsync操作を呼び出す必要があります.REDOログファイルが開いているためO_は使用されませんDIRECTオプション.したがって、REDOログ・バッファはファイル・システム・キャッシュに書き込まれます.REDOログがディスクに書き込まれることを確認するには、fsync操作を1回行う必要があります.fsyncの効率はディスクの性能に依存するため、ディスクの性能は物事のコミットの性能、すなわちデータベースの性能を決定する.
5:innodb_flush_log_at_trx_commit
InnoDBエンジンでは、ユーザーが手動で非永続的な設定を行うことで、データベースのパフォーマンスを向上させることができます.すなわち、物事がコミットされると、ログはREDOログファイルに書き込まれず、1サイクル後にfsync操作を実行します.ただし、データベースがダウンタイムになると、ログの一部がディスクにリフレッシュされないため、最後の時間のものが失われます.
innodb_flush_log_at_trx_commitは、物事がディスクをリフレッシュするポリシーを制御するために使用されます.
このパラメータのデフォルト値は1です.
この値は0または2に設定することもできます.0は、物事のコミット時にREDOログを書き込む操作を行わないことを示し、この操作はmaster threadで1秒に1回REDOログファイルのfsync操作を行う.2は、物事のコミット時にREDOログをREDOログファイルに書き込むが、ファイルシステムのバッファのみを書き込み、fsync操作を行わないことを示す.この設定の下でMySQLはダウンタイムして、オペレーティングシステムはダウンタイムがなくて、物事は失うことはありません.オペレーティング・システムがダウンタイムした場合、データベースを再起動すると、ファイル・システムからREDOログ・ファイルにリフレッシュされていないものの一部が失われます.
redo logは、コミットされた変更のページ操作を復元します.
undo logはローにロールバックして特定のバージョンを記録します.
redoは通常物理ログであり、ページの変更操作を記録する.undoは論理ログであり、各行の記録に基づいて記録される.
2:redo
redo REDOログは、物事の持続性、すなわち、物事ACIDのDを実現するために使用されます.メモリ内のredo log bufferとディスク上のredo log fileは永続的です.
InnoDBは事物の記憶エンジンであり,Force Log at Commitメカニズムにより事物の持続性を実現する.すなわち、物事がコミットされると、その物事のすべてのログをREDOログファイルに書き込んで永続化する必要があります.物事のCOMMIT操作が完了してから完了します.
3:undo
undo logは、物事のロールバックやMVCCを助ける機能です.redo logは順番に書かれており、データベースの実行時にredo logのファイルを読み込む必要はありません.undo logはランダムな読み書きが必要です.
4:fsync
各ログがREDOログ・ファイルに書き込まれるようにするには、REDOログ・バッファがREDOログ・ファイルに書き込まれるたびに、InnoDBストレージ・エンジンがfsync操作を呼び出す必要があります.REDOログファイルが開いているためO_は使用されませんDIRECTオプション.したがって、REDOログ・バッファはファイル・システム・キャッシュに書き込まれます.REDOログがディスクに書き込まれることを確認するには、fsync操作を1回行う必要があります.fsyncの効率はディスクの性能に依存するため、ディスクの性能は物事のコミットの性能、すなわちデータベースの性能を決定する.
5:innodb_flush_log_at_trx_commit
InnoDBエンジンでは、ユーザーが手動で非永続的な設定を行うことで、データベースのパフォーマンスを向上させることができます.すなわち、物事がコミットされると、ログはREDOログファイルに書き込まれず、1サイクル後にfsync操作を実行します.ただし、データベースがダウンタイムになると、ログの一部がディスクにリフレッシュされないため、最後の時間のものが失われます.
innodb_flush_log_at_trx_commitは、物事がディスクをリフレッシュするポリシーを制御するために使用されます.
このパラメータのデフォルト値は1です.
09:35:49>SHOW VARIABLES LIKE '%innodb_flush_log_at_trx_commit%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
1 row in set (0.00 sec)
この値は0または2に設定することもできます.0は、物事のコミット時にREDOログを書き込む操作を行わないことを示し、この操作はmaster threadで1秒に1回REDOログファイルのfsync操作を行う.2は、物事のコミット時にREDOログをREDOログファイルに書き込むが、ファイルシステムのバッファのみを書き込み、fsync操作を行わないことを示す.この設定の下でMySQLはダウンタイムして、オペレーティングシステムはダウンタイムがなくて、物事は失うことはありません.オペレーティング・システムがダウンタイムした場合、データベースを再起動すると、ファイル・システムからREDOログ・ファイルにリフレッシュされていないものの一部が失われます.