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