Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 27.1Mb
PDF (A4) - 27.2Mb
HTML Download (TGZ) - 7.2Mb
HTML Download (Zip) - 7.2Mb


14.2.1 MySQL および ACID モデル

ACID モデルは、ビジネスデータおよびミッションクリティカルなアプリケーションで重要となる信頼性の側面が強調されたデータベース設計原則のセットです。ソフトウェアのクラッシュやハードウェアの誤動作などの例外的な状況でも、データが破損せず、結果が歪曲されないように、MySQL には、ACID モデルに厳密に準拠した InnoDB ストレージエンジンなどのコンポーネントが含まれています。ACID に準拠した機能に依存していれば、一貫性チェックおよびクラッシュリカバリのメカニズムを再開発する必要がありません。追加のソフトウェアの保護手段、信頼性が最高のハードウェア、または少量のデータ損失や不整合に耐えることができるアプリケーションが備わっている場合は、ACID の信頼性の一部と引き換えに、パフォーマンスやスループットが向上するように MySQL の設定を調整できます。

次のセクションでは、どのように MySQL の機能 (特に InnoDB ストレージエンジン) が ACID モデルのカテゴリとやりとりするのかについて説明します。

  • A: 原子性。

  • C: 一貫性。

  • I:: 分離性。

  • D: 持続性。

原子性

ACID モデルの原子性の側面には、主に InnoDBトランザクションが関与しています。関連する MySQL の機能は次のとおりです。

  • 自動コミット設定。

  • COMMIT ステートメント。

  • ROLLBACK ステートメント。

  • INFORMATION_SCHEMA テーブルの運用データ。

一貫性

ACID モデルの一貫性の側面には、主にクラッシュからデータを保護するための内部的な InnoDB 処理が関与しています。関連する MySQL の機能は次のとおりです。

分離性

ACID モデルの分離性の側面には、主に InnoDBトランザクション (特に、各トランザクションに適用される分離レベル) が関与しています。関連する MySQL の機能は次のとおりです。

  • 自動コミット設定。

  • SET ISOLATION LEVEL ステートメント。

  • InnoDB ロックの低レベルの詳細。これらの詳細は、パフォーマンスチューニング時に INFORMATION_SCHEMA テーブルから参照します。

持続性

ACID モデルの持続性の側面には、特定のハードウェア構成とやりとりする MySQL ソフトウェアの機能が関与しています。CPU、ネットワーク、およびストレージデバイスの性能に応じて多くの可能性が考えられるため、具体的なガイドラインを示す際は、この側面がもっとも複雑になります。(これらのガイドラインに従うことは、新しいハードウェアを購入するという形になる場合があります。)関連する MySQL の機能は次のとおりです。

  • innodb_doublewrite 構成オプションでオンとオフが切り替えられる InnoDB二重書き込みバッファー

  • innodb_flush_log_at_trx_commit 構成オプション。

  • sync_binlog 構成オプション。

  • innodb_file_per_table 構成オプション。

  • ストレージデバイス内の書き込みバッファー (ディスクドライブ、SSD、RAID アレイなど)。

  • ストレージデバイス内のバッテリーでバックアップされるキャッシュ。

  • MySQL を実行する際に使用されるオペレーティングシステム (特に、fsync() システムコールでのサポート)。

  • MySQL サーバーを実行し、MySQL データを格納するすべてのコンピュータサーバーおよびストレージデバイスへの電力を保護する無停電電源装置 (UPS)。

  • バックアップ方針 (頻度、バックアップのタイプ、バックアップの保存期間など)。

  • 分散型またはホスト型のデータアプリケーションの場合、MySQL サーバー用のハードウェアが配置されているデータセンター、およびデータセンター間のネットワーク接続の特定の特性。


User Comments
  Posted by curt mayer on May 9, 2014
D - not so much. DDL in particular is not recoverable in the face of server crash. it is very possible to create half-open tables where innodb and the filesystem are inconsistent with each other, and it is impossible to repair without a complete dump/reload cycle. The most obvious way to fix this is to have a mysql-level intent log, with a two-phase commit with the innodb. Not trivial.
Sign Up Login You must be logged in to post a comment.