このページは機械翻訳したものです。
NDB Cluster ディスクデータストレージは、次のオブジェクトを使用して実装されます:
テーブルスペース: ほかのディスクデータオブジェクトのコンテナとして機能します。 テーブルスペースには、1 つ以上のデータファイルと 1 つ以上の undo ログファイルグループが含まれます。
データファイル: カラムデータを格納します。 データファイルは、テーブルスペースに直接割り当てられます。
undo ログファイル: トランザクションのロールバックに必要な undo 情報が含まれます。 undo ログファイルグループに割り当てられます。
log file group: 1 つ以上の undo ログファイルが含まれています。 テーブルスペースに割り当てられます。
undo ログファイルとデータファイルは、各データノードのファイルシステム内の実際のファイルです。デフォルトでは、NDB Cluster config.ini
ファイルで指定された DataDir
内の ndb_
に配置され、node_id
_fsnode_id
はデータノードのノード ID です。 Undo ログファイルまたはデータファイルの作成時に、ファイル名の一部として絶対パスまたは相対パスを指定すると、これらを別の場所に配置できます。 これらのファイルを作成するステートメントは、このセクションの後半で示します。
undo ログファイルは「ディスクデータ」テーブルでのみ使用され、メモリーにのみ格納されている NDB
テーブルでは不要または使用されません。
「NDB Cluster」テーブルスペースおよびログファイルグループは、ファイルとして実装されません。
すべてのディスクデータオブジェクトがファイルとして実装されるとはかぎりませんが、すべてが同じ名前空間を共有します。 つまり、各ディスクデータオブジェクトは (単に、特定の型の各ディスクデータオブジェクトというだけでなく)、一意の名前が付けられている必要があります。 たとえば、テーブルスペースとログファイルグループの両方に dd1
という名前を付けることはできません。
すべてのノード (管理ノードおよび SQL ノードを含む) で「NDB Cluster」をすでに設定している場合、ディスクに「NDB Cluster」テーブルを作成する基本的なステップは次のとおりです:
ログファイルグループを作成し、それに 1 つ以上の Undo ログファイルを割り当てます (Undo ログファイルは、undofile と呼ばれることもあります)。
テーブルスペースを作成し、そのテーブルスペースにログファイルグループおよび 1 つ以上のデータファイルを割り当てます。
データストレージ用に、このテーブルスペースを使用するディスクデータテーブルを作成します。
これらの各タスクは、次の例に示すように、mysql クライアントまたはその他の MySQL クライアントアプリケーションで SQL ステートメントを使用することで実現できます。
-
CREATE LOGFILE GROUP
を使用して、lg_1
という名前のログファイルグループを作成します。 このログファイルグループは、undo_1.log
およびundo_2.log
という名前の 2 つの Undo ログファイルで構成されます。初期サイズは、それぞれ 16M バイトと 12M バイトです。 (Undo ログファイルのデフォルト初期サイズは128M バイトです。) 必要に応じて、ログファイルグループの undo バッファのサイズを指定したり、デフォルト値の 8 MB を想定することもできます。 この例では、UNDO バッファサイズを 2 MB に設定します。 ログファイルグループは、Undo ログファイルとともに作成する必要があります。そのため、次のCREATE LOGFILE GROUP
ステートメントでundo_1.log
をlg_1
に追加しています。Press CTRL+C to copyCREATE LOGFILE GROUP lg_1 ADD UNDOFILE 'undo_1.log' INITIAL_SIZE 16M UNDO_BUFFER_SIZE 2M ENGINE NDBCLUSTER;
ログファイルグループに
undo_2.log
を追加するには、次のALTER LOGFILE GROUP
ステートメントを使用します。Press CTRL+C to copyALTER LOGFILE GROUP lg_1 ADD UNDOFILE 'undo_2.log' INITIAL_SIZE 12M ENGINE NDBCLUSTER;
いくつかの注意事項:
ここで使用される
.log
ファイル拡張子は必須ではありません。 ログファイルを簡単に認識できるようにするだけで済みます。-
すべての
CREATE LOGFILE GROUP
およびALTER LOGFILE GROUP
ステートメントにENGINE
オプションが含まれている必要があります。 このオプションに指定できる値は、NDBCLUSTER
およびNDB
のみです。重要常に同じ NDB Cluster 内に最大 1 つのログファイルグループが存在できます。
ADD UNDOFILE '
を使用して、ログファイルグループに Undo ログファイルを追加すると、クラスタ内の各データノードのfilename
'DataDir
内にあるndb_
ディレクトリに、node_id
_fsfilename
という名前のファイルが作成されます。ここで、node_id
はデータノードのノード ID です。 各 Undo ログファイルのサイズは、SQL ステートメントで指定されます。 たとえば、NDB Cluster に 4 つのデータノードがある場合、示されているALTER LOGFILE GROUP
ステートメントは 4 つの undo ログファイルを作成し、それぞれ 4 つのデータノードのデータディレクトリに 1 つずつ作成します。これらの各ファイルの名前はundo_2.log
で、各ファイルのサイズは 12 MB です。UNDO_BUFFER_SIZE
は、使用可能なシステムメモリーの量によって制限されます。これらのステートメントの詳細は、セクション13.1.16「CREATE LOGFILE GROUP ステートメント」 および セクション13.1.6「ALTER LOGFILE GROUP ステートメント」 を参照してください。
-
では、「ディスクデータ」テーブルがデータを格納するために使用するファイルの抽象コンテナであるテーブルスペースを作成できるようになりました。 テーブルスペースは特定のログファイルグループに関連付けられます。新しいテーブルスペースを作成する場合は、undo ロギングに使用するログファイルグループを指定する必要があります。 少なくとも 1 つのデータファイルを指定する必要もあります。テーブルスペースの作成後に、テーブルスペースにデータファイルを追加できます。 テーブルスペースからデータファイルを削除することもできます (このセクションの後半の例を参照)。
ログファイルグループとして
lg_1
を使用するts_1
という名前のテーブルスペースを作成すると仮定します。 テーブルスペースには、初期サイズがそれぞれ 32 MB および 48 MB のdata_1.dat
およびdata_2.dat
という名前の 2 つのデータファイルが含まれるようにします。 (INITIAL_SIZE
のデフォルトの値は 128M バイトです。) これは、次に示すように、2 つの SQL ステートメントを使用することで実行できます。Press CTRL+C to copyCREATE TABLESPACE ts_1 ADD DATAFILE 'data_1.dat' USE LOGFILE GROUP lg_1 INITIAL_SIZE 32M ENGINE NDBCLUSTER; ALTER TABLESPACE ts_1 ADD DATAFILE 'data_2.dat' INITIAL_SIZE 48M;
CREATE TABLESPACE
ステートメントは、データファイルdata_1.dat
を含むテーブルスペースts_1
を作成し、ts_1
をログファイルグループlg_1
に関連付けます。ALTER TABLESPACE
は、2 つめのデータファイル (data_2.dat
) を追加します。いくつかの注意事項:
undo ログファイルにこの例で使用されている
.log
ファイル拡張子と同様に、.dat
ファイル拡張子には特別な意味はなく、認識しやすいようにのみ使用されます。ADD DATAFILE '
を使用して、テーブルスペースにデータファイルを追加すると、クラスタ内の各データノードのfilename
'DataDir
内にあるndb_
ディレクトリに、node_id
_fsfilename
という名前のファイルが作成されます。ここで、node_id
はデータノードのノード ID です。 各データファイルのサイズは、SQL ステートメントで指定します。 たとえば、NDB Cluster に 4 つのデータノードがある場合、示されているALTER TABLESPACE
ステートメントは、4 つのデータファイルを作成し、それぞれ 4 つの各データノードのデータディレクトリに 1 つずつ作成します。これらの各ファイルの名前はdata_2.dat
で、各ファイルのサイズは 48 MB です。NDB
は、データノードの再起動時に使用するために各テーブルスペースの 4% を予約します。 この領域はデータの格納には使用できません。CREATE TABLESPACE
ステートメントにはENGINE
句を含める必要があります。テーブルスペースに作成できるのは、テーブルスペースと同じストレージエンジンを使用するテーブルのみです。ALTER TABLESPACE
では、ENGINE
句は受け入れられますが、非推奨であり、将来のリリースで削除される可能性があります。NDB
テーブルスペースの場合、このオプションに使用できる値はNDBCLUSTER
およびNDB
のみです。NDB 8.0.20 以降では、エクステントの割り当ては、特定のテーブルスペースで使用されるすべてのデータファイル間でラウンドロビン方式で実行されます。
CREATE TABLESPACE
およびALTER TABLESPACE
ステートメントについての詳細は、セクション13.1.21「CREATE TABLESPACE ステートメント」およびセクション13.1.10「ALTER TABLESPACE ステートメント」を参照してください。
-
テーブルスペース
ts_1
のファイルを使用して、インデックス付けされていないカラムがディスクに格納されているテーブルを作成できるようになりました:Press CTRL+C to copyCREATE TABLE dt_1 ( member_id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, last_name VARCHAR(50) NOT NULL, first_name VARCHAR(50) NOT NULL, dob DATE NOT NULL, joined DATE NOT NULL, INDEX(last_name, first_name) ) TABLESPACE ts_1 STORAGE DISK ENGINE NDBCLUSTER;
TABLESPACE ts_1 STORAGE DISK
は、ディスク上のデータ記憶域にテーブルスペースts_1
を使用するようにNDB
ストレージエンジンに指示します。次のようにテーブル
ts_1
が作成されたら、その他の MySQL テーブルの場合と同様に、INSERT
、SELECT
、UPDATE
、およびDELETE
ステートメントを実行できます。CREATE TABLE
ステートメントまたはALTER TABLE
ステートメントのカラム定義の一部としてSTORAGE
句を使用して、個々のカラムをディスクに格納するかメモリーに格納するかを指定することもできます。STORAGE DISK
を指定するとカラムはディスク上に格納され、STORAGE MEMORY
を指定するとインメモリーストレージが使用されます。 詳細は、セクション13.1.20「CREATE TABLE ステートメント」を参照してください。
次に示すように、INFORMATION_SCHEMA
データベースの FILES
テーブルをクエリーすることで、作成した NDB
ディスクデータファイルおよび undo ログファイルに関する情報を取得できます:
Press CTRL+C to copymysql> 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
は暗黙的にディスク記憶域を使用します:
Press CTRL+C to copymysql> 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
にインデックスを追加します:
Press CTRL+C to copymysql> 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
により、インデックスが追加されたことが確認されます。
Press CTRL+C to copymysql> 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 を使用して確認できます:
Press CTRL+C to copyshell> ./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
では、絶対および相対ファイルシステムパスを使用できます。相対パスは、データノードデータディレクトリに関して計算されます。
これらを使用しているログファイルグループ、テーブルスペース、およびディスクデータテーブルは、特定の順序で作成する必要があります。 これは、これらのオブジェクト (次の制約の対象) を削除する場合にも当てはまります:
ログファイルグループは、テーブルスペースで使用されているかぎり削除できません。
テーブルスペースは、データファイルを格納しているかぎり、削除できません。
テーブルスペースを使用しているテーブルが残っているかぎり、テーブルスペースからどのデータファイルも削除できません。
ファイルが作成されたテーブルスペース以外の別のテーブルスペースと関連して作成されたファイルは削除できません。
たとえば、このセクションでこれまでに作成したすべてのオブジェクトを削除するには、次のステートメントを使用できます:
Press CTRL+C to copymysql> 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
ステートメントは、どちらの順序でも実行できます。