GridDB クイックスタートガイド
Revision: revision-number
Table of Contents
1 はじめに
1.1 本文書の目的と構成
1.2 GridDBとは
1.2.1 概要
GridDBは、キーと複数の値からなるデータ(ロウと呼ばれる)の集合を管理する、分散NoSQL型データベースです。
- GridDBは、データ管理をインメモリで行い、高速処理が可能です。
- ロウの集合をインメモリ格納しており、高速な更新および検索処理ができます。
- GridDBは、インメモリ処理ながら大容量化が可能です。
- 複数マシンにデータを分散配置することで大容量化を行えます。さらに、本文書では紹介していませんが、ディスクを併用したデータ管理も可能です。そのため、単体のノードで動作させた場合も、メモリサイズに制限されない大容量化を実現できています。
- GridDBは、高い可用性を実現できます。
- クラスタ内でデータの複製を作成しており、いずれかのノードに障害が発生した場合には複製を使用することで処理を継続できます。また、各ノードはディスクを使用してデータ更新情報の永続化を行っており、障害時にはそれまでのデータを復元することもできます。
- GridDBは、1,000台規模までスケールアウトが可能です。
- コンテナ単位のトランザクションにおいて、クラスタ処理の並列性を高めることで、高いスケーラビリティを実現できています。
- GridDBは、人手によるクラスタ管理を必要としません。
- ノード相互に分散プロトコルを用いて通信を行い、GridDB自身が自律的にクラスタを制御します。
- GridDBは、社会インフラで利用される時系列データをサポートしています。
1.2.2 特徴
GridDB(community edition)の特徴は以下のようにまとめられます。
要件 | 説明 |
---|---|
【基本要件】 | |
大容量性(ペタバイト級) | 高速性と大容量性を両立するため、インメモリとSSDの長所を活かしたデータ格納 |
高速性(インメモリ) | インメモリ処理 |
高スケーラビリティ性 | 1台から1000台超までサーバ増設可能 |
高可用性 | 複数サーバでのデータ複製、HDD併用により更なる可用性向上 |
高自律性 | データ複製やデータ配置バランシングを自動化。 |
【社会インフラ要件】 | |
時系列データ | 時系列に特化したコンテナを提供 |
一貫性の保証 | 同一コンテナ内でACIDトランザクションをサポート |
1.3 用語の説明
GridDBの説明で用いられる用語の説明です。
用語 | 意味 |
---|---|
ノード | GridDBでデータ管理を行う個々のサーバプロセスを指します。 |
クラスタ | 一体となってデータ管理を行う、1つ、もしくは複数のノードの集合を指します。 |
パーティション | データを格納する論理的な領域です。GridDB内部にのみ存在し、ユーザからは直接は見えません。 |
ロウ | GridDBで管理する1件分のデータを指します。キーと複数の値からなるひとまとまりのデータです。 |
コンテナ | ロウの集合を管理する入れ物です。コレクションと時系列コンテナの2種類が存在します。 |
コレクション | 一般の型のキーを持つロウを管理するコンテナの1種です。 |
時系列コンテナ | 時刻型のキーを持つロウを管理するコンテナの1種です。時系列データを扱う専用の機能を持ちます。 |
マスタノード | クラスタ管理処理を行うノードです。 |
フォロワノード | クラスタに参加している、マスタノード以外のノードです。 |
オーナノード | 複製されたコンテナのうち、マスタコンテナを記録しているノードです。 |
バックアップノード | 複製されたコンテナのうち、レプリカコンテナを記録しているノードです。 |
2 システム設計・構築
この章では、基本的なシステム設計・構築の流れを示します。
GridDBノードおよびクラスタの設計・構築は以下の流れで行います。
クライアントの設定は、以下の項目を参照ください。
2.1 必要なリソースを確認する
GridDBは、スケールアウト型データベースであり、 従来DBのように慎重なシステム設計作業やサイジング作業は不要です。 しかし、初期のシステム設計の目安として以下のような点を考慮してください。
- メモリ使用量
- クラスタ構成台数
- ディスク使用量
以下、順に見積もり方法を説明します。
ただし、以下のメモリサイズの計算では、SSDなどの外部ストレージによる大容量化機能は考慮していません。
2.1.1 総メモリ使用量
コンテナに格納するデータ量を予測し、メモリ使用量を見積もります。
まず、アプリケーションで格納するデータ量を予測します。 以下のサイズと件数を予測します。
- ロウのデータサイズ
- 登録するロウ件数
次に、予測したデータ量を格納するために必要なメモリ使用量を見積もります。
- メモリ使用量 = ロウデータサイズ × 登録ロウ件数 ÷ 0.75 + 8 × 登録ロウ件数 × ( 付与索引数 + 2 ) ÷ 0.66 (バイト)
アプリケーションで作成、使用する全コレクションについて同様の見積もりを行います。 総和がGridDBクラスタで使用するメモリ使用量となります。
- 総メモリ使用量 = 全コレクションのメモリ使用量の総和
ただし、正確なメモリ使用量は更新頻度にも依存するため、 最低限の目安と考えてください。
2.1.2 クラスタ構成台数
GridDBで使用するノードの必要台数を見積もります。 以下では、1マシン上では1ノードを実行することを前提としています。
まず、マシン1台あたりのメモリサイズを想定します。
- マシンのメモリサイズ
また、作成するレプリカ数を想定します。 レプリカ数は、GridDBの設定値として与えられます。
- レプリカ数
レプリカ数のデフォルト値は、2です。
- ノード台数 = ( 総メモリ使用量 ÷ マシンのメモリサイズ ) × レプリカ数 (台)
ただし、負荷分散や可用性向上を考慮すれば、より余裕のある台数が好ましいため、 最低限の目安と考えてください。
2.1.3 ディスク使用量
GridDBで作成するファイルのサイズを見積もり、 ノード実行するマシンに必要なディスク容量を見積もります。 作成するファイルにはチェックポイントファイルとトランザクションログファイルの二種類があります。
ノード単体でのメモリ使用量は以下のように求められます。
- 単体メモリ使用量 = ( 総メモリ使用量 × レプリカ数 ) ÷ ノード台数 (バイト)
この数値を元に、以下のようにチェックポイントファイルを見積もります。
- ファイルサイズ = 単体メモリ使用量 × 2 (バイト)
また、トランザクションログファイルサイズは、アプリケーションの更新頻度に依存するため、 以下の情報を予測します。
- ロウ更新頻度 (回/秒)
さらに、チェックポイント間隔を想定します。 チェックポイント間隔は、GridDBの設定値として与えられます。
- チェックポイント間隔
チェックポイント間隔のデフォルト値は、1200秒(20分)です。
これらの数値を元に、以下のようにトランザクションログファイルサイズを見積もります。
- ファイルサイズ = ロウデータサイズ × ロウ更新頻度 × チェックポイント間隔 (バイト)
これらをあわせ、以下のように単体ディスク使用量を見積もります。
- 単体ディスク使用量 = トランザクションログファイルサイズ + チェックポイントファイルサイズ
2.2 インストールおよびセットアップを行う(ノード)
1台のマシンへのインストールについて説明します。 クラスタの構成については、運用の章を参照ください。
2.2.1 環境の確認
CentOS 6.7でのみ動作を確認しています。
$ lsb_release -id Distributor ID: CentOS Description: CentOS release 6.7 (Final)
【注意点】
- OSインストール時のOSパッケージグループの選択では、最低以下を選択してください。
- Basic Server
2.2.2 ノードをインストールする
GridDBのソースコードパッケージをダウンロードしてビルドしてください。
$ git clone git://github.com/griddb/griddb.git $ cd griddb $ sh bootstrap.sh $ ./configure $ make $ export GS_HOME=$PWD $ export GS_LOG=$PWD/log
以下の環境変数が定義されます。
環境変数 | 値 | 意味 |
---|---|---|
GS_HOME | ソースコードを展開したディレクトリ | GridDBホームディレクトリ |
GS_LOG | $GS_HOME/log | イベントログファイル出力ディレクトリ |
- これら環境変数は、以降で説明する運用コマンドで参照されます。
2.2.3 インストール後の確認を行う
#インストールされたGridDBノードのディレクトリ構成を確認します。 #まず、GridDBホームディレクトリと、関連ディレクトリ、ファイルが作成されていることを確認します。
正常にインストールできている場合、以下のファイルが作成されます。
$GS_HOME/bin/gsserver
補足
以後の手順に従い、GridDBを動作させると、以下のファイルが作成されます。
【データベースファイル】
$GS_HOME # GridDBホームディレクトリ data/ # データベースファイルディレクトリ gs_log_n_m.log # トランザクションログを記録するログファイル(n,mは数字) gs_cp_n_p.dat # データを定期的に記録するチェックポイントファイル(n,pは数字)
【ログファイル】
$GS_HOME # GridDBホームディレクトリ log/ # ログディレクトリ gridstore-%Y%m%d-n.log # イベントログファイル gs_XXXX.log # 運用ツールログファイル
これらファイルの作成ディレクトリはノード定義ファイル中のパラメータ設定で変更できます。
2.2.4 管理ユーザを設定する(必須)
管理ユーザは、ノードやクラスタへの認証のために用いられます。管理ユーザの情報は、 ユーザ定義ファイル に保存されています。デフォルトでは以下のファイルです。
- $GS_HOME/conf/password
インストール直後では、下記のデフォルトユーザが存在します。
ユーザ | パスワード |
---|---|
admin | 未設定 |
上記のデフォルトユーザを含む管理ユーザ情報は、運用コマンドのユーザ管理コマンドを用いて変更できます。
コマンド | 機能 |
---|---|
gs_adduser | 管理ユーザを追加する |
gs_deluser | 管理ユーザを削除する |
gs_passwd | 管理ユーザのパスワードを変更する |
デフォルトユーザを利用する場合は、以下のようにパスワードを変更してください。 パスワードは登録の際に暗号化されます。
【注意点】
- デフォルトユーザのパスワードは設定されていません。管理ユーザのパスワードが設定されていない場合、サーバは起動できないため必ずパスワードを変更してください。
$ gs_passwd admin Password:(パスワードを入力します) Retype password:(パスワードを再入力します)
デフォルト以外の新しい管理ユーザを追加する場合、ユーザ名はgs#で始まる必要があります。
gs#以降は1文字以上のASCII英数字ならびにアンダースコア「_」を使用可能です。
管理ユーザを新たに追加する例を以下に示します。
$ gs_adduser gs#newuser Password:(パスワードを入力します) Retype password:(パスワードを再入力します)
【注意点】
- ユーザ管理コマンドによる管理ユーザ情報の変更は、ノードを再起動することで有効になります。
- クライアントで認証に用いるため、全ノードで同一のユーザ情報が登録されている必要があります。 ユーザ定義ファイル をコピーするなどして、 全ノードで同一のユーザ情報が参照されるようにしてください。
2.3 環境依存パラメータを設定する
インストール後、GridDBを動作させるためには以下の設定が必要です。
- ネットワーク環境の設定
- クラスタ名の設定
GridDBの設定は、2種類の定義ファイルを編集して行います。
- クラスタ定義ファイル(gs_cluster.json)
- ノード定義ファイル(gs_node.json)
クラスタ定義ファイルは、クラスタ全体で共通とするパラメータを定義するファイルです。
ノード定義ファイルは、ノード毎に異なる設定値とするパラメータを定義するファイルです。
以下のとおり、これら定義ファイルの雛形がインストールされています。
$GS_HOME # GridDBホームディレクトリ conf/ # 定義ファイルディレクトリ gs_cluster.json # クラスタ定義ファイルの雛形 gs_node.json # ノード定義ファイルの雛形
【注意点】
- クラスタ定義ファイルは、クラスタ全体で共通となるパラメータを定義するファイルです。そのため、 クラスタに参加する全ノードで、同一の設定内容でなければなりません。 内容が異なるノードは、後に説明するクラスタ参加の段階でエラーとなり、クラスタに参加できません。
2.3.1 ネットワーク環境の設定(必須)
まず、ネットワーク環境について設定します。設定項目は以下のように大別されます。
- (1)クライアントとのインタフェースとなるアドレス情報
- (2)クラスタ管理処理のためのアドレス情報
これらの設定項目は環境に合わせて設定する必要がありますが、基本的にはデフォルト設定でも動作します。
ただし、GridDBクラスタが複数ノード構成かシングルノード構成かによらず、マシンのホスト名から 逆引きしたIPアドレスが、外部から接続できるアドレスである必要があります。
これは通常、/etc/hostsファイルにホスト名とIPアドレスの対応を記載することで設定できます。
/etc/hostsの設定
まず、既に設定済みかどうかを以下のコマンドで確認します。IPアドレスが表示されれば、既に設定が行われています。
$ hostname -i 192.168.11.10
下記のような場合には、設定が行われていません。
$ hostname -i hostname: 名前に対応するアドレスがありません
また、外部から接続できないループバックアドレスが表示される場合があります。
$ hostname -i 127.0.0.1
設定が行われていない場合またはループバックアドレスが表示される場合には、以下の例を参考に/etc/hostsの設定を 行ってください。ホスト名とIPアドレス、適切なネットワークインタフェースカード(NIC)は環境によって異なります。
- ホスト名とIPアドレスを確認します。
$ hostname GS_HOST $ ip route | grep eth0 | cut -f 12 -d " " | tr -d "\n" 192.168.11.10
- rootユーザで、確認したIPアドレスとホスト名の対応を/etc/hostsファイルに追加します。
192.168.11.10 GS_HOST
- 設定が正しく行われたことを確認します。
$ hostname -i 192.168.11.10
※表示が設定前と変わらない場合、より優先度の高い設定が/etc/hostsファイルに記載されています。適宜優先順位を変更してください。
/etc/hostsが正しく設定されていることが確認できたら、以降の設定に進んでください。
(1)クライアントとのインタフェースとなるアドレス情報
クライアントとのインタフェースとなるアドレス情報には ノード定義ファイル および クラスタ定義ファイル に設定項目があります。
ノード定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/transaction/serviceAddress | string | トランザクション処理の受付アドレス |
/transaction/servicePort | string | トランザクション処理の受付ポート |
/system/serviceAddress | string | 運用コマンドの接続アドレス |
/system/servicePort | string | 運用コマンドの接続ポート |
トランザクション処理の受付アドレスおよびポートは、 クライアントがクラスタを構成するノードに個別に接続してGridDBクラスタに対してトランザクション処理要求するために使用します。 クラスタをノード1台で構成する場合は利用しますが、複数台で構成する場合にはAPIを用いて明示的にこのアドレスを利用することはありません。
運用コマンドの接続アドレスおよびポートは、運用コマンドの処理要求先の指定としても利用します。
これら受付/接続アドレスは、複数インタフェースを使用/使い分ける必要がない限り設定不要です。
クラスタ定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/transaction/notificationAddress | string | クライアントとクラスタとのインタフェースアドレス |
/transaction/notificationPort | string | クライアントとクラスタとのインタフェースポート |
クライアントとクラスタとのインタフェースアドレスにはマルチキャストアドレスおよびポートを指定します。 GridDBクラスタがクライアントに対してクラスタ情報を通知し、クライアントでクラスタにAPIで処理要求を送信するために利用します。 詳しくは、『GridDB APIリファレンス』(GridDB_API_Reference_ja.html)のGridStoreFactoryクラス/メソッドの説明を参照ください。
(2)クラスタ管理処理のためのアドレス情報
クラスタが自律的に行うクラスタ管理処理のためのアドレス情報には ノード定義ファイル および クラスタ定義ファイル に設定項目があります。 これらのアドレスは、クラスタ間のハートビート(クラスタ間の生存確認)やクラスタ間の情報交換用にGridDBが内部的に利用するアドレスです。 複数のネットワークインタフェースカードを利用する場合や、同一ネットワーク上の他のシステムと利用するアドレスが重複しない限り設定は不要です。
ノード定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/cluster/serviceAddress | string | クラスタ管理のために使用する受信アドレス |
/cluster/servicePort | string | クラスタ管理のために使用する受信ポート |
クラスタ定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/cluster/notificationAddress | string | クラスタ管理用のためのマルチキャスト用アドレス |
/cluster/notificationPort | string | クラスタ管理用のためのマルチキャスト用ポート |
- クラスタ構成が変化した際にレプリカとの同期処理が行われますが、その処理でのタイムアウト時間を設定できます。
- /sync/timeoutInterval
【注意点】
- いずれもGridDB以外では使用されていないアドレス、ポートを設定する必要があります。
- ノード定義ファイルgs_node.jsonの/transaction/serviceAddress、/system/serviceAddress、および/cluster/serviceAddress は同一のアドレスを設定して動作させることが可能です。 マシンが複数のネットワークインタフェースを持っている場合には、 それぞれ別のアドレスを割り当てることで帯域を増やすことができます。
2.3.2 クラスタ名の設定(必須)
対象のノードが構成するクラスタの名前をあらかじめ設定しておきます。設定した名前は クラスタを構成するコマンドで指定した値と一致するかがチェックされます。そのため、 コマンドの指定誤りで、異なるノードとクラスタを構成してしまうという誤りを防げます。
クラスタ名の指定は クラスタ定義ファイル の以下設定項目に指定します。
クラスタ定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/cluster/clusterName | string | 作成するクラスタの名前 |
【注意点】
- デフォルト値("")では、ノードの起動に失敗します。
- サブネットワーク上で一意となる名前にすることを推奨します。
- クラスタ名は、1文字以上のASCII英数字ならびにアンダースコア「_」の列で構成されます。ただし、 先頭の文字には数字を指定できません。また、大文字・小文字は区別されません。また、64文字以内で指定する必要があります。
2.4 チューニングパラメータを設定する
ここでは、主なチューニングパラメータについて説明します。 必須の設定項目ではありませんが、クラスタの処理性能に影響を与えるパラメータです。
2.4.1 更新性能に関するパラメータ
GridDBは、永続化のためにトランザクションログファイル、チェックポイントファイルを作成します。 これらファイルへのデータ書き込みは更新性能に影響を与えるため、 以下のパラメータにより作成の方法を切り替えることができます。 ただし、デメリットとして、障害時にデータを失ってしまう可能性が高くなる場合があります。
これに関するパラメータには以下があります。
ノード定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/dataStore/persistencyMode | string | 永続化モード |
/dataStore/logWriteMode | int | ログ書き込みモード |
永続化モードは、データ更新時のファイルへの書き込み有無を指定するものです。 ログ書き込みモードは、トランザクションログファイルの書き込みのタイミングを指定するものです。
永続化モードには、以下のいずれかの値を設定できます。
- "NORMAL"
- "KEEP_ALL_LOGS"
"NORMAL" は、トランザクションログファイル、チェックポイントファイルに更新都度書き込みを行います。 チェックポイントにより、不要になったトランザクションログファイルは削除されます。 "KEEP_ALL_LOGS"は、書込みタイミングが"NORMAL"と同じですが、全てのトランザクションログファイルを残します。 デフォルト値は"NORMAL"です。
【注意点】
ログ書き込みモードには、以下のいずれかの値を設定できます。
- 0: SYNC
- 1以上の整数値: DELAYED_SYNC
"SYNC"では、更新トランザクションのコミット・アボートごとに、ログ書き込みを同期的に行います。 "DELAYED_SYNC"では、更新時のログ書き込みを、更新タイミングとは関係なく、指定秒数毎に遅延して行います。 デフォルト値は"1(DELAYED_SYNC 1秒)"です。
2.4.2 性能と可用性に関するパラメータ
GridDBは、クラスタを構成することで、データを複数ノードに複製して検索性能、可用性を向上させることができます。 これらデータの複製は更新性能に影響を与えるため、 以下のパラメータにより作成の方法を切り替えることができます。 ただし、デメリットとして、障害時にデータを失ってしまう可能性が高くなる場合があります。
これに関するパラメータには以下があります。
クラスタ定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/transaction/replicationMode | int | レプリケーションモード |
レプリケーションモードは、レプリカの方法を指定するものです。クラスタ内の全ノードで一致させる必要があります。
- "0": 非同期レプリケーション
- "1": 準同期レプリケーション
"非同期レプリケーション"は、更新処理のタイミングと同期せずにレプリケーションを行います。 "準同期レプリケーション"は、更新処理のタイミングで同期的にレプリケーションを行いますが、 レプリケーション完了の待ち合わせは行いません。デフォルトは"0"です。
2.4.3 その他のパラメータ
その他のパラメータについて説明します。 デフォルト値は、付録のパラメータ一覧を参照ください。
ノード定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/dataStore/dbPath | string | データベースファイルディレクトリ |
/dataStore/storeMemoryLimit | string | メモリバッファサイズ |
/dataStore/concurrency | int | 処理並列度 |
/dataStore/affinityGroupSize | int | データアフィニティのグループ数 |
/checkpoint/checkpointInterval | int | チェックポイント実行間隔(単位:秒) |
/system/eventLogPath | string | イベントログファイルの出力ディレクトリ |
/transaction/connectionLimit | int | コネクション数上限値 |
/trace/カテゴリ | string | イベントログ出力レベル |
- データベースファイルディレクトリは、インメモリに登録されたデータを永続化する際に作成される、 トランザクションログファイル、チェックポイントファイルが作成されるディレクトリです。
- メモリバッファサイズは、データ管理のために用いるメモリサイズです。 単位付きの文字列で指定します(例: "2048MB")。
- 処理並列度は、GridDBが二次記憶装置のI/O処理を並列に実行する上限数です。
- データアフィニティでは、関連するデータを集めて配置管理する際のグループ数を指定します。
- グループ数には、1から64までの数値が指定できます。グループ数を多くするとメモリ利用効率は 低下しますので注意して設定してください。
- チェックポイント実行間隔は、内部的に定期的に実行される(データの永続化に関する) チェックポイント処理を実行する間隔です。
- イベントログの出力ディレクトリは、ノード内部で発生した例外などのイベント情報に 関するメッセージ(イベントメッセージファイル)が出力されるディレクトリです。
- コネクション数上限値は、想定されるクライアント数を2倍した値以上を目安に設定してください。
- イベントログ出力レベルは、イベントログの各カテゴリに対する出力レベルです。
2.5 各ノードに定義ファイルを配布する
定義ファイルのうち、ユーザ定義ファイルとクラスタ定義ファイルは、GridDBクラスタを構成する すべてのノードで同一の設定内容にする必要があります。
そのため、2台以上のノードでクラスタを構成する場合、下記の手順ですべてのノードの設定を行います。 (1台のノードでクラスタを構成する場合、これまでの手順でノードおよびクラスタの設定は完了しています。)
- ノードをインストールしたいずれかのマシン上で、管理ユーザの設定、環境依存パラメータの設定を行う。
- 設定した クラスタ定義ファイル 、 ユーザ定義ファイル を他のノードの定義ファイルディレクトリに上書きコピーする。
- 各ノードで共通としたい設定を行った場合は、 ノード定義ファイル も合わせてコピーします。
- 各ノードで異なる設定を別途行う。(ネットワーク環境の設定など)
2.6 インストールおよびセットアップを行う(クライアント)
クライアントライブラリのインストール手順を説明します。
2.6.1 環境の確認
CentOS 6.7でのみ動作を確認しています。
$ lsb_release -id Distributor ID: CentOS Description: CentOS release 6.7 (Final)
【注意点】
- OSインストール時のOSパッケージグループの選択では、最低以下を選択してください。
- Software Development WorkStation
Java言語の開発環境としては、Oracle Java 7でのみ動作を確認しています。
$ java -version java version "1.7.0_79" Java(TM) SE Runtime Environment (build 1.7.0_79-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.79-b02, mixed mode)
2.6.2 クライアントライブラリをインストールする
以下のコマンドを用いてインストールします。
$ ant -f java_client/build.xml
2.6.3 インストール後の確認を行う
正常にインストールできている場合、以下のファイルが作成されます。
$GS_HOME/bin/gridstore.jar # javaクライアントライブラリ
2.6.4 ライブラリを設定する
Java版クライアントを使用する場合、クライアントライブラリをCLASSPATHに追加します。
$ export CLASSPATH=${CLASSPATH}:$GS_HOME/bin/gridstore.jar
2.6.5 クライアント側の設定を行う
クライアントの設定を行うための定義ファイルはありません。 クライアントプログラム中で接続先やユーザ/パスワードの指定を行います。
指定の詳細については、NoSQLの場合『GridDB APIリファレンス』(GridDB_API_Reference_ja.html)を参照ください
3 運用
この章では、GridDBの運用手順について説明します。
以下のケース毎に順に説明します。
- 起動から停止までの操作
運用では以下のコマンドを使用します。
【コマンド一覧】
コマンド | 機能 |
---|---|
gs_startnode | ノードを起動する |
gs_joincluster | クラスタを作成する/ノードを参加させる |
gs_stopcluster | クラスタを停止する(処理停止する) |
gs_stopnode | ノードを停止する(シャットダウン) |
gs_leavecluster | クラスタからノードを離脱させる |
gs_stat | ノードの内部情報を取得する |
【運用コマンドを利用する上での注意点】
- プロキシ変数(http_proxy)が設定されている場合、ノードのアドレス(群)を、no_proxyで設定し、proxyから除外してください。 運用コマンドはREST/http通信を行うため、誤ってproxyサーバ側に接続されてしまい、運用コマンドが動作しません。
- 「接続サーバ:ポート」のオプション指定があるコマンドの場合、ポート設定をデフォルトから変更していなければ、 このオプションを指定する必要はありません。 また、「接続サーバ:ポート」のオプションを指定すれば、 ノードを起動したマシンとは別のマシン上からこのコマンドを実行できます。
以下、使用方法について、順次説明します。
3.1 起動から停止までの操作
3.1.1 基本の流れ
GridDBノードのインストールおよびセットアップを行った後、 GridDBクラスタの起動から停止までの、通常運用の流れは以下のようになります。
- 各ノードを起動する。
- クラスタを構成する。
- GridDBのサービスを利用する。
- クラスタを停止する。
- 各ノードを停止する。
【利用する上での注意点】
- 以下の手順では、運用管理者が、ノードを実行する全マシンのホスト名(もしくはアドレス)の一覧を把握していることを想定しています。
- 同様に、クラスタに参加させている、全ノードの台数も把握していることを想定しています。
- ユーザ認証オプション(-u)には、ユーザ「admin」、パスワード「admin」を例として使用しています。
3.1.2 各ノードを起動する
ノードを実行するマシン上でノード起動コマンドを実行します。 このコマンドはノード毎に実行する必要があります。
ノードの起動には以下のコマンドを用います。
- gs_startnode
GridDBホームディレクトリ下のconfディレクトリ下にあるノード定義ファイル、クラスタ定義ファイル、ユーザ定義ファイルの設定を用いてノードを起動します。 以下に、コマンド実行例を示します。
【コマンド実行例】
$ gs_startnode
クラスタを構成する全てのマシンで、ノード起動を行う必要があります。
【注意点】
- クラスタを構成する場合、参加する各ノードの クラスタ定義ファイル は同一である必要があります。起動前に、各ノードのクラスタ定義ファイルを同一にしておいてください。
- 同様に、各ノードの ユーザ定義ファイル も同一である必要があります。
3.1.3 クラスタを構成する
起動したノードをクラスタに参加させ、クラスタを構成します。 シングルノードで使用する(複数ノードでクラスタを組まない)場合でも、この操作は必要です。
ノードをクラスタに参加させるためには、以下のクラスタ参加コマンドを実行します。
- gs_joincluster [-s 接続サーバ:ポート] -n|–nodeNum 構成ノード数 -c|–clusterName クラスタ名 -u ユーザ名/パスワード
オプションとして「クラスタ名」、「構成ノード数」を与えて実行します。
オプションとして指定するクラスタの「構成ノード数」には、GridDBクラスタを構成するノード数を指定します。 GridDBが初回に起動する際に、各種サービスを開始する閾値として用いられます。
以下に、ノードが起動しているマシン上で実行する場合のコマンド実行例を示します。 クラスタ名を「設定したクラスタ名」、構成ノード数を「1」として クラスタを作成しています。
【コマンド実行例】
$ gs_joincluster -c 設定したクラスタ名 -n 1 -u admin/admin
ノードが起動しているマシンとは別のマシン上で実行する場合のコマンド実行例を示します。 ノードが起動しているマシンのアドレス「192.168.10.11」に対して、 クラスタ名「example_three_nodes_cluster」、構成ノード数「3」のクラスタに参加しています。
【コマンド実行例】
$ gs_joincluster -s 192.168.10.11:10040 -c example_three_nodes_cluster -n 3 -u admin/admin
クラスタを構成する3台のマシンに対してそれぞれ正しくクラスタ名を指定して実行することで、クラスタが構成されます。 クラスタの参加ノード数が構成ノード数と等しくなると、クラスタはサービスを開始します。 サービスが開始されると、アプリケーションからアクセスできるようになります。
ただし、このコマンドはリクエスト受付後すぐに制御が戻ります。 クラスタが構成されるまではアプリケーションからの接続に失敗することがありますので、 クラスタを構成する最後の1台で-wオプションを指定し、クラスタ構成完了を待合わせてください。
以下に、他の2台のマシンに対して、同様にコマンドを実行して、3台のノードでクラスタを構成する例を示します。
【コマンド実行例】
$ gs_joincluster -s 192.168.10.12:10040 -c example_three_nodes_cluster -n 3 -u admin/admin $ gs_joincluster -s 192.168.10.13:10040 -c example_three_nodes_cluster -n 3 -u admin/admin -w ... クラスタを構成しました。
【注意点】
- 構成ノード数は、シングルノード構成では1を指定してください。
- クラスタ参加コマンドがエラーとなる場合、そのノードのクラスタ定義ファイルに差異があります。 再度、クラスタ定義ファイルを確認し、同一の定義としてください。
- クラスタの参加ノード数が構成ノード数に満たない場合、クラスタは一切のサービスを開始しません。 サービスが開始されない場合は、ノード数が正しいか確認してください。
構成ノード数を誤って指定してしまった場合は、ノードをクラスタから 離脱させてください。以下のクラスタ離脱コマンドを実行します。
- gs_leavecluster [-s 接続サーバ:ポート] -u ユーザ名/パスワード
以下に、クラスタから離脱させるノードが起動しているマシン上でコマンドを実行する例を示します。
【コマンド実行例】
$ gs_leavecluster -u admin/admin
【注意点】
- このコマンドをクラスタの停止目的に使用すると、クラスタの再稼動後のデータを参照できなくなる可能性があります。
- クラスタが既に稼動している場合は、クラスタ停止コマンド(gs_stopcluster)を使用してください。
3.1.4 サービスを利用する
クラスタを構成したあとは、登録したユーザを用いて、 クライアントプログラムからGridDBに対して、データ登録や検索ができます。
クライアントプログラムの作成についての詳細は、
『GridDB APIリファレンス』(GridDB_API_Reference_ja.html)を参照ください。
3.1.5 クラスタを停止する
GridDBクラスタを停止させます。 各ノードを停止するためには、GridDBクラスタ管理処理を停止させた後、 順次ノード停止させる手順を踏む必要があります。
まず、クラスタ管理処理を停止させます。そのためにはクラスタ全停止コマンドを実行します。 クラスタに参加しているノードのいずれかに以下のコマンドを実行します。
- gs_stopcluster [-s 接続サーバ:ポート] -u ユーザ名/パスワード
以下に、停止させるクラスタのノードが起動しているマシン上でコマンド実行する例を示します。
【コマンド実行例】
$ gs_stopcluster -u admin/admin
この時点で、クラスタに参加していた全てのノードがデータ登録および検索サービスを停止します。
この後、ノードを停止(シャットダウン)させます。このためにはノード停止コマンドを実行します。
- gs_stopnode [-w [WAIT_TIME]][-s 接続サーバ:ポート] [-f|–force] -u ユーザ名/パスワード
以下に、ノードが起動しているマシン上でのノード停止コマンド実行例を示します。
【コマンド実行例】
$ gs_stopnode -w -u admin/admin
ノード停止させると、チェックポイント(メモリデータのファイル書き出し)処理のため、 ノードのプロセスが終了するまでに時間を要することがあります。-wオプションを指定することで、終了を待ち合わせることをお勧めします。
3.1.6 一度停止したクラスタを再稼動する
GridDBクラスタをシャットダウンした後、通常の起動と同じ以下の手順で再稼動させることができます。
- 事前にシャットダウン時点の参加ノード数を確認しておきます。
- ノードを起動する。
- シャットダウン時点の構成台数を指定してクラスタに参加させる。
以下は、シングルノード構成のクラスタを再稼動させる具体例です。
【コマンド実行例】
$ gs_startnode ... $ gs_joincluster -c 設定したクラスタ名 -n 1 -u admin/admin ...
- クラスタ名は、クラスタ定義ファイルに設定したクラスタ名を指定してください。
- 構成ノード数は、シングルノード構成では1を指定してください。複数台構成の場合はシャットダウン時点でのノード台数を指定してください。
- シャットダウン時点でのクラスタ参加ノードは、イベントログファイルに情報が出力されています。
再稼動させると、GridDBクラスタはデータベースファイル(トランザクションログファイル、チェックポイントファイル)を読み込み、 シャットダウン時点の状態を復元します。 「構成ノード数」台のノードがクラスタに参加すると、サービスを開始します。
【注意点】
- 「構成ノード数」には、シャットダウン時点でのノード台数を正しく指定する必要があります。クラスタの参加ノード数が構成ノード数に満たない場合、クラスタは一切のサービスを開始しません。サービスが開始されない場合は、ノード数が正しいか確認してください。
- 「構成ノード数」を誤って指定した際、クラスタが稼動していない状態のときは、クラスタ離脱コマンドでクラスタから離脱させ、再度正しい「構成ノード数」を指定してクラスタに参加させてください。
- 「構成ノード数」を誤って指定した際、クラスタが稼動してしまったときは、誤った状態でサービスを開始してしまう可能性があります。この場合は、クラスタを停止する手順を実施した後で、再稼動手順を実施してください。
- マシン故障などにより、シャットダウン時点とノード数が変わってしまった(シャットダウン時点より少ない)場合、再起動可能なノード数を指定して、再起動手順を実施してください。運用中の障害発生時と同様にデータの再配置を行います。ただし、大幅にノード数が減少してしまう場合には、データを参照できなくなる可能性があります。
- 元々クラスタに参加していたマシンのIPアドレス、ポート(ノード定義ファイルの/xxx/serviceAddress、/xxx/servicePort)の変更は可能です。
3.2 各種情報を取得する
3.2.1 クラスタ情報を取得する
クラスタ情報(クラスタ構成情報および内部情報)を取得します。 そのためには、以下のクラスタ構成情報取得コマンドを実行します。
- gs_stat [-s 接続サーバ:ポート] -u ユーザ名/パスワード
以下に、ノードが起動しているマシン上で実行する場合のコマンド実行例を示します。
【コマンド実行例】
$ gs_stat -u admin/admin { : : "cluster": { "activeCount": 3, "clusterName": "defaultCluster", "clusterStatus": "MASTER", : : }
クラスタ状態(clusterStatus)の意味は以下のとおりとなります。
- MASTER : マスタ
- SUB_MASTER : マスタ障害時にマスタとなる候補
- FOLLOWER : フォロワ
- SUB_FOLLOWER : マスタ障害時にフォロワとなる候補
- SUB_CLUSTER : クラスタが稼動していない
システム状態(nodeStatus)の意味は以下のとおりとなります。
- INACTIVE : 停止
- ACTIVATING : 稼働開始
- ACTIVE : 稼働
- DEACTIVATING : 停止開始
- ABNORMAL : 異常停止
- NORMAL_SHUTDOWN : 通常終了開始
その他の項目の説明はパラメータ一覧を参照ください。
4 注意点
以下はコミュニティ版のみの注意点です。
- 圧縮機能はサポートしていません。
- 非常に単純なユーザ認証のみをサポートしています。
- 登録済の全ユーザがアクセス可能な「public」という名前の1個のデータベースのみをサポートしています。
- デフォルトのビルド環境はトリガ機能を無効にしています。トリガ機能を有効にするにはビルドする際に以下オプションを追加してください。
$ ./configure --enable-activemq
5 付録
5.1 パラメータ一覧
GridDBの定義ファイルであるノード定義ファイルとクラスタ定義ファイルのパラメータ一覧を以下に示します。
5.1.1 ノード定義ファイル(gs_node.json)
パラメータ | データ型 | 意味 | デフォルト |
---|---|---|---|
/dataStore/dbPath | string | データベースファイルディレクトリ | "data" |
/dataStore/storeMemoryLimit | string | メモリバッファサイズ | "1024MB" |
/dataStore/concurrency | int | 処理並列度 | 1 |
/dataStore/logWriteMode | int | ログ書き込みモード | 1 |
/dataStore/persistencyMode | string | 永続化モード | "NORMAL" |
/dataStore/affinityGroupSize | int | アフィニティグループ数 | 4 |
/checkpoint/checkpointInterval | string | チェックポイント実行間隔 | "1200s" |
/checkpoint/checkpointMemoryLimit | string | チェックポイント用メモリバッファサイズ | "1024MB" |
/checkpoint/useParallelMode | boolean | チェックポイントの並列動作(false:無効、true:有効) | false |
/cluster/serviceAddress | string | クラスタ管理のために使用する受信アドレス | "127.0.0.1" |
/cluster/servicePort | int | クラスタ管理のために使用する受信ポート | 10010 |
/sync/serviceAddress | string | データ同期に使用する受信アドレス | "127.0.0.1" |
/sync/servicePort | int | データ同期に使用する受信ポート | 10020 |
/system/serviceAddress | string | 運用コマンドの接続アドレス | "127.0.0.1" |
/system/servicePort | int | 運用コマンドの接続ポート | 10040 |
/system/eventLogPath | string | イベントログファイルの出力ディレクトリ | "log" |
/transaction/serviceAddress | string | トランザクション処理の受付アドレス | "127.0.0.1" |
/transaction/servicePort | int | トランザクション処理の受付ポート | 10001 |
/transaction/connectionLimit | int | コネクション数上限値 | 5000 |
/trace/default | string | イベントログ出力レベル | "LEVEL_ERROR" |
/trace/dataStore | string | "LEVEL_ERROR" | |
/trace/collection | string | "LEVEL_ERROR" | |
/trace/timeSeries | string | "LEVEL_ERROR" | |
/trace/chunkManager | string | "LEVEL_ERROR" | |
/trace/objectManager | string | "LEVEL_INFO" | |
/trace/checkpointFile | string | "LEVEL_ERROR" | |
/trace/checkpointService | string | "LEVEL_INFO" | |
/trace/logManager | string | "LEVEL_WARNING" | |
/trace/clusterOperation | string | "LEVEL_INFO" | |
/trace/clusterService | string | "LEVEL_ERROR" | |
/trace/syncService | string | "LEVEL_ERROR" | |
/trace/systemService | string | "LEVEL_INFO" | |
/trace/transactionManager | string | "LEVEL_ERROR" | |
/trace/transactionService | string | "LEVEL_ERROR" | |
/trace/transactionTimeout | string | "LEVEL_WARNING" | |
/trace/sessionTimeout | string | "LEVEL_WARNING" | |
/trace/replicationTimeout | string | "LEVEL_WARNING" | |
/trace/recoveryManager | string | "LEVEL_INFO" | |
/trace/eventEngine | string | "LEVEL_WARNING" | |
/trace/triggerService | string | "LEVEL_ERROR" |
5.1.2 クラスタ定義ファイル(gs_cluster.json)
パラメータ | データ型 | 意味 | デフォルト |
---|---|---|---|
/dataStore/partitionNum | int | パーティション数 | 128 |
/dataStore/storeBlockSize | string | ブロックサイズ("64KB"、"1MB") | "64KB" |
/cluster/clusterName | string | クラスタ名 | "" |
/cluster/replicationNum | int | レプリカ数 | 2 |
/cluster/notificationAddress | string | クラスタ管理用のためのマルチキャスト用アドレス | "239.0.0.1" |
/cluster/notificationPort | int | クラスタ管理用のためのマルチキャスト用ポート | 20000 |
/cluster/notificationInterval | string | クラスタ管理用のためのマルチキャスト間隔 | "5s" |
/cluster/heartbeatInterval | string | ハートビート間隔 | "5s" |
/cluster/loadbalanceCheckInterval | string | ロードバランスチェック間隔 | "180s" |
/sync/timeoutInterval | string | 短期同期タイムアウト時間 | "30s" |
/transaction/notificationAddress | string | クライアントへのマルチキャスト用アドレス | "239.0.0.1" |
/transaction/notificationPort | int | クライアントへのマルチキャスト用ポート | 31999 |
/transaction/notificationInterval | string | クライアントへのマルチキャスト間隔 | "5s" |
/transaction/replicationTimeoutInterval | string | レプリケーション・タイムアウト時間 | "10s" |
/transaction/replicationMode | int | レプリケーション方法(0:非同期、1:準同期) | 0 |
5.2 ビルド・実行方法
プログラムのビルドおよび実行方法の例を示します。
【注意点】
- サンプルプログラム内のユーザ、パスワードは適宜変更する必要があります。
【NoSQL DBの場合】
Javaの場合
- 環境変数の設定
- サンプルプログラムをgsSampleディレクトリにコピー
- ビルド
- 実行
$ export CLASSPATH=${CLASSPATH}:$GS_HOME/bin/gridstore.jar $ mkdir gsSample $ cp $GS_HOME/docs/sample/program/Sample1.java gsSample/. $ javac gsSample/Sample1.java $ java gsSample/Sample1 239.0.0.1 31999 設定したクラスタ名 admin 設定したパスワード
6 商標
- GridDBは、株式会社東芝の商標です。
- OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
- LinuxはLinus Torvaldsの商標です。
- その他製品名は、それぞれの所有者の商標または登録商標です。
Copyright © 2013-2016 TOSHIBA CORPORATION