Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb
MySQL 8.0 リファレンスマニュアル  /  ...  /  NDB Cluster データノードのオンラインでの追加: 詳細な例

このページは機械翻訳したものです。

23.5.7.3 NDB Cluster データノードのオンラインでの追加: 詳細な例

このセクションでは、単一ノードグループ内に 2 つのデータノードを持つ NDB Cluster から開始し、2 つのノードグループ内に 4 つのデータノードを持つクラスタと結論付けて、新しい NDB Cluster データノードをオンラインで追加する方法を示す詳細な例を示します。

構成の開始.  説明のために、最小限の構成とし、次の情報のみを含む config.ini ファイルをクラスタで使用すると仮定します。 

[ndbd default]
DataMemory = 100M
IndexMemory = 100M
NoOfReplicas = 2
DataDir = /usr/local/mysql/var/mysql-cluster

[ndbd]
Id = 1
HostName = 198.51.100.1

[ndbd]
Id = 2
HostName = 198.51.100.2

[mgm]
HostName = 198.51.100.10
Id = 10

[api]
Id=20
HostName = 198.51.100.20

[api]
Id=21
HostName = 198.51.100.21
注記

データノード ID とその他のノード間のシーケンスにギャップを残しています。 これにより、あとで新たに追加されるデータノードに、まだ使用されていないノード ID を簡単に割り当てることができます。

また、適切なコマンド行または my.cnf オプションを使用して、クラスタをすでに起動しており、管理クライアントで SHOW を実行すると、次に示すものと同様の出力が生成されると仮定します。 

