GridDB クイックスタートガイド

Revision: 1794

Table of Contents

1 はじめに

1.1 本文書の目的と構成

本文書はGridDBの基本的な運用手順について説明したものです。

GridDBを用いたシステム構築を行う設計者、GridDBの運用管理を行う管理者の方を対象としています。

本文書は、以下のような構成となっています。

  • システム設計・構築
    • GridDBのインストールから、基本的なセットアップの方法について説明しています。
  • 運用
    • GridDBの起動および停止といった基本操作から、GridDB稼働中の管理操作と障害発生時の対応に関するポイントを説明しています。

1.2 GridDBとは

1.2.1 概要

GridDBは、キーと複数の値からなるデータ(ロウと呼ばれる)の集合を管理する、分散NoSQL型データベースです。GridDBには、以下の3つの製品があります。

  • GridDB Standard Edition
  • GridDB Advanced Edition
  • GridDB Vector Edition

GridDB Advanced Editionは、GridDB Standard Editionのベース技術をそのまま活用し、さらにSQL処理エンジンを追加した製品です。

GridDB Vector Editionは、GridDB Advanced Editionに画像照合やビッグデータ分析・大規模メディア解析における機械学習で利用される高次元のベクトルデータを高速照合する機能を追加した製品です。

3つの製品はアプリケーション開発で利用するライブラリやツールの違いはありますが、システムの構築や運用方法は同一です。

  • GridDBは、データ管理をインメモリで行い、高速処理が可能です。
    • ロウの集合をインメモリ格納しており、高速な更新および検索処理ができます。
  • GridDBは、インメモリ処理ながら大容量化が可能です。
    • 複数マシンにデータを分散配置することで大容量化を行えます。さらに、本文書では紹介していませんが、ディスクを併用したデータ管理も可能です。そのため、単体のノードで動作させた場合も、メモリサイズに制限されない大容量化を実現できています。
  • GridDBは、高い可用性を実現できます。
    • クラスタ内でデータの複製を作成しており、いずれかのノードに障害が発生した場合には複製を使用することで処理を継続できます。また、各ノードはディスクを使用してデータ更新情報の永続化を行っており、障害時にはそれまでのデータを復元することもできます。
  • GridDBは、1,000台規模までスケールアウトが可能です。
    • コンテナ単位のトランザクションにおいて、クラスタ処理の並列性を高めることで、高いスケーラビリティを実現できています。
  • GridDBは、人手によるクラスタ管理を必要としません。
    • ノード相互に分散プロトコルを用いて通信を行い、GridDB自身が自律的にクラスタを制御します。
  • GridDBは、社会インフラで利用される非定型データをサポートしています。
    • 社会インフラで利用される時系列データや空間データなど非定型データをサポートしています。
  • GridDB Advanced Edition / Vector Editionでは、ODBC/JDBC I/Fをサポートしています。
  • GridDB Vector Editionでは、ベクトルデータの操作を行う拡張SQLをサポートしています。

1.2.2 特徴

GridDBの特徴は以下のようにまとめられます。

要件説明
【基本要件】
大容量性(ペタバイト級)高速性と大容量性を両立するため、インメモリとSSDの長所を活かしたデータ格納
高速性(インメモリ)インメモリ処理
高スケーラビリティ性1台から1000台超までサーバ増設可能
高可用性複数サーバでのデータ複製、HDD併用により更なる可用性向上
高自律性データ複製やデータ配置バランシングを自動化。 オンラインでの サーバ増設を容易に可能
運用管理機能監視、セキュリティ、バックアップなど
【社会インフラ要件】
時系列データ特徴を失わずにサイズを削減する圧縮機能も提供
空間データ型2D、3Dデータ型をサポート、検索高速化のための索引設定も可能
一貫性の保証同一コンテナ内でACIDトランザクションをサポート

1.3 用語の説明

GridDBの説明で用いられる用語の説明です。

用語意味
ノードGridDBでデータ管理を行う個々のサーバプロセスを指します。
クラスタ一体となってデータ管理を行う、1つ、もしくは複数のノードの集合を指します。
パーティションデータを格納する論理的な領域です。GridDB内部にのみ存在し、ユーザからは直接は見えません。
ロウGridDBで管理する1件分のデータを指します。キーと複数の値からなるひとまとまりのデータです。
コンテナロウの集合を管理する入れ物です。コレクションと時系列コンテナの2種類が存在します。
コレクション一般の型のキーを持つロウを管理するコンテナの1種です。
時系列コンテナ時刻型のキーを持つロウを管理するコンテナの1種です。時系列データを扱う専用の機能を持ちます。
マスタノードクラスタ管理処理を行うノードです。
フォロワノードクラスタに参加している、マスタノード以外のノードです。
オーナノード複製されたコンテナのうち、マスタコンテナを記録しているノードです。
バックアップノード複製されたコンテナのうち、レプリカコンテナを記録しているノードです。

2 システム設計・構築

この章では、基本的なシステム設計・構築の流れを示します。

GridDBノードおよびクラスタの設計・構築は以下の流れで行います。

  1. 必要なリソースを確認する
  2. インストールおよびセットアップを行う(ノード)
  3. 環境依存パラメータを設定する
  4. チューニングパラメータを設定する
  5. 各ノードに定義ファイルを配布する

クライアントの設定は、以下の項目を参照ください。

2.1 必要なリソースを確認する

GridDBは、スケールアウト型データベースであり、また無停止で運用を行えるため、従来DBのように慎重なシステム設計作業やサイジング作業は不要です。しかし、初期のシステム設計の目安として以下のような点を考慮してください。

  • メモリ使用量
  • クラスタ構成台数
  • ディスク使用量

以下、順に見積もり方法を説明します。

ただし、以下のメモリサイズの計算では、SSDなどの外部ストレージによる大容量化機能は考慮していません。 この機能を用いた場合の見積もりについては、サービス窓口にお問い合わせください。

2.1.1 総メモリ使用量

