Skip navigation links
MySQL 5.1 リファレンスマニュアル :: 14 MySQL Cluster :: 14.13 MySQL Cluster の既知の制限
14.14 MySQL Cluster 開発ロードマップ »
Section Navigation      [Toggle]

14.13. MySQL Cluster の既知の制限

この項では、MySQL Cluster の 5.1.x シリーズのリリースの MyISAM および InnoDB ストレージ エンジンを使用した際に利用できる機能との比較における既知の制限のリストを提供します。現在、これからリリースされる MySQL 5.1 でこれらを試す計画はありません。しかし、今後のリリースではこれらの問題で解決されたことを提供するつもりです。「Cluster」 カテゴリを http://bugs.mysql.com の MySQL バグ データベースでチェックすると、MySQL 5.1 の今後のリリースで修正する既知のバグ (「5.1」 の印の) を検索できます。

ここに掲げるリストは以下の条件で完成する予定です。何か齟齬があった場合には 項1.7. 「質問またはバグの報告」 の指示に従って MySQL バグ データベースにレポートできます。その問題を MySQL 5.1 で修正しない場合には、それをリストに追加します。

(注:現在のバージョンで解決された MySQL 5.0 Cluster の問題のリストについてはこの項の末尾を参照してください。

MySQL Cluster のレプリケーションに特定の制限とその他の問題に関しては、項14.10.3. 「既知の問題」 の説明を参照してください。

  • 構文の不承諾 (既存のアプリケーションを実行中のエラーによる):

    • テンポラリ テーブルはサポートしていません。

    • テキスト インデックスはサポートしていません。つまり、TEXT データベースのカラムにはインデックスを作成できません。また NDB ストレージ エンジンは FULLTEXT インデックス (これらは MyISAM のみサポートしています。) をサポートしていません。しかし、NDB テーブルの VARCHAR カラムはインデックスできます。

    • A BIT カラムはプライマリ キー、インデックスにはできません。またコンポジットのプライマリ キー、一意のキー、あるいはインデックスの一部を構成することもできません。

    • ジオメトリーデータ タイプは (WKT および WKB) はMySQL の NDB テーブルでサポートされています。5.1.しかし、スペーシャル インデックスはサポートされていません。

    • CREATE TABLE ステートメントは 4096 文字以内です。この制限は MySQL 5.1.6、5.1.7、および 5.1.8 のみに影響を及ぼします。.(See Bug#17813)

    • MySQL 5.1.7 およびそれ以前では、INSERT IGNORE、UPDATE IGNORE、および REPLACE はプライマリ キーのみサポートしており、一意のキーはサポートしていません。この制約を外す一つの解決策は一意のインデックスを削除し、挿入を実行し、次に一意のインデックスを再度追加することです。

      この制限は MySQL 5.1.8 のINSERT IGNORE および REPLACE には削除されています (Bug#17431)。

    • MySQL 5.1 の MySQL Cluster のユーザー定義のパーティショニングのサポートは [LINEAR] KEY パーティショニングに制限されています。MySQL 5.1.12 以降では、他のパーティショニング タイプを CREATE TABLE の ENGINE=NDB あるいは ENGINE=NDBSLUSTER ステートメントで使用するとエラーになります。

      MySQL 5.1.6 では、デフォルトでテーブルのプライマリ キーをパーティショニング キーとして使用して KEY によってパーティションされています。プライマリ キーが明示的にテーブルに設定されていない場合、代わりに NDB ストレージ エンジンによって自動的に作成された 「非表示」 のプライマリ キーが使用されます。これらの説明およびf関する問題に関しては、 項15.2.4. 「KEY パーティショニング」 を参照してください。

      NDB テーブルから ALTER TABLE ...DROP PARTITION を使用してパーティションを削除することはできません。ALTER TABLE — ADD PARTITION、REORGANIZE PARTITION、および COALESCE PARTITION — への他のパーティションの拡張はクラスタ テーブルにはサポートされていますが、コピーなどの使用は最適化できません。 項15.3.1. 「RANGE と LIST パーティションの管理」 および 項12.1.2. 「ALTER TABLE 構文」 を参照してください。

    • 行ベースのレプリケーションを MySQL Cluster で使用する場合、バイナリのロギングは無効にできません。つまり、NDB ストレージ エンジンは SQL_LOG_BIN の値を無視します。(Bug#16680)

    • auto_increment_increment および auto_increment_offset サーバーシステムの変数はクラスタのレプリケーションをサポートしていません。

  • 制限あるいは振る舞いの不承認 (既存のアプリケーションを実行した場合エラーになる場合があります。):

    • メモリの使用:

      データが NDB テーブルに挿入された際に使用されたメモリは他のストレージ エンジン同様削除されても自動的元に戻りません。代わりに以下の規則が適用されます。

      • NDB テーブルの DELETE ステートメントは削除された行で公式に使用されたメモリを同じテーブルに挿入に対してのみ再利用できるようにします。メモリは他の NDB テーブルでは使用できません。

      • NDB テーブルの DROP TABLE あるいは TRUNCATE オペレーションはこのテーブルで使用されたメモリを NDB テーブル — を同じテーブルあるいは別の NDB テーブルのいずれかで使用できるようにします。

        (TRUNCATE はテーブルを削除して再度作成するこを思い出してください項12.2.9. 「TRUNCATE 構文」 参照。)

        DELETE オペレーションで使用できるようになったがそれでも特定のテーブルに割り当てられているメモリはクラスタのローリング再起動を実行することで一般的に再度使用できるようになります。項14.5.1. 「クラスタのローリング再起動の実行」 参照。

    • エラーの報告:

      • キーエラー2 回でエラーメッセージ ERROR 23000 が返されます。:書き込みできません。キーをtbl_name' で.

      • 他の MySQL ストレージ エンジン同様、NDB ストレージ エンジンは最大の AUTO_INCREMENT カラムをテーブル毎に扱います。しかし、明示のプライマリ キーのないクラスタ テーブルの場合、AUTO_INCREMENT カラムは自動的に定義され 「非表示」 のプライマリ キーとして使用されます。このため、AUTO_INCREMENT カラムを持つテーブルはカラムもまた PRIMARY KEY オプションを使用して宣言されない限りテーブルを定義することはできません。

        テーブルのプライマリ キーではない AUTO_INCREMENT カラムのテーブルを作成しようとして NDB ストレージ エンジンを使用すると、エラーになり失敗します。

    • トランザクションの取扱い:

      • NDB Cluster は READ COMMITTED トランザクションの分離レベルのみサポートします。

      • トランザクションの部分的なロールバックはありません。複製キーおよび同様のエラーはトランザクション全体のロールバックにつながります。

      • 重要クラスタ　テーブルの SELECT が BLOB あるいは TEXT カラムを含む場合、READ COMMITTED トランザクションの分離は読み込みロックで読み込みに変換されます。これはこれらのタイプのカラムに保存された値の一部は実際は個別のテーブルから読まれるので一貫性を保証するために行われます。

      • 本章で気付かれたことと思いますが、MySQL Cluster は大きなトランザクションの取扱いは得意ではありません。非常にたくさんのオペレーションを含む 1 つの大きなトランザクションを扱うよりはオペレーションの数が少ない多くの小さなトランザクションの扱いに向いています。

        とりわけ、大きなトランザクションは非常に大きなメモリを必要とします。このため、多くのMySQL ステートメントのトランザクションの振る舞いが以下のリストで説明するように影響を受けます。

        • TRUNCATE は NDB テーブルで使用するとトランザクションを行いません。TRUNCATE がテーブルを空に出来ない場合、成功するまで続ける必要があります。

        • DELETE FROM (WHERE 節がない場合でも) はトランザクションできます。非常に多くの行を含むテーブルの場合、いくつかの DELETE FROM ...LIMIT ... ステートメントを使用して削除操作を 「チャンク」 することでパフォーマンスが改善する場合があります。テーブルを空にしたい場合には、代わりに TRUNCATE を使用します。

        • TRUNCATE は NDB テーブルで使用するとトランザクションを行いません。そのようなオペレーション中には、NDB エンジンは指示に従って実行されます。

          LOAD DATA FROM MASTER は MySQL Cluster ではサポートされていません。

        • テーブルを ALTER TABLE の一部としてコピーする場合、コピーの作成は非トランザクションです。(いぞれの場合も、このオペレーションはコピーが削除されるとロールバックします。)

      • ノードの起動、停止、あるいは再起動:ノードの起動、停止、あるいは再起動によってトランザクションの失敗につながるテンポラリのエラーが増える場合があります。これらには以下のケースが含まれます。

        • 最初にノードを起動する場合、エラー 1204 のテンポラリな不具合、配布の変更、 および類似のテンポラリ エラーが表示される場合があります。

        • データ ノードの停止あるいは不具合によって多くの異なるノード不具合エラーにつながる場合があります。(しかし、クラスタの予定したシャットダウンを実行中にはトランザクションの中断はありません。)

        これらのいずれのケースの場合にも、生成されたエラーはアプリケーション内で処理する必要があります。トランザクションを再試行することによって行われます。

    • 設定可能な多くのハードの制限がありまが、クラスタの設定制限のメインメモリで利用できます。項14.4.4. 「設定ファイル」 の設定パラメータの完全なリストを参照してください。多くの設定パラメータはオンラインで更新できます。これらのハードの制限には以下が含まれます。

      • データベースのメモリ サイズとインデックスのメモリ サイズ (DataMemory および IndexMemory、それぞれ)。

        DataMemory には 32KB ページが割り当てられています。各 DataMemory ページが使用されると、それは特定のテーブルに割り当てられます。一度割り当てられるとこのメモリはテーブルを削除しない限り自由にはできません。

        DataMemory および IndexMemory の詳細は、項14.4.4.5. 「Defining Data Nodes」 を参照してください。

      • トランザクション毎に実行できる最大のオペレーション数は設定パラメータ MaxNoOfConcurrentOperations および MaxNoOfLocalOperations で設定できます。バルクでローディングする場合、TRUNCATE TABLE、および ALTER TABLE が複数のトランザクションを実行することで特別なケースとして扱われ、よってこの制限は適用されません。

      • テーブルおよびインデックスに関連した異なる制限例えば、テーブル毎の最大数の順序付けされたインデックスが MaxNoOfOrderedIndexes で決められた場合。

    • データベース名、テーブル名および属性名は NDB テーブルでは他のテーブル ハンドラーより長くすることはできません。属性名は 31 文字に切り捨てられ、切り捨ての後一意でない場合にはえらーになります。データベース名およびテーブル名の合計は 122 文字です。(つまり、NDB Cluster のテーブル名の最大長は 122 文字からテーブルが属しているデータベースの数を引いたものになります。

    • クラスタのデータベースの最大テーブル数は 20320 に制限されています。

    • MySQL 5.1.10 および以前のバージョンでは、非表示のプライマリ キーを含む AUTO_INCREMENT カラム — を持つ最大のテーブル数— は 2048です。

      この制限は MySQL 5.1.11 では解除されています。

    • テーブル毎の最大属性数は 128 に制限さえれています。

    • 1 行の許可された最大サイズは 8KB です。それぞれの BLOB あるいは TEXT カラムはこの合計に対して 256 + 8 = 264 バイトです。

    • キー毎の属性の最大数は 32 です。

  • サポートされていない機能 (エラーにはならないが、サポートされていないもしくは強化できない）：

    • 外部キーの構成は、MyISAM テーブルの場合と同様無視されます。

    • セーブポイントおよびサーブポイントへのロールへバックは MyISAM で無視されます。

    • OPTIMIZE オペレーションはサポートされていません。

    • LOAD TABLE ...FROM MASTER はサポートされていません。

  • パフォーマンスおよび制限に関連した問題:

    • NDB ストレージ エンジンへのシーケンシャルなアクセスによるクエリのパフォーマンスの問題があります。多くの範囲のスキャンをするのは MyISAM あるいは InnoDB で行うより比較的高価になります。

    • Records in range 統計は利用できますが検証が済んでいないあるいは公式にはサポートしていません。これにより場合によっては non-optimal query plan になります。必要に応じてこの目的のために USE INDEX あるいは FORCE INDEX を使用できます。

    • USING HASH で作成された一意のハッシュ インデックスは NULL がキーの一部として与えられた場合はテーブルのアクセスに使用できません。

    • SQL_LOG_BIN はデータのオペレーションには影響を及ぼしません。それはスキーマのオペレーションにサポートされています。

      MySQL Cluster は BLOB カラムを持ちしかもプライマリ キーではないテーブルの binlog は生成しません。

      以下のスキーマのみがステートメントを実行する mysqld にはない クラスタの binlog にログインされます。

      • CREATE TABLE

      • ALTER TABLE

      • DROP TABLE

      • CREATE DATABASE / CREATE SCHEMA

      • DROP DATABASE / DROP SCHEMA

      • CREATE TABLESPACE

      • ALTER TABLESPACE

      • DROP TABLESPACE

      • CREATE LOGFILE GROUP

      • ALTER LOGFILE GROUP

      • DROP LOGFILE GROUP

  • 不明な機能:

    • 唯一サポートされている分離レベルは READ COMMITTED です。(InnoDB は READ COMMITTED、READ UNCOMMITTED、REPEATABLE READ、および SERIALIZABLE をサポートしています。)これがバックアップおよびクラスタ データベースの保存に与える影響に関する情報は、項14.8.5. 「バックアップのトラブルシューティング」 を参照してください。

    • ディスクで複製できないコミットコミットは複製できますがログのコミットのフラッシュは保証していません。

  • 複数の MySQL サーバー (MyISAM あるいは InnoDB には無関係):

    • ALTER TABLE は複数の MySQL サーバー (配布テーブル ロックがない場合) を稼働中は完全にロックできません。

    • DDL オペレーションはノード不具合が起こる場合があります。これらの 1 つ (CREATE TABLE あるいは ALTER TABLE など) を実行しようとすると、データディクショナリがロックされクラスタを再起動しない限り DDL ステートメントはそれ以上実行されません。

  • MySQL Cluster 専用に発行 (MyISAM あるいは InnoDB には関連せず):

    • クラスタで使用されるすべてのマシンは同じアーキテクチャである必要があります。つまり、ノードをホストするすべてのマシンは big-endian あるいは little-endian のいずれかである必要があり、その両方を一緒に使用することはできません。例えば、x86 マシンで動作しているデータ ノードに指示する PowerPC で動作しているマネジメント ノードを持つことはできません。この制限は単に mysql あるいはクラスタの SQL ノードにアクセスする他のクライアントで稼動しているマシンには適用されません。

    • ノードをオンラインで追加あるいは削除することはできません (そのような場合クラスタを再起動する必要があります)。

    • 1 台のホストで同時に複数のクラスタのプロセスを実行できますが、他の要因はともかくパフォーマンスおよび高可用性の理由によってそのように使用することは推奨できません。とくに、MySQL 5.1 は 1 つい上の ndbd プロセスが 1 台の物理マシンで実行されている MySQL Cluster の開発を使用している生産をサポートしていません。

      今後の MySQL リリースではホスト毎の複数のデータ ノードを以下のテストを行うことでサポートします。しかし、MySQL 5.1 では、そのような設定は実験レベルだけでの検討になります。

    • クラスタをディスク無しで稼動している場合ディスク データ テーブルはサポートされていません。MySQL 5.1.12 以降のバージョンではそれはどちらも許可されていません。(Bug#20008)

    • 複数のマネジメント サーバーを使用する場合：

      • ノード ID の自動割り当ては複数のマネジメント サーバー間では機能しないので接続文字列でノードに明示の ID を与える必要があります。

      • すべてのマネジメント サーバーに同じ設定をする際は特別な注意が必要です。この件に関してクラスタではと特別なチェックありません。

    • データ ノード毎の複数のネットワークはサポートされていません。これらを使用すると問題が発生します。データ ノードの不具合が発生した場合には、そのデータ ノードに別のルートが開放されていますので SQL はデータ ノードが停止ししかもそれを受信しなくなるまでその確認を待ちます。これにより効果的にクラスタの稼動を止めます。

      1 つのデータ ノードに複数のネットワーク ハードウェア インターフェース （Ethernet カードなど) を使用できますが、これらは同じアドレスを使用する必要があります。こらは config.ini ファイルで接続毎に 1 つ以上の [TCP] セクションを使用できないことを意味しています。詳細については、項14.4.4.7. 「Cluster TCP/IP Connections」 をご参照してください。

    • データ ノードの最大数は 48 です。

    • MySQL Cluster のノードの最大数は 63 です。この数にはすべての SQL ノード (MySQL サーバー)、API ノード (MySQL サーバー以外にクラスタにアクセスするアプリケーション)、データ ノード、およびマネジメント サーバーが含まれています。

    • MySQL 5.1 Cluster のメタデータ オブジェクトの最大数は 20320 です。この制限はハードで制限されています。

  • MySQL 5.1 で解決された MｙSQL Cluster 以前のバージョンの問題:

    • NDB Cluster ストレージ エンジンは今はin-memory テーブルにサポートしています。

      以前は、これは— 例えば — 比較的に小さい値をもつ 1 つ以上の VARCHAR フィールドを持ち、NDBCluster ストレージ エンジンを使用するときに同じ テーブルおよびデータを持つ MyISAM エンジンを使用した場合に比べてより多くのメモリやディスク スペースを必要としたクラスタ テーブルのことを意味します。言い換えれば、VARCHAR カラムの場合で、同じサイズの CHAR カラムと同じストレージ容量が要求されるカラムのです。MySQL 5.1 では、これはもはや in-memory テーブルには当てはまらず、そこでは VARCHAR および BINARY などの変数カラムのストレージ要件が MyISAM テーブルで使用された場合これらのカラム タイプに対してそれらと互換性があります(項10.5. 「データタイプが必要とする記憶容量」 参照)。

      重要MySQL Cluster のディスク データ テーブルでは、固定幅の制限はそのまま適用されます。項14.11. 「MySQL Cluster ディスク データ ストレージ」 参照。

    • MySQL のレプリケーションを Cluster データベースに使用できるようになりました。詳細に関しては 項14.10. 「MySQL Cluster レプリケーション」 を参照して下さい。

      しかしながら、循環型レプリケーションは現在 MySQL では現在サポートされていません 。項14.10.3. 「既知の問題」 参照。

    • 所定の mysqld が既に動作していてデータベースが異なる mysqld で作成されると同時にクラスタに接続される場合、データベースの自動検索は現在同じ MySQL Cluster にアクセスする複数の MySQL サーバーをサポートしています。

      このことは mysqld プロセスが db_name の名前のデータベースが作成された後に最初にクラスタの接続すると、それが最初に MySQL Cluster にアクセスしたときに「新しい」 MySQL サーバーで CREATE SCHEMA db_name ステートメントを発行する必要があります。これが完了すると、その 「新しい」 mysqld はそのデータベースのテーブルをエラーなしで削除できます。

      このとこはまたオンラインで NDB テーブルのスキーマの変更が可能であることを意味しています。つまり、クラスタの SQL ノードで実行された ALTER TABLE および CREATE INDEX などのオペレーションの結果がなんら他の操作をしなくてもクラスタの他の SQL ノードに見えるということです。

    • MySQL 5.1.10 以降では、クラスタのバックアップを行って異なるアーキテクチャ間で保存できます。以前は— 例えば — big-endian プラットフォームで動作しているクラスタをバックアップできず、またそのバックアップから little-endian システムで動作しているクラスタに保存できませんでした。(Bug#19255)

    • MySQL 5.1.10 以降は MySQL をクラスタのサポート付きで非デフォルトのロケーションにインストールして--basedir あるいは --character-sets-dir オプションのいずれかを使用してフロント ディスクリプション ファイルの検索パスｋを変更できます。(以前は MySQL 5.1 の ndbd はデフォルトのパスのみを検索していました — 一般的には/usr/local/mysql/share/mysql/charsets — 文字セットに対して)

    • MySQL 5.1 では、それはもはや必要なくなり、複数のマネジメント サーバーを稼動するとき、マネジメント ノードがお互いを見るにようにするにはすべてのクラスタのデータ ノードを再起動します。