-- NDB Cluster -- Management Client --
ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (8.0.23-ndb-8.0.23, Nodegroup: 0, *)
id=2    @198.51.100.2  (8.0.23-ndb-8.0.23, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (8.0.23-ndb-8.0.23)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (8.0.23-ndb-8.0.23)
id=21   @198.51.100.21  (8.0.23-ndb-8.0.23)

最後に、次に示すように作成された単一の NDBCLUSTER テーブルがクラスタに含まれていると仮定します。 

USE n;

CREATE TABLE ips (
    id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    country_code CHAR(2) NOT NULL,
    type CHAR(4) NOT NULL,
    ip_address VARCHAR(15) NOT NULL,
    addresses BIGINT UNSIGNED DEFAULT NULL,
    date BIGINT UNSIGNED DEFAULT NULL
)   ENGINE NDBCLUSTER;

このセクションの後半で示すメモリーの使用率および関連情報は、このテーブルに約 50000 行挿入したあとに生成されました。

注記

この例では、データノードプロセスに、シングルスレッド ndbd を使用することを示します。 この例は、マルチスレッド ndbmtd を使用している場合にも適用できます。そのためには、次のステップに示されている箇所で ndbmtd を ndbd に置き換えます。

ステップ 1: 構成ファイルの更新.  テキストエディタでクラスタのグローバル構成ファイルを開き、2 つの新しいデータノードに対応する [ndbd] セクションを追加します。 (これらのデータノードに ID 3 と 4 を付与し、それらがそれぞれ 198.51.100.3 と 198.51.100.4 のアドレスにあるホストマシンで実行されると仮定します。) 新しいセクションを追加したら、config.ini ファイルの内容が次に示すように見えます。ここで、ファイルに追加した部分は太字で示しています。 

[ndbd default]
DataMemory = 100M
IndexMemory = 100M
NoOfReplicas = 2
DataDir = /usr/local/mysql/var/mysql-cluster

[ndbd]
Id = 1
HostName = 198.51.100.1

[ndbd]
Id = 2
HostName = 198.51.100.2

[ndbd]
Id = 3
HostName = 198.51.100.3

[ndbd]
Id = 4
HostName = 198.51.100.4

[mgm]
HostName = 198.51.100.10
Id = 10

[api]
Id=20
HostName = 198.51.100.20

[api]
Id=21
HostName = 198.51.100.21

必要な変更が完了したら、ファイルを保存します。

ステップ 2: 管理サーバーの再起動.  クラスタ管理サーバーを再起動するには、次のように別々のコマンドを発行して、管理サーバーを停止してから再起動する必要があります。

  1. 次に示すように管理クライアントの STOP コマンドを使用して、管理サーバーを停止します。 

    ndb_mgm> 10 STOP
Node 10 has shut down.
Disconnecting to allow Management Server to shutdown

shell>

  2. 管理サーバーをシャットダウンすると管理クライアントが終了するため、システムシェルから管理サーバーを起動する必要があります。 単純にするために、config.ini は管理サーバーバイナリと同じディレクトリにあると仮定していますが、実際には、構成ファイルの正確なパスを指定する必要があります。 また、管理サーバーがその構成キャッシュからではなく、ファイルから新しい構成を読み取るように、--reload または --initial オプションも指定する必要があります。 シェルの現在のディレクトリも管理サーバーバイナリが配置されているディレクトリと同じである場合は、次に示すように管理サーバーを呼び出すことができます。 

    shell> ndb_mgmd -f config.ini --reload
2008-12-08 17:29:23 [MgmSrvr] INFO     -- NDB Cluster Management Server. 8.0.23-ndb-8.0.23
2008-12-08 17:29:23 [MgmSrvr] INFO     -- Reading cluster configuration from 'config.ini'

ndb_mgm プロセスが再起動されたあとに、管理クライアントで SHOW の出力をチェックすると、次に示すように表示されます。 

-- NDB Cluster -- Management Client --
ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (8.0.23-ndb-8.0.23, Nodegroup: 0, *)
id=2    @198.51.100.2  (8.0.23-ndb-8.0.23, Nodegroup: 0)
id=3 (not connected, accepting connect from 198.51.100.3)
id=4 (not connected, accepting connect from 198.51.100.4)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (8.0.23-ndb-8.0.23)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (8.0.23-ndb-8.0.23)
id=21   @198.51.100.21  (8.0.23-ndb-8.0.23)

ステップ 3: 既存のデータノードのローリング再起動の実行.  次に示すように RESTART コマンドを使用すると、このステップを完全にクラスタ管理クライアント内で実現できます。 

ndb_mgm> 1 RESTART
Node 1: Node shutdown initiated
Node 1: Node shutdown completed, restarting, no start.
Node 1 is being restarted

ndb_mgm> Node 1: Start initiated (version 8.0.23)
Node 1: Started (version 8.0.23)

ndb_mgm> 2 RESTART
Node 2: Node shutdown initiated
Node 2: Node shutdown completed, restarting, no start.
Node 2 is being restarted

ndb_mgm> Node 2: Start initiated (version 8.0.23)

ndb_mgm> Node 2: Started (version 8.0.23)
重要

各 X RESTART コマンドを発行したら、管理クライアントによって「Node X: Started (version ...)」というレポートが出力されるまで待機してから、先に進みます。

mysql クライアントで ndbinfo.nodes テーブルをチェックすると、既存のデータノードがすべて更新済みの構成を使用して再起動されたことを確認できます。

ステップ 4: すべてのクラスタ API ノードのローリング再起動の実行.  mysqladmin shutdown に続いて、mysqld_safe (または別の起動スクリプト) を使用して、クラスタ内の SQL ノードとして機能している各 MySQL サーバーをシャットダウンし、再起動します。 これは、次に示すものと同様になります。ここで、password は特定の MySQL サーバーインスタンスの MySQL root パスワードです。 

shell> mysqladmin -uroot -ppassword shutdown
081208 20:19:56 mysqld_safe mysqld from pid file
/usr/local/mysql/var/tonfisk.pid ended
shell> mysqld_safe --ndbcluster --ndb-connectstring=198.51.100.10 &
081208 20:20:06 mysqld_safe Logging to '/usr/local/mysql/var/tonfisk.err'.
081208 20:20:06 mysqld_safe Starting mysqld daemon with databases
from /usr/local/mysql/var

当然、正確な入力および出力は、MySQL がシステムにインストールされている方法や場所、および起動する際に選択したオプション (およびこれらのオプションの一部またはすべてを my.cnf ファイルに指定しているかどうか) によって異なります。

ステップ 5: 新しいデータノードの初期起動の実行.  次に示すように、新しいデータノードの各ホスト上のシステムシェルから --initial オプションを使用して、データノードを起動します。 

shell> ndbd -c 198.51.100.10 --initial
注記

既存のデータノードを再起動する場合とは異なり、新しいデータノードは同時に起動できます。あるデータノードの起動が完了するまで待機してから、別のデータノードを起動する必要はありません。

新しいデータノードの両方が起動されるまで待機してから、次のステップに進みます。 新しいデータノードが起動されたら、管理クライアントの SHOW コマンドの出力で、(次に太字で示されているように) それらがどのノードグループにも属していないことを確認できます。 

ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (8.0.23-ndb-8.0.23, Nodegroup: 0, *)
id=2    @198.51.100.2  (8.0.23-ndb-8.0.23, Nodegroup: 0)
id=3    @198.51.100.3  (8.0.23-ndb-8.0.23, no nodegroup)
id=4    @198.51.100.4  (8.0.23-ndb-8.0.23, no nodegroup)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (8.0.23-ndb-8.0.23)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (8.0.23-ndb-8.0.23)
id=21   @198.51.100.21  (8.0.23-ndb-8.0.23)

ステップ 6: 新しいノードグループの作成.  これは、クラスタ管理クライアントで CREATE NODEGROUP コマンドを発行することで実行できます。 次に示すように、このコマンドは、引数として、新しいノードグループに含むデータノードのノード ID をカンマで区切ったリストを取ります。 

ndb_mgm> CREATE NODEGROUP 3,4
Nodegroup 1 created

再度 SHOW を発行すると、(同様に太字に示されているように) データノード 3 と 4 が新しいノードグループに参加したことを確認できます。 

ndb_mgm> SHOW
Connected to Management Server at: 198.51.100.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @198.51.100.1  (8.0.23-ndb-8.0.23, Nodegroup: 0, *)
id=2    @198.51.100.2  (8.0.23-ndb-8.0.23, Nodegroup: 0)
id=3    @198.51.100.3  (8.0.23-ndb-8.0.23, Nodegroup: 1)
id=4    @198.51.100.4  (8.0.23-ndb-8.0.23, Nodegroup: 1)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @198.51.100.10  (8.0.23-ndb-8.0.23)

[mysqld(API)]   2 node(s)
id=20   @198.51.100.20  (8.0.23-ndb-8.0.23)
id=21   @198.51.100.21  (8.0.23-ndb-8.0.23)

ステップ 7: クラスタデータの再配布.  ノードグループが作成されても、管理クライアントで適切な REPORT コマンドを発行することで確認できるように、既存のデータおよびインデックスは新しいノードグループのデータノードに自動的に配布されません: 

ndb_mgm> ALL REPORT MEMORY

Node 1: Data usage is 5%(177 32K pages of total 3200)
Node 1: Index usage is 0%(108 8K pages of total 12832)
Node 2: Data usage is 5%(177 32K pages of total 3200)
Node 2: Index usage is 0%(108 8K pages of total 12832)
Node 3: Data usage is 0%(0 32K pages of total 3200)
Node 3: Index usage is 0%(0 8K pages of total 12832)
Node 4: Data usage is 0%(0 32K pages of total 3200)
Node 4: Index usage is 0%(0 8K pages of total 12832)

-p オプションを付けて ndb_desc を使用すると、出力にパーティション化の情報が含まれるため、テーブルではまだ 2 つのパーティションしか使用されていないことを (ここに太字のテキストで示されている、出力の「Per partition info」セクションで) 確認できます。 

shell> ndb_desc -c 198.51.100.10 -d n ips -p
-- ips --
Version: 1
Fragment type: 9
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 6
Number of primary keys: 1
Length of frm data: 340
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 1
FragmentCount: 2
TableStatus: Retrieved
-- Attributes --
id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR
country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY
addresses Bigunsigned NULL AT=FIXED ST=MEMORY
date Bigunsigned NULL AT=FIXED ST=MEMORY

-- Indexes --
PRIMARY KEY(id) - UniqueHashIndex
PRIMARY(id) - OrderedIndex

-- Per partition info --
Partition   Row count   Commit count  Frag fixed memory   Frag varsized memory
0           26086       26086         1572864             557056
1           26329       26329         1605632             557056

NDBT_ProgramExit: 0 - OK

mysql クライアントで NDB テーブルごとに ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION ステートメントを実行することで、すべてのデータノード間でデータを再分散できます。

重要

ALTER TABLE ... ALGORITHM=INPLACE, REORGANIZE PARTITION は、MAX_ROWS オプションで作成されたテーブルでは機能しません。 かわりに、ALTER TABLE ... ALGORITHM=INPLACE, MAX_ROWS=... を使用してこのようなテーブルを再編成します。

MAX_ROWS を使用してテーブル当たりのパーティション数を設定することは非推奨であり、かわりに PARTITION_BALANCE を使用する必要があります。詳細は、セクション13.1.20.11「NDB_TABLE オプションの設定」 を参照してください。

ALTER TABLE ips ALGORITHM=INPLACE, REORGANIZE PARTITION ステートメントを発行した後、ndb_desc を使用して、このテーブルのデータが 4 つのパーティションを使用して格納されるようになったことを確認できます (出力の関連部分は太字で示されています): 

shell> ndb_desc -c 198.51.100.10 -d n ips -p
-- ips --
Version: 16777217
Fragment type: 9
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: no
Number of attributes: 6
Number of primary keys: 1
Length of frm data: 341
Row Checksum: 1
Row GCI: 1
SingleUserMode: 0
ForceVarPart: 1
FragmentCount: 4
TableStatus: Retrieved
-- Attributes --
id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY AUTO_INCR
country_code Char(2;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
type Char(4;latin1_swedish_ci) NOT NULL AT=FIXED ST=MEMORY
ip_address Varchar(15;latin1_swedish_ci) NOT NULL AT=SHORT_VAR ST=MEMORY
addresses Bigunsigned NULL AT=FIXED ST=MEMORY
date Bigunsigned NULL AT=FIXED ST=MEMORY

-- Indexes --
PRIMARY KEY(id) - UniqueHashIndex
PRIMARY(id) - OrderedIndex

-- Per partition info --
Partition   Row count   Commit count  Frag fixed memory   Frag varsized memory
0           12981       52296         1572864             557056
1           13236       52515         1605632             557056
2           13105       13105         819200              294912
3           13093       13093         819200              294912

NDBT_ProgramExit: 0 - OK
注記

通常、ALTER TABLE table_name [ALGORITHM=INPLACE,] REORGANIZE PARTITION は、パーティション識別子のリストおよびパーティション定義のセットとともに使用され、すでに明示的にパーティション化されているテーブルの新しいパーティション化スキームを作成します。 ここでは、データを新しい NDB Cluster ノードグループに再配布するために使用することは例外です。この方法で使用する場合、REORGANIZE PARTITION に続くほかのキーワードや識別子はありません。

詳細は、セクション13.1.9「ALTER TABLE ステートメント」を参照してください。

また、無駄な領域を再利用するには、テーブルごとに ALTER TABLE ステートメントの後に OPTIMIZE TABLE を続ける必要があります。 INFORMATION_SCHEMA.TABLES テーブルに対して次のクエリーを使用すると、すべての NDBCLUSTER テーブルのリストを取得できます。 

SELECT TABLE_SCHEMA, TABLE_NAME
    FROM INFORMATION_SCHEMA.TABLES
    WHERE ENGINE = 'NDBCLUSTER';
注記

「NDB Cluster」テーブルの INFORMATION_SCHEMA.TABLES.ENGINE 値は、テーブル (または、既存のテーブルを別のストレージエンジンから変換するために使用される ALTER TABLE ステートメント) の作成に使用された CREATE TABLE ステートメントの ENGINE オプションで NDB と NDBCLUSTER のどちらが使用されたかに関係なく、常に NDBCLUSTER です。

これらのステートメントを実行したあとは、次に示すように ALL REPORT MEMORY の出力で、データおよびインデックスがすべてのデータノード間で再配布されたことを確認できます。 

ndb_mgm> ALL REPORT MEMORY

Node 1: Data usage is 5%(176 32K pages of total 3200)
Node 1: Index usage is 0%(76 8K pages of total 12832)
Node 2: Data usage is 5%(176 32K pages of total 3200)
Node 2: Index usage is 0%(76 8K pages of total 12832)
Node 3: Data usage is 2%(80 32K pages of total 3200)
Node 3: Index usage is 0%(51 8K pages of total 12832)
Node 4: Data usage is 2%(80 32K pages of total 3200)
Node 4: Index usage is 0%(50 8K pages of total 12832)
注記

NDBCLUSTER テーブルに対して一度に実行できる DDL 操作は 1 つのみであるため、次の DDL 操作を発行する前に、各 ALTER TABLE ... REORGANIZE PARTITION ステートメントが終了するまで待機する必要があります。

新しいデータノードが追加されたあとに作成された NDBCLUSTER テーブルに対して ALTER TABLE ... REORGANIZE PARTITION ステートメントを発行する必要はありません。このようなテーブルに追加されたデータは、すべてのデータノードに自動的に分散されます。 ただし、次より前に存在する NDBCLUSTER テーブルでは、ALTER TABLE ... REORGANIZE PARTITION を使用してこれらのテーブルが再編成されるまで、既存のデータも新しいデータも新しいノードを使用して分散されません。

ローリング再起動を使用しない代替の手順.  はじめてクラスタを起動するときに、余分なデータノードを構成するが、それらを起動しないことによって、ローリング再起動の必要性を回避できます。 前のように、まず 1 つのノードグループ内の 2 つのデータノード (ノード 1 と 2) から開始し、あとでノード 3 と 4 で構成される 2 つめのノードグループを追加することで、クラスタを 4 つのデータノードまで拡張すると仮定します。 

[ndbd default]
DataMemory = 100M
IndexMemory = 100M
NoOfReplicas = 2
DataDir = /usr/local/mysql/var/mysql-cluster

[ndbd]
Id = 1
HostName = 198.51.100.1

[ndbd]
Id = 2
HostName = 198.51.100.2

[ndbd]
Id = 3
HostName = 198.51.100.3
Nodegroup = 65536

[ndbd]
Id = 4
HostName = 198.51.100.4
Nodegroup = 65536

[mgm]
HostName = 198.51.100.10
Id = 10

[api]
Id=20
HostName = 198.51.100.20

[api]
Id=21
HostName = 198.51.100.21

あとでオンラインになるデータノード (ノード 3 と 4) を NodeGroup = 65536 で構成できます。この場合、ノード 1 と 2 はそれぞれ次のように起動できます。 

shell> ndbd -c 198.51.100.10 --initial

NodeGroup = 65536 で構成されたデータノードは、StartNoNodeGroupTimeout データノード構成パラメータの設定によって指定された期間待機してから、--nowait-nodes=3,4 を使用してノード 1 と 2 を起動したかのように、管理サーバーによって扱われます。 デフォルトでは、これは 15 秒 (15000 ミリ秒) です。

注記

StartNoNodegroupTimeout はクラスタ内のすべてのデータノードで同じである必要があります。そのため、これは個々のデータノードではなく、常に config.ini ファイルの [ndbd default] セクションに設定するようにしてください。

2 つめのノードグループを追加する準備ができたら、次の追加ステップを実行する必要があるだけです。

  1. データノード 3 と 4 を起動し、新しいノードごとにデータノードのプロセスを 1 回ずつ呼び出します。 

    shell> ndbd -c 198.51.100.10 --initial

  2. 管理クライアントで適切な CREATE NODEGROUP コマンドを発行します。 

    ndb_mgm> CREATE NODEGROUP 3,4

  3. mysql クライアントで、既存の NDBCLUSTER テーブルごとに ALTER TABLE ... REORGANIZE PARTITION および OPTIMIZE TABLE ステートメントを発行します。 (このセクションの他の場所で説明されているように、既存の「NDB Cluster」テーブルでは、これが完了するまでデータ分散に新しいノードを使用できません。)


PREV   HOME   UP   NEXT
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb