GridDB® クイックスタートガイド
Revision: 1426
Table of Contents
1 はじめに
1.1 本文書の目的と構成
1.2 GridDBとは
1.2.1 概要
GridDBは、キーと複数の値からなるデータ(ロウと呼ばれる)の集合を管理する、分散NoSQL型データベースです。GridDBには、GridDB Advanced EditionとGridDB Standard Editionの2つの製品があります。両製品の相違点は、GridDB Advanced Editionが問い合わせ言語としてSQLをサポートするという点のみで、アプリケーション開発で利用するライブラリの違いはありますが、システムの構築や運用方法は同一です。
-
GridDBは、データ管理をインメモリで行い、高速処理が可能です。
- ロウの集合をインメモリ格納しており、高速な更新および検索処理ができます。
-
GridDBは、インメモリ処理ながら大容量化が可能です。
- 複数マシンにデータを分散配置することで大容量化を行えます。さらに、本文書では紹介していませんが、ディスクを併用したデータ管理も可能です。そのため、単体のノードで動作させた場合も、メモリサイズに制限されない大容量化を実現できています。
-
GridDBは、高い可用性を実現できます。
- クラスタ内でデータの複製を作成しており、いずれかのノードに障害が発生した場合には複製を使用することで処理を継続できます。また、各ノードはディスクを使用してデータ更新情報の永続化を行っており、障害時にはそれまでのデータを復元することもできます。
-
GridDBは、1,000台規模までスケールアウトが可能です。
- コンテナ単位のトランザクションにおいて、クラスタ処理の並列性を高めることで、高いスケーラビリティを実現できています。
-
GridDBは、人手によるクラスタ管理を必要としません。
- ノード相互に分散プロトコルを用いて通信を行い、GridDB自身が自律的にクラスタを制御します。
-
GridDBは、社会インフラで利用される非定型データをサポートしています。
- 社会インフラで利用される時系列データや空間データなど非定型データをサポートしています。
- GridDB Advanced Editionでは、ODBC/JDBC I/Fをサポートしています。
1.2.2 特徴
GridDBの特徴は以下のようにまとめられます。
要件 | 説明 |
---|---|
【基本要件】 | |
大容量性(ペタバイト級) | 高速性と大容量性を両立するため、インメモリとSSDの長所を活かしたデータ格納 |
高速性(インメモリ) | インメモリ処理 |
高スケーラビリティ性 | 1台から1000台超までサーバ増設可能 |
高可用性 | 複数サーバでのデータ複製、HDD併用により更なる可用性向上 |
高自律性 | データ複製やデータ配置バランシングを自動化。 オンラインでの サーバ増設を容易に可能 |
運用管理機能 | 監視、セキュリティ、バックアップなど |
【社会インフラ要件】 | |
時系列データ | 特徴を失わずにサイズを削減する圧縮機能も提供 |
空間データ型 | 2D、3Dデータ型をサポート、検索高速化のための索引設定も可能 |
一貫性の保証 | 同一コンテナ内で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 環境の確認
RHEL 6.2/6.3/6.4/6.5、もしくはCentOS 6.2/6.3/6.4/6.5であることを確認します。
$ lsb_release -id Distributor ID: CentOS Description: CentOS release 6.3 (Final)
【注意点】
-
OSインストール時のOSパッケージグループの選択では、最低以下を選択してください。
- Basic Server
2.2.2 ノードをインストールする
GridDBノードのインストールに用いるRPMパッケージは以下の3つです。インストールするマシンの任意の場所に配置してください。
パッケージ名 | ファイル名 | 内容 |
---|---|---|
griddb-server | griddb-server-X.X.X-linux.x86_64.rpm | GridDBのノードモジュールとサーバの起動コマンドなどが含まれます |
griddb-client | griddb-client-X.X.X-linux.x86_64.rpm | ノード起動を除く運用コマンド一式が含まれます。 |
griddb-docs | griddb-docs-X.X.X-linux.x86_64.rpm | GridDBのマニュアルとプログラムのサンプルが含まれます。 |
rootユーザでrpmコマンドを用いてインストールします。
$ su # rpm -Uvh griddb-server-X.X.X-linux.x86_64.rpm 準備中... ########################################### [100%] User gsadm and group gridstore have been registered. GridStore uses new user and group. 1:griddb-server ########################################### [100%] # rpm -Uvh griddb-client-X.X.X-linux.x86_64.rpm 準備中... ########################################### [100%] User and group has already been registered correctly. GridStore uses existing user and group. 1:griddb-client ########################################### [100%] # rpm -Uvh griddb-docs-X.X.X-linux.x86_64.rpm 準備中... ########################################### [100%] 1:griddb-docs ########################################### [100%]
パッケージをインストールすると、以下のグループとユーザがOSに作成されます。このOSユーザはGridDBを運用するためのユーザとして使用します。
グループ | ユーザ | ホームディレクトリ |
---|---|---|
gridstore | gsadm | /var/lib/gridstore |
このgsadmユーザでは以下の環境変数が定義されます。
環境変数 | 値 | 意味 |
---|---|---|
GS_HOME | /var/lib/gridstore | gsadm/GridDBホームディレクトリ |
GS_LOG | /var/lib/gridstore/log | イベントログファイル出力ディレクトリ |
【注意点】
- これら環境変数は、以降で説明する運用コマンドで参照されます。
-
gsadmユーザのパスワードは設定されていません。 OSのroot権限を用いて適宜設定してください。
- 運用ツールの一部機能で必要となる場合があります。
また、GridDBノードモジュールをインストールすると、OS起動とともに自動実行されるサービスが登録されます。
サービス名 | ランレベル |
---|---|
gridstore | 3,4,5 |
サービスの登録情報は、以下のコマンドで確認できます。
# /sbin/chkconfig --list | grep gridstore gridstore 0:off 1:off 2:off 3:on 4:on 5:on 6:off
このサービスによって、OS起動時にGridDBノードが自動起動します。
【注意点】
- インストール直後にサービスの自動起動は行いません。
なお、サービスの自動起動を停止するには、以下のコマンドを用います。
# /sbin/chkconfig gridstore off
サービスの詳細については、『GridDB 運用管理ガイド』(GridDB_OperationGuide.html)のサービスの章を参照ください。
2.2.3 インストール後の確認を行う
インストールされたGridDBノードのディレクトリ構成を確認します。
まず、GridDBホームディレクトリと、関連ディレクトリ、ファイルが作成されていることを確認します。
GridDBホームディレクトリ
/var/lib/gridstore/ # GridDBホームディレクトリ admin/ # 統合運用管理GUIホームディレクトリ backup/ # バックアップディレクトリ conf/ # 定義ファイルディレクトリ gs_cluster.json # クラスタ定義ファイル gs_node.json # ノード定義ファイル password # ユーザ定義ファイル data/ # データベースファイルディレクトリ log/ # ログディレクトリ
以下のコマンドで確認します。
$ ls /var/lib/gridstore/ admin backup conf data log
次に、インストールディレクトリが作成されていることを確認します。
インストールディレクトリ
/usr/gridstore-X.X.X/ # インストールディレクトリ Fixlist.pdf # 修正記録 Readme.txt # リリース説明書 bin/ # 運用コマンド、モジュールディレクトリ conf/ # 定義ファイルの雛形ディレクトリ docs/ # ドキュメントディレクトリ etc/ lib/ # ライブラリディレクトリ license/ # ライセンスディレクトリ prop/ # 設定ファイルディレクトリ web/ # 統合運用管理GUIファイルディレクトリ
以下のコマンドで確認します。
$ ls /usr/gridstore-X.X.X/ Fixlist.pdf Readme.txt bin conf etc lib license prop web
ドキュメントはすべて1つのZIPファイルに圧縮しています。下記のように、適宜解凍して参照ください。
$ cd /usr/gridstore-X.X.X/docs $ unzip griddb-documents-X.X.X.zip
また、利便性のため、インストールディレクトリの幾つかのディレクトリには以下のようにシンボリックリンクが作成されます。
$ ls /usr/gridstore/ conf lib prop web
最後に、インストールされたサーバモジュールのバージョンを以下のコマンドで確認します。
$ gsserver --version GridDB version X.X.X build XXXXX
補足
以後の手順に従い、GridDBを動作させると、以下のファイルが作成されます。
【データベースファイル】
/var/lib/gridstore/ # GridDBホームディレクトリ data/ # データベースファイルディレクトリ gs_log_n_m.log # トランザクションログを記録するログファイル(n,mは数字) gs_cp_n_p.dat # データを定期的に記録するチェックポイントファイル(n,pは数字)
【ログファイル】
/var/lib/gridstore/ # GridDBホームディレクトリ log/ # ログディレクトリ gridstore-%Y%m%d-n.log # イベントログファイル gs_XXXX.log # 運用ツールログファイル
これらファイルの作成ディレクトリはノード定義ファイル中のパラメータ設定で変更できます。
※: gs_XXXXは、運用ツール名です。(例:gs_startnode.log)
2.2.4 管理ユーザを設定する
管理ユーザは、ノードやクラスタへの認証のために用いられます。管理ユーザの情報は、 ユーザ定義ファイル に保存されています。デフォルトでは以下のファイルです。
- /var/lib/gridstore/conf/password
インストール直後では、下記のデフォルトユーザが存在します。
ユーザ | パスワード | 使い分けの例 |
---|---|---|
admin | admin | 運用管理ユーザ、運用コマンドの認証用 |
system | manager | アプリケーションユーザ、クライアント実行の認証用 |
上記のデフォルトユーザを含む管理ユーザ情報は、運用コマンドのユーザ管理コマンドを用いて変更できます。
コマンド | 機能 |
---|---|
gs_adduser | 管理ユーザを追加する |
gs_deluser | 管理ユーザを削除する |
gs_passwd | 管理ユーザのパスワードを変更する |
デフォルトユーザを利用する場合は、以下のようにパスワードを変更してください。パスワードは登録の際に暗号化されます。
$ gs_passwd admin Password:(パスワードを入力します) Retype password:(パスワードを再入力します)
デフォルト以外の新しい管理ユーザを追加する場合、ユーザ名はgs#で始まる必要があります。
gs#以降は1文字以上のASCII英数字ならびにアンダースコア「_」を使用可能です。
管理ユーザを新たに追加する例を以下に示します。
$ gs_adduser gs#newuser Password:(パスワードを入力します) Retype password:(パスワードを再入力します)
【注意点】
- GridDBの管理ユーザは、インストール時に作成されるOSユーザgsadmとは異なります。
- ユーザ管理コマンドによる管理ユーザ情報の変更は、ノードを再起動することで有効になります。
- クライアントで認証に用いるため、全ノードで同一のユーザ情報が登録されている必要があります。 ユーザ定義ファイル をコピーするなどして、 全ノードで同一のユーザ情報が参照されるようにしてください。
- 運用コマンドはgsadmユーザで実行してください。
【メモ】
- ユーザ管理コマンドの詳細は、『GridDB 運用管理ガイド』(GridDB_OperationGuide.html)を参照ください。
2.3 環境依存パラメータを設定する
インストール後、GridDBを動作させるためには以下の設定が必要です。
- ネットワーク環境の設定
- クラスタ名の設定
GridDBの設定は、2種類の定義ファイルを編集して行います。
- クラスタ定義ファイル(gs_cluster.json)
- ノード定義ファイル(gs_node.json)
クラスタ定義ファイルは、クラスタ全体で共通とするパラメータを定義するファイルです。
ノード定義ファイルは、ノード毎に異なる設定値とするパラメータを定義するファイルです。
以下のとおり、これら定義ファイルの雛形がインストールされています。
/usr/gridstore/ # インストールディレクトリ conf/ # 定義ファイルディレクトリ gs_cluster.json # クラスタ定義ファイルの雛形 gs_node.json # ノード定義ファイルの雛形
新規インストールでは、GridDBホームディレクトリ下のconfディレクトリにも同じファイルが配置されています。
/var/lib/gridstore/ # GridDBホームディレクトリ conf/ # 定義ファイルディレクトリ gs_cluster.json # (編集後の)クラスタ定義ファイル gs_node.json # (編集後の)ノード定義ファイル
運用の際には、こちらの定義ファイルを編集してください。
【注意点】
- GridDBをバージョンアップした場合、新たにインストールされた雛形と、これらの定義ファイルとを比較し、追加されたパラメータを適宜反映してください。
- クラスタ定義ファイルは、クラスタ全体で共通となるパラメータを定義するファイルです。そのため、 クラスタに参加する全ノードで、同一の設定内容でなければなりません。 内容が異なるノードは、後に説明するクラスタ参加の段階でエラーとなり、クラスタに参加できません。
2.3.1 ネットワーク環境の設定(必須)
まず、ネットワーク環境を設定します。
以下では、マルチキャストが利用可能な環境で推奨される設定方法について説明します。マルチキャストが利用不可能な環境や、マルチキャストでノード同士の疎通が取れない環境では、マルチキャスト方式以外のクラスタ構成方式を利用する必要があります。詳しくは、『GridDB 運用管理ガイド』(GridDB_OperationGuide.html)の[マルチキャスト方式以外のクラスタ構成方式の設定]を参照ください。
設定項目は以下のように大別されます。
- (1)クライアントとのインタフェースとなるアドレス情報
- (2)クラスタ管理処理のためのアドレス情報
- (3)JDBCクライアントとのインタフェースとなるアドレス情報(GridDB Advanced Editionのみ)
これらの設定項目は環境に合わせて設定する必要がありますが、基本的にはデフォルト設定でも動作します。
ただし、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を用いて明示的にこのアドレスを利用することはありません。
運用コマンドの接続アドレスおよびポートは、運用コマンドの処理要求先の指定だけでなく、統合運用管理GUIのリポジトリ情報としても利用します。
これら受付/接続アドレスは、複数インタフェースを使用/使い分ける必要がない限り設定不要です。
クラスタ定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/transaction/notificationAddress | string | クライアントとクラスタとのインタフェースアドレス |
/transaction/notificationPort | string | クライアントとクラスタとのインタフェースポート |
クライアントとクラスタとのインタフェースアドレスにはマルチキャストアドレスおよびポートを指定します。GridDBクラスタがクライアントに対してクラスタ情報を通知し、クライアントでクラスタにAPIで処理要求を送信するために利用します。詳しくは、『GridDB APIリファレンス』(GridDB_API_Reference.html)のGridStoreFactoryクラス/メソッドの説明を参照ください。
エクスポート/インポートツールの接続先アドレス、統合運用管理GUIのリポジトリ情報としても利用します。
(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は同一のアドレスを設定して動作させることが可能です。マシンが複数のネットワークインタフェースを持っている場合には、それぞれ別のアドレスを割り当てることで帯域を増やすことができます。
以下の設定はGridDB Advanced Editionのみを対象としています。
(3)JDBCクライアントとのインタフェースとなるアドレス情報
JDBC/ODBCクライアントとのインタフェースとなるアドレス情報には ノード定義ファイル および クラスタ定義ファイル に設定項目があります。
ノード定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/sql/serviceAddress | string | JDBC/ODBCクライアント接続用の受信アドレス |
/sql/servicePort | int | JDBC/ODBCクライアント接続用の受信ポート |
JDBC/ODBCクライアント接続用の受信アドレスおよびポートは、JDBC/ODBCクライアントがクラスタを構成するノードに個別に接続してクラスタのデータにSQLでアクセスするために使用します。クラスタをノード1台で構成する場合は利用しますが、複数台で構成する場合にはAPIを用いて明示的にこのアドレスを利用することはありません。
クラスタ定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/sql/notificationAddress | string | JDBC/ODBCクライアントへのマルチキャスト用アドレス |
/sql/notificationPort | int | JDBC/ODBCクライアントへのマルチキャスト用ポート |
JDBC/ODBCクライアントへのマルチキャスト用アドレスおよびポートは、GridDBクラスタがJDBC/ODBCクライアントに対してクラスタ情報を通知し、JDBC/ODBCクライアントでクラスタのデータにSQLでアクセスするために利用します。
その他のパラメータとデフォルト値は、付録のパラメータ一覧を参照ください。
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"です。
【注意点】
- 差分バックアップを行う場合には永続化モードを"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/storeWarmStart | boolean | スタート処理モード |
- false: 非ウォームスタートモード
- true: ウォームスタートモード
デフォルトはfalse(無効)です。
2.4.4 その他のパラメータ
その他のパラメータについて説明します。デフォルト値は、付録のパラメータ一覧を参照ください。
ノード定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/dataStore/dbPath | string | データベースファイルディレクトリ |
/dataStore/backupPath | 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 インストールおよびセットアップを行う(クライアント)
クライアントライブラリのインストール手順を説明します。GridDBのクライアントライブラリは、Java版とC版の2種類あります。なお、GridDB Advanced Edition NewSQLインターフェースをサポートするライブラリは、Java版のみです。
2.6.1 環境の確認
RHEL 6.2/6.3/6.4/6.5/6.6/6.7/6.8/7.2、もしくはCentOS 6.2/6.3/6.4/6.5/6.6/6.7/6.8/7.2であることを確認します。
$ lsb_release -id Distributor ID: CentOS Description: CentOS release 6.3 (Final)
【注意点】
-
OSインストール時のOSパッケージグループの選択では、最低以下を選択してください。
- Software Development WorkStation
Java言語の開発環境としては、以下がインストールされている必要があります。
- Oracle Java 6/7/8
- GridDB Advanced Edition NewSQLインターフェースの場合 64ビット Javaのみがサポート対象です
$ 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 クライアントライブラリをインストールする
GridDBクライアントライブラリのインストールに必要なRPMパッケージは以下の4つです。インストールするマシンの任意の場所に配置してください。
griddb-newsqlパッケージはGridDB Advanced Editionをご購入の場合のみ含まれています。
パッケージ名 | ファイル名 | 内容 |
---|---|---|
griddb-java_lib | griddb-java_lib-X.X.X-linux.x86_64.rpm | javaのライブラリが含まれます。 |
(/usr/share/java/gridstore.jar) | ||
griddb-c_lib | griddb-c_lib-X.X.X-linux.x86_64.rpm | Cのヘッダファイルとライブラリが含まれます。 |
(/usr/include/gridstore.h と /usr/lib64/libgridstore.so) | ||
griddb-docs | griddb-docs-X.X.X-linux.x86_64.rpm | GridDBのマニュアルとプログラムのサンプルが含まれます。 |
griddb-newsql | griddb-newsql-X.X.X-linux.x86_64.rpm | NewSQLインターフェースのライブラリが含まれます。 |
rootユーザでrpmコマンドを用いてインストールします。
$ su # rpm -ivh griddb-c_lib-X.X.X-linux.x86_64.rpm 準備中... ########################################### [100%] 1:griddb-c_lib ########################################### [100%] # rpm -ivh griddb-java_lib-X.X.X-linux.x86_64.rpm 準備中... ########################################### [100%] 1:griddb-java_lib ########################################### [100%] # rpm -ivh griddb-docs-X.X.X-linux.x86_64.rpm 準備中... ########################################### [100%] 1:griddb-docs ########################################### [100%] # rpm -ivh griddb-newsql-X.X.X-linux.x86_64.rpm 準備中... ########################################### [100%] 1:griddb-newsql ########################################### [100%]
2.6.3 インストール後の確認を行う
インストール後、GridDBクライアントライブラリのディレクトリ構成を確認します。正常にインストールできている場合、以下のようなディレクトリが作成されます。
インストールディレクトリ
/usr/gridstore-X.X.X/ # インストールディレクトリ docs/ # ドキュメントディレクトリ lib/ # ライブラリディレクトリ GridDB Advanced Editionをインストールしている場合、以下のディレクトリも作成されます。 /usr/gridstore-newsql-X.X.X/ # NewSQLインターフェース インストールディレクトリ lib/ # ライブラリディレクトリ
また、以下のシンボリックリンクが作成されます。
シンボリックリンク
/usr/lib64/libgridstore.so -> /usr/lib64/libgridstore.so.0 /usr/lib64/libgridstore.so.0 -> /usr/lib64/libgridstore.so.0.0.0 /usr/lib64/libgridstore.so.0.0.0 -> /usr/gridstore-X.X.X/lib/libgridstore.so.0.0.0 /usr/share/java/gridstore.jar -> /usr/gridstore-X.X.X/lib/gridstore-X.X.X.jar GridDB Advanced Editionをインストールしている場合、以下のファイルも作成されます。 /usr/share/java/gridstore-jdbc.jar -> /usr/gridstore-newsql-X.X.X/lib/gridstore-jdbc-X.X.X.jar
2.6.4 ライブラリを設定する
Java版クライアントを使用する場合、クライアントライブラリをCLASSPATHに追加します。
$ export CLASSPATH=${CLASSPATH}:/usr/share/java/gridstore.jar
C版クライアントを使用する場合、クライアントライブラリをLD_LIBRARY_PATHに追加します。
$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/lib64
2.6.5 クライアント側の設定を行う
クライアントの設定を行うための定義ファイルはありません。クライアントプログラム中で接続先やユーザ/パスワードの指定を行います。
指定の詳細については、GridDB Standard Edition NoSQLインターフェースの場合『GridDB APIリファレンス』(GridDB_API_Reference.html)、GridDB Advanced Edition NewSQLインターフェースの場合『GridDB Advanced Edition JDBCドライバ説明書』(GridDB_AE_JDBC_Driver_Guide.pdf)を参照ください
2.7 アンインストールする
GridDBが不要となった場合には全てのパッケージをアンインストールします。以下の手順でアンインストールを実行してください。
$ su # rpm -e griddb-server # rpm -e griddb-client # rpm -e griddb-java_lib # rpm -e griddb-c_lib # rpm -e griddb-newsql # rpm -e griddb-docs
定義ファイルやデータファイルなど、GridDBホームディレクトリ下のファイルはアンインストールされません。
不要な場合は手動で削除して下さい。
3 運用
この章では、GridDBの運用手順について説明します。
以下のケース毎に順に説明します。
- 起動から停止までの操作
- クラスタが稼動中の操作
- 障害発生時の対応
運用では以下のコマンドを使用します。
【コマンド一覧】
コマンド | 機能 |
---|---|
gs_startnode | ノードを起動する |
gs_joincluster | クラスタを作成する/ノードを参加させる |
gs_stopcluster | クラスタを停止する(処理停止する) |
gs_stopnode | ノードを停止する(シャットダウン) |
gs_leavecluster | クラスタからノードを離脱させる |
gs_appendcluster | クラスタを拡張する |
gs_config | クラスタの構成ノード情報を取得する |
gs_stat | ノードの内部情報を取得する |
gs_paramconf | サービスで利用するメモリを変更する |
gs_logs | ノードのイベントログを取得する |
gs_logconf | ノードのログ出力レベルを変更する |
gs_backup | ノードのデータをバックアップする |
gs_backuplist | バックアップデータを確認する |
gs_restore | バックアップデータをリストアする |
gs_import | データのインポート |
gs_export | データのエクスポート |
【運用コマンドを利用する上での注意点】
- 運用コマンドはgsadmユーザで実行してください。
- プロキシ変数(http_proxy)が設定されている場合、ノードのアドレス(群)を、no_proxyで設定し、proxyから除外してください。運用コマンドはREST/http通信を行うため、誤ってproxyサーバ側に接続されてしまい、運用コマンドが動作しません。
- 「接続サーバ:ポート」のオプション指定があるコマンドの場合、ポート設定をデフォルトから変更していなければ、このオプションを指定する必要はありません。また、「接続サーバ:ポート」のオプションを指定すれば、ノードを起動したマシンとは別のマシン上からこのコマンドを実行できます。
以下、使用方法について、順次説明します。なお、エクスポート/インポートに関しては、『GridDB 運用管理ガイド』(GridDB_OperationGuide.html)を参照ください。
3.1 起動から停止までの操作
3.1.1 基本の流れ
GridDBノードのインストールおよびセットアップを行った後、GridDBクラスタの起動から停止までの、通常運用の流れは以下のようになります。
- 各ノードを起動する。
- クラスタを構成する。
- GridDBのクラスタを利用する。
- クラスタを停止する。
- 各ノードを停止する。
【利用する上での注意点】
- 以下の手順では、運用管理者が、ノードを実行する全マシンのホスト名(もしくはアドレス)の一覧を把握していることを想定しています。
- 同様に、クラスタに参加させている、全ノードの台数も把握していることを想定しています。
- ユーザ認証オプション(-u)には、ユーザ「admin」、パスワード「admin」を例として使用しています。
3.1.2 各ノードを起動する
ノードを実行するマシン上でノード起動コマンドを実行します。このコマンドはノード毎に実行する必要があります。
ただし、GridDBノードプロセス(gsserver)がサービスにより自動起動されている場合には、以下の起動操作は必要ありません。次節の「クラスタを構成する」の操作から行ってください。
ノードの起動には以下のコマンドを用います。
- 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.html)および『GridDB プログラミングチュートリアル』(GridDB_ProgrammingTutorial.html)を参照ください。
3.1.5 クラスタで利用するメモリを変更する
GridDBで利用するメモリは、GridDBを構成するノードの ノード定義ファイル で定義されます。この値を、ノードやクラスタの再起動を行わずオンラインで変更できます。
ノード定義ファイル
パラメータ | データ型 | 意味 |
---|---|---|
/dataStore/storeMemoryLimit | string | 利用可能なメモリサイズ |
以下のコマンドを実行します。
- gs_paramconf [-s 接続サーバ:ポート] -u ユーザ名/パスワード --show storeMemoryLimit | --set storeMemoryLimit 値
以下に、ノードが起動しているマシン上でコマンドを実行する例を示します。
【コマンド実行例】
$ gs_paramconf -u admin/admin --set storeMemoryLimit 2048MB $ gs_paramconf -u admin/admin --show storeMemoryLimit "2048MB"
【注意点】
- この操作は、ノード単位の操作となります。すべてのノードに同様の変更を行いたい場合は、各ノードに上記操作を行ってください。
- ノードをシャットダウンした場合、変更した設定は保存されません。 値を永続化するにはノード定義ファイルを変更してください。
3.1.6 クラスタを停止する
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.7 一度停止したクラスタを再稼動する
GridDBクラスタをシャットダウンした後、通常の起動と同じ以下の手順で再稼動させることができます。
- 事前にシャットダウン時点の参加ノード数を確認しておきます。
- ノードを起動する。
- シャットダウン時点の構成台数を指定してクラスタに参加させる。
以下は、シングルノード構成のクラスタを再稼動させる具体例です。
【コマンド実行例】
$ gs_startnode ... $ gs_joincluster -c 設定したクラスタ名 -n 1 -u admin/admin ...
- クラスタ名は、クラスタ定義ファイルに設定したクラスタ名を指定してください。
- 構成ノード数は、シングルノード構成では1を指定してください。複数台構成の場合はシャットダウン時点でのノード台数を指定してください。
- シャットダウン時点でのクラスタ参加ノードは、イベントログファイルに情報が出力されています。
再稼動させると、GridDBクラスタはデータベースファイル(トランザクションログファイル、チェックポイントファイル)を読み込み、シャットダウン時点の状態を復元します。 「構成ノード数」台のノードがクラスタに参加すると、サービスを開始します。
【注意点】
- 「構成ノード数」には、シャットダウン時点でのノード台数を正しく指定する必要があります。クラスタの参加ノード数が構成ノード数に満たない場合、クラスタは一切のサービスを開始しません。サービスが開始されない場合は、ノード数が正しいか確認してください。
- 「構成ノード数」を誤って指定した際、クラスタが稼動していない状態のときは、クラスタ離脱コマンドでクラスタから離脱させ、再度正しい「構成ノード数」を指定してクラスタに参加させてください。
- 「構成ノード数」を誤って指定した際、クラスタが稼動してしまったときは、誤った状態でサービスを開始してしまう可能性があります。この場合は、クラスタを停止する手順を実施した後で、再稼動手順を実施してください。
- マシン故障などにより、シャットダウン時点とノード数が変わってしまった(シャットダウン時点より少ない)場合、再起動可能なノード数を指定して、再起動手順を実施してください。運用中の障害発生時と同様にデータの再配置を行います。ただし、大幅にノード数が減少してしまう場合には、データを参照できなくなる可能性があります。
- 新規にノードを追加する場合は、もともと稼動していた(シャットダウン時点での)ノードを全て起動し、クラスタが稼動した後に行ってください。手順の詳細は「稼働中のクラスタにノードを追加する」節を参照してください。
- 元々クラスタに参加していたマシンのIPアドレス、ポート(ノード定義ファイルの/xxx/serviceAddress、/xxx/servicePort)の変更は可能です。
3.2 各種情報を取得する
3.2.1 クラスタ構成情報を取得する
クラスタ構成情報(クラスタに参加しているノードの一覧情報)を取得します。そのためには、以下のクラスタ構成情報取得コマンドを実行します。
- gs_config [-s 接続サーバ:ポート] -u ユーザ名/パスワード
以下に、ノードが起動しているマシン上で実行する場合のコマンド実行例を示します。
【コマンド実行例】
$ gs_config -u admin/admin { "follower": [], "master": { "address": "192.168.1.10", "port": 10040 }, "multicast": { "address": "239.0.0.1", "port": 31999 }, "self": { "address": "192.168.1.10", "port": 10040, "status": "ACTIVE" } }
- "follower"では、参加しているクラスタの、上記マスタノード以外のノード一覧(アドレスとポート)が表示されます。複数台ある可能性があります。本情報はマスタノードのみで表示されます。
- "master"では、そのノードが参加しているクラスタについて、クラスタ管理するマスタノードのアドレスとポートが表示されます。必ず1台のみです。
- "multicast"では、クラスタのマルチキャストアドレスおよびポートが表示されます。
- "self"では、コマンドを実行したノード自身のアドレスとポートが表示されます。
システム状態(status)の意味は以下のとおりとなります。
- INACTIVE : 停止
- ACTIVATING : 稼働開始
- ACTIVE : 稼働
- DEACTIVATING : 停止開始
- ABNORMAL : 異常停止
- NORMAL_SHUTDOWN : 通常終了開始
3.2.2 クラスタ情報を取得する
クラスタ情報(クラスタ構成情報および内部情報)を取得します。そのためには、以下のクラスタ構成情報取得コマンドを実行します。
- 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 : 通常終了開始
その他の項目の説明はパラメータ一覧を参照ください。
3.2.3 イベントログの表示
直近のイベントログを取得します。以下のコマンドを用います。
- gs_logs [-s 接続サーバ:ポート] -u ユーザ名/パスワード --lines 取得行数 [第一キーワード [第二キーワード]]
以下に、ノードが起動しているマシン上で実行する場合のコマンド実行例を示します。
【コマンド実行例】
$ gs_logs -u admin/admin --lines 3 WARNING 2015-02-23T05:28:47.780+0900 host1 728 WARNING EVENT_ENGINE [130901:EE_WAIT_COMPLETION] (queueingElapsed=0, handlerElapsed=10000, watcherEngine=CHECKPOINT_SERVICE, watchedEngine=TRANSACTION_SERVICE, eventType=3004) 2015-02-23T05:29:12.437+0900 host1 726 WARNING IO_MONITOR [1900:CM_LONG_IO] [LONG I/O] sync time,34656,fileName,data/gs_log_0_60.log 2015-02-23T05:29:12.438+0900 host1 726 WARNING IO_MONITOR [LONG EVENT] eventType=PARTITION_GROUP_END, pId=0, pgId=0, time=34658
イベントログは、イベント情報の文字列リストです。イベント情報の書式は以下のようになります。
- 時刻、ホスト名、スレッド番号、イベントレベル、発生モジュール、イベント番号、イベント名、メッセージ
詳細については、サポート窓口にお問い合わせください。
3.2.4 イベントログ出力レベルの表示と変更
イベントログの出力レベルの一覧を表示するには、以下のコマンドを用います。
- gs_logconf [-s 接続サーバ:ポート] -u ユーザ名/パスワード
以下に、ノードが起動しているマシン上で実行する場合のコマンド実行例を示します。
【コマンド実行例】
$ gs_logconf -u admin/admin { "levels": { "CHECKPOINT_SERVICE": "INFO", "CHECKPOINT_SERVICE_DETAIL": "ERROR", "CHUNK_MANAGER": "ERROR", "CLUSTER_OPERATION": "INFO", : : } }
イベントログの出力レベルを変更するには、以下のコマンドを用います。
- gs_logconf [-s 接続サーバ:ポート] -u ユーザ名/パスワード カテゴリ 出力レベル
以下に、ノードが起動しているマシン上で実行する場合のコマンド実行例を示します。
【コマンド実行例】
$ gs_logconf -u admin/admin CHUNK_MANAGER INFO $ gs_logconf -u admin/admin { "levels": { "CHECKPOINT_SERVICE": "INFO", "CHECKPOINT_SERVICE_DETAIL": "ERROR", "CHUNK_MANAGER": "INFO", "CLUSTER_OPERATION": "INFO", : ; } }
出力レベルの一覧はレベルが高いものから低いものの順に以下のとおりとなります。
- ERROR : エラー
- WARNING : 警告
- INFO : 情報
- DEBUG : デバッグ
低い出力レベルを設定した場合、そのレベルよりも高い出力レベルのログもすべて出力されます。例えばINFOを設定した場合は、INFO、WARNING、ERRORのログが出力されます。
【注意点】
- ノードをシャットダウンした場合、変更した設定は保存されません。
- ログ出力レベルは雛形のgs_node.jsonに記載されているデフォルト値か、それより低いレベルを設定することを推奨しています。また、デフォルト値は付録のパラメータ一覧に記載しています。
3.3 バックアップとリストア
3.3.1 データをバックアップする
GridDBでは、ノード単位のホットバックアップが可能です。
以下のコマンドを実行することで、稼働中のノードのデータをバックアップできます。
- gs_backup [-s 接続サーバ:ポート] -u ユーザ名/パスワード バックアップ名
以下に、ノードが起動しているマシン上で実行する場合のコマンド実行例を示します。
【コマンド実行例】
$ cat /var/lib/gridstore/conf/gs_node.json # 設定の確認 { "dataStore":{ "dbPath":"/var/lib/gridstore/data", "backupPath":"/var/lib/gridstore/backup", # バックアップディレクトリ "storeMemoryLimit":"1024MB", "storeWarmStart":true, "concurrency":1, "logWriteMode":1, "persistencyMode":"NORMAL", : : } $ gs_backup -u admin/admin 20130301_backup # バックアップの実行 ...
この結果、以下のような処理が実行されます。
- バックアップディレクトリ(/var/lib/gridstore/backup)の下に、20130301_backup ディレクトリを作成する。
- チェックポイントファイル(gs_cp_n_p.dat)、(一つもしくは複数の)トランザクションログファイル(gs_log_n_m.log)、バックアップ情報ファイル(gs_backup_info.json,gs_backup_info_digest.json)を作成する(以降バックアップファイル群と呼びます)。
バックアップ開始後に制御が戻ります。データ規模、オンライン処理負荷により、バックアップ完了まで数時間以上かかる場合があります。
バックアップの進捗状況は、gs_statコマンドで取得できます。
以下のコマンドを実行することで、バックアップの進捗状況を確認できます。
- gs_stat -t backup [-s 接続サーバ:ポート] -u ユーザ名/パスワード
【コマンド実行例】
$ gs_stat -t backup -u admin/admin 20130301_backup BackupStatus: Processing # バックアップの実行中 $ gs_stat -t backup -u admin/admin 20130301_backup BackupStatus: - # バックアップの完了もしくは未稼働
【注意点】
- バックアップの詳細については、『GridDB バックアップガイド』(GridDB_BackupGuide.html)を参照ください。
- サービスを継続しながらクラスタ全体のホットバックアップを行うには、クラスタを構成する全ノードに対して、上記のバックアップ操作を実行する必要があります。
-
例では、説明の便宜上、backupPathは
/var/lib/gridstore/backup
でしたが、実際の運用では、システムの構成に合わせて適切なディレクトリに変更してください。 - このバックアップデータを用いてリストアすると、バックアップ完了直前の状態に復元されます。
- バックアップ中に障害が発生した場合、採取されたバックアップは不完全なため、これを用いてのリストアはできません。
- ホットバックアップを実行すると、コンテナを複数作成している場合には、クラスタ全体として不整合な状態でバックアップが作成される可能性があります。必要に応じて、トランザクションサービスを禁止し、静止状態でバックアップを実行するようにしてください。
- GridDBでは、障害発生した場合には自動的にデータ再配置が行われます。そのため、バックアップ中に障害が発生すると、必要なデータがバックアップされなくなる可能性があります。障害発生時には、再度、1台目のノードからバックアップを取り直してください。
3.3.2 バックアップしたデータをリストアする
ノードにバックアップデータをリストアします。
バックアップしたデータからクラスタ全体をリストアする場合、以下の手順で操作を行います。
-
ノードが起動していないことを確認します。
- クラスタ定義ファイルが、参加させるクラスタの他のノードと同一であることを確認します。
-
ノードのデータベースファイルディレクトリ(デフォルトでは、
/var/lib/gridstore/data
)に過去のトランザクションログファイル、チェックポイントファイルが残っていないことを確認します。- 不要であれば削除、必要であれば別のディレクトリに移動してください。
- ノードを実行するマシン上で、リストアコマンドを実行します。
- ノードを起動します。
- クラスタに参加させます。
以下のコマンドを実行します。
- gs_backuplist -u ユーザ名/パスワード
以下は、バックアップ名の一覧を表示する具体例です。バックアップ名の一覧は、ノードの起動状態に関わらず表示できます。ノードが起動状態で、バックアップ処理中の場合はStatusはProcessingと表示されます。
【コマンド実行例】
$ gs_backuplist -u admin/admin BackupName Status StartTime EndTime ------------------------------------------------------------------------ 20141025NO2 P 2014-10-25T06:37:10+0900 - 20141025 NG 2014-10-25T02:13:34+0900 - 20140925 OK 2014-09-25T05:30:02+0900 2014-09-25T05:59:03+0900 20140825 OK 2014-08-25T04:35:02+0900 2014-08-25T04:55:03+0900
バックアップ状態(Status)は以下のいずれかになります。
- OK:正常
- NG:異常
- P :実行中
【注意点】
- StatusがNGと表示される場合、そのバックアップファイルはファイルが破損している可能性があるため、リストアすることはできません。
以下は、バックアップデータをリストアする実行例です。リストアはノードを停止した状態で実行します。
【コマンド実行例】
$ mv ${GS_HOME}/data/*.{dat,log} ${GS_HOME}/temp # データベースファイルの移動 $ gs_restore 20130521_backup # リストア
この結果、以下のような処理が実行されます。
-
バックアップディレクトリ(
/var/lib/gridstore/backup
)の下にある、20130521_backupディレクトリから、バックアップファイル群をデータディレクトリ(/var/lib/gridstore/data
)にコピーする。
この例では、説明の便宜上、バックアップディレクトリは /var/lib/gridstore/backup
、データディレクトリは /var/lib/gridstore/data
でしたが、実際の運用では、システムの構成に合わせて適切なディレクトリに変更してください。(その他のパラメータを参照)
リストア完了後、ノードを通常の起動と同じ手順で起動し、クラスタ参加させてください。
【コマンド実行例】
$ gs_startnode ... $ gs_joincluster -c [設定したクラスタ名] -n 1 -u admin/admin ...
起動後、ノードはリストアで配置されたデータベースファイル(バックアップファイル群)を読み込みます。読み込み完了後、ノードはサービスを開始します。
【注意点】
- クラスタ定義ファイルの、パーティション数と処理並列度のパラメータに注意が必要です。バックアップしたノードの設定値とリストアするノードの設定値は同一にしてください。同一でないと正しくノードが起動できません。
- バックアップした状態を正しくリストアしたい場合、バックアップ、リストアの作業をクラスタ全体で行う必要があります。
- 仮に、一部ノードをリストアしたとしても、それらノードをバックアップ時点の状態に戻すことはできません。リストア後、データを利用するためには稼働中のクラスタに参加させる必要がありますが、バックアップ後にクラスタでデータ更新されていた場合には、リストアしたデータはクラスタの(更新された)データで更新されてしまいます。
- 特に、バックアップを作成した時点からクラスタの構成が変化している場合には、リストアの効果がありません。そのノードをクラスタに参加させると自律的にデータを再配置するので、リストアしても高い確率でデータが無効になります。
- バックアップ情報ファイルの情報が欠けている場合、または内容を改変した場合は、ノードはサービスを開始できません。
3.4 クラスタへのノード増設/切り離し
3.4.1 稼働中のクラスタにノードを増設する
稼働中のGridDBクラスタに新たにノードを増設します。ノードの増設コマンドは、構成ノード数(クラスタ構成gs_joincluster時に指定した数)を超えて、クラスタにノードを追加したい際に利用します
稼働中のクラスタに新たにノードを増設する場合、以下の手順で操作を行います。
- クラスタが稼動していることを確認します。
- クラスタの稼動情報を確認します。
-
増設したいノードを起動します。
- 増設したいノードのクラスタ定義ファイルが、ノードを追加したいクラスタの他のノードのものと同一であることを確認します。
-
「増設したいノード」にノード増設コマンドを実行します。
- 増設したいノードのクラスタ情報をgs_statコマンドで取得して、クラスタ状態がFOLLOWERになっていれば、クラスタに参加できています。
ノードを増設するには、以下のコマンドを実行します。
- gs_appendcluster --cluster 接続サーバ:ポート [-s 接続サーバ:ポート] -u ユーザ名/パスワード
clusterオプションには「ノードを追加したいクラスタを構成しているいずれかのノード」のサーバアドレスとポート(運用コマンド用)を指定します。以下は、クラスタに新たにノードを追加する具体例です。
追加対象のクラスタの状態を確認します。
【コマンド実行例】
$ gs_stat -s 192.168.33.29:10040 -u admin/admin { : "cluster":{ //クラスタ関連 "activeCount":5, //有効ノード数 "clusterName":"function_1", //クラスタ名 "clusterStatus":"MASTER", //クラスタ状態 "designatedCount":5, //構成ノード数(既定ノード数) :
クラスタの追加は構成ノード=有効ノード数(現在クラスタに参加している台数)の場合に使用できます。構成ノード数>有効ノード数の場合、クラスタへのノード追加はgs_joincluster(クラスタ構成への参加)を用います。
追加したいノードを起動するマシン上で以下を実行します。ノードを追加したいクラスタに参加しているノードのいずれか1台のサーバアドレスおよびポート(運用コマンド用)を指定します(ノードがマスタである必要はありません)。
【コマンド実行例】
$ gs_startnode $ gs_appendcluster --cluster 192.168.33.29:10040 -u admin/admin
ノードを追加後、構成ノード数および、有効ノード数の数が変更されています。
【コマンド実行例】
$ gs_stat -u admin/admin { : "cluster":{ //クラスタ関連 "activeCount":6, //有効ノード数 "clusterName":"function_1", //クラスタ名 "clusterStatus":"MASTER", //クラスタ状態 "designatedCount":6, //構成ノード数(既定ノード数) : }
【注意点】
- クラスタを停止し、再起動する場合の構成ノード数として使用しますので、クラスタの拡張を実行した際は、gs_statコマンドで構成ノード数を確認してください。
- 無停止でのGridDBクラスタの拡張(ノードの増設)は1台ずつ行うことになります。
- 大規模な拡張を行いたい場合は、一旦クラスタを停止させた後で、構成ノード数に拡張後のノード数を指定してクラスタを再構成してください。
3.4.2 稼働中のクラスタからノードを離脱させる(クラスタの縮小)
稼働中のGridDBクラスタからノードを1台離脱させます。
稼働中のクラスタから任意のノード1台を離脱させたい場合、以下の手順で操作を行います。
- クラスタが稼動していることを確認します。
- クラスタから離脱させたいノードに、クラスタ離脱コマンドを実行します。
クラスタからノードを離脱させるには、以下のコマンドを実行します。
- gs_leavecluster [-s 接続サーバ:ポート] [-f] -u ユーザ名/パスワード
以下は、クラスタからノード1台を離脱させる具体例です。
クラスタから離脱させたいノードを起動しているマシン上で以下を実行します。
【コマンド実行例】
$ gs_leavecluster -u admin/admin
【注意点】
- 指定したノードを離脱させるとデータロストが起こる可能性がある場合、クラスタの縮小は行えません。強制的にノードを離脱させたい場合は、-fオプションを使用してください。
- 無停止でのGridDBクラスタの縮小は1台ずつ行うことになります。
- クラスタに参加しているノード数が構成ノード数の半数に満たなくなると、クラスタは停止します。大規模な縮小を行いたい場合は、一旦クラスタを停止させた後で、構成ノード数に縮小後のノード数を指定してクラスタを再構成してください。大規模な縮小を行うと、データロストが起こる可能性が高くなります。
3.5 ソフトウェアの更新
3.5.1 ソフトウェアを更新する
以下の手順で、ソフトウェアの更新を行います。
- クラスタ停止
- ノード停止
- 念のための、定義ファイル、データベースファイルとイベントログファイルの退避/コピー
- ソフトウェア更新
- ノード起動
- クラスタ構成
以下は、ノードが起動しているマシン上で実行する場合の実行例です。
【コマンド実行例】
$ gs_stopcluster -u admin/admin $ gs_stopnode -u admin/admin $ cp -rp /var/lib/gridstore/data /xxx/shelter # 念のためコピー $ cp -rp /var/lib/gridstore/log /xxx/shelter # 念のためコピー $ cp -rp /var/lib/gridstore/conf /xxx/shelter # 念のためコピー $ su # rpm -Uvh griddb-server-Y.Y.Y-linux.x86_64.rpm # rpm -Uvh griddb-client-Y.Y.Y-linux.x86_64.rpm # rpm -Uvh griddb-docs-Y.Y.Y-linux.x86_64.rpm # exit $ gs_startnode $ gs_joincluster -c 設定したクラスタ名 -u admin/admin
※Y.Y.Y:更新するGridDBのバージョン
3.6 障害発生時の対応
障害の種類や対応方法の詳細については『GridDB バックアップガイド』(GridDB_BackupGuide.html)を参照ください。
3.6.1 基本の流れ
障害発生時、管理者が行う運用の流れは以下のようになります。
- まず、クラスタの稼動状態を確認し、離脱ノードを特定します。
- 離脱している障害ノードからイベントログ情報を取得します。
- イベントログ情報を解析し、障害の原因を確認します。
- 障害ノードを除去し、新しいノードと交換します
GridDBは障害が発生しても、クラスタ内でフェイルオーバーを行い、サービスを継続します。稼働しているバックアップノードが(レプリカが)存在する限り、フェイルオーバを繰り返し行います。バックアップノードがなくなった場合には、エラーとなります。
GridDBは障害発生時には以下のような動作を行います。
- 障害発生時、障害ノードはクラスタから自動的に離脱します。
- 離脱した障害ノードに代わり、既に作成されているバックアップノードへのフェイルオーバーが行われます。
3.6.2 クラスタの稼動状態を確認します
ノード情報取得コマンドを用いて、ノードの状態を確認できます。全ノードに対して個別に状態を確認します。
コマンド実行例
【コマンド実行例】
$ gs_stat -u admin/admin { : "cluster": { : "nodeStatus": "ACTIVE", : } # 全ノードに繰り返し実行
出力された/cluster/nodeStatusの値を確認します。以下の状態にあるノードが、障害ノードである可能性があります。
-
予期せず離脱状態となっているノード
- 状態が、INACTIVE、DEACTIVATING、ABNORMAL、NORMAL_SHUTDOWN、の場合。
- 結果を返却しないノード
3.6.3 障害ノードからイベントログ情報を取得します
障害ノードから、原因解析のため情報を取得します。以下のコマンドを用いて、直近のイベントログを取得します。
- gs_logs [-s 接続サーバ:ポート] -u ユーザ名/パスワード
以下に、ノードが起動しているマシン上で実行する場合のコマンド実行例を示します。
【コマンド実行例】
$ gs_logs -u admin/admin 2015-03-20T10:07:47.219+0900 host01 22962 INFO CHECKPOINT_SERVICE [30902:CP_STATUS] [CP_START] mode=NORMAL_CHECKPOINT, backupPath= : :
イベントログは、イベント情報の文字列リストです。イベント情報の書式は以下のようになります。
- 時刻、マシン名、スレッド番号、イベント種別、イベントカテゴリ、発生ソースファイル名、発生メソッド、発生行数 : 後は任意の文字列(※)
(※)改行を含む場合は、改行後の最初の文字にスペースが付与されます
イベントログの情報を取得し、障害情報の取得、原因の特定を行いますが、障害原因の分析についての詳細はサービス窓口にお問い合わせください。
【注意点】
- ローテートしていくため、イベントログファイルは複数存在します。このうちの、現在のイベントログファイルの情報しか表示しません。
3.6.4 障害ノードを交換します
障害ノードを稼動させているマシンをネットワークから取り外します。その後、新規マシンにGridDBノードをインストール、セットアップし、新たにクラスタに参加させます。その後は、「稼働中のクラスタにノードを追加する」の節で説明したのと同じように、クラスタは、新規に追加したノードを含めて、自動的にデータの再分配を行い、再分配が完了した後、新規に追加したノードはサービスを開始します。
4 付録
以下のX.X.Xは、GridDBのバージョンを表します。
4.1 パラメータ一覧
GridDBの定義ファイルであるノード定義ファイルとクラスタ定義ファイルのパラメータ一覧を以下に示します。
4.1.1 ノード定義ファイル(gs_node.json)
パラメータ | データ型 | 意味 | デフォルト |
---|---|---|---|
/dataStore/dbPath | string | データベースファイルディレクトリ | "data" |
/dataStore/backupPath | string | バックアップファイルディレクトリ | "backup" |
/dataStore/storeMemoryLimit | string | メモリバッファサイズ | "1024MB" |
/dataStore/storeWarmStart | boolean | 再起動時のウォームスタート(false:無効、true:有効) | false |
/dataStore/concurrency | int | 処理並列度 | 1 |
/dataStore/logWriteMode | int | ログ書き込みモード | 1 |
/dataStore/persistencyMode | string | 永続化モード | "NORMAL" |
/dataStore/affinityGroupSize | int | アフィニティグループ数 | 4 |
/dataStore/storeComperssionMode | string | データブロック圧縮モード | "NO_COMPRESSION" |
/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" |
GridDB Advanced Editionで上記に加えて利用するパラメータは以下のとおりです。
パラメータ | データ型 | 意味 | デフォルト |
---|---|---|---|
/sql/serviceAddress | string | JDBC/ODBCクライアント接続用の受信アドレス | "127.0.0.1" |
/sql/servicePort | int | JDBC/ODBCクライアント接続用の受信ポート | 20001 |
/sql/connectionLimit | int | コネクション数上限値 | 5000 |
/sql/concurrency | int | 処理並列度 | 5 |
/trace/sqlService | string | イベントログ出力レベル | "LEVEL_ERROR" |
4.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" |
/cluster/notificationMember | array | 固定リスト方式にする際のアドレスリスト | |
/cluster/notificationProvider/url | string | プロバイダ方式にする際のアドレスプロバイダのURL | |
/cluster/notificationProvider/updateInterval | int | アドレスプロバイダからリストを取得する間隔 | "5s" |
/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 |
/transaction/authenticationTimeoutInterval | string | 認証タイムアウト時間 | "5s" |
GridDB Advanced Editionで上記に加えて利用するパラメータは以下のとおりです。
パラメータ | データ型 | 意味 | デフォルト |
---|---|---|---|
/sql/notificationAddress | string | JDBC/ODBCクライアントへのマルチキャスト用アドレス | "239.0.0.1" |
/sql/notificationPort | int | JDBC/ODBCクライアントへのマルチキャスト用ポート | 41999 |
/sql/notificationInterval | string | JDBC/ODBCクライアントへのマルチキャスト間隔 | "5s" |
4.2 ビルド・実行方法
プログラムのビルドおよび実行方法の例を示します。
サンプルプログラムはドキュメントパッケージ内のZIPファイルに格納されていますので、適宜解凍してください。
【注意点】
- サンプルプログラム内のユーザ、パスワードは適宜変更する必要があります。
① gsadmでログインする。
② プログラムをビルドし実行する。
【GridDB Standard Edition NoSQLインターフェースの場合】
Javaの場合
- 環境変数の設定
- サンプルプログラムをgsSampleディレクトリにコピー
- ビルド
- 実行
$ export CLASSPATH=${CLASSPATH}:/usr/share/java/gridstore.jar $ mkdir gsSample $ cp /usr/gridstore-X.X.X/docs/sample/program/Sample1.java gsSample/. $ javac gsSample/Sample1.java $ java gsSample/Sample1 239.0.0.1 31999 設定したクラスタ名
Cの場合
- 環境変数の設定
- サンプルプログラムをコピー
-
sample2.cファイルの最終行に
void main(int argc,char *argv[]){ sample2(argv[1],argv[2],argv[3]);}
の追加 - ビルド
- 実行
【出力例】
$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/lib64 $ cp /usr/gridstore-X.X.X/docs/sample/program/sample2.c . $ echo "void main(int argc,char *argv[]){ sample2(argv[1],argv[2],argv[3]);}" >> sample2.c $ gcc -I/usr/gridstore-X.X.X/lib sample2.c -lgridstore $ a.out 239.0.0.1 31999 設定したクラスタ名
引数は、クライアントとクラスタとのインタフェースアドレス、ポート、クラスタ名の3つを指定して下さい。
【GridDB Advanced Edition NewSQLインターフェースの場合】
- 環境変数の設定
- サンプルプログラムをコピー
- ビルド
- 実行
$ export CLASSPATH=${CLASSPATH}:/usr/share/java/gridstore-jdbc.jar $ cp /usr/gridstore-X.X.X/docs/sample/program/SampleJDBC.java . $ javac SampleJDBC.java $ java SampleJDBC 239.0.0.1 41999 設定したクラスタ名
引数は、JDBC/ODBCクライアントへのマルチキャスト用アドレス、ポート、クラスタ名の3つを指定して下さい。
【注意点】
- sample2が実行済みである必要があります。
【出力例】
DB Connection Start Start 1414054670561|0|100.0| End DB Connection Close
5 商標
- GridDBは、当社の登録商標です。
- OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
- LinuxはLinus Torvaldsの商標です。
- Red Hatは米国およびその他の国におけるRed Hat, Inc.の登録商標もしくは商標です。
- その他製品名は、それぞれの所有者の商標または登録商標です。
6 その他
本製品には、Apache License, Version 2.0(http://www.apache.org/licenses/LICENSE-2.0) のソフトウェア(Apache Commons CliおよびApache CXF、MessagePack、opencsv、 Spring Framework、ActiveMQ-CPP、Apache Portable Runtime、JSONIC、commons io、 Jackson、fangyidong json-simple)を含んでいます。Apache Licenseは以下を参照ください。 サーバをインストールしたマシンの/usr/gridstore-X.X.X/license/Apache_License-2.0.txt 本製品には、The MIT License(http://opensource.org/licenses/MIT)のソフトウェア (flotおよびjQuery、jQuery-browser-plugin、jquery-cookie、jQuery-ui、libebb、 SLF4J、contextMenu、dynatree、jQuery-Templates-plugin、jqPlot)を含んでいます。 それぞれのソフトウェアの著作権および使用条件・免責事項は以下を参照ください。 ・サーバをインストールしたマシンの/usr/gridstore-X.X.X/license/MIT_License.txt ・サーバをインストールしたマシンの/usr/gridstore-X.X.X/license/<各ソフトウェア名ディレクトリ>の下 本製品には、BSD License(http://opensource.org/licenses/BSD-3-Clause または http://opensource.org/licenses/BSD-2-Clause)のソフトウェア(picojsonおよび sha2、 DataTables、orion SSH2、JLine、yield、purewell)を含んでいます。 それぞれのソフトウェアの著作権および使用条件・免責事項は以下を参照ください。 ・サーバをインストールしたマシンの/usr/gridstore-X.X.X/license/BSD_License.txt ・サーバをインストールしたマシンの/usr/gridstore-X.X.X/license/<各ソフトウェア名ディレクトリ>の下 本製品には、COMMON DEVELOPMENT AND DISTRIBUTION LICENSE(http://opensource.org/licenses /cddl1.php)のソフトウェア(JavaTM API for JSON ProcessingおよびJersey)を含んでいます。 COMMON DEVELOPMENT AND DISTRIBUTION LICENSEは以下を参照ください。 ・サーバをインストールしたマシンの/usr/gridstore-X.X.X/license/CDDL_License.txt それぞれのソフトウェアは以下のURLより入手しました。 ・JavaTM API for JSON Processing:http://jcp.org/en/jsr/detail?id=353 ・Jersey:https://jersey.java.net/download.html 本製品には、Eclipse Public License (http://www.eclipse.org/legal/epl-v10.html) のソフトウェア(logback)を含んでいます。 logbackは以下のURLより入手しました。 http://logback.qos.ch/download.html 本製品には、BSDスタイルのライセンスのソフトウェア(uuid)を含んでいます。それぞれの ソフトウェアの著作権および使用条件・免責事項は以下を参照ください。 サーバをインストールしたマシンの/usr/gridstore-X.X.X/license/uuidの下
7 お問い合わせ窓口
本製品をご利用いただく上でのお問い合わせは、基本サポートサービスの窓口へご連絡ください。
Copyright Toshiba Solutions Corporation 2013 - 2016