MySQL :: MySQL 5.6 リファレンスマニュアル :: 18.5.13.3 MySQL Cluster データノードのオンライン追加: 詳細な例

8.0 English
5.7 English
5.6 English
5.5 English

MySQL 5.6 リファレンスマニュアル / ... / MySQL Cluster データノードのオンライン追加: 詳細な例

18.5.13.3 MySQL Cluster データノードのオンライン追加: 詳細な例

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

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

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

[ndbd]
Id = 1
HostName = 192.168.0.1

[ndbd]
Id = 2
HostName = 192.168.0.2

[mgm]
HostName = 192.168.0.10
Id = 10

[api]
Id=20
HostName = 192.168.0.20

[api]
Id=21
HostName = 192.168.0.21

注記

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

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

-- NDB Cluster -- Management Client --
ndb_mgm> SHOW
Connected to Management Server at: 192.168.0.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @192.168.0.1  (5.6.22-ndb-7.4.4, Nodegroup: 0, *)
id=2    @192.168.0.2  (5.6.22-ndb-7.4.4, Nodegroup: 0)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @192.168.0.10  (5.6.22-ndb-7.4.4)

[mysqld(API)]   2 node(s)
id=20   @192.168.0.20  (5.6.22-ndb-7.4.4)
id=21   @192.168.0.21  (5.6.22-ndb-7.4.4)

