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


MySQL 5.6 リファレンスマニュアル  /  ...  /  MySQL Cluster でのトランザクション処理に関する制限

18.1.6.3 MySQL Cluster でのトランザクション処理に関する制限

MySQL Cluster には、トランザクションの処理に関していくつかの制限があります。これらには、次のものが含まれます。

  • トランザクション分離レベル  NDBCLUSTER ストレージエンジンは、READ COMMITTED トランザクション分離レベルのみをサポートします。(たとえば、InnoDBREAD COMMITTEDREAD UNCOMMITTEDREPEATABLE READ、および SERIALIZABLE をサポートします。)これがクラスタデータベースのバックアップとリストアに与える影響については、セクション18.5.3.4「MySQL Cluster バックアップのトラブルシューティング」を参照してください。)

  • トランザクションと BLOB または TEXT カラム  NDBCLUSTER は、MySQL から認識できるテーブルに MySQL の BLOB または TEXT データ型のいずれかを使用するカラム値の一部のみを格納します。BLOB または TEXT の残りの部分は、MySQL からアクセスできない別の内部テーブルに格納されます。これに関連して、これらの型のカラムを含むテーブルに対して SELECT ステートメントを実行するときに常に注意すべき問題が 2 つ発生します。

    1. MySQL Cluster テーブルからの SELECT の場合: SELECTBLOB または TEXT カラムが含まれる場合は、READ COMMITTED トランザクション分離レベルが読み取りロック付きの読み取りに変換されます。これは一貫性を保証するために行われます。

    2. 一意キーのルックアップを使用して BLOB または TEXT データ型のいずれかを使用するカラムを取得し、1 つのトランザクション内で実行される SELECT の場合は、共有読み取りロックがトランザクションの期間中 (つまり、トランザクションがコミットまたは中止されるまで) そのテーブルに保持されます。

      インデックスまたはテーブルスキャンを使用するクエリーでは、BLOB または TEXT カラムを含む NDB テーブルが対象であっても、この問題は発生しません。

      たとえば、次の CREATE TABLE ステートメントによって定義されたテーブル t について考えます。

      CREATE TABLE t (
          a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
          b INT NOT NULL,
          c INT NOT NULL,
          d TEXT,
          INDEX i(b),
          UNIQUE KEY u(c)
      ) ENGINE = NDB,

      t に対する次のクエリーでは、1 つ目のクエリーが主キールックアップを使用し、2 つ目が一意キールックアップを使用しているため、いずれも共有読み取りロックが発生します。

      SELECT * FROM t WHERE a = 1;
      
      SELECT * FROM t WHERE c = 1;

      しかし、ここに示す 4 つのクエリーでは、いずれも共有読み取りロックは発生しません。

      SELECT * FROM t WHERE b 1;
      
      SELECT * FROM t WHERE d = '1';
      
      SELECT * FROM t;
      
      SELECT b,c WHERE a = 1;

      その理由は、これら 4 つのクエリーのうち、1 つ目はインデックススキャンを使用し、2 つ目と 3 つ目はテーブルスキャンを使用し、4 つ目は (主キールックアップを使用していますが) BLOB または TEXT カラムの値を取得していないためです。

      BLOB または TEXT カラムを取得する一意キールックアップを使用するクエリーを回避するか、このようなクエリーを回避できない場合はトランザクションのコミットをできるだけあとで行うようにすると、共有読み取りロックによる問題を最小限に抑えることができます。

  • ロールバック  部分的なトランザクションおよびトランザクションの部分的なロールバックはありません。重複キーまたは同様のエラーが発生すると、トランザクション全体がロールバックされます。

    この動作は、個々のステートメントをロールバックできる InnoDB などのほかのトランザクション対応のストレージエンジンと異なります。

  • トランザクションとメモリー使用量  この章の別の場所で説明したように、MySQL Cluster では大規模なトランザクションが適切に処理されません。多数の操作を含む 1 つの大規模なトランザクションを実行するより、少数の操作を含む複数の小規模なトランザクションを実行する方が適切です。特に考慮すべき点は、大規模なトランザクションが非常に大量のメモリーを必要とすることです。このため、いくつかの MySQL ステートメントのトランザクション動作に対して次のリストに示すような影響があります。

    • TRUNCATE TABLE は、NDB テーブルに対して使用した場合、トランザクションになりません。TRUNCATE TABLE でテーブルを空にできない場合は、成功するまでこれを再実行する必要があります。

    • DELETE FROM (WHERE 句が内場合も含む) は、トランザクションになります。テーブルに非常に多くの行が含まれる場合は、複数の DELETE FROM ... LIMIT ... ステートメントを使用して削除操作をひとまとめにすると、パフォーマンスが向上することがあります。テーブルを空にすることが目的である場合は、代わりに TRUNCATE TABLE を使用することをお勧めします。

    • LOAD DATA ステートメント  LOAD DATA INFILE は、NDB テーブルに使用した場合、トランザクションになりません。

      重要

      LOAD DATA INFILE ステートメントを実行すると、NDB エンジンは通信ネットワークの利用率が高くなるように不規則な間隔でコミットを実行します。このようなコミットが発生するタイミングを事前に知ることはできません。

    • ALTER TABLE とトランザクション  ALTER TABLE の一部として NDB テーブルをコピーする場合、コピーの作成はトランザクションになりません。(いずれにしても、コピーが削除されたときにこの操作はロールバックされます。)

  • トランザクションと COUNT() 関数  MySQL Cluster レプリケーションを使用する場合、スレーブでの COUNT() 関数のトランザクション一貫性は保証されません。つまり、1 つのトランザクション内でテーブル内の行数を変更する一連のステートメント (INSERTDELETE、またはその両方) をマスターで実行しているときに、スレーブで SELECT COUNT(*) FROM table クエリーを実行すると、中間の結果が返される可能性があります。これは、SELECT COUNT(...) がダーティー読み取りを行うために発生し、NDB ストレージエンジンのバグではありません。(詳細は、Bug #31321 を参照してください。)


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
  Posted by Hartmut Holzgraefe on April 23, 2012
Another transaction related limitation: A long running transaction holding some lock can block a node restart. A restarting node needs to do a "lock everything" for a very short period of time to complete start phase 5. When stopping a node ongoing transactions blocking the stop operation will get terminated after a 5 second wait period, a starting node will not terminate any active transactions but will gracefully and silently wait for all transactions to complete, so an endless transaction that does not run into an inactivity timeout itself can block a node restart forever ...

See also http://bugs.mysql.com/bug.php?id=65037
Sign Up Login You must be logged in to post a comment.