無料PHPプログラム

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

テキスト インデックスはサポートしていません。つまり、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 テーブルに挿入された際に使用されたメモリは他のストレージ エンジン同様削除されても自動的元に戻りません。代わりに以下の規則が適用されます。

エラーの報告:

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

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

データベース名、テーブル名および属性名は 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 にログインされます。

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

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

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

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

クラスタで使用されるすべてのマシンは同じアーキテクチャである必要があります。つまり、ノードをホストするすべてのマシンは 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)

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

データ ノード毎の複数のネットワークはサポートされていません。これらを使用すると問題が発生します。データ ノードの不具合が発生した場合には、そのデータ ノードに別のルートが開放されていますので 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 です。この制限はハードで制限されています。

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