コンテナに格納するデータ量を予測し、メモリ使用量を見積もります。

まず、アプリケーションで格納するデータ量を予測します。以下のサイズと件数を予測します。

  • ロウのデータサイズ
  • 登録するロウ件数

次に、予測したデータ量を格納するために必要なメモリ使用量を見積もります。メモリ使用量は、コンテナの種類により計算式が異なります。

  • コレクションの場合
    • メモリ使用量(バイト)=600*<コンテナ数> + 1.8*<ロウサイズ>*<全ロウ数> + 24*<全ロウ数>*<索引数>
  • 時系列コンテナの場合
    • メモリ使用量(バイト)=700*<コンテナ数> + 1.5*<ロウサイズ>*<全ロウ数> + 24*<全ロウ数>*<索引数>

アプリケーションで作成、使用する全コンテナについて同様の見積もりを行います。総和がGridDBクラスタで使用するメモリ使用量となります。

  • 総メモリ使用量 = 全コンテナのメモリ使用量の総和

ただし、正確なメモリ使用量は更新頻度にも依存するため、最低限の目安と考えてください。

2.1.2 クラスタ構成台数

GridDBで使用するノードの必要台数を見積もります。以下では、1マシン上では1ノードを実行することを前提としています。

まず、マシン1台あたりのメモリサイズを想定します。

  • マシンのメモリサイズ

また、作成するレプリカ数を想定します。レプリカ数は、GridDBの設定値として与えられます。

  • レプリカ数

レプリカ数のデフォルト値は、2です。

  • ノード台数 = ( 総メモリ使用量 ÷ マシンのメモリサイズ ) × レプリカ数 (台)

ただし、負荷分散や可用性向上を考慮すれば、より余裕のある台数が好ましいため、最低限の目安と考えてください。

2.1.3 ディスク使用量

GridDBで作成するファイルのサイズを見積もり、ノード実行するマシンに必要なディスク容量を見積もります。作成するファイルにはチェックポイントファイルとトランザクションログファイルの二種類があります。

ノード単体でのメモリ使用量は以下のように求められます。

  • 単体メモリ使用量 = ( 総メモリ使用量 × レプリカ数 ) ÷ ノード台数 (バイト)

この数値を元に、以下のようにチェックポイントファイルを見積もります。

  • ファイルサイズ = 単体メモリ使用量 × 2 (バイト)

また、トランザクションログファイルサイズは、アプリケーションの更新頻度に依存するため、以下の情報を予測します。

  • ロウ更新頻度 (回/秒)

さらに、チェックポイント間隔を想定します。チェックポイント間隔は、GridDBの設定値として与えられます。

  • チェックポイント間隔

チェックポイント間隔のデフォルト値は、60秒です。

これらの数値を元に、以下のようにトランザクションログファイルサイズを見積もります。

  • ファイルサイズ = ロウデータサイズ × ロウ更新頻度 × チェックポイント間隔 (バイト)

これらをあわせ、以下のように単体ディスク使用量を見積もります。

  • 単体ディスク使用量 = トランザクションログファイルサイズ + チェックポイントファイルサイズ

【注意点】

  • チェックポイントファイルのサイズはデータ容量に応じて拡張されます。ただし、一度拡張されたファイルサイズは、コンテナやロウなどのデータを削除しても減少しませんのでご注意ください。データ削除後の空き領域は再利用されます。

2.2 インストールおよびセットアップを行う(ノード)

1台のマシンへのインストールについて説明します。クラスタの構成については、運用の章を参照ください。

2.2.1 環境の確認

RHEL 6.2/6.3/6.4/6.5/6.6/6.7/6.8/6.9/7.2/7.3、もしくはCentOS 6.2/6.3/6.4/6.5/6.6/6.7/6.8/6.9/7.2/7.3であることを確認します。

$ cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)

【注意点】

  • OSインストール時のOSパッケージグループの選択では、最低以下を選択してください。
    • Basic Server

2.2.2 ノードをインストールする

GridDBノードのインストールに用いるRPMパッケージは以下の3つです。インストールするマシンの任意の場所に配置してください。

パッケージ名ファイル名内容
griddb-xx-servergriddb-xx-server-X.X.X-linux.x86_64.rpmGridDBのノードモジュールとサーバの起動コマンドなどが含まれます
griddb-xx-clientgriddb-xx-client-X.X.X-linux.x86_64.rpmノード起動を除く運用コマンド一式が含まれます。
griddb-xx-docsgriddb-xx-docs-X.X.X-linux.x86_64.rpmGridDBのマニュアルとプログラムのサンプルが含まれます。
※: xxはGridDBのエディション(se, ae, ve)※: X.X.XはGridDBのバージョン

rootユーザでrpmコマンドを用いてインストールします。

$ su
# rpm -Uvh griddb-xx-server-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
User gsadm and group gridstore have been registered.
GridDB uses new user and group.
   1:griddb-xx-server          ########################################### [100%]
# rpm -Uvh griddb-xx-client-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
User and group has already been registered correctly.
GridDB uses existing user and group.
   1:griddb-xx-client          ########################################### [100%]
# rpm -Uvh griddb-xx-docs-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
   1:griddb-xx-docs            ########################################### [100%]

パッケージをインストールすると、以下のグループとユーザがOSに作成されます。このOSユーザはGridDBを運用するためのユーザとして使用します。

グループユーザホームディレクトリ
gridstoregsadm/var/lib/gridstore

このgsadmユーザでは以下の環境変数が定義されます。

環境変数意味
GS_HOME/var/lib/gridstoregsadm/GridDBホームディレクトリ
GS_LOG/var/lib/gridstore/logイベントログファイル出力ディレクトリ

【注意点】

  • これら環境変数は、以降で説明する運用コマンドで参照されます。
  • gsadmユーザのパスワードは設定されていません。 OSのroot権限を用いて適宜設定してください。
    • 運用ツールの一部機能で必要となる場合があります。