最後に、次に示すように作成された単一の 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 を使用することを示します。ただし、MySQL Cluster NDB 7.0.4 以降では、マルチスレッドの ndbmtd を使用している場合でも、以降のステップの ndbd が示されている箇所をすべて ndbmtd に置き換えることによって、この例を適用できます。(Bug #43108)

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

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

[ndbd]
Id = 1
HostName = 192.168.0.1

[ndbd]
Id = 2
HostName = 192.168.0.2

[ndbd]
Id = 3
HostName = 192.168.0.3

[ndbd]
Id = 4
HostName = 192.168.0.4

[mgm]
HostName = 192.168.0.10
Id = 10

[api]
Id=20
HostName = 192.168.0.20

[api]
Id=21
HostName = 192.168.0.21

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

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

次に示すように管理クライアントの STOP コマンドを使用して、管理サーバーを停止します。
```
ndb_mgm> 10 STOP
Node 10 has shut down.
Disconnecting to allow Management Server to shutdown

shell>
```
管理サーバーをシャットダウンすると管理クライアントが終了するため、システムシェルから管理サーバーを起動する必要があります。単純にするために、config.ini は管理サーバーバイナリと同じディレクトリにあると仮定していますが、実際には、構成ファイルの正確なパスを指定する必要があります。また、管理サーバーがその構成キャッシュからではなく、ファイルから新しい構成を読み取るように、--reload または --initial オプションも指定する必要があります。シェルの現在のディレクトリも管理サーバーバイナリが配置されているディレクトリと同じである場合は、次に示すように管理サーバーを呼び出すことができます。
```
shell> ndb_mgmd -f config.ini --reload
2008-12-08 17:29:23 [MgmSrvr] INFO     -- NDB Cluster Management Server. 5.6.22-ndb-7.4.4
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: 192.168.0.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @192.168.0.1  (5.6.22-ndb-7.4.4, Nodegroup: 0, *)
id=2    @192.168.0.2  (5.6.22-ndb-7.4.4, Nodegroup: 0)
id=3 (not connected, accepting connect from 192.168.0.3)
id=4 (not connected, accepting connect from 192.168.0.4)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @192.168.0.10  (5.6.22-ndb-7.4.4)

[mysqld(API)]   2 node(s)
id=20   @192.168.0.20  (5.6.22-ndb-7.4.4)
id=21   @192.168.0.21  (5.6.22-ndb-7.4.4)

ステップ 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 7.4.4)
Node 1: Started (version 7.1.35)

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 7.4.4)

ndb_mgm> Node 2: Started (version 7.4.4)

重要

各 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=192.168.0.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 192.168.0.10 --initial

注記

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

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

ndb_mgm> SHOW
Connected to Management Server at: 192.168.0.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @192.168.0.1  (5.6.22-ndb-7.4.4, Nodegroup: 0, *)
id=2    @192.168.0.2  (5.6.22-ndb-7.4.4, Nodegroup: 0)
id=3    @192.168.0.3  (5.6.22-ndb-7.4.4, no nodegroup)
id=4    @192.168.0.4  (5.6.22-ndb-7.4.4, no nodegroup)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @192.168.0.10  (5.6.22-ndb-7.4.4)

[mysqld(API)]   2 node(s)
id=20   @192.168.0.20  (5.6.22-ndb-7.4.4)
id=21   @192.168.0.21  (5.6.22-ndb-7.4.4)

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

ndb_mgm> CREATE NODEGROUP 3,4
Nodegroup 1 created

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

ndb_mgm> SHOW
Connected to Management Server at: 192.168.0.10:1186
Cluster Configuration
---------------------
[ndbd(NDB)]     2 node(s)
id=1    @192.168.0.1  (5.6.22-ndb-7.4.4, Nodegroup: 0, *)
id=2    @192.168.0.2  (5.6.22-ndb-7.4.4, Nodegroup: 0)
id=3    @192.168.0.3  (5.6.22-ndb-7.4.4, Nodegroup: 1)
id=4    @192.168.0.4  (5.6.22-ndb-7.4.4, Nodegroup: 1)

[ndb_mgmd(MGM)] 1 node(s)
id=10   @192.168.0.10  (5.6.22-ndb-7.4.4)

[mysqld(API)]   2 node(s)
id=20   @192.168.0.20  (5.6.22-ndb-7.4.4)
id=21   @192.168.0.21  (5.6.22-ndb-7.4.4)

ステップ 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 192.168.0.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

NDBCLUSTER テーブルごとに、mysql クライアントで ALTER ONLINE TABLE ... REORGANIZE PARTITION ステートメントを実行して、すべてのデータノード間でデータが再配布されるようにできます。ALTER ONLINE TABLE ips REORGANIZE PARTITION ステートメントを発行したあとに、ndb_desc を使用すると、次に示すように (太字の出力の関連部分によって)、このテーブルのテータが 4 つのパーティションを使用して格納されるようになったことを確認できます。

shell> ndb_desc -c 192.168.0.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 [ONLINE] TABLE table_name REORGANIZE PARTITION は、パーティション識別子のリストおよびパーティション定義のセットとともに使用して、すでに明示的にパーティション化されているテーブルに新しいパーティション化スキームを作成します。この点で、新しい MySQL Cluster ノードグループにデータを再配布するここでの使い方は例外です。このように使用する場合、TABLE キーワードのあとにテーブルの名前のみを使用し、その他のキーワードや識別子は REORGANIZE PARTITION のあとに続けません。

詳細は、セクション13.1.7「ALTER TABLE 構文」を参照してください。

さらに、無駄になっている領域が再利用されるように、テーブルごとに、ALTER ONLINE TABLE ステートメントのあとに OPTIMIZE TABLE を続けて指定するべきです。INFORMATION_SCHEMA.TABLES テーブルに対して次のクエリーを使用すると、すべての NDBCLUSTER テーブルのリストを取得できます。

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

注記

MySQL Cluster テーブルでは、テーブルを作成するために使用された CREATE TABLE ステートメント (または、別のストレージエンジンから既存のテーブルを変換するために使用された ALTER TABLE ステートメント) の ENGINE オプションで NDB が使用されたか、または NDBCLUSTER が使用されたかに関係なく、INFORMATION_SCHEMA.TABLES.ENGINE の値は常に 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 テーブルに対して同時に 1 回の DDL 操作しか実行できないため、各 ALTER ONLINE TABLE ... REORGANIZE PARTITION ステートメントが完了するまで待機してから、次のステートメントを発行する必要があります。

新しいデータノードが追加されたあとに作成された NDBCLUSTER テーブルに対しては、ALTER ONLINE TABLE ... REORGANIZE PARTITION ステートメントを発行する必要はありません。このようなテーブルに追加されたデータは、すべてのデータノード間で自動的に配布されます。ただし、新しいノードが追加される前に存在していた NDBCLUSTER テーブルでは、それらのテーブルが ALTER ONLINE 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 = 192.168.0.1

[ndbd]
Id = 2
HostName = 192.168.0.2

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

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

[mgm]
HostName = 192.168.0.10
Id = 10

[api]
Id=20
HostName = 192.168.0.20

[api]
Id=21
HostName = 192.168.0.21

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

shell> ndbd -c 192.168.0.10 --initial

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

注記

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

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

データノード 3 と 4 を起動し、新しいノードごとにデータノードのプロセスを 1 回ずつ呼び出します。
```
shell> ndbd -c 192.168.0.10 --initial
```
管理クライアントで適切な CREATE NODEGROUP コマンドを発行します。
```
ndb_mgm> CREATE NODEGROUP 3,4
```
mysql クライアントで、既存の NDBCLUSTER テーブルごとに ALTER ONLINE TABLE ... REORGANIZE PARTITION および OPTIMIZE TABLE ステートメントを発行します。(このセクションの別の場所で述べたように、これが完了するまで、既存の MySQL Cluster テーブルはデータ配布に新しいノードを使用できません。)

PREV HOME UP NEXT

User Comments

User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.