NDB Cluster ディスクデータストレージは、次のオブジェクトを使用して実装されます:

undo ログファイルとデータファイルは、各データノードのファイルシステム内の実際のファイルです。デフォルトでは、NDB Cluster config.ini ファイルで指定された DataDir 内の ndb_node_id_fs に配置され、node_id はデータノードのノード ID です。 Undo ログファイルまたはデータファイルの作成時に、ファイル名の一部として絶対パスまたは相対パスを指定すると、これらを別の場所に配置できます。 これらのファイルを作成するステートメントは、このセクションの後半で示します。

undo ログファイルは「ディスクデータ」テーブルでのみ使用され、メモリーにのみ格納されている NDB テーブルでは不要または使用されません。

「NDB Cluster」テーブルスペースおよびログファイルグループは、ファイルとして実装されません。

すべてのディスクデータオブジェクトがファイルとして実装されるとはかぎりませんが、すべてが同じ名前空間を共有します。 つまり、各ディスクデータオブジェクトは (単に、特定の型の各ディスクデータオブジェクトというだけでなく)、一意の名前が付けられている必要があります。 たとえば、テーブルスペースとログファイルグループの両方に dd1 という名前を付けることはできません。

すべてのノード (管理ノードおよび SQL ノードを含む) で「NDB Cluster」をすでに設定している場合、ディスクに「NDB Cluster」テーブルを作成する基本的なステップは次のとおりです:

これらの各タスクは、次の例に示すように、mysql クライアントまたはその他の MySQL クライアントアプリケーションで SQL ステートメントを使用することで実現できます。

次に示すように、INFORMATION_SCHEMA データベースの FILES テーブルをクエリーすることで、作成した NDB ディスクデータファイルおよび undo ログファイルに関する情報を取得できます:

mysql> SELECT
              FILE_NAME AS File, FILE_TYPE AS Type,
              TABLESPACE_NAME AS Tablespace, TABLE_NAME AS Name,
              LOGFILE_GROUP_NAME AS 'File group',
              FREE_EXTENTS AS Free, TOTAL_EXTENTS AS Total
          FROM INFORMATION_SCHEMA.FILES
          WHERE ENGINE='ndbcluster';
+--------------+----------+------------+------+------------+------+---------+
| File         | Type     | Tablespace | Name | File group | Free | Total   |
+--------------+----------+------------+------+------------+------+---------+
| ./undo_1.log | UNDO LOG | lg_1       | NULL | lg_1       |    0 | 4194304 |
| ./undo_2.log | UNDO LOG | lg_1       | NULL | lg_1       |    0 | 3145728 |
| ./data_1.dat | DATAFILE | ts_1       | NULL | lg_1       |   32 |      32 |
| ./data_2.dat | DATAFILE | ts_1       | NULL | lg_1       |   48 |      48 |
+--------------+----------+------------+------+------------+------+---------+
4 rows in set (0.00 sec)

詳細および例については、セクション26.15「INFORMATION_SCHEMA FILES テーブル」を参照してください。

ディスクに暗黙的に格納されたカラムのインデックス付け.  前述の例で定義されているテーブル dt_1 の場合、dob および joined カラムのみがディスクに格納されます。 この理由は、id、last_name、および first_name カラムにインデックスがあるため、これらのカラムに属するデータが RAM 内に格納されるためです。 インデックス付けされていないカラムのみをディスクに保持できます。インデックスおよびインデックス付けされたカラムデータは引き続きメモリーに格納されます。 インデックスの使用と RAM の保存のこのようなトレードオフは、ディスクデータテーブルを設計する際に留意する必要があります。

最初に記憶域タイプを MEMORY に変更しないと、明示的に宣言された STORAGE DISK のカラムにインデックスを追加できません。追加しようとすると、エラーで失敗します。 暗黙的がディスク記憶域を使用するカラムにはインデックスを付けることができます。その場合、カラム記憶域タイプは自動的に MEMORY に変更されます。 「「暗黙的」」では、記憶域タイプが宣言されていないが、親テーブルから継承されるカラムを意味します。 次の CREATE TABLE ステートメント (以前に定義したテーブルスペース ts_1 を使用) では、カラム c2 および c3 は暗黙的にディスク記憶域を使用します:

mysql> CREATE TABLE ti (
    ->     c1 INT PRIMARY KEY,
    ->     c2 INT,
    ->     c3 INT,
    ->     c4 INT
    -> )
    ->     STORAGE DISK
    ->     TABLESPACE ts_1
    ->     ENGINE NDBCLUSTER;
Query OK, 0 rows affected (1.31 sec)

c2、c3 および c4 自体は STORAGE DISK で宣言されていないため、インデックス付けできます。 ここでは、CREATE INDEX および ALTER TABLE をそれぞれ使用して、c2 および c3 にインデックスを追加します:

mysql> CREATE INDEX i1 ON ti(c2);
Query OK, 0 rows affected (2.72 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> ALTER TABLE ti ADD INDEX i2(c3);
Query OK, 0 rows affected (0.92 sec)
Records: 0  Duplicates: 0  Warnings: 0

SHOW CREATE TABLE により、インデックスが追加されたことが確認されます。

mysql> SHOW CREATE TABLE ti\G
*************************** 1. row ***************************
       Table: ti
Create Table: CREATE TABLE `ti` (
  `c1` int(11) NOT NULL,
  `c2` int(11) DEFAULT NULL,
  `c3` int(11) DEFAULT NULL,
  `c4` int(11) DEFAULT NULL,
  PRIMARY KEY (`c1`),
  KEY `i1` (`c2`),
  KEY `i2` (`c3`)
) /*!50100 TABLESPACE `ts_1` STORAGE DISK */ ENGINE=ndbcluster DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

インデックス付けされたカラム (強調されたテキスト) がディスク上の記憶域ではなくインメモリーを使用するようになったことを、ndb_desc を使用して確認できます:

shell> ./ndb_desc -d test t1
-- t1 --
Version: 33554433
Fragment type: HashMapPartition
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 4
Number of primary keys: 1
Length of frm data: 317
Max Rows: 0
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 1
PartitionCount: 4
FragmentCount: 4
PartitionBalance: FOR_RP_BY_LDM
ExtraRowGciBits: 0
ExtraRowAuthorBits: 0
TableStatus: Retrieved
Table options:
HashMap: DEFAULT-HASHMAP-3840-4
-- Attributes --
c1 Int PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY
c2 Int NULL AT=FIXED ST=MEMORY
c3 Int NULL AT=FIXED ST=MEMORY
c4 Int NULL AT=FIXED ST=DISK
-- Indexes --
PRIMARY KEY(c1) - UniqueHashIndex
i2(c3) - OrderedIndex
PRIMARY(c1) - OrderedIndex
i1(c2) - OrderedIndex

NDBT_ProgramExit: 0 - OK

パフォーマンスに関する注意.  データノードファイルシステムから分離された物理ディスク上にディスクデータファイルが保持されている場合、ディスクデータストレージを使用しているクラスタのパフォーマンスが大幅に改善されます。 顕著な利点を引き出すには、クラスタ内のデータノードごとに、これを実行する必要があります。

ADD UNDOFILE および ADD DATAFILE では、絶対および相対ファイルシステムパスを使用できます。相対パスは、データノードデータディレクトリに関して計算されます。

これらを使用しているログファイルグループ、テーブルスペース、およびディスクデータテーブルは、特定の順序で作成する必要があります。 これは、これらのオブジェクト (次の制約の対象) を削除する場合にも当てはまります:

たとえば、このセクションでこれまでに作成したすべてのオブジェクトを削除するには、次のステートメントを使用できます:

mysql> DROP TABLE dt_1;

mysql> ALTER TABLESPACE ts_1
    -> DROP DATAFILE 'data_2.dat'
    -> ENGINE NDBCLUSTER;

mysql> ALTER TABLESPACE ts_1
    -> DROP DATAFILE 'data_1.dat'
    -> ENGINE NDBCLUSTER;

mysql> DROP TABLESPACE ts_1
    -> ENGINE NDBCLUSTER;

mysql> DROP LOGFILE GROUP lg_1
    -> ENGINE NDBCLUSTER;

これらのステートメントは、ここで示した順序で実行する必要があります。ただし、2 つの ALTER TABLESPACE ... DROP DATAFILE ステートメントは、どちらの順序でも実行できます。