また、GridDBノードモジュールをインストールすると、OS起動とともに自動実行されるサービスが登録されます。

サービス名ランレベル
gridstore3,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

サービスで起動するには、起動設定ファイル(/etc/sysconfig/gridstore/gridstore.conf)の設定が必要です。詳細は、『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/griddb/              # インストールディレクトリ
            Fixlist.pdf   # 修正記録
            Readme.txt    # リリース説明書
            bin/          # 運用コマンド、モジュールディレクトリ
            conf/         # 定義ファイルの雛形ディレクトリ
            docs/         # ドキュメントディレクトリ
            etc/
            lib/          # ライブラリディレクトリ
            license/      # ライセンスディレクトリ
            prop/         # 設定ファイルディレクトリ
            web/          # 統合運用管理GUIファイルディレクトリ

以下のコマンドで確認します。

$ ls /usr/griddb/
Fixlist.pdf  Readme.txt  bin  conf  etc  lib  license  prop  web

ドキュメントはすべて1つのZIPファイルに圧縮しています。下記のように、適宜解凍して参照ください。

$ cd /usr/griddb/docs
$ unzip griddb-documents-X.X.X.zip

最後に、インストールされたサーバモジュールのバージョンを以下のコマンドで確認します。

$ gsserver --version
GridDB version X.X.X build XXXXX ***** Edition

補足

以後の手順に従い、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

インストール直後では、下記のデフォルトユーザが存在します。

ユーザパスワード使い分けの例
adminadmin運用管理ユーザ、運用コマンドの認証用
systemmanagerアプリケーションユーザ、クライアント実行の認証用

上記のデフォルトユーザを含む管理ユーザ情報は、運用コマンドのユーザ管理コマンドを用いて変更できます。

コマンド機能
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を動作させるためには以下の設定が必要です。

  1. ネットワーク環境の設定
  2. クラスタ名の設定

GridDBの設定は、2種類の定義ファイルを編集して行います。

  • クラスタ定義ファイル(gs_cluster.json)
  • ノード定義ファイル(gs_node.json)

クラスタ定義ファイルは、クラスタ全体で共通とするパラメータを定義するファイルです。

ノード定義ファイルは、ノード毎に異なる設定値とするパラメータを定義するファイルです。

以下のとおり、これら定義ファイルの雛形がインストールされています。

/usr/griddb/                     # インストールディレクトリ
            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 / Vector 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)は環境によって異なります。

  1. ホスト名とIPアドレスを確認します。
    $ hostname
    GS_HOST
    $ ip route | grep eth0 | cut -f 12 -d " " | tr -d "\n"
    192.168.11.10
    
  2. rootユーザで、確認したIPアドレスとホスト名の対応を/etc/hostsファイルに追加します。
    192.168.11.10   GS_HOST
    
  3. 設定が正しく行われたことを確認します。
    $ hostname -i
    192.168.11.10
    

※表示が設定前と変わらない場合、より優先度の高い設定が/etc/hostsファイルに記載されています。適宜優先順位を変更してください。

/etc/hostsが正しく設定されていることが確認できたら、以降の設定に進んでください。

(1)クライアントとのインタフェースとなるアドレス情報

クライアントとのインタフェースとなるアドレス情報には ノード定義ファイル および クラスタ定義ファイル に設定項目があります。

ノード定義ファイル

パラメータデータ型意味
/transaction/serviceAddressstringトランザクション処理の受付アドレス
/transaction/servicePortstringトランザクション処理の受付ポート
/system/serviceAddressstring運用コマンドの接続アドレス
/system/servicePortstring運用コマンドの接続ポート

トランザクション処理の受付アドレスおよびポートは、クライアントがクラスタを構成するノードに個別に接続してGridDBクラスタに対してトランザクション処理要求するために使用します。クラスタをノード1台で構成する場合は利用しますが、複数台で構成する場合にはAPIを用いて明示的にこのアドレスを利用することはありません。

運用コマンドの接続アドレスおよびポートは、運用コマンドの処理要求先の指定だけでなく、統合運用管理GUIのリポジトリ情報としても利用します。

これら受付/接続アドレスは、複数インタフェースを使用/使い分ける必要がない限り設定不要です。

クラスタ定義ファイル

パラメータデータ型意味
/transaction/notificationAddressstringクライアントとクラスタとのインタフェースアドレス
/transaction/notificationPortstringクライアントとクラスタとのインタフェースポート

クライアントとクラスタとのインタフェースアドレスにはマルチキャストアドレスおよびポートを指定します。GridDBクラスタがクライアントに対してクラスタ情報を通知し、クライアントでクラスタにAPIで処理要求を送信するために利用します。詳しくは、『GridDB APIリファレンス』(GridDB_API_Reference.html)のGridStoreFactoryクラス/メソッドの説明を参照ください。

エクスポート/インポートツールの接続先アドレス、統合運用管理GUIのリポジトリ情報としても利用します。

(2)クラスタ管理処理のためのアドレス情報

クラスタが自律的に行うクラスタ管理処理のためのアドレス情報には ノード定義ファイル および クラスタ定義ファイル に設定項目があります。これらのアドレスは、クラスタ間のハートビート(クラスタ間の生存確認)やクラスタ間の情報交換用にGridDBが内部的に利用するアドレスです。複数のネットワークインタフェースカードを利用する場合や、同一ネットワーク上の他のシステムと利用するアドレスが重複しない限り設定は不要です。

ノード定義ファイル

パラメータデータ型意味
/cluster/serviceAddressstringクラスタ管理のために使用する受信アドレス
/cluster/servicePortstringクラスタ管理のために使用する受信ポート

クラスタ定義ファイル

パラメータデータ型意味
/cluster/notificationAddressstringクラスタ管理用のためのマルチキャスト用アドレス
/cluster/notificationPortstringクラスタ管理用のためのマルチキャスト用ポート
  • クラスタ構成が変化した際にレプリカとの同期処理が行われますが、その処理でのタイムアウト時間を設定できます。
    • /sync/timeoutInterval

【注意点】

  • いずれもGridDB以外では使用されていないアドレス、ポートを設定する必要があります。
  • ノード定義ファイルgs_node.jsonの/transaction/serviceAddress、/system/serviceAddress、および/cluster/serviceAddressは同一のアドレスを設定して動作させることが可能です。マシンが複数のネットワークインタフェースを持っている場合には、それぞれ別のアドレスを割り当てることで帯域を増やすことができます。

以下の設定はGridDB Advanced Edition / Vector Editionのみを対象としています。

(3)JDBCクライアントとのインタフェースとなるアドレス情報

JDBC/ODBCクライアントとのインタフェースとなるアドレス情報には ノード定義ファイル および クラスタ定義ファイル に設定項目があります。

ノード定義ファイル

パラメータデータ型意味
/sql/serviceAddressstringJDBC/ODBCクライアント接続用の受信アドレス
/sql/servicePortintJDBC/ODBCクライアント接続用の受信ポート

JDBC/ODBCクライアント接続用の受信アドレスおよびポートは、JDBC/ODBCクライアントがクラスタを構成するノードに個別に接続してクラスタのデータにSQLでアクセスするために使用します。クラスタをノード1台で構成する場合は利用しますが、複数台で構成する場合にはAPIを用いて明示的にこのアドレスを利用することはありません。

クラスタ定義ファイル

パラメータデータ型意味
/sql/notificationAddressstringJDBC/ODBCクライアントへのマルチキャスト用アドレス
/sql/notificationPortintJDBC/ODBCクライアントへのマルチキャスト用ポート

JDBC/ODBCクライアントへのマルチキャスト用アドレスおよびポートは、GridDBクラスタがJDBC/ODBCクライアントに対してクラスタ情報を通知し、JDBC/ODBCクライアントでクラスタのデータにSQLでアクセスするために利用します。

その他のパラメータとデフォルト値は、付録のパラメータ一覧を参照ください。

2.3.2 クラスタ名の設定(必須)

対象のノードが構成するクラスタの名前をあらかじめ設定しておきます。設定した名前はクラスタを構成するコマンドで指定した値と一致するかがチェックされます。そのため、コマンドの指定誤りで、異なるノードとクラスタを構成してしまうという誤りを防げます。

クラスタ名の指定は クラスタ定義ファイル の以下設定項目に指定します。

クラスタ定義ファイル

パラメータデータ型意味
/cluster/clusterNamestring作成するクラスタの名前

【注意点】

  • デフォルト値("")では、ノードの起動に失敗します。
  • サブネットワーク上で一意となる名前にすることを推奨します。
  • クラスタ名は、1文字以上のASCII英数字ならびにアンダースコア「_」の列で構成されます。ただし、先頭の文字には数字を指定できません。また、大文字・小文字は区別されません。また、64文字以内で指定する必要があります。

2.4 チューニングパラメータを設定する

ここでは、主なチューニングパラメータについて説明します。必須の設定項目ではありませんが、クラスタの処理性能に影響を与えるパラメータです。

2.4.1 更新性能に関するパラメータ

GridDBは、永続化のためにトランザクションログファイル、チェックポイントファイルを作成します。これらファイルへのデータ書き込みは更新性能に影響を与えるため、以下のパラメータにより作成の方法を切り替えることができます。ただし、デメリットとして、障害時にデータを失ってしまう可能性が高くなる場合があります。

これに関するパラメータには以下があります。

ノード定義ファイル

パラメータデータ型意味
/dataStore/persistencyModestring永続化モード
/dataStore/logWriteModeintログ書き込みモード

永続化モードは、データ更新時のファイルへの書き込み有無を指定するものです。ログ書き込みモードは、トランザクションログファイルの書き込みのタイミングを指定するものです。

永続化モードには、以下のいずれかの値を設定できます。

  • "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/replicationModeintレプリケーションモード

レプリケーションモードは、レプリカの方法を指定するものです。クラスタ内の全ノードで一致させる必要があります。

  • "0": 非同期レプリケーション
  • "1": 準同期レプリケーション

"非同期レプリケーション"は、更新処理のタイミングと同期せずにレプリケーションを行います。"準同期レプリケーション"は、更新処理のタイミングで同期的にレプリケーションを行いますが、レプリケーション完了の待ち合わせは行いません。デフォルトは"0"です。

2.4.3 起動直後のアクセス性能に関するパラメータ

ノードの起動と同時に、ディスク等に永続化されたデータをメモリ上にロードさせることができます(ウォームスタート処理)。

ウォームスタート処理の有効/無効は以下のパラメータで切り替えることができます。

ノード定義ファイル

パラメータデータ型意味
/dataStore/storeWarmStartbooleanスタート処理モード
  • false: 非ウォームスタートモード
  • true: ウォームスタートモード

デフォルトはfalse(無効)です。

2.4.4 その他のパラメータ

その他のパラメータについて説明します。デフォルト値は、付録のパラメータ一覧を参照ください。

ノード定義ファイル

パラメータデータ型意味
/dataStore/dbPathstringデータベースファイルディレクトリ
/dataStore/backupPathstringバックアップファイルディレクトリ
/dataStore/storeMemoryLimitstringメモリバッファサイズ
/dataStore/concurrencyint処理並列度
/dataStore/affinityGroupSizeintデータアフィニティのグループ数
/checkpoint/checkpointIntervalintチェックポイント実行間隔(単位:秒)
/system/eventLogPathstringイベントログファイルの出力ディレクトリ
/transaction/connectionLimitintコネクション数上限値
/trace/カテゴリstringイベントログ出力レベル
  • データベースファイルディレクトリは、インメモリに登録されたデータを永続化する際に作成される、トランザクションログファイル、チェックポイントファイルが作成されるディレクトリです。
  • バックアップファイルディレクトリは、次節以降で説明する、バックアップを実行した際に作成される、バックアップファイルが格納されるディレクトリです。
  • メモリバッファサイズは、データ管理のために用いるメモリサイズです。単位付きの文字列で指定します(例: "2048MB")。
  • 処理並列度は、GridDBが二次記憶装置のI/O処理を並列に実行する上限数です。
  • データアフィニティでは、関連するデータを集めて配置管理する際のグループ数を指定します。
  • グループ数には、1から64までの数値が指定できます。グループ数を多くするとメモリ利用効率は低下しますので注意して設定してください。
  • チェックポイント実行間隔は、内部的に定期的に実行される(データの永続化に関する)チェックポイント処理を実行する間隔です。
  • イベントログの出力ディレクトリは、ノード内部で発生した例外などのイベント情報に関するメッセージ(イベントメッセージファイル)が出力されるディレクトリです。
  • コネクション数上限値は、想定されるクライアント数を2倍した値以上を目安に設定してください。
  • イベントログ出力レベルは、イベントログの各カテゴリに対する出力レベルです。

2.5 各ノードに定義ファイルを配布する

定義ファイルのうち、ユーザ定義ファイルとクラスタ定義ファイルは、GridDBクラスタを構成する すべてのノードで同一の設定内容にする必要があります。

そのため、2台以上のノードでクラスタを構成する場合、下記の手順ですべてのノードの設定を行います。(1台のノードでクラスタを構成する場合、これまでの手順でノードおよびクラスタの設定は完了しています。)

  1. ノードをインストールしたいずれかのマシン上で、管理ユーザの設定環境依存パラメータの設定を行う。
  2. 設定した クラスタ定義ファイルユーザ定義ファイル を他のノードの定義ファイルディレクトリに上書きコピーする。
  3. 各ノードで共通としたい設定を行った場合は、 ノード定義ファイル も合わせてコピーします。
  4. 各ノードで異なる設定を別途行う。(ネットワーク環境の設定など)

2.6 インストールおよびセットアップを行う(クライアント)

クライアントライブラリのインストール手順を説明します。GridDBのクライアントライブラリは、Java版とC版の2種類あります。なお、GridDB NewSQLインターフェースをサポートするライブラリは、Java版のみです。

2.6.1 環境の確認

RHEL 6.2/6.3/6.4/6.5/6.6/6.7/6.8/6.9/7.2/7.3、もしくはCentOS 6.2/6.3/6.4/6.5/6.6/6.7/6.8/6.9/7.2/7.3であることを確認します。

$ cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)

【注意点】

  • OSインストール時のOSパッケージグループの選択では、最低以下を選択してください。
    • Software Development WorkStation

Java言語の開発環境としては、以下がインストールされている必要があります。

  • Oracle Java 6/7/8
  • GridDB 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-xx-newsqlパッケージはGridDB Advanced Edition / Vector Editionをご購入の場合のみ含まれています。

パッケージ名ファイル名内容
griddb-xx-java_libgriddb-xx-java_lib-X.X.X-linux.x86_64.rpmjavaのライブラリが含まれます。
(/usr/share/java/gridstore.jar)
griddb-xx-c_libgriddb-xx-c_lib-X.X.X-linux.x86_64.rpmCのヘッダファイルとライブラリが含まれます。
(/usr/include/gridstore.h と /usr/lib64/libgridstore.so)
griddb-xx-python_libgriddb-xx-python-X.X.X-linux.x86_64.rpmpythonのライブラリが含まれます。(必要に応じてインストールしてください)
griddb-xx-docsgriddb-xx-docs-X.X.X-linux.x86_64.rpmGridDBのマニュアルとプログラムのサンプルが含まれます。
griddb-xx-newsqlgriddb-xx-newsql-X.X.X-linux.x86_64.rpmNewSQLインターフェースのライブラリが含まれます。

【注意点】

  • pythonライブラリのパッケージは必要に応じてインストールしてください。インストールする場合は、Cライブラリのパッケージを先にインストールしてください。

rootユーザでrpmコマンドを用いてインストールします。

$ su
# rpm -ivh griddb-xx-c_lib-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
   1:griddb-xx-c_lib           ########################################### [100%]
# rpm -ivh griddb-xx-java_lib-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
   1:griddb-xx-java_lib        ########################################### [100%]
# rpm -ivh griddb-xx-python_lib-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
   1:griddb-xx-python_lib      ########################################### [100%]
# rpm -ivh griddb-xx-docs-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
   1:griddb-xx-docs            ########################################### [100%]
# rpm -ivh griddb-xx-newsql-X.X.X-linux.x86_64.rpm
準備中...                ########################################### [100%]
   1:griddb-xx-newsql          ########################################### [100%]

2.6.3 インストール後の確認を行う

インストール後、GridDBクライアントライブラリのディレクトリ構成を確認します。正常にインストールできている場合、以下のようなディレクトリが作成されます。

インストールディレクトリ

/usr/griddb/              # インストールディレクトリ
            docs/         # ドキュメントディレクトリ
            lib/          # ライブラリディレクトリ

griddb-xx-newsqlパッケージをインストールしている場合、以下のディレクトリも作成されます。

/usr/griddb-xx-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/griddb-xx-X.X.X/lib/libgridstore.so.0.0.0

/usr/share/java/gridstore.jar -> /usr/griddb-xx-X.X.X/lib/gridstore-X.X.X.jar

griddb-xx-newsqlパッケージをインストールしている場合、以下のファイルも作成されます。

/usr/share/java/gridstore-advanced.jar -> /usr/griddb-xx-newsql-X.X.X/lib/gridstore-advanced-X.X.X.jar
/usr/share/java/gridstore-jdbc.jar -> /usr/griddb-xx-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

Python版クライアントを使用する場合、pythonパッケージのインストールを行います。

$ pip install /usr/griddb/lib/python

【メモ】

  • GridDB Advanced Edition / Vector Editionで、Java版クライアントを用いてパーティションテーブル(コンテナ)を操作する場合、クライアントライブラリと合わせて、互換性ライブラリをCLASSPATHに追加します。互換性ライブラリはgriddb-xx-newsqlパッケージに含まれます。
    $ export CLASSPATH=${CLASSPATH}:/usr/share/java/gridstore.jar:/usr/share/java/gridstore-advanced.jar
    

2.6.5 クライアント側の設定を行う

クライアントの設定を行うための定義ファイルはありません。クライアントプログラム中で接続先やユーザ/パスワードの指定を行います。

指定の詳細については、GridDB NoSQLインターフェースの場合『GridDB APIリファレンス』(GridDB_API_Reference.html)、GridDB NewSQLインターフェースの場合『GridDB Advanced Edition JDBCドライバ説明書』(GridDB_AE_JDBC_Driver_Guide.pdf)を参照ください

2.7 アンインストールする

GridDBが不要となった場合には全てのパッケージをアンインストールします。以下の手順でアンインストールを実行してください。

$ su
# rpm -e griddb-xx-server
# rpm -e griddb-xx-client
# rpm -e griddb-xx-java_lib
# rpm -e griddb-xx-python_lib
# rpm -e griddb-xx-c_lib
# rpm -e griddb-xx-docs
# rpm -e griddb-xx-newsql

※: xxはGridDBのエディション(se, ae, ve)

定義ファイルやデータファイルなど、GridDBホームディレクトリ下のファイルはアンインストールされません。

不要な場合は手動で削除して下さい。

3 運用

この章では、GridDBの運用手順について説明します。

以下のケース毎に順に説明します。

  • 起動から停止までの操作
  • クラスタが稼動中の操作
  • 障害発生時の対応

運用では以下のコマンドを使用します。

【コマンド一覧】

コマンド機能
gs_startnodeノードを起動する
gs_stopnodeノードを停止する(シャットダウン)
gs_joinclusterクラスタを作成する/ノードを参加させる
gs_leaveclusterクラスタからノードを離脱させる
gs_stopclusterクラスタを停止する(処理停止する)
gs_configクラスタの構成ノード情報を取得する
gs_statノードの内部情報を取得する
gs_appendclusterクラスタを拡張する
gs_failoverclusterクラスタを手動でフェイルオーバーする
gs_partitionパーティション情報を取得する
gs_increaseclusterクラスタ構成ノード数を拡張する
gs_loadbalanceクラスタの自律的データ配置の有効無効を設定する
gs_logsノードのイベントログを取得する
gs_logconfノードのログ出力レベルを変更する
gs_backupノードのデータをバックアップする
gs_backuplistバックアップデータを確認する
gs_restoreバックアップデータをリストアする
gs_importデータのインポート
gs_exportデータのエクスポート
gs_paramconfサービスで利用するメモリを変更する

【運用コマンドを利用する上での注意点】

  • 運用コマンドはgsadmユーザで実行してください。
  • プロキシ変数(http_proxy)が設定されている場合、ノードのアドレス(群)を、no_proxyで設定し、proxyから除外してください。運用コマンドはREST/http通信を行うため、誤ってproxyサーバ側に接続されてしまい、運用コマンドが動作しません。
  • 「接続サーバ:ポート」のオプション指定があるコマンドの場合、ポート設定をデフォルトから変更していなければ、このオプションを指定する必要はありません。また、「接続サーバ:ポート」のオプションを指定すれば、ノードを起動したマシンとは別のマシン上からこのコマンドを実行できます。

以下、各運用手順について説明します。なお、各コマンドの詳細に関しては、『GridDB 運用管理ガイド』(GridDB_OperationGuide.html)を参照ください。

3.1 起動から停止までの操作

3.1.1 基本の流れ

GridDBノードのインストールおよびセットアップを行った後、GridDBクラスタの起動から停止までの、通常運用の流れは以下のようになります。

  1. 各ノードを起動する。
  2. クラスタを構成する。
  3. GridDBのクラスタを利用する。
  4. クラスタを停止する。
  5. 各ノードを停止する。

【利用する上での注意点】

  • 以下の手順では、運用管理者が、ノードを実行する全マシンのホスト名(もしくはアドレス)の一覧を把握していることを想定しています。
  • 同様に、クラスタに参加させている、全ノードの台数も把握していることを想定しています。
  • ユーザ認証オプション(-u)には、ユーザ「admin」、パスワード「admin」を例として使用しています。

3.1.2 各ノードを起動する

ノードを実行するマシン上でノード起動コマンドを実行します。このコマンドはノード毎に実行する必要があります。

ただし、GridDBノードプロセス(gsserver)がサービスにより自動起動されている場合には、以下の起動操作は必要ありません。次節の「クラスタを構成する」の操作から行ってください。

ノードの起動には以下のコマンドを用います。

  • gs_startnode

GridDBホームディレクトリ下のconfディレクトリ下にあるノード定義ファイル、クラスタ定義ファイル、ユーザ定義ファイルの設定を用いてノードを起動します。以下に、コマンド実行例を示します。

【コマンド実行例】

$ gs_startnode -u admin/admin -w

クラスタを構成する全てのマシンで、ノード起動を行う必要があります。

【注意点】

  • クラスタを構成する場合、参加する各ノードの クラスタ定義ファイル は同一である必要があります。起動前に、各ノードのクラスタ定義ファイルを同一にしておいてください。
  • 同様に、各ノードの ユーザ定義ファイル も同一である必要があります。

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/storeMemoryLimitstring利用可能なメモリサイズ

以下のコマンドを実行します。

  • 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 -u admin/admin -w
...
$ 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":false,
                "concurrency":4,
                "logWriteMode":1,
                "persistencyMode":"NORMAL",
      :
      :
}
$ gs_backup -u admin/admin 20130301_backup        # バックアップの実行
...

この結果、以下のような処理が実行されます。

  1. バックアップディレクトリ(/var/lib/gridstore/backup)の下に、20130301_backup ディレクトリを作成する。
  2. チェックポイントファイル(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                        # リストア

この結果、以下のような処理が実行されます。

  1. バックアップディレクトリ( /var/lib/gridstore/backup )の下にある、20130521_backupディレクトリから、バックアップファイル群をデータディレクトリ( /var/lib/gridstore/data )にコピーする。

この例では、説明の便宜上、バックアップディレクトリは /var/lib/gridstore/backup 、データディレクトリは /var/lib/gridstore/data でしたが、実際の運用では、システムの構成に合わせて適切なディレクトリに変更してください。(その他のパラメータを参照)

リストア完了後、ノードを通常の起動と同じ手順で起動し、クラスタ参加させてください。

【コマンド実行例】

$ gs_startnode -u admin/admin -w
...
$ 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 -u admin/admin -w
$ 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 ソフトウェアを更新する

以下の手順で、ソフトウェアの更新を行います。

  1. クラスタ停止
  2. ノード停止
  3. 念のための、定義ファイル、データベースファイルとイベントログファイルの退避/コピー
  4. ソフトウェア更新
  5. ノード起動
  6. クラスタ構成

以下は、ノードが起動しているマシン上で実行する場合の実行例です。

【コマンド実行例】

$ 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-xx-server-Y.Y.Y-linux.x86_64.rpm
# rpm -Uvh griddb-xx-client-Y.Y.Y-linux.x86_64.rpm
# rpm -Uvh griddb-xx-docs-Y.Y.Y-linux.x86_64.rpm
# exit
$ gs_startnode -u admin/admin -w
$ gs_joincluster -c 設定したクラスタ名 -u admin/admin

※xx:更新対象と同じGridDBのエディション(se, ae, ve)※Y.Y.Y:更新するGridDBのバージョン

3.6 障害発生時の対応

障害の種類や対応方法の詳細については『GridDB バックアップガイド』(GridDB_BackupGuide.html)を参照ください。

3.6.1 基本の流れ

障害発生時、管理者が行う運用の流れは以下のようになります。

  1. まず、クラスタの稼動状態を確認し、離脱ノードを特定します。
  2. 離脱している障害ノードからイベントログ情報を取得します。
  3. イベントログ情報を解析し、障害の原因を確認します。
  4. 障害ノードを除去し、新しいノードと交換します

GridDBは障害が発生しても、クラスタ内でフェイルオーバーを行い、サービスを継続します。稼働しているバックアップノードが(レプリカが)存在する限り、フェイルオーバを繰り返し行います。バックアップノードがなくなった場合には、エラーとなります。

GridDBは障害発生時には以下のような動作を行います。

  1. 障害発生時、障害ノードはクラスタから自動的に離脱します。
  2. 離脱した障害ノードに代わり、既に作成されているバックアップノードへのフェイルオーバーが行われます。

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/dbPathstringデータベースファイルディレクトリ"data"
/dataStore/backupPathstringバックアップファイルディレクトリ"backup"
/dataStore/syncTempPathstring長期同期用一時ファイルディレクトリ"sync"
/dataStore/storeMemoryLimitstringメモリバッファサイズ"1024MB"
/dataStore/storeWarmStartboolean再起動時のウォームスタート(false:無効、true:有効)false
/dataStore/concurrencyint処理並列度4
/dataStore/logWriteModeintログ書き込みモード1
/dataStore/persistencyModestring永続化モード"NORMAL"
/dataStore/affinityGroupSizeintアフィニティグループ数4
/dataStore/storeComperssionModestringデータブロック圧縮モード"NO_COMPRESSION"
/checkpoint/checkpointIntervalstringチェックポイント実行間隔"60s"
/checkpoint/checkpointMemoryLimitstringチェックポイント用メモリバッファサイズ"1024MB"
/checkpoint/useParallelModebooleanチェックポイントの並列動作(false:無効、true:有効)false
/cluster/serviceAddressstringクラスタ管理のために使用する受信アドレス"127.0.0.1"
/cluster/servicePortintクラスタ管理のために使用する受信ポート10010
/sync/serviceAddressstringデータ同期に使用する受信アドレス"127.0.0.1"
/sync/servicePortintデータ同期に使用する受信ポート10020
/system/serviceAddressstring運用コマンドの接続アドレス"127.0.0.1"
/system/servicePortint運用コマンドの接続ポート10040
/system/eventLogPathstringイベントログファイルの出力ディレクトリ"log"
/transaction/serviceAddressstringトランザクション処理の受付アドレス"127.0.0.1"
/transaction/servicePortintトランザクション処理の受付ポート10001
/transaction/connectionLimitintコネクション数上限値5000
/trace/defaultstringイベントログ出力レベル"LEVEL_ERROR"
/trace/dataStorestring"LEVEL_ERROR"
/trace/collectionstring"LEVEL_ERROR"
/trace/timeSeriesstring"LEVEL_ERROR"
/trace/chunkManagerstring"LEVEL_ERROR"
/trace/objectManagerstring"LEVEL_INFO"
/trace/checkpointFilestring"LEVEL_ERROR"
/trace/checkpointServicestring"LEVEL_INFO"
/trace/logManagerstring"LEVEL_WARNING"
/trace/clusterOperationstring"LEVEL_INFO"
/trace/clusterServicestring"LEVEL_ERROR"
/trace/syncServicestring"LEVEL_ERROR"
/trace/systemServicestring"LEVEL_INFO"
/trace/transactionManagerstring"LEVEL_ERROR"
/trace/transactionServicestring"LEVEL_ERROR"
/trace/transactionTimeoutstring"LEVEL_WARNING"
/trace/sessionTimeoutstring"LEVEL_WARNING"
/trace/replicationTimeoutstring"LEVEL_WARNING"
/trace/recoveryManagerstring"LEVEL_INFO"
/trace/eventEnginestring"LEVEL_WARNING"
/trace/triggerServicestring"LEVEL_ERROR"

GridDB Advanced Edition / Vector Editionで上記に加えて利用するパラメータは以下のとおりです。

パラメータデータ型意味デフォルト
/sql/serviceAddressstringJDBC/ODBCクライアント接続用の受信アドレス"127.0.0.1"
/sql/servicePortintJDBC/ODBCクライアント接続用の受信ポート20001
/sql/storeSwapFilePathstringSQL中間ストアのスワップファイルディレクトリ"swap"
/sql/storeSwapSyncSizestringSQL中間ストアのスワップファイルのsyncおよび物理メモリキャッシュ消去を行うサイズ"1024MB"
/sql/storeMemoryLimitstringSQL中間ストアのメモリ上限"1024MB"
/sql/workMemoryLimitstringSQLワークエリアのメモリ上限"128MB"
/sql/workCacheMemorystringSQLワークエリアのメモリのキャッシュサイズ"128MB"
/sql/connectionLimitintコネクション数上限値5000
/sql/concurrencyint処理並列度5
/trace/sqlServicestringイベントログ出力レベル"LEVEL_WARNING"

4.1.2 クラスタ定義ファイル(gs_cluster.json)

パラメータデータ型意味デフォルト
/dataStore/partitionNumintパーティション数128
/dataStore/storeBlockSizestringブロックサイズ("64KB"、"1MB")"64KB"
/cluster/clusterNamestringクラスタ名""
/cluster/replicationNumintレプリカ数2
/cluster/notificationAddressstringクラスタ管理用のためのマルチキャスト用アドレス"239.0.0.1"
/cluster/notificationPortintクラスタ管理用のためのマルチキャスト用ポート20000
/cluster/notificationIntervalstringクラスタ管理用のためのマルチキャスト間隔"5s"
/cluster/heartbeatIntervalstringハートビート間隔"5s"
/cluster/loadbalanceCheckIntervalstringロードバランスチェック間隔"180s"
/cluster/notificationMemberarray固定リスト方式にする際のアドレスリスト
/cluster/notificationProvider/urlstringプロバイダ方式にする際のアドレスプロバイダのURL
/cluster/notificationProvider/updateIntervalintアドレスプロバイダからリストを取得する間隔"5s"
/sync/timeoutIntervalstring短期同期タイムアウト時間"30s"
/transaction/notificationAddressstringクライアントへのマルチキャスト用アドレス"239.0.0.1"
/transaction/notificationPortintクライアントへのマルチキャスト用ポート31999
/transaction/notificationIntervalstringクライアントへのマルチキャスト間隔"5s"
/transaction/replicationTimeoutIntervalstringレプリケーション・タイムアウト時間"10s"
/transaction/replicationModeintレプリケーション方法(0:非同期、1:準同期)0
/transaction/authenticationTimeoutIntervalstring認証タイムアウト時間"5s"

GridDB Advanced Edition / Vector Editionで上記に加えて利用するパラメータは以下のとおりです。

パラメータデータ型意味デフォルト
/sql/notificationAddressstringJDBC/ODBCクライアントへのマルチキャスト用アドレス"239.0.0.1"
/sql/notificationPortintJDBC/ODBCクライアントへのマルチキャスト用ポート41999
/sql/notificationIntervalstringJDBC/ODBCクライアントへのマルチキャスト間隔"5s"

4.2 ビルド・実行方法

プログラムのビルドおよび実行方法の例を示します。

サンプルプログラムはドキュメントパッケージ内のZIPファイルに格納されていますので、適宜解凍してください。

【GridDB NoSQLインターフェースの場合】

Javaの場合

  1. 環境変数の設定
  2. サンプルプログラムをtestディレクトリにコピー
  3. ビルド
  4. 実行
$ export CLASSPATH=${CLASSPATH}:/usr/share/java/gridstore.jar
$ mkdir test
$ cp /usr/griddb/docs/sample/program/Sample1.java test/
$ javac test/Sample1.java
$ java test/Sample1 239.0.0.1 31999 設定したクラスタ名 ユーザ名 パスワード

Cの場合

  1. 環境変数の設定
  2. サンプルプログラムをコピー
  3. ビルド
  4. 実行
$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/usr/lib64
$ cp /usr/griddb/docs/sample/program/sample2.c .
$ gcc -lgridstore -o sample2 sample2.c
$ ./sample2 239.0.0.1 31999 設定したクラスタ名 ユーザ名 パスワード

Pythonの場合

  1. サンプルプログラムをコピー
  2. 実行
$ cp /usr/griddb/docs/sample/program/sample1.py .
$ python sample1.py 239.0.0.1 31999 設定したクラスタ名 ユーザ名 パスワード

引数は、クライアントとクラスタとのインタフェースアドレス、ポート、クラスタ名、ユーザ名、パスワードの5つを指定して下さい。

【GridDB NewSQLインターフェースの場合】

  1. 環境変数の設定
  2. サンプルプログラムをtestディレクトリにコピー
  3. ビルド
  4. 実行
$ export CLASSPATH=${CLASSPATH}:/usr/share/java/gridstore-jdbc.jar
$ mkdir test
$ cp /usr/griddb/docs/sample/program/SampleJDBC.java test/
$ javac test/SampleJDBC.java
$ java test/SampleJDBC 239.0.0.1 41999 設定したクラスタ名 ユーザ名 パスワード

引数は、JDBC/ODBCクライアントへのマルチキャスト用アドレス、ポート、クラスタ名、ユーザ名、パスワードの5つを指定して下さい。

【注意点】

  • sample2が実行済みである必要があります。

【出力例】

DB Connection Start
Start
2018-03-17T01:14:30.843Z|false|100.0|
End
DB Connection Close

5 商標

  • GridDBは日本国内における東芝デジタルソリューションズ株式会社の登録商標です。
  • OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。
  • LinuxはLinus Torvaldsの商標です。
  • Red Hatは米国およびその他の国におけるRed Hat, Inc.の登録商標もしくは商標です。
  • その他製品名は、それぞれの所有者の商標または登録商標です。

Copyright (c) 2017-2018 Toshiba Digital Solutions Corporation