docs-ja

はじめに

本書の目的と構成

本書では、GridDBの機能について説明します。

本書は、GridDBを用いたシステム設計・開発を行う設計・開発者およびGridDBの運用管理を行う管理者の方を対象としています。

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

注意

GridDBとは

GridDBは、キーと複数の値からなるデータ(ロウと呼ばれる)の集合を管理する、分散NoSQL型データベースです。 データをすべてメモリに配置するインメモリデータベースとしての構成に加え、ディスク(SSDも含む)とメモリの利用を併用したハイブリッド構成も取ることができます。ハイブリッド構成を用いることで、小規模、小メモリシステムでも活用可能です。

GridDBはビッグデータソリューションで必要となる３つのV(Volume,Variety,Velocity)に加え、データの信頼性／可用性を備えています。また、自律的なノード監視と負荷バランシング機能により、クラスタ運用の省力化が実現できます。

GridDBの特徴

大容量データ(Volume)【EE限定】

システムの規模拡大とともに扱うデータの容量は増大し、大容量データを素早く処理するためにはシステムの拡張が必要になります。

システムの拡張のアプローチには、大きく分けてスケールアップ(垂直スケーラビリティ）とスケールアウト(水平スケーラビリティ）の２つのアプローチがあります。

GridDBでは、動作するノードをスケールアップしてシステム増強する方法に加え、システムに新たなノードを追加し、稼働するクラスタに組み込むスケールアウトでシステムを拡張することもできます。

GridDBは、インメモリ処理データベースとしてもスケールアウトモデルで大容量化が可能です。GridDBでは、複数ノードで構成されるクラスタ内のノードにデータを分散配置します。複数ノードのメモリを１つの大きなメモリ空間として利用することで、大規模なメモリデータベースを提供できます。

また、メモリの利用だけでなく、ディスクを併用したハイブリッド構成のデータ管理も可能であるため、単体のノードで動作させた場合も、メモリサイズを超えたデータを保持して、アクセスができます。メモリサイズに制限されない大容量化も実現できます。

インメモリ／ディスクの併用
インメモリ／ディスクの併用

スケールアウトでのシステム拡張は、オンラインで行うことができます。そのため、運用中のシステムを停止することなく、システムの成長とともに増大するデータに対応できます。

スケールアウトでシステムに追加したノードには、システムの負荷に応じて適切にデータが配置されます。GridDBが負荷バランスを最適化するため、運用管理者がデータ配置を気にする必要はありません。このような運用を自動化する仕組みが組み込まれており、運用も容易です。

スケールアウトモデル
スケールアウトモデル

さまざまなデータ(Variety)

GridDBのデータは、Key-Valueを発展させたKey-Container型のデータモデルです。コンテナというRDBのテーブルに相当する器にデータを格納します。 （コンテナをRDBのテーブルとして考えるとわかりやすいです。）

GridDBのデータアクセスでは、Key-Valueデータベース構造のため、Keyで絞り込みができるモデルが最も高速に処理できます。管理する実体に対応して、キーとなるコンテナを用意するという設計が必要です。

データモデル
データモデル

コンテナには、センサ等の時々刻々発生する時間と値のペアになった大量の時系列のデータを扱うのに適したコンテナ(時系列コンテナ）に加え、位置情報などの空間データを登録し、空間固有の演算（空間の交差）を行うこともできます。配列型のデータやBLOBなどの非定型なデータにも対応しているため、さまざまなデータを扱うことができます。

高速処理(Velocity)

GridDBには、さまざまなアーキテクチャ上の工夫が組み込まれ、高速化を実現しています。

できるだけメモリ上で処理をする

全てのデータがメモリに配置されてインメモリで動作するシステムの場合、ディスクへのアクセスのオーバヘッドをあまり気にする必要がありません。しかし、メモリ上に保持できないほどの大量のデータを処理するためには、アプリケーションがアクセスするデータを局所化して、ディスクに配置されたデータへのアクセスをできるだけ少なくする必要があります。

GridDBでは、アプリケーションからのデータアクセスを局所化するために、関連のあるデータをできるだけ同じブロックに配置する機能を提供します。データにヒント情報を与えることで、ヒントに従ったデータブロックにデータを集約し、データアクセス時のメモリ内ヒット率を高め、データアクセス時間を高速化します。アプリケーションでのアクセス頻度やアクセスパターンに応じて、メモリ集約のヒントを設定することで、限られたメモリ領域を有効活用して動作させることができます（アフィニティ機能）。

オーバヘッドを減らす

データベースに対して並列にアクセスする時のロックやラッチなどによる、データベースの実行処理待ちとなる時間をできるだけ少なくするために、GridDBでは、CPUコア・スレッドごとに占有するメモリとデータベースファイルを割り当て、排他、同期処理の待ちをなくしています。

アーキテクチャ
アーキテクチャ

また、GridDBでは、クライアントライブラリ側で初回アクセス時にデータ配置をキャッシュすることで、クライアントとノード間は直接アクセス可能です。データ配置やクラスタの動作状況を管理するマスタノードを介さず、直接目的とするデータにアクセスできるので、マスタノードへのアクセス集中や、通信コストを大幅に削減できます。

クライアントからのアクセス
クライアントからのアクセス

並列に処理をする

GridDBでは、1つの巨大なデータを複数ノードに分散配置（パーティショニング）したノード間、およびノード内での並列処理と、少ないリソースで多くの要求を処理できるイベント駆動エンジンで、高速化を実現しています。

信頼性／可用性【EE限定】

クラスタ内ではデータを複製して、複数のノード上にデータ(レプリカ)を多重配置しています。レプリカの中で、マスタのデータをオーナ、複製したデータをバックアップと呼びます。クラスタを構成するいずれかのノードに障害が発生した場合でも、レプリカを使用することで処理を継続できます。ノード障害発生後のデータ再配置もシステムが自動的に行うため(自律的データ配置）、特別な運用操作は不要です。障害対象のノードに配置されていたデータはレプリカから復旧され、自動的に設定されたレプリカ数となるようにデータは再配置されます。

レプリカは、可用性の要求に応じて2重化、3重化など多重度の設定ができます。

各ノードはディスクを使用してデータ更新情報の永続化を行っています。クラスタシステムに障害が発生しても、ディスクに問題がなければ、それまで登録・更新したデータを失わずに復元することができます。

また、クライアントでもデータ配置管理情報のキャッシュを保有しているため、ノードの障害を検知すると自動的にフェイルオーバーし、レプリカを用いたデータアクセスを継続できます。

高可用性
高可用性

GridDBの製品

GridDBには、以下の製品があります。

上記製品はGridDBの特徴で説明した特徴で説明した特徴に加え、 以下の2つの特徴を持ちます。

製品構成
製品構成

各インターフェースの特徴は以下のとおりです。

GridDBでは、NoSQL I/FとNewSQL I/Fの両方を用途によって使い分けることができます。

製品位置づけ
製品位置づけ

同一メジャーバージョン内(マイナーバージョンアップ時)では、GridDBのデータベースおよびNoSQL/NewSQLインターフェースの互換性があります。 バージョンの表記は、以下の通りです。

NoSQL I/FとNewSQL I/Fを併用する場合は以下の仕様をあらかじめ理解してください。

用語一覧

GridDBで利用する用語を一覧で解説します。

用語 意味
ノード GridDBでデータ管理を行う個々のサーバプロセスを指します。
クラスタ 一体となってデータ管理を行う、1つ、もしくは複数のノードの集合を指します。
マスタノード クラスタ管理処理を行うノードです。
フォロワノード クラスタに参加している、マスタノード以外のノードです。
構成ノード数 GridDBクラスタを構成するノード数を指定します。GridDBが初回に起動する際に、クラスタが成立する閾値として用いられます。（構成ノード数のノードがクラスタに参加することでクラスタサービスが開始されます。）
有効ノード数 GridDBクラスタを構成するノードの内、クラスタに組み込まれた稼働中のノードの数です。
ブロック ブロックとは、ディスクへのデータ永続化処理（以降、チェックポイントと呼びます）のデータ単位であり、GridDBの物理的なデータ管理の最小単位です。ブロックには複数のコンテナのデータが配置されます。ブロックサイズは、GridDBの初期起動前に定義ファイル（クラスタ定義ファイル）で設定します。
パーティション コンテナを配置するデータ管理の単位で、データをディスクに永続化する際のファイルシステム上のデータファイルに相当します。1つのパーティションに１つのデータファイルが対応します。また、クラスタ間でのデータ配置の最小単位であり、ノード間の負荷バランスを調整するため(リバランス）や、障害発生時のデータ多重化（レプリカ）管理のためのデータ移動や複製の単位です。
ロウ コンテナ(テーブル)に登録される1行のデータを指します。コンテナ(テーブル)には複数のロウが登録されます。ロウは、コンテナ(テーブル)のスキーマ定義に対応したカラムの値から構成されます。
コンテナ(テーブル) ロウの集合を管理する入れ物です。NoSQL I/Fで操作する場合はコンテナ、NewSQL I/Fで操作する場合はテーブルと呼ぶ場合があります。呼び方が異なるだけで、実体は同じオブジェクトです。コンテナには、コレクションと時系列コンテナの２種類のデータタイプが存在します。
コレクション(テーブル) 一般の型のキーを持つロウを管理するコンテナ(テーブル)の１種です。
時系列コンテナ(時系列テーブル) 時刻型のキーを持つロウを管理するコンテナ(テーブル)の１種です。時系列のデータを扱う専用の機能を持ちます。
データベースファイル クラスタを構成するノードの保有するデータをディスクやSSDに書き込み、永続化したファイル群です。データベースファイルは、データファイル、チェックポイントログファイル、トランザクションログファイルの総称です。
データファイル パーティションのデータが書き込まれたファイルです。 ノード定義ファイルのサイクル（/checkpoint/checkpointInterval）でメモリ上の更新情報が反映されます。
チェックポイントログファイル パーティションのブロック管理情報を格納するファイルです。ノード定義ファイルのサイクル（/checkpoint/checkpointInterval）で、ブロック管理情報の書き込みを分割で行います。
トランザクションログファイル トランザクションの更新情報がログとして逐次保存されるファイルです。
LSN（Log Sequence Number) パーティションごとに割り当てられる、トランザクションでの更新時の更新ログシーケンス番号です。クラスタ構成のマスタノードは、各ノードが保持している全パーティションのLSNのうちの最大数（MAXLSN)を保持しています。
レプリカ 複数のノードにパーティションを多重化配置することを指します。レプリカには更新されるマスタデータであるオーナと参照に利用されるバックアップがあります。
オーナノード パーティション内のコンテナに対して更新操作ができるノードです。複製されたコンテナのうち、マスタとなるコンテナを記録しているノードです。
バックアップノード 複製されたコンテナのうち、バックアップのためのデータを記録しているノードです。
定義ファイル クラスタを構成する際のパラメータファイル（gs_cluster.json：以降クラスタ定義ファイルと呼ぶ）とクラスタ内でのノードの動作やリソースを設定するパラメータファイル（gs_node.json：以降ノード定義ファイルと呼ぶ）の２つがあります。また、GridDBの管理ユーザのユーザ定義ファイルもあります。
イベントログファイル GridDBサーバのイベントログが保管されるファイルです。エラーや警告などのメッセージが含まれます。
監査ログファイル GridDBサーバの監査ログが保管されるファイルです。
OSユーザ（gsadm) GridDBの運用機能を実行できる権限を持つユーザです。GridDBインストール時にgsadmというOSのユーザが作成されます。
管理ユーザ GridDBの運用操作を行うために用意されたGridDBのユーザです。
一般ユーザ アプリケーションシステムで利用するユーザです。
ユーザ定義ファイル 管理ユーザが登録されるファイルです。初期インストールではsystem,adminの２つの管理ユーザが登録されています。
クラスタデータベース GridDBのクラスタシステムでアクセスできるデータベース全体を総称します。
データベース クラスタデータベースに作成される、論理的なデータ管理の単位です。クラスタデータベース内にデフォルトではpublicというデータベースが作成されています。新規にデータベースを作成し、一般ユーザに利用権限をあたえることで、ユーザ毎のデータ分離が実現できます。
フルバックアップ 現在利用中のクラスタデータベースをノード定義ファイルで指定したバックアップディレクトリにオンラインでバックアップします。
差分・増分バックアップ 現在利用中のクラスタデータベースをノード定義ファイルで指定したバックアップディレクトリにオンラインでバックアップし、以降のバックアップでは、バックアップ後の更新ブロックの差分増分のみをバックアップします。
自動ログバックアップ 現在利用中のクラスタデータベースをオンラインで指定したディレクトリにバックアップするとともに、トランザクションログファイルの書き込みと同じタイミングでトランザクションログも自動で採取します。トランザクションログファイルの書き込みタイミングは、ノード定義ファイルの/dataStore/logWriteModeの値に従います。
フェイルオーバ― 稼働中のクラスタに障害が発生した際に、バックアップノードがその機能を自動的に引き継ぎ、処理を続行する仕組みです。
クライアントフェイルオーバー 稼働中のクラスタに障害が発生した際、クライアント側のAPIで障害時のリトライ処理としてバックアップノードに自動的に接続し直し、処理を続行する仕組みです。
テーブルパーティショニング データ登録数が多い巨大なテーブルのデータを複数のノードに分散配置することで、複数ノードのメモリを有効に利用し、かつ複数ノードのプロセッサの並列実行を可能とし、巨大テーブルのアクセスを高速化するための機能です。
データパーティション テーブルパーティショニングによって分割されたデータを格納する入れ物を総称します。テーブルパーティショニングされた1つのテーブルに対して、データパーティションは複数作成されます。データパーティションは、通常のコンテナと同様に各ノードに分散配置されます。データパーティションの数や格納するデータの範囲は、テーブルパーティショニングの種類(ハッシュ、インターバル、インターバル-ハッシュ)によって異なります。
データアフィニティ 関連の強いコンテナのデータを同じブロックに配置し、データアクセスの局所化を図ることでメモリヒット率を高めるための機能です。
ノードアフィニティ 関連の強いコンテナを同じノードに配置し、データアクセス時のネットワーク負荷を減少させるための機能です。

GridDBの仕組み

GridDBのクラスタ動作の仕組みについて説明します。

クラスタの構成

GridDBは複数ノードで構成されるクラスタで動作します。アプリケーションシステムからデータベースにアクセスするにはノードが起動されており、かつクラスタが構成(クラスタサービスが実行)されている必要があります。

クラスタは、ユーザが指定した構成ノード数のノードがクラスタへ参加することで構成され、クラスタサービスが開始されます。構成ノード数のノードがクラスタに参加するまでクラスタサービスは開始されず、アプリケーションからはアクセスできません。

ノード1台で動作させる場合にも、クラスタを構成する必要があります。この場合構成ノード数を1台でクラスタを構成することになります。ノード1台で動作させる構成をシングル構成と呼びます。

クラスタ名と構成ノード数
クラスタ名と構成ノード数

ネットワーク上にあるGridDBの多数のノードを用いて、正しく（意図したノードを用いて）クラスタが構成できるよう、クラスタ名を使って複数のクラスタを区別します。これにより、同じネットワーク上に複数のGridDBクラスタが構成できます。 クラスタは、クラスタ名、構成ノード数、接続方式の設定が等しいノードで構成されます。クラスタ名は、クラスタを構成するノード毎に保有するクラスタ定義ファイルに設定するとともに、クラスタ構成する際のパラメータでも指定します。

マルチキャストを用いてクラスタを構成する方式をマルチキャスト方式と呼びます。クラスタ構成方式については、クラスタ構成の検討を参照してください。

以下にクラスタ構成の操作の流れを示します。

クラスタ構成の動作
クラスタ構成の動作

ノードの起動、クラスタの構成には、運用コマンドのgs_startnode/gs_joinclusterコマンドやgs_shを用います。また、OS起動と同時にノードを起動し、クラスタを構成するサービス制御機能もあります。

クラスタを構成するには、クラスタに参加させるノードの数（構成ノード数）とクラスタ名をすべての参加ノードで一致させる必要があります。

クラスタサービスは、クラスタでの運用開始後に構成するノードに障害がありクラスタからノードが切り離された場合でも、過半数のノードが参加している限りサービスは継続します。

過半数以上のノードさえ動作していればクラスタ運用は継続できるので、クラスタ運用中にメンテナンス等のために、オンラインでノード切り離したり、メンテナンス完了後にノードを組込む操作ができます。さらには、システムを増強するためにノードを追加することもオンラインでできます。

ノードのステータス

ノードには、ノードの状態を表す複数の種類のステータスがあります。ユーザのコマンド実行やノードの内部処理によってステータスが遷移します。クラスタのステータスは、クラスタに属する複数のノードのノードステータスによって決まります。

ノードステータスの種類と遷移、確認方法を説明します。

クラスタのステータス

クラスタの稼働ステータスは各ノードの状態で決まり、そのステータスには稼働／中断／停止の3つの種類があります。

クラスタのサービスは、システムの初回構築時においては、ユーザが指定したクラスタ構成するノード数（構成ノード数）のノードがすべてクラスタに参加した時点で開始されます。

初回のクラスタ構築時、クラスタを構成するノードがすべてクラスタに組み入れられておらず、クラスタ構成待ちの状態が【INIT_WAIT】状態です。構成ノード数のノードがクラスタに参加完了した時点で状態は自動遷移し稼働状態となります。

稼働状態には【STABLE】と【UNSTABLE】の2つの状態があります。

メンテナンスなどでノードをクラスタより切り離しても、構成ノード数の過半数が動作している限りクラスタは【UNSTABLE】状態で運用できます。

クラスタを構成するノードが、構成ノード数の半数以下となった場合、スプリットブレイン発生を防ぐためにクラスタは自動的にサービスを中断します。クラスタのステータスは【WAIT】状態となります。

【WAIT】状態からクラスタサービスを再開するには、エラーの回復したノードや新規のノードをノード追加操作でクラスタへ追加していきます。 再び構成ノード数のノードがクラスタに参加完了した時点で状態は【STABLE】状態となり、サービスが再開されます。

ノードの障害等でクラスタを構成するノード数が半数以下となり、クラスタのサービスが中断した場合でも、ノード追加操作でエラーの回復したノードや新規のノードをクラスタへ追加していき過半数のノードがクラスタに参加した時点で自動的にクラスタのサービスは再開されます。

クラスタステータス
クラスタステータス

STABLE状態はgs_statの示すjsonのパラメータである、/cluster/activeCountと/cluster/designatedCountの値が等しい状態です。（出力される内容はバージョンによって異なります。）

$ gs_stat -u admin/admin
{
    "checkpoint": {
　　　　　：
　　　　　：
    },
    "cluster": {
        "activeCount":4,　　　　　　　　　　　 ★ クラスタ内で稼働中のノード
        "clusterName": "test-cluster",
        "clusterStatus": "MASTER",
        "designatedCount": 4,                  ★ 構成ノード数
        "loadBalancer": "ACTIVE",
        "master": {
            "address": "192.168.0.1",
            "port": 10040
        },
        "nodeList": [　　　　　　　　　　　　　★　クラスタを構成するマシンリスト
            {
                "address": "192.168.0.1",
                "port": 10040
            },
            {
                "address": "192.168.0.2",
                "port": 10040
            },
            {
                "address": "192.168.0.3",
                "port": 10040
            },
            {
                "address": "192.168.0.4",
                "port": 10040
            },

        ],
        ：
        ：

クラスタのステータスは、gs_shやgs_adminで確認できます。以下にgs_shでのクラスタステータスの確認例を示します。

$ gs_sh
gs> setuser admin admin gsadm                  //接続ユーザの設定
gs> setnode node1 192.168.0.1 10040            //クラスタを構成するノードの定義
gs> setnode node2 192.168.0.2 10040
gs> setnode node3 192.168.0.3 10040
gs> setnode node4 192.168.0.4 10040
gs> setcluster cluster1 test150 239.0.0.5 31999 $node1 $node2 $node3 $node4 　//クラスタの定義
gs> startnode $cluster1                        //クラスタを構成する全ノードの起動
gs> startcluster $cluster1                     //クラスタ構成を指示
クラスタの開始を待っています。
クラスタが開始しました。
gs> configcluster  $cluster1                      ★クラスタのステータスを確認
Name                  : cluster1
ClusterName           : test-cluster
Designated Node Count : 4
Active Node Count     : 4
ClusterStatus         : SERVICE_STABLE　　　　　　★安定状態

Nodes:
  Name    Role Host:Port              Status
-------------------------------------------------
  node1     M  192.168.0.1:10040    SERVICING
  node2     F  192.168.0.2:10040    SERVICING
  node3     F  192.168.0.3:10040    SERVICING
  node4     F  192.168.0.4:10040    SERVICING

gs> leavecluster $node2
ノードがクラスタから離脱するのを待っています。
ノードがクラスタから離脱しました。
gs> configcluster  $cluster1
Name                  : cluster1
ClusterName           : test150
Designated Node Count : 4
Active Node Count     : 3
ClusterStatus         : SERVICE_UNSTABLE　　　　　★不安定な状態

Nodes:
  Name    Role Host:Port              Status
-------------------------------------------------
  node1     M  192.168.0.1:10040    SERVICING　　　　//マスタノード
  node2     -  192.168.0.2:10040    STARTED　　　　　
  node3     F  192.168.0.3:10040    SERVICING　　　　//フォロワノード
  node4     F  192.168.0.4:10040    SERVICING　　　　//フォロワノード

パーティションのステータス

パーティションステータスは、クラスタ上のパーティション全体の状態を表します。 クラスタステータスが稼働状態の時に、パーティションにアクセスできる状態か、パーティションに偏りが無いかなどを表すステータスです。

パーティションステータス 説明
NORMAL すべてのパーティションがデータ配置目標と同一の正常な状態
NOT_BALANCE レプリカロスやオーナロスは発生していないが、パーティションの配置が偏っている状態
REPLICA_LOSS レプリカのデータが欠損しているパーティションが存在する状態
（該当パーティションの可用性が落ちている・ノード離脱できない）
OWNER_LOSS オーナのデータが欠損しているパーティションが存在する状態
（該当パーティションのデータにはアクセスできない）
INITIAL クラスタ構成に参加していない初期状態

パーティションステータスは、マスタノードへのgs_statコマンドの実行で確認できます。（/cluster/partitionStatusの値）

$ gs_stat -u admin/admin
{
　　：
　　：
"cluster": {
    ：
    "nodeStatus": "ACTIVE",
    "notificationMode": "MULTICAST",
    "partitionStatus": "NORMAL",
    ：

[メモ]

クラスタ構成の検討

クラスタ構成を行う際には以下の検討が必要となります。

クラスタ構成方式

クラスタ構成方式とは、クラスタを構成するノード間、およびクラスタとクライアント間の通信において、それぞれのアドレスリストを認識して通信を行うための構成方式であり、以下の3つが提供されます。

クラスタ構成方式2

クラスタ構成方式の比較は以下のとおりです。

項目 マルチキャスト方式 固定リスト方式 プロバイダ方式
設定 ・マルチキャストアドレス、ポート ・全ノードのIPアドレス、ポート番号のリスト ・プロバイダURL
利用ケース ・マルチキャストが利用できる。 ・マルチキャストが利用できない。
・正確にシステム規模の見積りが行える		 ・マルチキャストが利用できない。
・システム規模が見積もれない。
クラスタ動作 ・一定時間間隔でノードの自動ディスカバリを行う。 ・全ノードに同一のアドレスリストを設定する。
・ノード起動時に1度だけそのリストを読み込む。		 ・アドレスプロバイダから一定時間間隔でアドレスリストを取得する。
メリット ・ノード追加のためのクラスタ再起動不要。 ・リストの整合性チェックが行われるため、間違いが無い。
現在のクラスタ構成ノードの把握が容易。		 ・ノード追加のためのクラスタ再起動不要。
デメリット ・クラウド環境でマルチキャスト利用不可の場合が多い。
セグメントを超えた通信が行えない。		 ・ノード追加にクラスタ再起動が必要。
・アプリ側の接続設定の更新も必要。		 ・アドレスプロバイダの可用性確保が必要。

複数通信経路

GridDBクラスタはクライアントに対する複数の通信経路を設定することができます。デフォルトのクラスタ-クライアント間の通信経路は、クラスタノード間の通信経路と共通のものとなりますが、複数通信経路設定を行うと、これとは別の通信経路を用いた接続が可能となります。この通信経路を外部通信経路と呼びます。 クライアントはどちらの通信経路を利用するかを個別に指定することが可能となります。

複数通信経路

このような複数通信経路を用いたネットワーク構成は以下のような場合に用いられます。

ラックゾーンアウェアネス

GridDBは、ラックやアベイラビリティゾーンなどの物理的な構成グループ単位の障害が発生した場合の可用性を向上させる、ラックゾーンアウェアネス機能を提供します。 あるデータのオーナとバックアップがともに同じ構成グループに配置されていると、そのグループに障害が発生した場合にはそのデータへのアクセスができなくなります。 ラックゾーンアウェアネス機能を利用すると、クラスタのノードが属するグループを事前に定義しておくことができ、GridDBは、その定義を参照し、オーナとバックアップを別グループに配置するように制御します。 これにより、あるグループに障害が発生した場合でも、別のグループにデータのバックアップがあるため、データへのアクセスが可能になります。 また、この際、オーナとバックアップが各グループ、各ノードにできるだけ均等に配置されるような割り当てが行われます。

ラックゾーンアウェネス機能は、ラックやアベイラビリティゾーンなどの構成グループを利用できる場合に、効果的に可用性を高める機能です。 一般的に可用性を向上させるにはレプリカ数を多く設定する必要がありますが、レプリカ数を増やすとトランザクション性能が劣化するトレードオフ関係が発生します。 ラックゾーンアウェアネス機能はグループ単位での障害に備えて配置を優先して計算します。 そのため、構成グループを利用できる場合には、レプリカ数を抑えつつ(トランザクション性能を維持しつつ)可用性を向上することができます。 この機能を利用するには、設定ファイルにラックゾーンに関する設定を行う必要があります。これ以外の特別な運用操作は必要ありません。

ノード数=6, グループ数＝3，パーティション数=6, レプリカ数=2でクラスタを構成した場合のデータ配置の違いを説明します。 （下図ではクラウドのアベイラビリティゾーン(AZ)を使用した例を示しています。） 下図の左側がラックゾーンアウェネス機能を利用した場合、右側がラックゾーンアウェネス機能を利用しない通常のデータ配置です。

ラックゾーン1

右側のラックゾーンアウェアネス機能なしの場合、データのオーナとバックアップが同一AZ内に配置されることがありえます。 例えば、AZ1のGridDB2には、クラスタパーティション4のデータのオーナ(青)が配置されています。 同時に、このクラスタパーティション4のデータのバックアップ(橙)は、同じAZ1のGridDB1に配置されています。 このようなデータ配置では、AZ1に障害が発生した場合、このクラスタパーティション4のデータにアクセスできなくなります。 一方、左側のラックゾーンアウェアネス機能ありの場合は、このような配置にならないことを保証します。 例えば、クラスタパーティション4のデータのオーナ(青)はAZ1に配置されています。 同時に、このデータのバックアップ(橙)は、AZ1とは別のAZ2に配置されています。他のクラスタパーティションのデータについても同様です。

このように、ラックゾーンアウェアネス機能は、全てのクラスタパーティションデータのオーナとバックアップを別々のAZに配置することで、 どのAZに障害が発生したとしても、全てのクラスタパーティションのデータにアクセスできるようにします。 ただし、同一ラックゾーンに対する配置を抑制するため、各ノードのオーナ、バックアップの割当て個数には若干偏りが生じる場合があります。 また、障害発生からクラスタ安定状態（データ同期処理が発生する時間）になるまでの時間も若干増加する傾向がありますが、 GridDBではこれらデータ偏りや安定状態までの時間をできるだけラックゾーンアウェアネス無の場合と大きな違いがないように最適化します。

【メモ】 ラックゾーンアウェアネス機能はクラスタパーティションの割付規則を決定する機能であり、同様の機能を持つ、6.11.1 生成規則の指定と6.11.2 配置表の固定化指定と併用利用することができません。用途に応じていずれかを使い分けるようにしてください。

設定方法

クラスタ構成方法

　クラスタ構成方法として、マルチキャスト方式、固定リスト方式、プロバイダ方式の3つの方式があり、これらをクラスタを構成するノード間、クラスタとクライアント間の個別に設定することになりますが、以下は前者の設定のみを記載します。後者の設定は、各種クライアントのAPIリファレンスを参照してください。

マルチキャスト方式

　マルチキャストアドレスを与えてノードを起動することで、マルチキャストを利用したクラスタを構成します。マルチキャストはクラスタ、トランザクション、SQLの3つのサービスに対して定義しますが、クラスタサービスとしてマルチキャストを選択した場合は、トランザクション、SQLサービスも必ずマルチキャスト方式にする必要があります。

　マルチキャスト方式でクラスタを構成する場合は、クラスタ定義ファイルのパラメータを設定します。

クラスタ定義ファイル

| パラメータ | データ型 | 意味 | |—————————–|———-|————————————————————————–| | /cluster/notificationAddress | string | クラスタ構成に必要なマルチキャストのIPアドレスを指定します。 | | /cluster/notificationPort | int | クラスタ構成に必要なマルチキャストのポート番号を指定します。 | | /transaction/notificationAddress | string | クライアントとのトランザクション処理に必要なマルチキャストのIPアドレスを指定します。 | | /transaction/notificationPort | int | クライアントとのトランザクション処理に必要なマルチキャストのポート番号を指定します。 | | /sql/notificationAddress | string | クライアントとのSQL処理に必要なマルチキャストのIPアドレスを指定します。 | | /sql/notificationPort | int | クライアントとのSQL処理に必要なマルチキャストのポート番号を指定します。 | 　

　マルチキャストが利用できない場合は固定リスト、もしくはプロバイダ方式を利用して下さい。

{
                             :
                             :
    "cluster":{
        "clusterName":"yourClusterName",
        "replicationNum":2,
        "heartbeatInterval":"5s",
        "loadbalanceCheckInterval":"180s",
        "notificationAddress":"239.0.0.1",
    		"notificationPort":20000        
    },
    "transaction":{
      "notificationAddress":"239.0.0.1",
  		"notificationPort":31999
    },
    "sql":{
      "notificationAddress":"239.0.0.1",
  		"notificationPort":41999
    }
    :
    :    
}
固定リスト方式

固定のアドレスリストを与えてノードを起動することで、そのリストを利用してクラスタを構成します。

固定リスト方式でクラスタを構成する場合は、クラスタ定義ファイルのパラメータを設定します。

クラスタ定義ファイル

パラメータ データ型 意味
/cluster/notificationMember string クラスタ構成方式を固定リスト方式にする際に、アドレスリストを指定します。

/cluster/notificationMemberの要素は各サービスごとに以下を記述します。 “サービス名”:{“address”}:”IPアドレス”,”port”:ポート番号

/cluster/notificationMember中の要素は以下の通りとなります。 複数接続経路を用いる場合、 transactionPublicおよびsqlPublicの項目を追加して、それぞれの外部接続用IPアドレス、ポート番号を記述します。 これらIPアドレスはノード起動時にノード定義ファイルで設定するtransaction/sqlのpublicServiceAddressと同じにする必要があります。また、ポート番号はtransaction/sqlのservicePortと同じにする必要があります。

パラメータ データ型 意味
/cluster/address string クラスタサービス通信用のIPアドレスを指定します。
/cluster/port int 上記のポート番号を指定します。
/sync/address string シンクサービス通信用のIPアドレスを指定します。
/sync/port int 上記のポート番号を指定します。
/system/address string システムサービス通信用のIPアドレスを指定します。
/system/port int 上記のポート番号を指定します。
/transaction/address string デフォルト通信経路となるトランザクションサービス通信用のIPアドレスを指定します。
/transaction/port int 上記のポート番号を指定します。
/sql/address string デフォルト通信経路となるSQLサービス通信用のIPアドレスを指定します。
/sql/port int 上記のポート番号を指定します。
/transactionPublic/address string 外部通信経路となるトランザクションサービス通信用のIPアドレスを指定します。
/transactionPublic/port int 上記のポート番号を指定します。
/sqlPublic/address string 外部通信経路となるSQLサービス通信用のIPアドレスを指定します。
/sqlPublic/port int 上記のポート番号を指定します。

デフォルトの通信経路を用いる場合のクラスタ定義ファイルの設定例は以下のとおりです。

{
                             :
                             :
    "cluster":{
        "clusterName":"yourClusterName",
        "replicationNum":2,
        "heartbeatInterval":"5s",
        "loadbalanceCheckInterval":"180s",
        "notificationMember": [
            {
                "cluster": {"address":"172.17.0.44", "port":10010},
                "sync": {"address":"172.17.0.44", "port":10020},
                "system": {"address":"172.17.0.44", "port":10040},
                "transaction": {"address":"172.17.0.44", "port":10001},
                "sql": {"address":"172.17.0.44", "port":20001}
            },
            {
                "cluster": {"address":"172.17.0.45", "port":10010},
                "sync": {"address":"172.17.0.45", "port":10020},
                "system": {"address":"172.17.0.45", "port":10040},
                "transaction": {"address":"172.17.0.45", "port":10001},
                "sql": {"address":"172.17.0.45", "port":20001}
            },
            {
                "cluster": {"address":"172.17.0.46", "port":10010},
                "sync": {"address":"172.17.0.46", "port":10020},
                "system": {"address":"172.17.0.46", "port":10040},
                "transaction": {"address":"172.17.0.46", "port":10001},
                "sql": {"address":"172.17.0.46", "port":20001}
            }
        ]
    },
                             :
                             :
}
プロバイダ方式【EE限定】

アドレスプロバイダが提供するアドレスリストを取得してクラスタ構成を行います。

プロバイダ方式でクラスタを構成する場合は、クラスタ定義ファイルのパラメータを設定します。

クラスタ定義ファイル

パラメータ データ型 意味
/cluster/notificationProvider/url string クラスタ構成方式をプロバイダ方式にする際に、アドレスプロバイダのURLを指定します。
/cluster/notificationProvider/updateInterval string アドレスプロバイダからリストを取得する間隔を指定します。1s以上、231s未満の値を指定します。

プロバイダが返却するノードリストの書式は固定リストの規則と同じになります。

クラスタ定義ファイルの設定例は以下のとおりです。

{
                             :
                             :
    "cluster":{
        "clusterName":"yourClusterName",
        "replicationNum":2,
        "heartbeatInterval":"5s",
        "loadbalanceCheckInterval":"180s",
        "notificationProvider":{
            "url":"http://example.com/notification/provider",
            "updateInterval":"30s"
        }
    },
                             :
                             :
}

アドレスプロバイダはWebサービスとして構成するか、静的コンテンツとして構成することができます。 アドレスプロバイダは以下の仕様を満たす必要があります。

アドレスプロバイダからのレスポンスの例は以下のとおりです。複数通信経路を設定した場合は、transactionPublicおよびsqlPublicの記載も必要となります。

$ curl http://example.com/notification/provider
[
    {
        "cluster": {"address":"172.17.0.44", "port":10010},
        "sync": {"address":"172.17.0.44", "port":10020},
        "system": {"address":"172.17.0.44", "port":10040},
        "transaction": {"address":"172.17.0.44", "port":10001},
        "sql": {"address":"172.17.0.44", "port":20001}
    },
    {
        "cluster": {"address":"172.17.0.45", "port":10010},
        "sync": {"address":"172.17.0.45", "port":10020},
        "system": {"address":"172.17.0.45", "port":10040},
        "transaction": {"address":"172.17.0.45", "port":10001},
        "sql": {"address":"172.17.0.45", "port":20001}
    },
    {
        "cluster": {"address":"172.17.0.46", "port":10010},
        "sync": {"address":"172.17.0.46", "port":10020},
        "system": {"address":"172.17.0.46", "port":10040},
        "transaction": {"address":"172.17.0.46", "port":10001},
        "sql": {"address":"172.17.0.46", "port":20001}
    }
]

【メモ】

複数通信経路

　GridDBクラスタにおいて複数通信経路を有効にするには、クラスタを構成する各ノードにおけるノード定義ファイルで外部通信経路のIPアドレスを指定してクラスタを構成します。ポート番号はservicePortに記載した値と共通のものになるため新たな記載は必要ありません。

ノード定義ファイル

パラメータ データ型 意味
/transaction/publicServiceAddress string トランザクションサービス外部通信経路に対応するIPアドレスを指定します。
/sql/publicServiceAddress string SQLサービス外部通信経路に対応するIPアドレスを指定します。

ノード定義ファイルの設定例は以下のとおりです。

{
                             :
                             :

    "transaction":{
        "serviceAddress":"172.17.0.44",
        "publicServiceAddress":"10.45.1.10",        
        "servicePort":10001
    },      
    "sql":{
      "serviceAddress":"172.17.0.44",
      "publicServiceAddress":"10.45.1.10",      
      "servicePort":20001
    },
    :
    :

複数通信経路を有効にする場合のノードリストのサンプルは以下になります。

{
                             :
                             :
    "cluster":{
        "clusterName":"yourClusterName",
        "replicationNum":2,
        "heartbeatInterval":"5s",
        "loadbalanceCheckInterval":"180s",
        "notificationMember": [
            {
                "cluster": {"address":"172.17.0.44", "port":10010},
                "sync": {"address":"172.17.0.44", "port":10020},
                "system": {"address":"172.17.0.44", "port":10040},
                "transaction": {"address":"172.17.0.44", "port":10001},
                "sql": {"address":"172.17.0.44", "port":20001},
                "transactionPublic": {"address":"10.45.1.10", "port":10001},
                "sqlPublic": {"address":"10.45.1.10", "port":20001}
            },
            {
                "cluster": {"address":"172.17.0.45", "port":10010},
                "sync": {"address":"172.17.0.45", "port":10020},
                "system": {"address":"172.17.0.45", "port":10040},
                "transaction": {"address":"172.17.0.45", "port":10001},
                "sql": {"address":"172.17.0.45", "port":20001},
                "transactionPublic": {"address":"10.45.1.11", "port":10001},
                "sqlPublic": {"address":"10.45.1.11", "port":20001}
            },
            {
                "cluster": {"address":"172.17.0.46", "port":10010},
                "sync": {"address":"172.17.0.46", "port":10020},
                "system": {"address":"172.17.0.46", "port":10040},
                "transaction": {"address":"172.17.0.46", "port":10001},
                "sql": {"address":"172.17.0.46", "port":20001},
                "transactionPublic": {"address":"10.45.1.12", "port":10001},
                "sqlPublic": {"address":"10.45.1.12", "port":20001}
            }
        ]
    },
                             :
                             :
}

ラックゾーンアウェアネス

クラスタ定義ファイル

パラメータ データ型 意味
/cluster/rackZoneAwareness bool ラックゾーンアウェイアウェアネス機能を利用したデータ配置戦略を行うかどうかを指定します。利用する場合はtrueとしてrackZoneIdを必ず指定してください。
/cluster/rackZoneId string ラックゾーンアウェアネス機能で必要となる、グルーピング単位に付与する識別子です。1以上64文字以内の英数字となります。

ノード定義ファイルの設定の例は以下の通りです。

{
                             :
                             :
    "cluster":{
        "servicePort":10010
        "rackZoneAwareness":true,
        "rackZoneId":"zone-01",
    },
                             :
                             :
}

データモデル

GridDBは、Key-Valueに似た独自のKey-Container型データモデルです。以下の特徴があります。

データモデル
データモデル

GridDBのデータは、ブロック、コンテナ、テーブル、ロウ、パーティションという単位でデータ管理されています。

データ管理の単位
データ管理の単位

　

コンテナ

GridDBにデータを登録し、検索するには、データを格納するコンテナ(テーブル)を作成する必要があります。 NoSQL I/Fで操作する場合はコンテナ、NewSQL I/Fで操作する場合はテーブルと呼びます。

コンテナ(テーブル)もデータベースと同様の命名規則があります。

[メモ]

種別

コンテナ(テーブル)には、2つのデータタイプがあります。 時々刻々発生するデータを発生した時刻とともに管理するのに適したデータタイプである 時系列コンテナ(時系列テーブル) とさまざまなデータを管理する コレクション(テーブル) です。

データ型

コンテナ(テーブル)にはスキーマを設定できます。登録できるデータ型には、基本的なデータ型である 基本型 と 配列型 があります。

基本型

登録できる基本型のデータを説明します。基本型とは、他の型の組み合わせで表現できない、基本的な型です。

データ型 説明
BOOL型 真または偽のいずれかの値
STRING型 Unicodeコードポイントを文字とする、任意個数の文字の列より構成
BYTE型 -27から27-1 (8ビット)の整数値
SHORT型 -215から215-1 (16ビット)の整数値
INTEGER型 -231から231-1 (32ビット)の整数値
LONG型 -263から263-1 (64ビット) の整数値
FLOAT型 IEEE754で定められた単精度型(32ビット)浮動小数点数
DOUBLE型 IEEE754で定められた倍精度型(64ビット)浮動小数点数
TIMESTAMP型 年月日ならびに時分秒からなる時刻を表す型。データベースに保持されるデータ形式はUTCで、精度はミリ秒
GEOMETRY型 空間構造を表すためのデータ型
BLOB型 画像や音声などのバイナリデータのためのデータ型

STRING型､GEOMETRY型、BLOB型は管理できるデータのサイズに以下の制限があります。制限値は、GridDBの定義ファイル（gs_node.json）のデータベースの入出力単位であるブロックサイズに応じて値が異なります。

型 ブロックサイズ(64KB) ブロックサイズ (1MB～32MB)
STRING型 最大31KB (UTF-8エンコード相当) 最大128KB (UTF-8エンコード相当)
GEOMETRY型 最大31KB (内部格納形式相当) 最大128KB (内部格納形式相当)
BLOB型 最大1GB - 1Byte 最大1GB - 1Byte

GEOMETRY型(空間型)

GEOMETRY型（空間型）のデータは地図情報システムなどでよく利用されています。空間型のデータは、NoSQLインターフェースでのみ使用できます。NewSQLインターフェースでは未サポートです。

GEOMETRY型のデータは、WKT（Well-known text）を用いて記述します。WKTは、地理空間に関する情報の標準化などを推進している非営利団体OGC(Open Geospatial Consortium)にて策定されています。GridDBでは、コンテナのカラムをGEOMETRY型に設定することで、WKTで記述された空間情報をカラムに格納できます。

GEOMETRY型では以下のWKT形式をサポートします。

ただし、空間構造QUADRATICSURFACEはコンテナに登録することはできず、検索条件としてのみ使用できます。

GEOMETRY型を利用した演算は、APIやTQLで実行できます。

TQLでは2次元、3次元の空間を定義する空間生成関数と空間型データ間での演算の関数を提供します。TQLではコンテナ内のGEOMETRY型のカラムと指定した空間データで演算を行いその結果を以下のようにして得ることができます。

 SELECT * WHERE ST_MBRIntersects(geom, ST_GeomFromText('POLYGON((0 0,10 0,10 10,0 10,0 0))'))

TQLで提供する関数の詳細は『GridDB TQL リファレンス』を参照ください。

複合型

コンテナに登録できる、基本型の組み合わせで構成される型を定義します。 現バージョンでは配列型のみです。

【メモ】

配列型カラムでは、TQLでの操作に以下の制約があります。

主キー

コンテナ(テーブル)には、主キーを設定できます。主キーによって、コンテナ(テーブル)のロウの一意性を保証します。また主キーを設定したカラムには、NULL値を許容しません。

主キーは、コンテナではROWKEY(ロウキー)、テーブルではPRIMARY KEY(プライマリキー)と呼びます。

ROWKEY(PRIMARY KEY)に設定したカラムには、カラムの型に応じてあらかじめ既定された、デフォルトの索引が設定されます。

GridDBの現バージョンでは、ROWKEY(PRIMARY KEY)に指定できるSTRING、INTEGER、LONG、TIMESTAMPのすべての型のデフォルトの索引はTREE索引です。

ビュー

コンテナのデータを参照するためのビューを作成できます。

ビュー作成時に、コンテナに対する参照(SELECT文)を定義します。ビューはコンテナと似たオブジェクトですが実データを持ちません。ビューを含むクエリの実行時に、ビュー作成時に定義されたSELECT文を評価して結果を返します。

ビューは参照(SELECT)のみ可能です。ビューに対して、データの追加(INSERT)/更新(UPDATE)/削除(DELETE)を行うことはできません。

[メモ]

　　

データベース機能

リソースの管理

GridDBのクラスタを構成するリソースには、メモリ上のデータベースのほかにディスク上に永続化されるリソースがあります。 永続化リソースには、以下のものがあります。

データベースファイル群
データベースファイル群

これらのリソースは、GridDBホーム（環境変数GS_HOMEで指定されるパス)で配置を定義します。 初期インストール状態では、/var/lib/gridstoreディレクトリがGridDBホームで、このディレクトリの下に各リソースの初期データが配置されます。

初期の配置状態は以下のとおりです。

/var/lib/gridstore/        # GridDBホームディレクトリ
     admin/                # 統合運用管理機能ホームディレクトリ
     backup/               # バックアップディレクトリ
     conf/                 # 定義ファイルディレクトリ
          gs_cluster.json  # クラスタ定義ファイル
          gs_node.json     # ノード定義ファイル
          password         # ユーザ定義ファイル
     data/                 # データファイル,チェックポイントログディレクトリ
     txnlog/               # トランザクションログディレクトリ
     expimp/               # Export/Importツールディレクトリ
     log/                  # サーバイベントログ・運用ツールログディレクトリ
     audit/                # サーバ監査ログディレクトリ(監査ログ設定時のみ)

GridDBホームは、OSユーザgsadmの.bash_profileファイルの設定で変更できます。GridDBホームを変更する場合は、上記ディレクトリのリソースも適宜移動してください。

.bash_profileファイルには、環境変数GS_HOMEとGSLOGの２つの環境変数の設定がされています。

vi .bash_profile

# GridStore specific environment variables
GS_LOG=/var/lib/gridstore/log
export GS_LOG
GS_HOME=/var/lib/gridstore　　　　　　　　　　★GridDBホームの変更
export GS_HOME

データベースディレクトリやバックアップディレクトリ、サーバイベントログディレクトリ、サーバ監査ログディレクトリは、ノード定義ファイルの設定値を変更することで変更できます。

クラスタ定義ファイルやノード定義ファイルで設定できる内容に関しましてはパラメータを参照してください。

データアクセス機能

GridDBのデータにアクセスするには、NoSQLインターフェースもしくはNewSQLインターフェースを用いてアプリケーションを開発する必要があります。データアクセスでは、コンテナやテーブルがクラスタデータベースのどこに配置されているかの位置情報を意識する必要はなく、GridDBのクラスタデータベースに接続するだけでアクセスができます。コンテナがクラスタを構成するどのノードに配置されているのかをアプリケーションシステムが意識する必要はありません。

GridDBのAPIでは、クラスタデータベースへの初期接続時に、ノード情報（パーティション）とともにコンテナの配置ヒント情報をクライアント側に保持（キャッシュ）します。

アプリケーションが利用するコンテナが切り替わる度に、配置されているノードを探す処理のためクラスタにアクセスする必要はなく、コンテナを保持するノードに直に接続して処理をするため、通信のオーバヘッドを最小限としています。

GridDBではリバランス処理により、コンテナ配置は動的に変わりますが、クライアントキャッシュは定期的に更新されるため、コンテナの位置は透過です。タイミングによってクライアントからのアクセスでノードがミスヒットした時でも、自動的に再配置情報を取得して処理を継続します。

TQLとSQL

データベースのアクセス言語として、TQLとSQL-92準拠のSQLをサポートしています。

複数コンテナへの一括処理機能

GridDBが提供するNoSQL I/Fでは、時々刻々発生するイベント情報を高速に処理するためのインターフェースを用意しています。

大量に発生するイベントを発生の都度データベースサーバに送信していると、ネットワークへの負荷が高くなりシステムのスループットがあがりません。通信回線帯域が狭い場合特に顕著な影響がでます。NoSQL I/Fでは複数のコンテナに対する複数のロウの登録や、複数のコンテナへの複数の問い合わせ(TQL)を1リクエストで処理するためのマルチ処理が用意されています。頻繁にデータベースサーバにアクセスしないため、システム全体のスループットがあがります。

以下に例を挙げます。

multiput処理
multiput処理
fetchAll処理
fetchAll処理
multiget処理
multiget処理

索引機能

コンテナ(テーブル)のカラムに対し索引を作成することで、条件付き検索が高速に処理できます。

索引タイプにはツリー索引(TREE)、空間索引(SPATIAL)の2種類があります。 設定できる索引はコンテナ(テーブル)のタイプやカラムのデータ型に応じて異なります。

コンテナに作成できる索引の数に制限はありませんが、索引の作成は慎重に設計する必要があります。索引は、設定されたコンテナのロウに対して挿入、更新、または削除の各操作が実行されると更新されます。したがって、頻繁に更新されるロウのカラムに多数の索引を作成すると、挿入、更新、または削除の各操作でパフォーマンスに影響ができます。

索引は以下のようなカラムに作成します。

【メモ】

時系列データ特有の機能

GridDBでは、高頻度で発生するセンサなどのデータ管理のために、メモリを最大限有効利用するデータ配置アルゴリズム(TDPA：Time Series Data Placement Algorithm)に従いデータ配置処理します。時系列コンテナ(時系列テーブル)では、内部データを周期性で分類しながらメモリ配置します。アフィニティ機能でヒント情報を与えるとさらに配置効率が上がります。また、データを必要に応じてディスクに追い出しながら、ほぼゼロコストで有効期限切れのデータを解放しています。

時系列コンテナ(時系列テーブル)は、TIMESTAMP型のROWKEY(PRIMARY KEY)を持ちます。

TQLの演算機能

集計演算

採取したデータの時間間隔でデータに重みをつけて計算します。つまり、時間間隔が長い場合、長時間その値が続いたことを想定した計算となります。

集計演算には以下の関数があります。

重みづけの集計演算（TIME_AVG)
重みづけの集計演算（TIME_AVG)

選択・補間演算

時刻データは、収集されるデータの内容や収集タイミングにより想定した時刻より多少の時間のずれが発生することがあります。したがって時刻データをキーにして検索する際にも、指定した時刻周辺のデータが取得できる機能が必要です。

時系列コンテナ(時系列テーブル)を検索し、指定したロウを取得するための以下のような関数があります。

また、実体のロウのカラムの値を補間演算で計算するための以下のような関数があります。

期限解放機能

期限解放とは、設定した保持期間を超えたロウデータを、検索や削除などの操作対象から外して参照不可とした後、DBから物理的に削除する機能です。 利用されなくなった古いデータを操作の対象から外して削除することで、DBサイズを一定に保ち、データベースサイズ肥大化によるパフォーマンス低下を防ぐことができます。

期限解放
期限解放

保持期間はコンテナ単位に設定します。保持期間を越えたロウを「期限切れデータ」と呼びます。期限切れデータは参照不可となってAPIから操作できなくなるので、アプリケーションからはそのロウは存在しない状態になります。期限切れデータは、一定期間が経過すると、DBから物理的に削除する対象のデータになります。この削除対象となった期限切れデータを「コールドデータ」と呼びます。コールドデータは、そのまま自動的にDBから削除します。

期限解放の設定

期限解放は、パーティショニングされたコンテナ(テーブル)で利用可能です。

パーティション期限解放
パーティション期限解放

【メモ】

コールドデータの自動削除

1秒間に1回、定期的にDBファイルの管理情報をスキャンして、その時点でコールドデータになっているロウを物理的に削除します。DBファイルの管理情報をスキャンする量は1回の実行につき2000ブロック分です。スキャンする量は、ノード定義ファイル(gs_node.json)の/dataStore/batchScanNumで設定できます。登録量が多いシステムなどでは、自動削除の速度が登録に追いつかずに、DBサイズが増加し続ける可能性があります。その場合はスキャンする量を増やしてください。

テーブルパーティショニング機能

複数ノードで動作するGridDBのアプリケーションを高速化するには、処理するデータをできるだけメモリに配置することが重要です。 データ登録数が多い巨大なコンテナ（テーブル）では、テーブルのデータを分割してノードに分散配置することで、複数ノードのCPUやメモリリソースを効率的に活用した処理が可能です。分割したデータは、「データパーティション」という複数の内部コンテナに格納します。データをどのデータパーティションに格納するかは、テーブル作成時に指定された「パーティショニングキー」のカラムの値を基に決定します。

GridDBではテーブルパーティショニングの方法として、ハッシュパーティショニング、インターバルパーティショニング、インターバル-ハッシュパーティショニングの3種類があります。

テーブルの作成・削除はNewSQLインターフェースのみ、データの登録・更新・検索はNewSQL/NoSQLインターフェースで実行できます。(一部制限があります。詳細はTQLとSQLを参照ください)

テーブルパーティショニング
テーブルパーティショニング

テーブルパーティショニングの利点

テーブルパーティショニングを利用して、大規模なデータを分割することで、メモリの効率的な利用や検索の処理対象データの絞込みによる性能向上の効果があります。

上記の点について、テーブルパーティショニングを利用しない場合と利用する場合の特徴を説明します。

テーブルパーティショニングを利用せずに大規模データをひとつのテーブルに格納する場合、処理に必要なデータをすべてメモリ上に載せることができず、メモリとデータベースファイル間でのスワップイン/スワップアウトが頻繁に発生してパフォーマンスが低下します。特に大規模テーブルのデータ量よりもGridDBノードのメモリが小さい場合に低下が顕著になります。また、テーブルに対するアクセスが1ノードに集中するため、並列度が低くなります。

テーブルパーティショニングを使用しない場合
テーブルパーティショニングを使用しない場合

テーブルパーティショニングを利用した場合、大規模データを各データパーティションに分割して、複数ノードに分散配置します。

登録や検索などの処理の際には、処理に必要なデータパーティションがメモリに読み込まれます。処理対象外のデータパーティションは読み込まれないため、テーブルパーティショニングを使わない大規模テーブルと比較すると必要なデータ量は小さくなる場合が多く、メモリへのスワップイン/スワップアウトの頻度が低減します。各データパーティションにデータを偏りなく均等に分割した方が各ノードのCPUやメモリリソースを有効に活用することができます。

また、データパーティションはノードに分散配置されるため、データへの並列アクセスが可能になります。

テーブルパーティショニングを使用する場合
テーブルパーティショニングを使用する場合

ハッシュパーティショニング

ハッシュパーティショニングでは、ハッシュ値 (HASH) に基づいてテーブルパーティションに均等にデータを分割して格納します。

高い頻度でデータ登録を行うアプリケーションシステムでの利用においては、テーブルの末尾にアクセスが集中し、待ち時間が発生する場合があります。ハッシュ分割を使用すると複数のテーブルが用意されるため、アクセス分散できます。

ハッシュパーティショニング
ハッシュパーティショニング

インターバルパーティショニング

インターバルパーティショニングでは、指定された一定の値間隔でデータを分割して、データパーティションに格納します。各データパーティションに格納するデータの区間(下限値から上限値)は、指定された値間隔を基に自動的に決定します。

ある一定の範囲の値を持つデータを同じデータパーティション上に格納するので、登録するデータが連続値の場合や、特定期間の範囲の検索を行う場合などに、より少ないメモリで処理できます。

インターバルパーティショニング
インターバルパーティショニング
インターバルパーティションテーブル作成・削除の例
インターバルパーティションテーブル作成・削除の例

ユーザ指定データパーティション配置

　対象テーブルがインターバルパーティションで、パーティショニングキーがTIMESTAMP型の場合は、ユーザがデータパーティションの配置先を指定したテーブル生成を行うことができます。

　通常のテーブル生成SQLでは、データパーティションの配置先はサーバが独自の規則を用いて決定しますが、複数のインターバルパーティショニングテーブルに対して、特定の日付のデータパーティション配置先が競合する場合があります。下図はそれを示したもので、同一日時の配置先が競合により処理スレッドが競合するので、データ処理の同時実行性能が低下することがあります。

同一日時に対するデータパーティションの競合
同一日時に対するデータパーティションの競合の例

　テーブル生成時に区間グループ番号を指定することで、データパーティションの配置に規則性を設けて、グループ番号が異なるテーブル同士は同一日時において処理スレッドが競合しないような割付が行われます。以下にその例を示します。

ユーザ指定データ配置機能
テーブル生成時にユーザがデータパーティション配置先を指定する機能

注意点 　本機能を効果的に利用するには幾つか条件があり、それらを運用開始時点で検討する必要があります。

  1. クラスタを構成する全ノードの並列度を揃えておく必要があります。また、テーブル生成以降は並列度を変更すると十分な効果が得られなくなるため、開始時点の並列度を維持した運用が必要となります。

  2. 競合を回避したいテーブルの個数は基本的には並列度以下となるようにテーブルの設計を行います。これ以上の指定を行った場合は性能が劣化するケースがあります。

  3. 安定した性能を維持し続けるには、テーブル生成した時点のクラスタノード構成および各ノードのオーナ、バックアップなどのクラスタパーティション配置を運用によって維持し続ける必要があります。また、ノード増設なども変動要因になるため、できる限り固定的な環境での運用が推奨となります。

インターバル-ハッシュパーティショニング

インターバル-ハッシュパーティショニングは、インターバルパーティショニングとハッシュパーティショニングを組み合わせたものです。まずインターバルパーティショニングでデータを分割し、その分割されたデータに対して、さらにハッシュパーティショニングが行われます。 データパーティショニングの数は、インターバルパーティションニングによって分割した区間の数×ハッシュの分割数になります。

インターバル-ハッシュパーティショニング
インターバル-ハッシュパーティショニング

インターバルパーティショニングで分割したデータパーティションを、さらにハッシュによって適切にノードに分散することができます。一方で、データパーティション数が多くなることで、検索時のオーバヘッドが発生します。ノード分散と処理のオーバヘッドを考慮してご利用ください。

インターバル-ハッシュパーティショニングは、インターバルパーティショニングとハッシュパーティショニングを組み合わせたものなので、基本的な機能はそれぞれのパーティショニングの機能と同等です。インターバル-ハッシュパーティショニングに特有の点のみ説明します。

テーブルパーティショニング種別の選択基準

GridDBでは、テーブルパーティショニングの分割の種別として、ハッシュ、インターバル、インターバルハッシュをサポートします。

検索やデータアクセスの条件となるようなカラムを、テーブルを分割するためのパーティショニングキーとします。そのパーティショニングキーの値に対して、大量データを均等に分割するための範囲が決定できる場合にはインターバルパーティショニングもしくはインターバル-ハッシュパーティショニング、決定が困難な場合にはハッシュを選択します。

データの範囲
データの範囲

トランザクション機能

GridDBではコンテナ単位のトランザクション処理をサポートし、トランザクションの特性として一般的に言われるACID特性をサポートしています。以下にトランザクション処理でサポートしている機能の詳細を説明していきます。

トランザクションの開始と終了

コンテナに対して、ロウの検索・更新などの操作を行ったときに新たなトランザクションが開始され、データの更新結果を確定(コミット)または破棄(アボート)した時にトランザクションが終了します。

【メモ】

トランザクションの初期の動作はautocommit（自動コミット）に設定されています。

autocommitでは、アプリケーションからのコンテナに対する更新（データの追加、削除、変更）操作開始毎に新たなトランザクションが開始され、操作終了とともに自動的にコミットされます。 autocommitをオフにすることで、アプリケーションからの要求に応じたタイミングでトランザクションのコミット、アボートを指示できます。

トランザクションのライフサイクルは、トランザクションのコミットやアボートによる完了とともにタイムアウトによるエラー終了があります。トランザクションがタイムアウトによりエラー終了した場合、そのトランザクションはアボートされます。トランザクションのタイムアウトは、トランザクションが開始してからの経過時間です。 トランザクションのタイムアウト時間は、アプリケーション単位にGridDBに接続する際のパラメータとして指定することができます。また、タイムアウト時間の上限値はノード定義ファイル（gs_node.json）に設定できます。

トランザクションの一貫性レベル

トランザクションの一貫性レベルにはimmediate consistencyとeventual consistencyの2種類があります。この指定はアプリケーションごとにGridDBに接続する際のパラメータとして指定することもできます。 デフォルトはimmediate consistencyです。

immediate consistencyは更新操作、読み取り操作で有効です。 eventual consistencyは読み取り操作でのみ有効です。 常に最新の結果を読み取る必要のないアプリケーションではeventual consistencyを指定すると読み取り性能が向上します。

トランザクションの隔離レベル

データベースの内容は常に整合性が保たれている必要があります。 複数のトランザクションを同時実行させたとき、一般に以下の現象が課題として挙がります。

GridDBでは、トランザクションの隔離レベルとして「READ_COMMITTED」をサポートしています。 READ_COMMITTEDでは、確定した最新データを常に読み取ります。

トランザクションを実行する場合、他のトランザクションからの影響を受けないように配慮する必要があります。隔離レベルは、実行トランザクションを他のトランザクションからどの程度隔離するか(どの程度整合性を保てるか)を示す指標であり、4つのレベルがあります。

4つの隔離レベルおよび、それに対して同時実行時の課題であげた現象が起こる可能性は以下のとおりです。

隔離レベル ダーティリード 反復不能読み取り ファントムリード
READ_UNCOMMITTED 発生の可能性あり 発生の可能性あり 発生の可能性あり
READ_COMMITTED 安全 発生の可能性あり 発生の可能性あり
REPEATABLE_READ 安全 安全 発生の可能性あり
SERIALIZABLE 安全 安全 安全

READ_COMMITEDでは、以前読み込んだデータを再度読み込んだ場合に、以前のデータとは異なるデータを得たり、問い合わせを再実行した場合に、同じ検索条件で問い合わせを実行しても異なる結果を得てしまうことがあります。これは前回の読み込み後に、別のトランザクションによって更新、コミットが行われ、データが更新されたためです。

GridDBでは、MVCCによって、更新中のデータを隔離しています。

MVCC

GridDBでは、READ_COMMITTEDを実現するために「MVCC(Multi-Version Concurrency Control：多版型同時実行制御方式)」を採用しています。

MVCCとは、各トランザクションがデータベースに対して問い合わせるときに、別のトランザクションが更新中の最新のデータでなく、更新前のデータを参照して処理を行う方式です。更新前のデータを参照してトランザクションを並行実行できるため、システムのスルー プットが向上します。

実行中のトランザクションの処理がコミットすると、他のトランザクションも最新のデータを参照できます。

MVCC
MVCC

ロック

コンテナに対する複数トランザクションからの更新処理要求競合時の一貫性を保つため、データのロック機構があります。

ロックの粒度は、コンテナの種別に応じて異なります。またロックの範囲は、データベースへの操作の種別に応じて異なります。

ロックの粒度

コンテナの種別ごとのロックの粒度は次のとおりです。

これらは、コンテナの種別ごとのユースケースの分析に基づいています。

データベース操作によるロック範囲

コンテナへの操作にはデータの登録、削除のみならず、データ構造の変更に伴うスキーマ変更や、アクセス高速化のための索引作成などの操作があります。ロック範囲は、コンテナ全体への操作、またはコンテナのロウ単位の操作のいずれかによって異なります。

ロック確保で競合した場合、先行したトランザクションがコミットもしくはロールバック処理で実行が完了しロックを解放するまで、後続のトランザクションはロック確保待ちとなります。

ロック確保待ちは、トランザクションの実行完了以外では、タイムアウトでも解消されます。

データ永続化

コンテナやテーブルに登録・更新されたデータは、ディスクやSSDに永続化され、ノード障害発生時のデータ消失から保護されます。メモリ上の更新データをブロック単位にデータファイル・チェックポイントログファイルに定期的に保存するチェックポイント処理と、データ更新に同期して更新データをシーケンシャルにトランザクションログファイルに書き込むトランザクションログ処理の２つの処理があります。

トランザクションログの書き込みには、以下のいずれかをノード定義ファイルに設定できます。

“SYNC”では、更新トランザクションのコミット・アボートごとに、ログ書き込みを同期的に行います。”DELAYED_SYNC”では、更新時のログ書き込みを、更新タイミングとは関係なく、指定秒数毎に遅延して行います。デフォルト値は”1(DELAYED_SYNC 1秒)”です。

“SYNC”を指定するとノード障害発生時に最新の更新内容を消失する可能性が低くなりますが更新が多いシステムでは性能に影響します。

一方、”DELAYED_SYNC”を指定すると、更新性能は向上しますが、ノード障害発生時ディスクに書き込まれていない更新内容があるとそれらが失われます。

クラスタ構成でレプリカ数が2以上の場合は、他のノードにレプリカを持つため、”DELAYED_SYNC”設定でも1ノード障害時に最新の更新内容を失う可能性は低くなります。 更新頻度が高く、性能が要求される場合には、”DELAYED_SYNC”を設定することも考慮してください。

チェックポイントでは、更新ブロックをデータベースファイルに更新します。 チェックポイント処理は、ノード単位に設定したサイクルで動作します。チェックポイントのサイクルはノード定義ファイルのパラメータで設定します。初期値は、60秒です。

チェックポイントの実行サイクルの数値を上げることで、ディスクへの永続化を夜間に実施するなど比較的時間に余裕がある時間帯に設定することができます。一方サイクルを長くした場合に、システム処理外でノードを再起動した際にロールフォワードすべきトランザクションログファイルが増え、リカバリ時間が増えるという欠点もあります。

チェックポイント
チェックポイント

タイムアウト処理

タイムアウト処理は、NoSQL I/F、NewSQL I/Fで設定できる内容が異なります。

NoSQL I/Fのタイムアウト処理

NoSQL I/Fでは、アプリケーション開発者に通知されるタイムアウトには2種類のタイムアウトがあります。アプリケーションの処理時間の制限に関するトランザクションタイムアウトと、障害発生時の回復処理のリトライ時間に関するフェイルオーバータイムアウトの２つです。

トランザクションタイムアウト、フェイルオーバータイムアウトともに、Java APIやC APIでGridStoreオブジェクトを用いてクラスタに接続する際に設定できます。 詳細は『GridDB Java APIリファレンス』や『GridDB C APIリファレンス』を参照ください。

　

NewSQL I/Fのタイムアウト処理

NewSQL I/Fでは、ログイン(接続)タイムアウト、ネットワーク応答タイムアウト、クエリタイムアウトの3種類のタイムアウトがあります。

レプリケーション機能

クラスタを構成する複数のノード間では、ユーザが設定したレプリケーション数に従って、パーティション単位にデータのレプリカが作成されます。

データのレプリカを分散ノード間で保持することで、ノード障害が発生しても、ノンストップで処理を継続できます。クライアントAPIでは、ノードの障害を検出すると、自動的にレプリカを保持する別ノードにアクセスを切り替えます。

レプリケーション数のデフォルト値は2で、複数ノードのクラスタ構成で動作した場合、データが2重化されます。

コンテナに更新があると、多重化されたパーティションのうちオーナノード（レプリカのマスタを持つノード）が更新されます。

その後オーナノードから更新内容がバックアップノードに反映されますが、その方法は2つあります。

可用性よりも性能を重視する場合は非同期レプリケーションに、可用性を重視する場合は準同期レプリケーションに設定してください。

【メモ】

データ同期機能【EE限定】

ノードに障害が発生した場合システムは自動的にレプリカを復旧してデータを再配置します。この機能を「自律的データ配置機能」と呼びます。 このレプリカ復旧にはデータ同期機能が用いられますが、これは以下の2通りのいずれかが用いられます。

A) 差分トランザクションログを用いた同期方法

B) オリジナルのデータファイルを用いた同期方法

多くの場合A)のほうが高速にデータ同期を行うことができますが、データ同期に必要な差分トランザクションログが削除された場合はB)の方法で実行されます。 A)のデータ同期を優先的に行いたい場合は以下の設定を行ってください。 障害発生から指定時間はデータ同期で利用するトランザクションログファイルが削除されにくくなります。 ただし、保持するトランザクションログファイル数が増加するため、本機能を利用する際は十分なディスク空きがあることを確認してください。

パラメータ 初期値  パラメータの意味と制限値  変更
/sync/enableKeepLog false 本機能を利用する場合はtrueを設定します。 また配置表の固定化指定もあわせて有効とする必要があります(詳細は配置表の固定化指定を参照) オンライン
/sync/keepLogInterval 1200s 障害発生から指定時間トランザクションログファイルの削除をできる限り抑制します。 オンライン

アフィニティ機能

アフィニティ機能とは、関連のあるデータを結びつける機能です。GridDBではアフィニティ機能として、データアフィニティとノードアフィニティの２種類を提供します。

データアフィニティ

データアフィニティには、複数のコンテナ(テーブル)をグループ化して別ブロックに配置する機能と、各コンテナ(テーブル)毎に別ブロックに配置する機能があります。

複数のコンテナをグループ化して別ブロックに配置

同じパーティションに配置されたコンテナ（テーブル）を、ヒント情報を元にグルーピングして、それぞれ別ブロックに配置するための機能です。各ブロックに関連性の強いデータのみ格納することで、データアクセスの局所化を図り、メモリヒット率を高めることができます。

ヒント情報は、コンテナ(テーブル)作成時にプロパティとして与えます。使用できる文字列は、コンテナ(テーブル)名の命名規則と同様に制限があります。

同じヒント情報があるデータをできるだけ同じブロックに配置します。ヒント情報はデータの更新頻度や参照頻度に応じて設定します。 たとえば、分単位、日単位、月単位、年単位にデータをサンプリングや参照する監視システムに対して、以下のような利用方法でシステムのデータが登録・参照・更新される場合のデータ構造を考えます。

  1. 監視機器から分単位のデータが送信され、監視機器単位に作成したコンテナにデータを保存
  2. 日単位のデータレポート作成のため、一日分のデータの集計を分単位データから行い、日単位コンテナ(テーブル)に保存
  3. 月単位のデータレポート作成のため、日単位コンテナ(テーブル)のデータの集計を行い、月単位コンテナ(テーブル)に保存
  4. 年単位のデータレポート作成のため、月単位コンテナ(テーブル)のデータの集計を行い、年単位コンテナ(テーブル)に保存
  5. カレントの使用量（分単位、日単位）は常に表示パネルに更新表示

GridDBでは、コンテナ単位にブロックを占有するのではなく、ブロックには時刻の近いデータが配置されます。したがって、2.の日単位コンテナ(テーブル)を参照し、月単位の集計を行い集計時間をROWKEY(PRIMARY KEY)とする3.のデータと、分単位の1.のデータが同一ブロックに保存される可能性があります。

メモリが小さく監視データがすべてメモリに収まらない大容量データで4.の年単位の集計処理を行う場合、ブロックが分断して配置された3.のデータをメモリに配置するために、常時必要な1．のデータがメモリから追い出されるなど、直近でないデータの読み込みにより監視したいデータがスワップアウトされる状況が発生します。

この場合、分単位、日単位、月単位などコンテナ(テーブル)のアクセス頻度に沿ったヒントを与えることで、アクセス頻度の低いデータと高いデータをデータ配置時に別ブロックに分離します。

このように、データアフィニティによってアプリケーションの利用シーンに合わせたデータ配置ができます。

Data Affinity
複数のコンテナをグループ化して別ブロックに配置

【注意】

コンテナ単位で別ブロックに配置

各コンテナ（テーブル）毎にブロックを占有するための機能です。コンテナに対して固有のブロックを割り当てることで、コンテナ単位のスキャンや削除を高速化することができます。

ヒント情報として、特殊文字列「 #unique 」をコンテナ作成時にプロパティ情報へ設定してください。他のコンテナと完全に別のブロックにデータを配置します。

data affinity independent

【注意】

ノードアフィニティ

ノードアフィニティとは、関連の強いコンテナやテーブルを同じノードに配置し、データアクセス時のネットワーク負荷を減少させるための機能です。GridDBのSQLではテーブルのJOIN操作が記述できます。テーブルのJOIN操作時にクラスタの別ノードに配置されたテーブルのネットワークアクセスでの負荷を減少させることができます。また、複数ノードを用いた並列処理ができなくなるため、ターンアラウンド時間の短縮には効果がない反面、ネットワーク負荷の減少によりスループットが上がる可能性があります。

ノードアフィニティによるコンテナ/テーブルの配置
ノードアフィニティによるコンテナ/テーブルの配置

ノードアフィニティを利用するには、コンテナ(テーブル)作成時にコンテナ(テーブル)名にヒント情報を与えます。ヒント情報が同一のコンテナ(テーブル)は同一のパーティションに配置されます。 以下のように指定します。

ノードアフィニティのヒント情報の命名もコンテナ(テーブル)名の命名規則と同様です。

【注意】

コンテナ(テーブル)の定義変更

コンテナ作成後に、カラム追加などのコンテナ定義の変更を行うことができます。変更可能な操作と使用するインターフェースは以下の通りです。

| 操作 | NoSQL API | SQL | |———————-|———–|——| | カラム追加(末尾) | ○ | ○ | | カラム追加(末尾以外) | ○(※1) | × | | カラム削除 | ○(※1) | × | | カラム名変更 | × | ○ |

カラム追加

コンテナに新しいカラムを追加します。

カラムを追加した後に既存ロウを取得した場合、追加カラムの値はカラムのデータ型ごとに定義されている「空の値」が返ります。 空の値の詳細は『GridDB Java APIリファレンス』のContainer<K,R>をご参照ください。 (V4.1では、制限事項「カラム追加後に既存のロウを参照した時、NOT NULL制約が付いていないカラムはNULLが返る」があります。

カラム追加の例
カラム追加の例

カラム削除

コンテナのカラムを削除します。NoSQL APIのみで操作できます。

カラム名変更

コンテナのカラム名を変更します。SQLのみで操作できます。

データベース圧縮/解放機能

データブロック圧縮

GridDBは、メモリ上のデータをデータベースファイルに書き込むことで、メモリサイズに依存しない大容量化を実現できますが、ストレージのコストは増加します。データブロック圧縮機能は、データベースファイル（データファイル）を圧縮することで、データ量に伴って増加するストレージコストの削減を支援する機能です。 特に、HDDと比べ容量単価が高いフラッシュメモリをより効率的に活用できます。

圧縮方法

メモリ上のデータをデータベースファイル（データファイル）に書き出す際に、GridDBの書き出し単位であるブロック毎に圧縮操作を行います。圧縮により空いた領域は、Linuxのファイルブロック割り当て解除処理を行うため、ディスク使用量を削減できます。

サポート環境

データブロック圧縮はLinuxの機能を利用しているため、Linuxカーネルバージョンとファイルシステムに依存します。データブロック圧縮のサポート環境は以下です。

　※上記以外の環境でデータブロック圧縮を有効にした場合、GridDBノードの起動に失敗します。

圧縮アルゴリズム

データブロック圧縮は以下の2種類のアルゴリズムから選択することができます。

設定方法

GridDBノードごとに圧縮機能を設定します。

ノード定義ファイル(gs_node.json)の/dataStore/storeCompressionModeに以下の文字列を設定します。

設定する文字列 意味
“NO_COMPRESSION” 圧縮機能を無効にする（既定値）
“COMPRESSION_ZLIB” または “COMPRESSION” ZLIB圧縮機能を有効にする
“COMPRESSION_ZSTD” ZSTD圧縮機能を有効にする

【注意】

データブロック未使用領域解放

データブロック未使用領域解放機能は、データベースファイル（データファイル）の使用されていないブロック領域に対して、Linuxのファイルブロック割り当て解除処理を行い、データベースファイルのサイズ(実ディスク割当量)を縮小することができる機能です。

以下のようなケースにおいて、ディスク使用量を削減したい場合にご利用ください。

未使用領域を解放する処理や、本機能のサポート環境、実行方法について説明します。

解放処理

GridDBノード起動時に、データベースファイル（データファイル）の未使用領域を解放します。 解放された領域は、新たなデータ更新が発生しない限りディスク領域は割り当てられません。

サポート環境

サポート環境は、データブロック圧縮機能と同じです。

実行方法

GridDBノード起動時に、gs_startnodeコマンドでデータブロック未使用領域解放オプション(–releaseUnusedFileBlocks)を指定します。

データベースファイル（データファイル）の未使用領域サイズとディスク割当サイズは、下記の方法で確認してください。

データブロック未使用領域解放機能の実施目安としては、データブロック未使用領域が多い(上記の値の比較で、storeTotalUse ≪ dataFileAllocateSize) 場合です。

【注意】

クラスタパーティション配置【EE限定】

GriDBは複数のノードにクラスタパーティションを多重化して配置します。クラスタパーティション内のコンテナに対して更新操作ができるノードが「オーナノード」、参照操作のみ可能なノードが「バックアップノード」であり、これら割付をクラスタ全体で決定したものを「クラスタパーティション配置表」と呼びます。

クラスタパーティション配置表はクラスタ構成時にサーバによって決定されますが、構成に関する以下の指定を行うことができます。

  1. 生成規則の指定
    • クラスタパーティション配置表の生成規則(アルゴリズム)が指定できます。
  2. 配置表の固定化指定
    • 現在のクラスタ構成をクラスタパーティション配置表ファイルとして出力し、それを用いて固定化することができます。

生成規則の指定

サーバが決定するクラスタパーティション配置表の生成規則として以下のいずれかを指定できます。

  1. デフォルト規則(DEFAULT)
    • その時点の各ノードのオーナ、バックアップの個数が均等になるように配置します。
    • その時点で保持しているデータ量を参照します。
    • 同じ構成であっても、その時点の状況により配置表が異なる場合があります。
  2. ラウンドロビン規則(ROUNDROBIN)
    • その時点の各ノードのオーナ、バックアップの個数が均等になるように配置します。
    • オーナ、バックアップをできるだけ偏りなく、スレッド処理効率が良いように配置しますが、データ量は参照しません。
    • 同じ構成であっても、その時点の状況により配置表が異なる場合があります。

ラウンドロビン規則では以下の規則で配置表を作成します。

1) クラスタを構成する各ノードの、ノードアドレス:ポート番号を文字列化して昇順に並べたノード順序を決定します。 2) クラスタパーティション番号の0番から昇順に、ノード順序に従いラウンドロビンでオーナを決定します。 3) クラスタパーティション番号の0番から2)で決定したオーナのノード番号+1を基点に、ラウンドロビンでレプリカ数分のバックアップを決定します。

4台クラスタ構成、クラスタパーティション数8のサンプルを以下に示します。

ラウンドロビン
ラウンドロビン

(メモ)

設定パラメータ 初期値  パラメータの意味と制限値  変更
/cluster/goalAssignmentRule DEFAULT クラスタパーティション配置表の生成規則を指定します。
DEFAULT、ROUNDROBINのいずれかを指定します		 起動

配置表の固定化指定

初回に構成されるクラスタ構成をクラスタパーティション配置表ファイルとして出力し、それを用いてクラスタパーティションを固定化することができます。 出力される配置表となるファイルは以下となります。

サンプルを以下に示します。

  [
      {
          "backup": [{"address": "192.168.11.11","port": 10010}],
          "owner": {
              "address": "192.168.11.10",
              "port": 10010
          },
          "pId": "0",
      },
          ：
  ]

本機能を利用する場合は以下の手順を行ってください。

本配置表の読み込みおよび生成されるタイミングは以下の通りです。

配置表ファイルが指定フォルダに既に存在する場合は上記タイミングでも「上書き更新」は行われません。また、上記タイミングでの現在のノード構成が配置表ファイルに記載された構成と異なる場合は配置表ファイルを用いず、現在のノード構成において6.1.1で指定した生成規則に従った配置表が適用されます。

クラスタのノード増設やノード縮退を行う場合は操作前に配置表ファイルを削除した後にクラスタ操作を実行すると、自動的に新しい構成に従った配置表ファイルを生成することができます。

(メモ)

設定パラメータ 初期値  パラメータの意味と制限値  変更
/cluster/enableStableGoal false クラスタパーティション配置表固定化の利用有無を指定します。 起動

クラスタパーティション数=8, ノード数=4、生成規則「ROUNDROBIN」を指定した場合のサンプルを以下に示します。初期クラスタ構成時に、4台構成のラウンドロビンに従った配置表となるgs_stable_goal.jsonが自動生成されます。障害発生時は、「ROUNDROBIN」規則による3台構成の配置となります。1ノード増設のタイミングで、gs_stable_goal.jsonを削除しておけば、5台構成のラウンドロビン配置表が新たに生成されます。

パーティション割当サンプル
パーティション割当サンプル

運用機能

サービス制御

OSの起動と同時にGridDBをサービスとして動作させるサービス制御機能があります。

GridDBのサービスは、パッケージのインストール直後からサービスが有効となっています。サービスが有効となっているため、OS起動と同時にGridDBのサーバが起動され、OS停止時はサーバが停止されます。

OSの監視やデータベースソフトウェアの動作を含めたミドルウェアやアプリケーションの運用を統合化したインターフェースを用いる場合、サービス制御の機能を用いるのか、もしくは運用コマンドを利用するのか、サービスの起動停止の他ミドルウェアとの依存性も検討する必要があります。

GridDBのサービスは、OS起動時に自動的に実行され、GridDBノード(以下、ノード)を起動し、 GridDBクラスタ(以下、クラスタ)へ参加します。OSのシャットダウン時には、クラスタから離脱し、ノードを停止します。

サービスにより、次のことができます。

　

ノード3台のクラスタに対するサービス操作の手順は以下の通りです。

　

　

【注意】

　

なお、サービス制御を使用しない場合、以下のようにすべてのランレベルでサービスを無効にします。

# /sbin/chkconfig gridstore off

ユーザ管理機能

GridDBのユーザには、インストール時に作成されるOSユーザとGridDBの運用／開発を行うGridDBのユーザ（以降GridDBユーザと呼ぶ）の2種類があります。

OSユーザ

OSユーザは、GridDBの運用機能を実行できる権限を持つユーザであり、GridDBインストール時にgsadmというユーザが作成されます。以降このOSユーザをgsadmと呼びます。

GridDBのリソースはすべて、gsadmの所有物となります。また、GridDBの運用操作のコマンド実行はすべてgsadmで実行します。

運用操作では、GridDBサーバに接続し運用操作を実行できる権限を持ったユーザか否かの認証を行います。この認証は、GridDBユーザで行います。

GridDBユーザ　

GridDBのユーザ
GridDBのユーザ

利用できる機能

管理ユーザができる運用操作と一般ユーザが利用できる操作を以下に示します。運用操作のうちGridDBユーザを用いずに、gsadmで実行可能なコマンドは◎印で明記します。

操作 操作詳細 利用する運用ツール gsadm 管理ユーザ 一般ユーザ
ノード操作 ノードの起動 gs_startnode/gs_sh   ○ ×
  ノードの停止 gs_stopnode/gs_sh   ○ ×
クラスタ操作 クラスタの構築 gs_joincluster/gs_sh   ○ ×
  クラスタへのノード増設 gs_appendcluster/gs_sh【EE限定】   ○ ×
  クラスタからのノード離脱 gs_leavecluster/gs_sh   ○ ×
  クラスタの停止 gs_stopcluster/gs_sh   ○ ×
ユーザ管理 管理ユーザ登録 gs_adduser ◎ × ×
  管理ユーザの削除 gs_deluser ◎ × ×
  管理ユーザのパスワード変更 gs_passwd ◎ × ×
  一般ユーザの作成 gs_sh   ○ ×
  一般ユーザの削除 gs_sh   ○ ×
  一般ユーザのパスワード変更 gs_sh   ○ ○：本人のみ
データベース管理 データベースの作成・削除 gs_sh   ○ ×
  データベースへのユーザ割り当て/解除 gs_sh   ○ ×
データ操作 コンテナやテーブルの作成・削除 gs_sh   ○ ○：本人のDB内で更新操作が可能な場合のみ
  コンテナやテーブルへのデータ登録 gs_sh   ○ ○：本人のDB内で更新操作が可能な場合のみ
  コンテナやテーブルの検索 gs_sh   ○ ○：本人のDB内のみ
  コンテナやテーブルへの索引操作 gs_sh   ○ ○：本人のDB内で更新操作が可能な場合のみ
バックアップ管理 バックアップ作成 gs_backup   ○ ×
バックアップ管理 バックアップリストア gs_restore ◎ × ×
  バックアップリスト gs_backuplist   ○ ×
システムステータス管理 システム情報の取得 gs_stat   ○ ×
  パラメータ変更 gs_paramconf   ○ ×
データインポート/ データのインポート gs_import   ○ ○：アクセスできる範囲
エクスポート データのエクスポート gs_export   ○ ○：アクセスできる範囲

データベースとユーザ

GridDBのクラスタデータベース(以降クラスタデータベースと呼びます)を利用ユーザ単位にアクセスを分離することができます。分離する単位を データベース と呼びます。 データベースは、クラスタデータベースの初期状態では以下のデータベースがあります。

データベースはクラスタデータベースに複数作成することができます。データベースの作成、削除、ユーザへの割り当ては管理ユーザが行います。

データベース作成時の規則は以下に示すとおりです。

データベースへ一般ユーザを割り当てる際、権限を指定します。権限は以下の種類があります。

データベースにアクセスできるのは割り当てた一般ユーザと管理ユーザのみです。管理ユーザはすべてのデータベースにアクセスすることができます。 データベースへ一般ユーザを割り当てる際、以下規則があります。

データベースとユーザ
データベースとユーザ

認証方式

GridDBの認証方式には、以下があります。

各方式について、説明します。

内部認証

GridDBの管理/一般ユーザのユーザ名、パスワード、および権限をGridDBで管理します。認証方式を指定しない場合、内部認証がデフォルトです。

管理ユーザは、運用コマンドのgs_adduser/gs_deluser/gs_passwdで管理します。

一般ユーザは、SQLのCREATE USER/DROP USER/SET PASSWORD文で管理します。また、一般ユーザのアクセス権は、SQLのGRANT/REVOKE文で管理します。

ユーザキャッシュ設定

一般ユーザ情報のキャッシュの設定は、以下のノード定義ファイル(gs_node.json)を編集します。

【注意】

パラメータ デフォルト 設定値
/security/userCacheSize 1000 キャッシュする一般ユーザ/LDAPユーザエントリ数を指定。
/security/userCacheUpdateInterval 60 キャッシュの更新間隔（秒）を指定。

LDAP認証【EE限定】

GridDBの一般ユーザをLDAPで管理します。また、LDAP内のユーザ名/グループ名と同じ名前のロールを作成し権限を操作することで、LDAPユーザの権限を管理します。また、認証処理の高速化のため、LDAPで管理するユーザ情報のキャッシュ機能を提供します。

【注意】

共通設定

LDAP認証を利用する場合は、以下、クラスタ定義ファイル(gs_cluster.json)を編集します。

パラメータ デフォルト 設定値
/security/authentication INTERNAL 認証方式として、INTERNAL(内部認証) / LDAP(LDAP認証)のいずれかを指定。
/security/ldapRoleManagement USER GridDBのロールとマッピングする対象として、USER(LDAPユーザ名でマッピング) / GROUP(LDAPグループ名でマッピング)のいずれかを指定。
/security/ldapUrl   LDAPサーバを次の形式で指定。ldap[s]://host[:port]

【注意】

ロール管理

ロールは、SQLのCREATE ROLE / DROP ROLE文で管理します。/security/ldapRoleManagementが「USER」の場合はLDAPのユーザ名で、「GROUP」の場合はLDAPのグループ名でロールを作成します。作成したロールに対するアクセス権限は、SQLのGRANT/REVOKE文で管理します。

LDAP認証モード設定

次に、LDAPユーザの認証方法として、単純モード（直接ユーザアカウントでバインド）またはサーチモード（LDAP管理ユーザでバインド後に、ユーザを検索/認証）を選択します。以下、クラスタ定義ファイル(gs_cluster.json)を編集します。

【注意】

■単純モード

パラメータ デフォルト 設定値
/security/ldapUserDNPrefix   ユーザのDN（識別子）を生成するために、ユーザ名の前に連結する文字列を指定。
/security/ldapUserDNSuffix   ユーザのDN(識別子)を生成するために、ユーザ名の後に連結する文字列を指定。

■サーチモード

パラメータ デフォルト 設定値
/security/ldapBindDn   LDAP管理ユーザのDNを指定。
/security/ldapBindPassword   LDAP管理ユーザのパスワードを指定。
/security/ldapBaseDn   検索を開始するルートDNを指定。
/security/ldapSearchAttribute uid 検索対象となる属性を指定。
/security/ldapMemberOfAttribute memberof ユーザが所属するグループDNが設定された属性を指定。(ldapRoleManagement=GROUPの場合に有効)

ユーザキャッシュ設定

LDAPユーザ情報のキャッシュの設定は、以下のノード定義ファイル(gs_node.json)を編集します。

【注意】

パラメータ デフォルト 設定値
/security/userCacheSize 1000 キャッシュする一般ユーザ/LDAPユーザエントリ数を指定。
/security/userCacheUpdateInterval 60 キャッシュの更新間隔（秒）を指定。

設定例

以下に設定例を記載します。条件は以下です

■ロールの設定例(SQL文)

 CREATE ROLE TEST
 GRANT SELECT ON sampleDB to TEST

■サーバの設定例（gs_cluster.jsonの一部抜粋）

            :
"security":{
    "authentication":"LDAP",
    "ldapRoleManagement":"USER",
    "ldapUrl":"ldaps://192.168.1.100:636",
    "ldapUserDnPrefix":"CN=",
    "ldapUserDnSuffix":",ou=d1,ou=dev,dc=example,dc=com",
    "ldapSearchAttribute":"",
    "ldapMemberOfAttribute": ""
},
            :

セキュリティ機能【EE限定】

通信の暗号化

GridDBでは、GridDBクラスタとクライアント間のSSL接続をサポートします。

【注意】

設定

SSL接続を行うためには、以下、クラスタ定義ファイル(gs_cluster.json)、およびノード定義ファイル(gs_node.json)を編集します。 そして、サーバ証明書および秘密鍵のファイルを適切なディレクトリに配置します。

【注意】

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

パラメータ デフォルト 設定値
/system/serverSslMode DISABLED SSL接続設定として、DISABLED(SSL無効)、PREFERRED(SSL有効、ただし非SSL接続も許容)、REQUIRED(SSL有効、非SSL接続は不可)のいずれかを指定。
/system/sslProtocolMaxVersion TLSv1.2 TLSプロトコルバージョンとして、TLSv1.2, TLSv1.3のいずれかを指定。

■ノード定義ファイル(gs_node.json)

パラメータ デフォルト 設定値
/system/securityPath security サーバ証明書、秘密鍵の配置ディレクトリをフルパスもしくは、相対パスで指定。
/system/serviceSslPort 10045 運用コマンド用待ち受けSSLポート

■サーバ証明書および秘密鍵

SSLを有効にする場合は、/system/securityPathに設定したディレクトリに、サーバ証明書および秘密鍵を それぞれ次のファイル名で配置します。

クライアント設定

クライアント側で、SSL接続、サーバ証明書検証の実施を指定できます。詳細は各ツール、およびAPIリファレンスをご参照ください。

障害処理機能【EE限定】

GridDBでは、クラスタを構成する各ノードでデータのレプリカを保持するため、単一点故障に対してのリカバリは不要です。 GridDBでは障害発生時には以下のような動作を行います。

  1. 障害発生時、障害ノードはクラスタから自動的に離脱する。
  2. 離脱した障害ノードに代わり、バックアップノードへのフェイルオーバーが行われる。
  3. 障害によりノード台数が減少するため、自律的にパーティションの再配置を行う（レプリカも配置する）。

障害の回復したノードはオンラインでクラスタ運用に組み込むことができます。障害によりUNSTABLEな状態となったクラスタには、gs_joinclusterコマンドを用いてノードを組み込めます。ノード組込みにより、自律的にパーティションの再配置が行われノードのデータ、負荷バランスが調整されます。

このように、単一点故障の場合にはリカバリのための事前の準備は不要ですが、シングル構成で運用する場合や、クラスタ構成においても複数の障害が重なった場合にはリカバリの操作が必要です。

クラウド環境で稼働させる場合、物理的なディスクの障害やプロセッサ障害で意図せずともクラスタを構成する複数ノードの障害、複数ノードでのデータベース障害といった多重障害となるケースがあります。

障害の種類と処置

発生する障害と対処方法の概要を以下の表に示します。

ノード障害とは、プロセッサ障害やGridDBのサーバプロセスのエラーによりノードが停止した状態、データベース障害とは、ディスクに配置したデータベースへのアクセスでエラーが発生した状態を指します。

GridDBの構成 障害の種類 動作と処置
シングル構成 ノード障害 アプリケーションからアクセスはできなくなりますが、ノードの障害要因を取り除き再起動するだけで、処理が完了したトランザクションのデータはリカバリされます。ノード障害が長期化した際は、別ノードでのリカバリを検討します。
シングル構成 データベース障害 アプリケーションでエラーを検出するため、バックアップしたデータからデータベースファイルを復旧します。データはバックアップ時点に復旧されます。
クラスタ構成 単一ノード障害 アプリケーションにはエラーが隠ぺいされ、レプリカのあるノードで処理が継続できます。障害が発生したノードでのリカバリ操作は不要です。
クラスタ構成 複数ノード障害 レプリカのオーナ／バックアップの双方のパーティションが障害対象ノードに存在する場合、対象パーティションにアクセスができませんが、クラスタは正常に稼働します。ノードの障害要因を取り除き再起動するだけで、処理が完了したトランザクションのデータはリカバリされます。ノードの障害が長期化する場合は別ノードでのリカバリを検討します。
クラスタ構成 単一データベース障害 単一ノードでのデータベース障害は、クラスタを構成する他のノードでデータアクセスが継続するため、異なるディスクにデータベース配置先を変更し、ノードを再起動するだけでリカバリされます。
クラスタ構成 複数データベース障害 レプリカで復旧できないパーティションは最新のバックアップデータからバックアップ採取時点にリカバリさせる必要があります。

クライアントフェイルオーバー

クラスタ構成で運用している際にノード障害が発生した場合、障害ノードに配置されているパーティション（コンテナ）にはアクセスできません。この時、クライアントAPI内で、自動的にバックアップノードに接続し直して処理を継続するクライアントフェイルオーバー機能が動作します。クライアントAPI内で自動的に障害対策を行うため、アプリケーション開発者はノードのエラー処理を意識する必要がありません。

しかし、複数のノードの同時障害やネットワーク障害などにより、アプリケーション操作対象にアクセスできずエラーになることもあります。

エラー発生後のリカバリではアクセス対象のデータに応じて以下の点を考慮する必要があります。

【メモ】

自動再起動機能

GridDBノードが異常終了した場合、またはノードプロセスが強制終了された場合、自動的にノードの再起動、およびクラスタ参加を実行します。 運用管理者が意識せずに、クラスタの状態を正常稼働に戻すことができます。

障害対策機能
障害対策機能

【注意】

以下の場合は自動起動処理を実施しません。

設定

障害対策機能の設定は以下になります。

パラメータ デフォルト 設定値
SVC_ENABLE_AUTO_RESTART true true(有効)/false(無効)
GS_USER admin 適宜
GS_PASSWORD admin 適宜

パラメータを変更するには起動設定ファイル( /etc/sysconfig/gridstore/gridstore.conf )を編集します。

【注意】

エクスポート/インポート機能

GridDBのエクスポート/インポートでは、データベースの局所的な破壊に対して復旧を行う障害回復処理や、システム構成が変更された際のデータベースの移行(マイグレーション)処理などを実現するために、データベースやコンテナ単位での保存/復元機能を提供します。

GridDBクラスタでは、コンテナデータをクラスタ内のノードに自動的に配置します。利用者は、どのノードにデータが配置されているかを意識する必要はありません(データの位置透過）。 エクスポート／インポートでも、データの取り出し・登録で配置位置を意識する必要はありません。エクスポート／インポートの構成は以下のとおりです。

エクスポート／インポートの構成
エクスポート／インポートの構成

【エクスポート(export)】

① GridDBクラスタのコンテナおよびロウデータを、以下のファイルに保存します。コンテナ名を指定して特定コンテナのみエクスポートすることもできます。

【インポート(import)】

② エクスポートデータを保存したコンテナデータファイルとエクスポート実行情報ファイルを読み込んで、コンテナおよびロウデータをGridDBに復元します。特定のコンテナデータを指定して、インポートすることもできます。

③ ユーザが作成したコンテナデータファイルを読み込んで、コンテナとロウデータを登録します。

【メモ】

バックアップ/リストア機能

データベース障害やアプリケーションの誤動作によるデータ破壊に備えるために、定期的なバックアップの採取が必要です。バックアップ運用は、サービスレベルの要求やシステムのリソースに応じて対処方法を選択する必要があります。

バックアップ方式と、それぞれの方式について以下の項目を説明します。

バックアップ方式

データベース障害やアプリケーションの誤動作によるデータ破壊に備えるために、定期的なバックアップの採取が必要です。 バックアップ運用は、障害発生時のリカバリの要件（いつの時点にリカバリするか）、クラスタとしての一貫性保持の必要性、バックアップにかかる時間、バックアップのために用意できるディスクの容量に応じて、バックアップの種別やバックアップの間隔を決定します。リカバリ保証のサービスレベルからの要求やシステムのリソースに応じて対処方法を選択する必要があります。 GridDBのバックアップ方式には、以下のものがあります。

バックアップ方式 復旧時点 特徴  
オフラインバックアップ クラスタ停止時点 バックアップのコピー完了までクラスタ停止が必要です。 ノード間で復旧時点が異なることはありません。  
オンラインバックアップ（フル+差分・増分） バックアップ採取完了時点 GridDBバックアップコマンドを利用します。バックアップの取得完了のタイミングにより、ノード間で復旧時点が異なることがあります。  
オンラインバックアップ（自動ログ） 障害直前の時点 GridDBバックアップコマンドを利用します。トランザクションログから最新状態にリカバリするため、起動時間が長くなることがあります。  
ファイルシステムレベルのオンラインバックアップ（クラスタスナップショット） スナップショット取得時点 クラスタスナップショット機能を用い、OSやストレージのスナップショットと連携してバックアップを取得します。  

オフラインバックアップを行うには、まずgs_stopclusterコマンドでクラスタを停止してから、クラスタを構成する全ノードを停止してください。 次に、各ノードのデータベースファイルの配置ディレクトリ（gs_node.jsonの/dataStore/dbPath、/dataStore/transactionLogPathで示すディレクトリ）下のデータをバックアップしてください。

GridDBのオンラインバックアップの機能については、ノード単位のオンラインバックアップとリカバリ操作を参照ください。

GridDBのオンラインバックアップ機能を使用せず、ファイルシステムレベルのオンラインバックアップを行う場合は、ファイルシステムレベルのオンラインバックアップとリカバリ操作（クラスタスナップショット機能の利用）を参照ください。

【注意】

定義ファイルのバックアップ

バックアップでは、データベースファイルの定期的なバックアップに加え、定義ファイルのバックアップも必要です。

$GS_HOME/confディレクトリ（デフォルトでは、/var/lib/gridstore/conf）にあるノード定義ファイル（gs_node.json)、クラスタ定義ファイル（gs_cluster.json)、ユーザ定義ファイル（password）のバックアップをOSのコマンドを用いて採取しておいてください。

定義ファイルのバックアップは、設定変更やユーザ登録・変更した場合には、必ず実施してください。

ノード単位のオンラインバックアップとリカバリ操作

バックアップ運用

GridDBの障害に備えたバックアップ運用について説明します。

バックアップの種類

GridDBでは、ノード単位のオンラインバックアップが可能です。これをGridDBクラスタを構成する全ノードに対して順次行うことで、サービスを継続しながら、クラスタ全体としてオンラインバックアップが行えます。ただし、この方法でクラスタ全体としてのバックアップを取得した場合は、クラスタとしての一貫性保持はなされないため、バックアップから復元してクラスタを再構築したあとで同期処理が実行される可能性が高いです。クラスタとしての一貫性保持を優先する場合は「クラスタスナップショットによるオンラインバックアップ」の使用を検討してください。

GridDBの提供するオンラインバックアップの種類には以下のものがあります。

バックアップ種別 バックアップの動作 復旧時点  
フルバックアップ 現在利用中のクラスタデータベースをノード定義ファイルで指定したバックアップディレクトリにノード単位にオンラインでバックアップする。 フルバックアップ採取時点  
差分・増分バックアップ 現在利用中のクラスタデータベースをノード定義ファイルで指定したバックアップディレクトリにノード単位にオンラインでバックアップし、以降のバックアップでは、バックアップ後の更新ブロックの差分増分のみをバックアップする。 差分増分バックアップ採取時点  
自動ログバックアップ 現在利用中のクラスタデータベースをノード定義ファイルで指定したバックアップディレクトリにノード単位にオンラインでバックアップするとともに、トランザクションログファイルの書き込みと同じタイミングでトランザクションログも自動で採取します。トランザクションログファイルの書き込みタイミングは、ノード定義ファイルの/dataStore/logWriteModeの値に従います。 最新トランザクションの更新時点  

利用するバックアップの種類に応じて復旧できる時点が異なります。

GridDBの提供する各バックアップの動作と、利用を推奨するシステムについて以下に示します

フルバックアップ
フルバックアップ
差分・増分バックアップ
差分・増分バックアップ
自動ログバックアップ
自動ログバックアップ

【注意】

バックアップの種別は、コマンドのオプションで指定します。

バックアップ関連パラメータの確認

バックアップ先は、ノード定義ファイルの　/dataStore/backupPathで指定します。ディスクの物理障害を考慮して、バックアップ先とデータベースファイル（/dataStore/dbPath、/dataStore/transactionLogPath）は必ず異なる物理ディスクに配置するように設定してください。

トランザクションのログ永続化には２つのモードがあります。デフォルト値はNORMALです。

KEEP_ALL_LOGは、他社のバックアップソフトウェアとの連携等でログファイルの削除を指示する運用を行うなど特別な用途の場合のみ指定しますが、通常は利用しません。

ノード定義ファイルの指定例を以下に示します。

$ cat /var/lib/gridstore/conf/gs_node.json         # 設定の確認例
{
    "dataStore":{
        "dbPath":"/var/lib/gridstore/data",
        "transactionLogPath":"/var/lib/gridstore/txnlog",
        "backupPath":"/mnt/gridstore/backup",      # バックアップディレクトリ
        "storeMemoryLimit":"1024",
        "concurrency":2,
        "logWriteMode":1,
        "persistencyMode":"NORMAL"                 #永続化モード
　　　　　　：
　　　　　　：
}
バックアップの実行

フルバックアップ、差分・増分バックアップ、自動ログバックアップの各々の利用方法を説明します。

どのバックアップでも、バックアップ名（BACKUPNAME)を指定してバックアップを実行します。バックアップで作成されるデータは、ノード定義ファイルのbackupPathで指定したディレクトリ下にバックアップ名（BACKUPNAME）と同じ名前のディレクトリが作成され、配置されます。

BACKUPNAMEは、12文字以内の英数字で指定できます。

フルバックアップ

障害発生時、フルバックアップの採取完了時点までリカバリできます。 フルバックアップをクラスタを構成するすべてのノードに対して実施します。バックアップデータはコマンドのBACKUPNAMEで示すディレクトリに配置されます。採取したバックアップデータをわかりやすく管理するためにBACKUPNAMEに日付を指定する運用をお勧めします。

以下のコマンドをクラスタ内の全ノードに対して実行します。

$ gs_backup -u admin/admin 20141025

この例では、

  1. バックアップ名（BACKUPNAME)を「20141025」とすると、バックアップディレクトリ下に「20141025」というディレクトリが作成されます。
  2. 「20141025」ディレクトリに、バックアップ情報ファイル(gs_backup_info.json,gs_backup_info_digest.json)とLSN情報ファイル(gs_lsn_info.json)が作成されます。また、「data」ディレクトリにデータファイルとチェックポイントログファイル、「txnlog」ディレクトリにトランザクションログファイルが作成されます。
/var/lib/gridstore/backup/
        20141025/                           # バックアップディレクトリ                
                gs_backup_info.json         # バックアップ情報ファイル
                gs_backup_info_digest.json  # バックアップ情報ファイル
                gs_lsn_info.json            # LSN情報ファイル
                data/
                    0/                      # パーティション番号0
                        0_part_0.dat        # データファイルバックアップ
                        0_117.cplog         # チェックポイントログバックアップ
                        0_118.cplog         
                        ...
                    1/                      
                    2/                                           
                    ...
                txnlog/
                    0/                      # パーティション番号0
                        0_120.xlog          # トランザクションログバックアップ
                        0_121.xlog         
                    1/
                    2/                     
                    ...

バックアップコマンドは、バックアップの指示をサーバに通知するだけで、処理の完了は待ち合わせません。

バックアップ処理の完了は、gs_statコマンドのステータスで確認してください。


$ gs_backup -u admin/admin 20141025
$ gs_stat -u admin/admin --type backup
BackupStatus: Processing

バックアップが正しく採取できたか否かは、gs_backuplistコマンドのステータスで確認できます。

$ 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の記号を以下に示します。

差分・増分ブロックバックアップ

障害発生時、ベースライン（基準点）となるフルバックアップとベースライン以降の差分・増分バックアップを用いて、最後の差分・増分バックアップ採取時点まで復旧できます。 差分・増分バックアップのベースラインとしてフルバックアップを取得し、以降差分・増分バックアップを指定します。

データの更新容量とリカバリにかかる時間のサービス目標に応じてバックアップの採取間隔は検討する必要がありますが、以下を目安として運用してください。

フルバックアップのベースライン作成は、以下のように指定します。この例ではBACKUPNAMEは「201504」です。

$ gs_backup  -u admin/admin --mode baseline 201504
$ gs_stat -u admin/admin --type backup
BackupStatus: Processing(Baseline)

バックアップのベースラインとして、データディレクトリにあるデータベースファイルが、バックアップディレクトリ下にコピーされます。

ベースライン作成後の定期的な差分・増分ブロックのバックアップ（ベースラインのフルバックアップ以降に更新されたデータブロックのバックアップ）は、バックアップコマンド（gs_backup）のモードとしてincrementalやsinceを指定します。BACKUPNAMEには、ベースライン作成時のBACKUPNAMEと同じ値を指定します。この例ではBACKUPNAMEは『201504』です。

*****　増分バックアップの場合
$ gs_backup  -u admin/admin --mode incremental 201504
$ gs_stat  -u admin/admin --type backup
BackupStatus: Processing(Incremental)

*****　差分バックアップの場合
$ gs_backup  -u admin/admin --mode since 201504
$ gs_stat  -u admin/admin --type backup
BackupStatus: Processing(Since)

バックアップが正しく採取できたか否かはgs_backuplistコマンドで確認できます。差分・増分バックアップは、複数のバックアップで1つのリカバリ単位となるため、BACKUPNAMEの一覧では1つとして扱われます。したがってステータスの詳細を見るには、バックアップ名を指定して詳細を確認します。

差分・増分バックアップであるというこことはBACKUPNAMEの先頭に”*“：アスタリスクがついていることで確認できます。差分・増分のバックアップのステータスは常に”–“です。

差分・増分バックアップのステータスは、gs_backuplistコマンドの引数にBACKUPNAMEを指定することで確認できます。

*****　BACKUPNAMEの一覧を表示します
$ gs_backuplist -u admin/admin

BackupName   Status   StartTime                EndTime
------------------------------------------------------------------------
*201504          --  2015-04-01T05:20:00+0900 2015-04-24T06:10:55+0900
*201503          --  2015-03-01T05:20:00+0900 2015-04-24T06:05:32+0900
  :
 20141025NO2     OK   2014-10-25T06:37:10+0900 2014-10-25T06:37:10+0900

*****　個別のBACKUPNAMEを指定し、詳細情報を表示します
$ gs_backuplist -u admin/admin 201504

BackupName : 201504

BackupData            Status   StartTime                EndTime
--------------------------------------------------------------------------------
201504_lv0                OK  2015-04-01T05:20:00+0900 2015-04-01T06:10:55+0900
201504_lv1_000_001        OK  2015-04-02T05:20:00+0900 2015-04-01T05:20:52+0900
201504_lv1_000_002        OK  2015-04-03T05:20:00+0900 2015-04-01T05:20:25+0900
201504_lv1_000_003        OK  2015-04-04T05:20:00+0900 2015-04-01T05:20:33+0900
201504_lv1_000_004        OK  2015-04-05T05:20:00+0900 2015-04-01T05:21:15+0900
201504_lv1_000_005        OK  2015-04-06T05:20:00+0900 2015-04-01T05:21:05+0900
201504_lv1_001_000        OK  2015-04-07T05:20:00+0900 2015-04-01T05:22:11+0900
201504_lv1_001_001        OK  2015-04-07T05:20:00+0900 2015-04-01T05:20:55+0900

差分・増分のバックアップデータは、バックアップディレクトリに以下の規則でディレクトリが作成され、データが配置されます。

バックアップリストのStatusの記号を以下に示します。

差分・増分バックアップでは、BackupDataディレクトリ/dataディレクトリ/<パーティション番号>ディレクトリの下に、<パーティション番号>_n_incremental.cplogという名前で更新ブロックのログが出力されます。(※nは数値)

差分・増分バックアップはフルバックアップと比較してバックアップ時間を削減できます。しかし障害発生時のリカバリにはフルバックアップのデータに更新ブロックをロールフォワードするため、リカバリには時間がかかります。 定期的なベースライン取得やSince指定によるベースラインからの差分バックアップを実施してください。

【注意】

自動ログバックアップ

GridDBが自動的にトランザクションログをバックアップディレクトリに出力します。従って、常に最新の状態にリカバリすることができます。 自動的なバックアップ操作のため、『システムの利用時間の低い時間にあらかじめスケジューリングしてバックアップ処理をしたい』といったシステムの運用形態に応じた計画的なバックアップはできません。また、自動ログバックアップにより、通常運用中にも多少のシステム負荷が発生します。従って、システムのリソースに余裕がある場合にのみ本指定を用いることをお勧めします。

自動ログバックアップを利用するには次のように指定します。この例ではBACKUPNAMEは「201411252100」です。

$ gs_backup -u admin/admin --mode auto 201411252100
$ gs_stat -u admin/admin --type backup

コマンドを実行するとBACKUPNAMEで示すディレクトリにバックアップを取得します。

この例では、

  1. バックアップディレクトリ下に「201411252100」というディレクトリが作成されます。
  2. 「201411252100」ディレクトリに、バックアップ情報ファイル(gs_backup_info.json,gs_backup_info_digest.json)とLSN情報ファイル(gs_lsn_info.json)が作成されます。また、「data」ディレクトリにデータファイルとチェックポイントログファイル、「txnlog」ディレクトリにトランザクションログファイルが作成されます。
  3. 「201411252100/txnlog」ディレクトリの下にトランザクションの実行完了とともにトランザクションログファイルが作成されます。

自動ログバックアップで運用した場合、障害発生時のリカバリは、2)のフルバックアップデータに対して、3)のトランザクションログファイルをロールフォワードします。従ってリカバリに利用するログファイルが多数になるとリカバリ時間が増大しますので、定期的に、–mode autoを指定してフルバックアップを採取してください。

バックアップ動作の確認

現在実行しているバックアップのモードや実行状態の詳細はgs_statコマンドで取得できる情報でも確認できます。

$ gs_stat -u admin/admin

    "checkpoint": {
        "backupOperation": 3,
        "duplicateLog": 0,
        "endTime": 0,
        "mode": "INCREMENTAL_BACKUP_LEVEL_0",
        "normalCheckpointOperation": 139,
        "pendingPartition": 1,
        "requestedCheckpointOperation": 0,
        "startTime": 1429756253260
    },
        ：
        ：

gs_statで出力されるバックアップ関連の各パラメータの意味は以下のとおりです。

コンテナ情報の採取

データベース障害発生時には、どのコンテナがリカバリ対象なのかを把握してコンテナの使用者に連絡するなどの手立てが必要です。リカバリ対象のコンテナを検出するには、定期的に以下の情報を採取している必要があります。

コンテナ一覧を出力するgs_shのコマンドスクリプトを作成しておくことで運用の省力化が図れます。

以下の例では、gs_shのサブコマンドをlistContainer.gshというファイル名で作成します。

setnode node1 198.2.2.1  10040
setnode node2 198.2.2.2  10040
setnode node3 198.2.2.3  10040
setcluster cl1 clusterSeller 239.0.0.20 31999 $node1 $node2 $node3
setuser admin admin gstore
connect $cl1
showcontainer
connect $cl1 db0
showcontainer
 :   dbの数だけ繰り返す
quit

クラスタを構成するノードを示すnode1,node2,node3といったノード変数や、cl1というクラスタ変数、ユーザ設定やデータベース情報は適宜環境に合わせて変更してください。

gs_shのスクリプトファイルを以下のように実行することで、コンテナとパーティションの一覧が採取できます。

$ gs_sh listContainer.gsh>`date +%Y%m%d`Container.txt

20141001Container.txtには以下の形式で情報が保存されます。

Database : public
Name                  Type         PartitionId
------------------------------------------------
container_7           TIME_SERIES            0
container_9           TIME_SERIES            7
container_2           TIME_SERIES           15
container_8           TIME_SERIES           17
container_6           TIME_SERIES           22
container_3           TIME_SERIES           25
container_0           TIME_SERIES           35
container_5           TIME_SERIES           44
container_1           TIME_SERIES           53
：
 Total Count: 20

Database : db0
Name                  Type         PartitionId
---------------------------------------------
CO_ALL1              COLLECTION           32
COL1                 COLLECTION          125
 Total Count: 2

リカバリ操作

障害発生時のリカバリ操作の概要は以下のとおりです。

  1. 障害の認識とリカバリ範囲の確認
  2. リカバリ操作とノード起動
  3. ノードのクラスタへの組込み
  4. 復旧結果の確認と操作
障害の認識とリカバリ範囲の確認

GridDB内で障害が発生すると、エラーが発生したノードのイベントログファイルに障害の原因が出力されるとともに、ノードの動作が継続不能と判断した際は、ノードがABNORMAL状態となり、クラスタサービスから切り離されます。

クラスタ構成では、通常複数レプリカが存在する運用を実施しているため、ノードがABNORMAL状態となってもクラスタサービスが停止することはありません。パーティションがレプリカも含めてすべて障害となった場合、データのリカバリが必要です。

データのリカバリが必要か否かは、マスタノードのステータスをgs_statで確認し、/cluster/partitionStatusの値が”OWNER_LOSS”の場合はリカバリが必要です。

$ gs_stat -u admin/admin -p 10041
{
    "checkpoint": {
        ：
    },
    "cluster": {
        "activeCount": 2,
        "clusterName": "clusterSeller",
        "clusterStatus": "MASTER",
        "designatedCount": 3,
        "loadBalancer": "ACTIVE",
        "master": {
            "address": "192.168.0.1",
            "port": 10011
        },
        "nodeList": [
            {
                "address": "192.168.0.2",
                "port": 10011
            },
            {
                "address": "192.168.0.3",
                "port": 10010
            }
        ],
        "nodeStatus": "ACTIVE",
        "partitionStatus": "OWNER_LOSS",     ★
        "startupTime": "2014-10-07T15:22:59+0900",
        "syncCount": 4
          :

リカバリしなければならないデータは、gs_partitionコマンドで確認します。–lossオプションを指定してコマンドを実行することで問題のあるパーティションが確認できます。

以下の例では192.168.0.3のノードの問題によりパーティション68がエラーになっています。

$ gs_partition -u admin/admin -p 10041 --loss

[
 {
        "all": [
            {
                "address": "192.168.0.1",
                "lsn": 0,
                "port": 10011,
                "status": "ACTIVE"
            },
            ：
            ：
            ,
            {
                "address": "192.168.0.3",
                "lsn": 2004,
                "port": 10012,
                "status": "INACTIVE"   <---　このノードのステータスがACTIVEでない
            }
        ],
        "backup": [],
        "catchup": [],
        "maxLsn": 2004,
        "owner": null,           //クラスタ内でパーティションのオーナが不在の状態
        "pId": "68",             //リカバリが必要なパーティションID     
        "status": "OFF"
   },
   {
     :

   }
  ]
リカバリ操作とノード起動
バックアップデータからのリカバリ

ディスク障害などで、利用しているシステムの問題でデータベースに問題が発生した場合、バックアップデータからリカバリします。リカバリ時は以下のことに注意する必要があります。

【注意】

GridDBノードにバックアップデータをリストアします。

バックアップしたデータからリストアする場合、以下の手順で操作を行います。

  1. ノードが起動していないことを確認します。
    • クラスタ定義ファイルが、参加させるクラスタの他のノードと同一であることを確認します。
  2. リカバリに利用するバックアップ名を確認します。この操作はノード上で実行します。
    • バックアップのステータスを確認し、正しくバックアップされているものを選択します。
  3. ノードのデータベースファイルディレクトリ(デフォルトでは、/var/lib/gridstore/data, /var/lib/gridstore/txnlog)に過去のデータファイル、チェックポイントログファイル、トランザクションログファイルが残っていないことを確認します。
    • 不要であれば削除、必要であれば別のディレクトリに移動してください。
  4. ノードを起動するマシン上で、リストアコマンドを実行します。
  5. ノードを起動します。

バックアップしたデータの確認には、以下のコマンドを用います。

以下は、バックアップ名の一覧を表示する具体例です。 バックアップ名の一覧は、ノードの起動状態に関わらず表示できます。ノードが起動状態で、バックアップ処理中の場合はStatusは”P”（Processingの略）と表示されます。

バックアップのリスト表示では、最新のものから順に表示されます。以下の例の場合、201912のBACKUPNAMEが最新です。

$ gs_backuplist -u admin/admin
 BackupName   Status  StartTime                 EndTime
-------------------------------------------------------------------------
*201912           --  2019-12-01T05:20:00+09:00 2019-12-01T06:10:55+09:00
*201911           --  2019-11-01T05:20:00+09:00 2019-11-01T06:10:55+09:00
  :
 20191025NO2      OK  2019-10-25T06:37:10+09:00 2019-10-25T06:38:20+09:00
 20191025         NG  2019-10-25T02:13:34+09:00 -
 20191018         OK  2019-10-18T02:10:00+09:00 2019-10-18T02:12:15+09:00

$ gs_backuplist -u admin/admin 201912

BackupName : 201912

BackupData            Status StartTime                 EndTime
--------------------------------------------------------------------------------
201912_lv0                OK 2019-12-01T05:20:00+09:00 2019-12-01T06:10:55+09:00
201912_lv1_000_001        OK 2019-12-02T05:20:00+09:00 2019-12-02T05:20:52+09:00
201912_lv1_000_002        OK 2019-12-03T05:20:00+09:00 2019-12-03T05:20:25+09:00
201912_lv1_000_003        OK 2019-12-04T05:20:00+09:00 2019-12-04T05:20:33+09:00
201912_lv1_000_004        OK 2019-12-05T05:20:00+09:00 2019-12-05T05:21:25+09:00
201912_lv1_000_005        OK 2019-12-06T05:20:00+09:00 2019-12-06T05:21:05+09:00
201912_lv1_001_000        OK 2019-12-07T05:20:00+09:00 2019-12-07T05:22:11+09:00
201912_lv1_001_001        OK 2019-12-08T05:20:00+09:00 2019-12-08T05:20:55+09:00

【注意】

この201912のバックアップデータのうちでリカバリに利用されるデータを確認します。gs_restoreの–testオプションではリカバリに利用する、差分・増分バックアップのデータが確認できます。–testオプションでは、リカバリに利用する情報の表示のみでデータのリストアは行いません。事前確認する際に利用してください。

上記例で出力された201912のBACKUPNAMEのリカバリでは、ベースラインの201912_lv0ディレクトリのデータ、および差分(Since)の201912_lv1_001_000ディレクトリ、増分(Incremental)の201912_lv1_001_001ディレクトリのデータがリカバリに利用されることを示しています。


-bash-4.2$ gs_restore --test 201912

BackupName : 201912
BackupFolder : /var/lib/gridstore/backup

RestoreData           Status StartTime                 EndTime
--------------------------------------------------------------------------------
201912_lv0                OK 2019-09-06T11:39:28+09:00 2019-09-06T11:39:28+09:00
201912_lv1_001_000        OK 2019-09-06T20:01:00+09:00 2019-09-06T20:01:00+09:00
201912_lv1_001_001        OK 2019-09-06T20:04:42+09:00 2019-09-06T20:04:43+09:00

なお、特定のパーティションの障害の場合、そのパーティションの最新データがどこに保持されているのかを確認する必要があります。

クラスタを構成するすべてのノード上で、gs_backuplistコマンドを用い、–partitionIdオプションに確認したいパーティションIDを指定して実行します。最も数値の大きいLSNを含むノードのバックアップを利用してリカバリします。

****　クラスタを構成する各ノードで実行します。

$ gs_backuplist -u admin/admin --partitionId=68
 BackupName    ID   LSN
----------------------------------------------------------
 20191018      68   1534
*201911        68   2349
*201912        68   11512

”*“は、差分・増分バックアップのBACKUPNAMEの場合に付与されます。

以下は、バックアップデータをリストアする実行例です。リストアはノードを停止した状態で実行します。

$ mv ${GS_HOME}/data/* ${GS_HOME}/temp/data         # データファイル、チェックポイントログファイルの移動
$ mv ${GS_HOME}/txnlog/* ${GS_HOME}/temp/txnlog     # トランザクションログファイルの移動
$ gs_restore 201912                                 # リストア

gs_restoreコマンドの実行により、以下のような処理が実行されます。

リストア後はノードを起動します。起動後の処理は、ノード起動後の操作を参照してください。

$ gs_startnode -u admin/admin -w
ノード障害からのリカバリ

ノード障害でノードの状態がABNORMAL状態になったり、ノードが異常終了した際は、イベントログファイルでエラー原因を特定する必要があります。

データベースファイルに障害がない場合、ノードの障害原因を除去し、ノードを起動するだけでデータベースファイルのデータはリカバリできます。

ノードの状態がABNORMAL状態になったときは、一旦ノードを強制終了させ、エラー原因を調査後再起動します。

強制的にノードを停止します。

$ gs_stopnode -f -u admin/admin -w

エラー原因を特定し、データベースの障害ではないと判断した場合、ノードを起動します。ノードを起動することで、トランザクションログのロールフォワードが行われ、最新の状態にデータがリカバリされます。

$ gs_startnode -u admin/admin -w

起動後の処理は、ノード起動後の操作を参照してください。

ノード起動後の操作

ノード起動後には以下の操作を行います。

  1. ノードをクラスタに組み込む
  2. データ一貫性の確認とフェイルオーバー操作
ノードをクラスタに組み込む

ノードを起動後、回復したノードをクラスタに組み込むには、gs_joinclusterコマンドを 待合せオプション(-w)を指定して 実行します。

$ gs_joincluster -u admin/admin -c clusterSeller -n 5 -w
データ一貫性の確認とフェイルオーバー操作

ノードをクラスタに組み込んだ後、パーティションのリカバリ状態を確認します。オンラインで動作しているクラスタに対して、データベースファイルのリカバリをバックアップから実施した場合、オンラインで保持しているパーティションのLSNに一致しない場合があります。 以下のコマンドでパーティションの詳細情報を調べ、コンテナ情報の採取で採取した情報と照らし合わせることで、ロスト対象に含まれるコンテナがわかります。

gs_partitionコマンドを用いてパーティションの欠損情報を取得します。パーティションの欠損が発生している場合は、欠損が発生しているパーティションのみが表示されます。表示されなければ、データの一貫性に問題はありません。

$ gs_partition  -u admin/admin --loss
 [
      {
        "all": [
            {
                "address": "192.168.0.1",
                "lsn": 0,
                "port": 10040,
                "status": "ACTIVE"
            },
            {
                "address": "192.168.0.2",
                "lsn": 1207,
                "port": 10040,
                "status": "ACTIVE"
            },
            {
                "address": "192.168.0.3",
                "lsn": 0,
                "port": 10040,
                "status": "ACTIVE"
            },
        ],
        "backup": [],
        "catchup": [],
        "maxLsn": 1408,
        "owner": null,
        "pId": "1",
        "status": "OFF"
    },
：
]

LSNがマスタノードが保持するMAXLSNと異なる場合パーティション欠損と判断されます。 クラスタを構成するノードのstatusはACTIVEですが、パーティションのstatusはOFF状態です。 このままシステムに組み込むにはgs_failoverclusterコマンドを実行します。

$ gs_failovercluster -u admin/admin --repair

フェイルオーバーの完了は、マスタノードに対するgs_statコマンドの実行で/cluster/partitionStatusがNORMALになっていること、 gs_partitionコマンドでパーティションの欠損が発生していないことで確認します。

リカバリ完了後の操作

リカバリ完了後は、クラスタを構成する全ノードでフルバックアップを採取してください。

ファイルシステムレベルのオンラインバックアップとリカバリ操作（クラスタスナップショット機能の利用）

クラスタの一貫性を保ってバックアップを行いたい場合、クラスタスナップショット機能を使用してファイルシステムレベルのオンラインバックアップを取得します。この方法では、LVMやストレージのスナップショット機能を利用したり、ファイルを直接コピーすることで、データディレクトリのバックアップを取得します。

また、GridDBの自動ログバックアップ機能と組み合わせることで、この方法で取得したバックアップをベースラインとして、最新データまでリカバリすることも可能です。ただし、この場合クラスタ全体の一貫性保持はなされないため、ノード単位で復元してクラスタを再構築した後で同期処理が発生する可能性があります。自動ログバックアップ機能については、オンラインバックアップを参照ください。

クラスタスナップショットによるオンラインバックアップ

クラスタスナップショット機能は、クラスタ全体で静止点を作成し、一貫性のある状態を保持したバックアップを可能にする機能です。 この機能を利用することにより、LVMスナップショットやストレージのスナップショット機能を用いてオンラインバックアップを実行できます。バックアップに要する時間を大幅に短縮できるほか、クラスタの各ノードの復旧時点を揃えることができ、復元後すぐに安定運用が可能になります。

以下の手順で操作を行います。

  1. クラスタのノードリバランス処理を一時停止します。
  2. クラスタの全ノードに対して定期チェックポイント処理を一時停止します。
  3. クラスタの全ノードに対して手動チェックポイント処理を実行し、完了を待ち合わせます。
  4. クラスタスナップショット復元情報ファイル作成コマンドを任意のノードから実行します。
    • ※この時点が復元ポイントとなります
  5. クラスタの全ノードに対して、データベースファイルディレクトリを含むスナップショットを取得します。
    • ※このスナップショット取得の手順は、各ノードで個別に実行します。同時刻に開始する必要はありません。
    • ※スナップショットを取得できない環境の場合、ここでOSのコピーコマンドによりデータをコピーします。はじめにトランザクションログファイルをコピーし、その後、データファイルとチェックポイントログファイルをコピーする順序で行います。(この場合、以下8.の手順は不要です。)
  6. クラスタの全ノードに対して定期チェックポイント処理を再開します。
  7. クラスタのノードリバランス処理を再開します。
  8. クラスタの全ノードに対して、取得したスナップショットからデータベースファイルディレクトリをコピーします。
    • ※必要に応じて、不要となったスナップショットを削除してください。

取得したバックアップのおおよその復旧時点は、クラスタスナップショット復元情報ファイル作成コマンド実行時点となります。

【注意】

以下では、手順の具体例を説明します。

クラスタのデータのリバランス処理(ノード間のデータの再配置)を一時停止します。以下のコマンドを実行すると、クラスタ全体で新たなリバランス処理を停止します。バックアップ作成中にデータの配置が変更されないようにするためです。

$ gs_loadbalance -u admin/admin --cluster --off

次に、チェックポイント制御コマンドを実行し、定期チェックポイント処理を一時停止します。これにより、データベースファイルへの新たな書き込みを停止し、静止状態にします。

$ gs_checkpoint -u admin/admin --off

その後、手動チェックポイント処理を待合せオプション(-w)を指定して実行します。これにより、GridDBのストアメモリ中のデータをデータベースファイルに書き込み、永続化します。

$ gs_checkpoint -u admin/admin --manual -w

手動チェックポイント処理完了後（上記コマンドの応答後）、クラスタスナップショット復元情報ファイル作成コマンドを任意のノードから実行します。この際、ファイルを作成するディレクトリを指定します(以下例では/mnt/backup/202208010300/snapshotinfo)(※1)。１度の実行でクラスタの全てのノードについてのファイルが作成されます。 クラスタスナップショット復元情報ファイルは、スナップショット作成した時点を記録しています。クラスタスナップショット機能を用いたバックアップから、データベースを復元する際に使用します。

$ gs_clustersnapshotinfo -u admin/admin -d /mnt/backup/202208010300/snapshotinfo

この状態で、スナップショット取得を実行しバックアップを作成します。具体的な手順は環境に依存するため、個別に確認する必要があります。

上記の手順が完了したら、通常のデータベースの更新処理に戻すため、定期チェックポイント処理を再開します。

$ gs_checkpoint -u admin/admin --on

最後に、停止していたクラスタのリバランス処理を再開します。以下のコマンドを実行するとクラスタ全体でリバランス処理を再開します。

$ gs_loadbalance -u admin/admin --cluster --on

この時点で、通常のGridDBクラスタの状態に戻ります。

通常の状態に戻った後、クラスタの全ノードに対して、取得したスナップショットからデータベースファイルディレクトリをコピーします。 必要に応じて、不要となったスナップショットを削除してください。これらの具体的な手順は環境に依存するため、個別に確認する必要があります。

【注意】

リカバリ操作とノードの起動

スナップショットやファイルコピーによってバックアップしたデータからリストアする場合、以下の手順で操作を行います。

  1. ノードが起動していないことを確認します。
    • クラスタ定義ファイルが、参加させるクラスタの他のノードと同一であることを確認します。
  2. ノードのデータベースファイルディレクトリ(デフォルトでは、/var/lib/gridstore/data, /var/lib/gridstore/txnlog)に過去のデータファイル、チェックポイントログファイル、トランザクションログファイルが残っていないことを確認します。
    • 不要であれば削除、必要であれば別のディレクトリに移動してください。
  3. ノードごとに、リストアするバックアップデータ(※2)とクラスタスナップショット復元情報ファイル(※1)をデータベースファイルディレクトリにコピーします。
    • ログバックアップを併用して最新のデータへリカバリする場合は、続けてリストアコマンドでログ更新オプションを指定し、対応するログバックアップデータをリストアします。
  4. ノードを起動します。

以下では、3の手順の具体例を説明します。

はじめに、リストアするバックアップデータをデータベースファイルディレクトリにコピーします。 以下の例では、/mnt/backup/202208010300/data/および/mnt/backup/202208010300/txnlogにバックアップ(※２)があるものとしています。

$ cp -p /mnt/backup/202208010300/data/* ${GS_HOME}/data
$ cp -p /mnt/backup/202208010300/txnlog/* ${GS_HOME}/txnlog

さらに、該当するクラスタスナップショット復元情報ファイルをノードごとにデータベースファイルディレクトリにコピーします。

$ cp -p gs_cluster_snapshot_info.json ${GS_HOME}/data

クラスタスナップショット復元情報ファイルは、出力先ディレクトリパス(※1)に以下のような構成でファイル出力されています。各ノードごとに、該当するディレクトリのファイル(gs_cluster_snapshot_info.json)をコピーしてください。

/mnt/backup/202208010300/snapshotinfo
  +- yyyymmddhhmmss
       +- cluster_snapshot_info_<ノードIPアドレス>_<システムサービスポート番号>
            gs_cluster_snapshot_info.json
       +- cluster_snapshot_info_<ノードIPアドレス>_<システムサービスポート番号>
            gs_cluster_snapshot_info.json
       +- cluster_snapshot_info_<ノードIPアドレス>_<システムサービスポート番号>
            gs_cluster_snapshot_info.json
（yyyymmddhhmmss はコマンド実行時の年月日時分秒になります。）

上記のとおり各ノードごとにそれぞれファイルを配置した後、ノードを起動すると、リストアが行われます。起動後の処理は、ノード起動後の操作を参照してください。

バックアップファイル

ファイル構成

ノード定義ファイルの　/dataStore/backupPathが指すディレクトリ下に、バックアップコマンドのBACKUPNAMEで指定した名前でディレクトリが作成され、以下のファイルが配置されます。なお、差分・増分バックアップの場合は、バックアップディレクトリ下にBACKUPNAME_lv0 (ベースライン） BACKUPNAME_lv1_NNN_MMM(差分・増分バックアップ）ディレクトリが作成され、同様に以下のファイルが配置されます。

  1. バックアップ情報ファイル(gs_backup_info.json,gs_backup_info_digest.json)
    • バックアップ時の情報として、バックアップの採取開始時間、完了時間やバックアップファイルのサイズなどの情報がgs_backup_info.jsonに保持され、gs_backup_info_digest.jsonにダイジェスト情報が保持されています。本ファイルを元にgs_backuplistで情報が出力されます。
  2. シーケンス番号(gs_lsn_info.json)
    • パーティション更新のシーケンス番号を示すLSN(Log Sequence Number)が出力されます。バックアップ採取時点でパーティションが保持しているLSNが出力されます。
  3. データファイル(<パーティション番号>_part_n.dat) ※nは数値
    • dataディレクトリ/<パーティション番号>ディレクトリの下に出力されます。
    • データファイル分割を行う設定となっている場合、分割数(/dataStore/dbFileSplitCount)の数だけファイルが作成されます。
  4. チェックポイントログファイル(<パーティション番号>_n.cplog) ※nは数値
    • dataディレクトリ/<パーティション番号>ディレクトリの下に出力されます。
  5. トランザクションログファイル(<パーティション番号>_n.xlog) ※nは数値
    • txnlogディレクトリ/<パーティション番号>ディレクトリの下に出力されます。
    • フルバックアップ時もしくは、自動ログバックアップの動作に応じて新しいしいトランザクションログファイルが追加されます。
  6. 差分・増分ブロックログファイル(<パーティション番号>_n_incremental.cplog) ※nは数値
    • 差分・増分バックアップで、更新ブロックのチェックポイントログファイルを保持します。
    • dataディレクトリ/<パーティション番号>ディレクトリの下に出力されます。

不要となったバックアップファイルの削除

不要となったバックアップデータの削除は、BACKUPNAME単位に不要となったディレクトリを削除するのみです。バックアップデータの管理情報はすべて各々のBACKUPNAMEのディレクトリ下にあるため、他のレジストリ情報などを削除するといった操作は不要です。 なお、差分・増分バックアップの際は、BACKUPNAME_lv0, BACKUPNAME_lv1_NNN_MMMのディレクトリ群をすべて削除してください。

ローリングアップデート機能【EE限定】

ローリングアップデート機能では、クラスタ構成を稼動したままノードのアップデートを行うことができます。 ノード1台ずつ順番に、クラスタからノードを離脱してGridDB製品をアップデートし、再びクラスタ構成へノードを参加させることで、最終的にクラスタを構成するすべてのノードを新しいバージョンのGridDB製品に置き換えることができます。

以下の手順で、ローリングアップデート機能を用いたアップデートを行います。

  1. ローリングアップデートの運用計画を立てる
    • ローリングアップデートの作業時間を見積もります。ノード1台分の作業は下記の項目となります。 これらにかかる時間を見積り、クラスタの全ノードでの作業時間を計算します。 ノード起動(リカバリ)以外の項目は、約5分程度が目安の時間です。
      • クラスタ離脱
      • ノード停止
      • GridDBインストール
      • ノード起動(リカバリ)
      • クラスタ参加
    • クラスタ離脱前にデータ更新が多い場合(チェックポイントされていない更新が多い場合)、また、ローリングアップデート中にデータ更新が多い場合は、リカバリに時間がかかる場合があります。
  2. クラスタのデータ配置目標の自動設定を無効にする
    • ローリングアップデートでは、繰り返しクラスタ構成を変更するため、データ配置目標の自動設定を無効にした状態で全ノードのアップデートを実施します。これにより、無駄なデータ再配置が行われず、処理やネットワーク通信の負荷を軽減できます。
    • gs_goalconfコマンドで–clusterオプションを付けて実行すると、クラスタを構成する全ノードに対してデータ配置目標の自動設定の無効化が行われます。
    • 例) 
      $ gs_goalconf -u admin/admin --off --cluster
  3. クラスタ構成を確認する
    • ローリングアップデートの手順では、すべてのフォロワノードをアップデートした後で、最後にマスタノードをアップデートします。 そのため、事前にクラスタ構成を確認し、ノードをアップデートする順序を決めます。
    • gs_configコマンドでマスタノードを確認します。確認したマスタノード以外はフォロワノードです。
    • 例) 
      $ gs_config -u admin/admin
  4. すべてのフォロワノードを1台ずつアップデートする
    • 下記の作業を各フォロワノードに対して行います。ノードにログインして実施してください。 この作業の開始以降、5の作業が完了するまでSQL処理は継続できない場合があります。詳しくは【注意】を参照ください。
      • a. 現在のデータ配置目標をマスタノードから取得する (gs_goalconf)
        • 例) 
          $ gs_goalconf -u admin/admin -s MASTER_IP --manual > last_goal.json
      • b. 対象のノードを離脱対象とするための配置目標を全ノードに設定する (gs_goalconf)
        • ノードを安全に離脱させるため、離脱させるノードがレプリカのオーナを持たないデータ配置にする必要があります。この操作は、(パーティション数 * ノード数 / 10)秒程度かかります。
        • このとき、一部パーティションのオーナとバックアップが切り替わるため、クライアントフェイルオーバが発生することがあります。またクライアントフェイルオーバ非対応の処理はエラーとなります。
        • 例) 
          $ gs_goalconf -u admin/admin --manual --leaveNode NODE_IP --cluster
      • c. マスタノードのパーティション状態がNORMALになるまで待つ (gs_stat)
        • 例) 
          $ gs_stat -u admin/admin -s MASTER_IP | grep partitionStatus
      • d. 全ノードの自律的データ配置機能を無効にする (gs_loadbalance)
        • 例) 
          $ gs_loadbalance -u admin/admin --off --cluster
      • e. ノードをクラスタから離脱する (gs_leavecluster)
        • 例) 
          $ gs_leavecluster -u admin/admin --force -w
      • f. ノードを通常停止する (gs_stopnode)
        • 例) 
          $ gs_stopnode -u admin/admin -w
      • g. GridDBをアップデートする
      • h. ノードを起動する (gs_startnode)
        • 例) 
          $ gs_startnode -u admin/admin -w
      • i. 自律的データ配置機能を無効にする (gs_loadbalance)
        • ノード1台に対して行う操作なので、–clusterオプションは不要です。
        • 例) 
          $ gs_loadbalance -u admin/admin --off
      • j. データ配置目標の自動設定を無効にする (gs_goalconf)
        • ノード1台に対して行う操作なので、–clusterオプションは不要です。
        • 例) 
          $ gs_goalconf -u admin/admin --off
      • k. ノードをクラスタに参加させる (gs_joincluster)
        • 例) クラスタ名:mycluster、クラスタ構成ノード数:5の場合 
          $ gs_joincluster -u admin/admin -c mycluster -n 5 -w
      • l. マスタノードのパーティション状態がREPLICA_LOSSになるまで待つ (gs_stat)
        • 例) 
          $ gs_stat -u admin/admin -s MASTER_IP | grep partitionStatus
      • m. データ配置目標を離脱前の状態に戻す (gs_goalconf)
        • この操作は、(パーティション数 * ノード数 / 10)秒程度かかります。
        • 例) 
          $ gs_goalconf -u admin/admin --manual --set last_goal.json --cluster
      • n. 全ノードの自律的データ配置機能に有効にする (gs_loadbalance)
        • このとき、一部パーティションのオーナとバックアップが切り替わるため、クライアントフェイルオーバが発生することがあります。またクライアントフェイルオーバ非対応の処理はエラーとなります。
        • 例) 
          $ gs_loadbalance -u admin/admin --on --cluster
      • o. マスタノードのパーティション状態がNORMALになるまで待つ (gs_stat)
        • 例) 
          $ gs_stat -u admin/admin -s MASTER_IP | grep partitionStatus
  5. マスタノードをアップデートする
    • 手順3で確認したマスタノードを最後にアップデートします。手順は4と同様です。

  6. クラスタ内のすべてのノードが新しいバージョンになっていることを確認する (gs_stat)

  7. クラスタのデータ配置目標の自動設定を有効にする
    • 例) 
      $ gs_goalconf -u admin/admin --on --cluster

上記の操作手順を支援する運用ツールとして、gs_rollingupdateが提供されています。ローリングアップデート支援コマンドを用いることにより、ローリングアップデートを行う一連の手順の大半の自動化を行うことができます。

ローリングアップデート
ローリングアップデート支援コマンド

【メモ】

【注意】

イベントログ機能

イベントログは、GridDBノード内部で発生した例外などのイベント情報に関するメッセージやシステム稼働情報を記録するログです。

イベントログは、環境変数GS_LOGで示すディレクトリにgridstore-%Y%m%d-n.logというファイル名で作成されます(例: gridstore-20150328-5.log)。ファイルは以下のタイミングで切り替わります。

イベントログファイルの上限数の初期値は30です。30ファイルを超えると古いファイルから削除されます。ファイル数の上限値はノード定義ファイルで変更できます。

イベントログの出力形式は以下の内容です。


2014-11-12T10:35:29.746+0900 TSOL1234 8456 ERROR TRANSACTION_SERVICE [10008:TXN_CLUSTER_NOT_SERVICING] (nd={clientId=2, address=127.0.0.1:52719}, pId=0, eventType=CONNECT, stmtId=1) <Z3JpZF9zdG9yZS9zZXJ2ZXIvdHJhbnNhY3Rpb25fc2VydmljZS5jcHAgQ29ubmVjdEhhbmRsZXI6OmhhbmRsZUVycm9yIGxpbmU9MTg2MSA6IGJ5IERlbnlFeGNlcHRpb24gZ3JpZF9zdG9yZS9zZXJ2ZXIvdHJhbnNhY3Rpb25fc2VydmljZS5jcHAgU3RhdGVtZW50SGFuZGxlcjo6Y2hlY2tFeGVjdXRhYmxlIGxpbmU9NjExIGNvZGU9MTAwMDg=>

イベントログの出力レベルはgs_logconfコマンドを用いてオンラインで変更できます。障害情報の詳細を分析する際には、オンラインで変更します。ただし、オンラインでの変更は一時的なメモリ上での変更のため、ノードの再起動でも設定を有効とするような恒久的設定にするには、クラスタを構成する各ノードのノード定義ファイルのtrace項目を設定する必要があります。

設定状況はgs_logconfコマンドで確認できます。出力される内容はバージョンによって異なります。

 $ gs_logconf -u admin/admin
{
    "levels": {
        "CHECKPOINT_FILE": "ERROR",
        "CHECKPOINT_SERVICE": "INFO",
        "CHUNK_MANAGER": "ERROR",
        "CHUNK_MANAGER_IODETAIL": "ERROR",
        "CLUSTER_OPERATION": "INFO",
        "CLUSTER_SERVICE": "ERROR",
        "COLLECTION": "ERROR",
        "DATA_STORE": "ERROR",
        "DEFAULT": "ERROR",
        "EVENT_ENGINE": "WARNING",
        "IO_MONITOR": "WARNING",
        "LOG_MANAGER": "WARNING",
        "MAIN": "WARNING",
        "MESSAGE_LOG_TEST": "ERROR",
        "OBJECT_MANAGER": "ERROR",
        "RECOVERY_MANAGER": "INFO",
        "REPLICATION_TIMEOUT": "WARNING",
        "SESSION_TIMEOUT": "WARNING",
        "SYNC_SERVICE": "ERROR",
        "SYSTEM": "UNKNOWN",
        "SYSTEM_SERVICE": "INFO",
        "TIME_SERIES": "ERROR",
        "TRANSACTION_MANAGER": "ERROR",
        "TRANSACTION_SERVICE": "ERROR",
        "TRANSACTION_TIMEOUT": "WARNING"
    }
}

監査ログ機能【EE限定】

監査ログの目的

データベース監査を実施するには、従来のイベントログでは以下の理由により不十分となります。

GridDBは「監査ログ機能」を有効とすることで上記問題に対応可能となり、主に以下の観点からデータベース監査を実施することができます。

監査ログを用いたデータベース監査
監査ログを用いたデータベース監査

機能概要

監査ログは、データベースに対するアクセス、操作、エラーに対する履歴を記録するログです。具体的には以下の3つのイベントが監査ログとして記録されます。

監査ログはノード定義ファイルで監査ログ機能を有効(auditLogs=true)とした場合に有効となります。この際、監査ログファイルの出力先となるディレクトリパス(auditLogsPath)を指定することが可能で、以下のファイル名で監査ログファイルが生成されます。

gs_audit-%Y%m%d-n.log (nは同一日時における生成順序)

監査ログはイベントログと異なり、ノード定義ファイルで監査ログを有効にしない限り、監査ログファイルおよびディレクトリは生成されません。

監査ログファイルは以下のタイミングで切り替わります。ファイルサイズの閾値はノード定義ファイル(auditMessageLimitSize)で変更可能となります。

監査ログの出力形式は以下のように、各監査項目が空白を区切り文字としたCSV形式となります。

(日付時刻) (ホスト名) (スレッド番号) (出力レベル) (カテゴリ) [(エラー・トレース番号):(エラー・トレース番号名)] (ユーザ名) (管理者権限) (データベース名) (アプリケーション名) (接続元IPアドレス:接続元ポート番号) (接続先IPアドレス:接続先ポート番号) (操作クラス) (要求種別) (操作内容) (操作対象) (操作識別子) (操作情報詳細)

以下に監査ログの出力サンプルを示します。なお、以降のサンプルは表示を見やすくするため途中に適宜改行が含まれています。


2023-03-24T17:26:26.359+09:00 TDSL1234 14268 ERROR AUDIT_DDL
[280003:SQL_DDL_TABLE_ALREADY_EXISTS]　user1 admin db1 (null)
192.0.2.1:63482 203.0.113.1:20001　SQL CREATE_TABLE
"create table table1(a integer);"
e71c8b74-8752-4726-987d-ebd0e8da8d4:1 
"'tableName'=['table1']
Execute SQL failed (reason=CREATE TABLE failed
(reason=Specified create table 'table1' already exists)
on executing statement..."

監査ログ機能を用いる場合は、一般的に監査ログの出力数に比例して性能的なオーバヘッド(ファイル書き込みコスト)が発生します。よって、運用ごとに監査対象となる操作を選定することを検討してください。

監査対象となる操作は、操作内容に基づいて以下の「操作カテゴリ」にカテゴライズされます。出力レベルの設定はイベントログと同様になりますが、監査ログの場合は以下のような意味合いとなります。

操作カテゴリ パラメータの意味と制限値 デフォルト出力レベル
AUDIT_CONNECT 接続(接続、切断、認証)に関する監査ログの出力レベル INFO
AUDIT_SQL_READ SQL(SELECT)に関する監査ログの出力レベル CRITICAL
AUDIT_SQL_WRITE SQL(DML)に関する監査ログの出力レベル CRITICAL
AUDIT_DDL SQL(DDL)に関する監査ログの出力レベル CRITICAL
AUDIT_DCL SQL(DCL)に関する監査ログの出力レベル CRITICAL
AUDIT_NOSQL_READ NoSQL(参照系)に関する監査ログの出力レベル CRITICAL
AUDIT_NOSQL_WRITE NoSQL(更新系)に関する監査ログの出力レベル CRITICAL
AUDIT_SYSTEM 運用コマンド(STAT以外)に関する監査ログの出力レベル CRITICAL
AUDIT_STAT 運用コマンド(STAT)に関する監査ログの出力レベル CRITICAL

デフォルトの出力レベルはアクセスログ(AUDIT_CONNECT)のみINFOでそれ以外はCRITICAL(監査対象外)となっています。よって、ノード定義ファイルで監査ログを有効とした場合は、アクセスログのみ記録されます。運用開始前に監査目的に応じて適切に監査対象とする操作カテゴリを設定する必要があります。

データベース管理者は、監査対象となる操作カテゴリをノード定義ファイルもしくはオンラインで設定することもできます。設定状況はイベントログと同様にgs_logconfコマンドで確認できますがこの場合は永続化されませんので、再起動時に元の操作カテゴリに戻ります。よって、できる限り運用開始前に監査カテゴリを決定しておくことが推奨されます。

ノード定義ファイルで設定する監査ログ関連の設定項目は以下となります。

監査カテゴリ 初期値  パラメータの意味と制限値  変更
/trace/auditLogs false 監査ログを設定する場合はtrueを設定します。 起動
/trace/auditLogsPath ”” 監査ログファイルの配置先ディレクトリ(ディレクトリ名=audit)です。
起動時に該当パスにディレクトリ(audit)が存在なければ設定に基づき監査用ディレクトリおよび監査ログファイルが生成されます。
auditLogs=true、かつ、この項目未設定の場合はGridDBホームディレクトリに生成されます。		 起動
/trace/auditFileLimit 10MB 同一日時における1つの監査ログファイルのサイズ上限値です。
指定されたサイズを超えると自動的に新たな監査ログファイルが生成され切り替わります。
その際にファイル名の連番部分が+1ととなります。		 起動
/trace/auditMessageLimit 1024 1つの監査ログレコードの文字列サイズ上限値です。
指定されたサイズを超えた場合、指定サイズ以降をカットした情報を監査ログとして記録されます。		 起動

監査ログの実施手順

データベース監査を実施する事前準備として、監査対象となる操作カテゴリおよび出力レベルを決定します。出力レベルの指定は監査ログと同様の指定になりますが、監査ログ対象指定から外す場合はCRITICAL指定となる点にご注意ください。

監査対象カテゴリの典型的な設定方針を幾つか示します。このうち、「アクセスログ」は監査上重要項目になりますので、監査ログ機能を有効とした場合、デフォルトでアクセスログが監査対象となります。操作ログ、エラーログに関しては監査案件ごとに必要となる場合にその記述をノード定義ファイルに加えます。

　監査ログを用いた場合のシステム構成を以下に示します。

監査ログを用いたデータベース監査
監査ログを用いたシステム構成

監査ログはクライアントと直接接続があったノードに対して出力されます。つまり、監査ログはノード単位で記録されるので、以下の対応が必要となります。

監査ログを用いた分析

監査ログの出力項目は、アクセスログ、操作ログ、イベントログともに出力フォーマットが共通となります。監査ログ出力項目の詳細は以下になります。必須項目以外で、対応する項目が無い場合は(null)の文字列が出力されます。

監査項目  内容  サンプル データ型 必須項目
日時 形式は:yyyy-mm-ddThh:mm:ss.ms+tz 2023-03-24T17:26:26.359+09:00 時刻型 〇
ホスト名 呼出し元ホスト名 tdsl1234 文字列型 〇
スレッド番号 システムから取得したスレッドID。 2345 数値型 〇
出力レベル INFO/ERROR/CRITICALのいずれか。 INFO 文字列型 〇
操作カテゴリ 監査対象となる操作カテゴリ。 AUDIT_CONNECT 文字列型 〇
エラー/トレース情報 [エラー/トレースコード番号:エラー/トレースコード名] [280003:SQL_DDL_TABLE_ALREADY_EXISTS] 文字列型 〇
ユーザ名 ログインユーザ名。 user1 文字列型 ×
管理者権限 ADMIN/USERのいずれか。 ADMIN 文字列型 ×
データベース名 指定なしだとPUBLIC、指定した場合はそのデータベース名。 db1 文字列型 ×
アプリケーション名 クライアントで設定した場合のみ。 app1 文字列型 ×
接続元IPアドレス 接続元(クライアント側)のIPアドレスとポート番号。
IPアドレスはIPv4形式の文字列型、ポート番号は数値型で、”:”で分割		 192.0.2.1:63482 文字列型 ×
接続先IPアドレス 接続先(サーバ側)のIPアドレスとポート番号。
IPアドレスはIPv4形式の文字列型、ポート番号は数値型で、”:”で分割		 203.0.113.1:20001 文字列型 ×
操作クラス カテゴリ “AUDIT_XXX” から、”AUDIT_” を除いた文字列と同じ CONNECT 文字列型 ×
要求種別 SQL/NOSQL/SYSTEMのいずれか SQL 文字列型 ×
操作内容 要求種別がSQLの場合はSELECT/DML/DDL/DCLのいずれか、NoSQLの場合はAPIに対応するコマンド名、管理コマンドの場合はコマンド名 SELECT 文字列型 ×
操作対象 要求種別がSQLの場合はSQL名、NoSQLの場合は対象コンテナもしくは索引名、管理コマンドの場合はコマンド名　 SELECT * from table1 文字列型 ×
操作識別子 ステートメント識別子(内部情報)。
32文字から構成されるUUIDを8/4/4/4/12文字単位”-“で分割し、末尾に”:”と任意の識別数字を加えたもの		 6a4ccd7a-818a-45e8-88c7-1ebda78d1959:1 文字列型 ×
操作情報詳細 監査ログの詳細情報。
エラー時にはメッセージ。
必要に応じて以下のキーバリュー形式で情報が付与される。
‘キー名’ = [‘バリュー値1’, ‘バリュー値2’,…]		 “‘tableName’=[‘table1’] Execute SQL failed (reason=CREATE TABLE failed …” ×  

SQLに対する操作対象のテーブル名は解析内容によっては対象が複数個数になることがあります。これらは、操作情報詳細’tableName’=[‘テーブル名1’, ‘テーブル名2’…]の項目が追加されます。

以下に幾つかサンプルを示します。

a) アクセスログの取得

AUDIT_CONNECT=INFOとして、JDBCを用いて以下のような接続を行います。

Connection con = DriverManager.getConnection(url, user, password);

この場合以下の監査ログが出力されます。ユーザ名(user1)、IPアドレス(192.0.2.1:63482)、対象のデータベース(db1)などの情報が記録されていることが分かります。

023-03-27T17:16:13.507+09:00 TDSL1234 1848 INFO AUDIT_CONNECT
[10917:TXN_AUDIT_CALLED]
user1 user db1 app1
192.0.2.1:63482 203.0.113.1:50001
SQL CONNECT 
"" 0000-00-00-00-000000:0 ""

コネクションをクローズ、もしくは切断すると、以下の監査ログが出力されます。

2023-03-24T17:46:15.723+09:00 TDSL1234 1848 INFO AUDIT_CONNECT
[10917:TXN_AUDIT_CALLED]
user1 user db1 app1
192.0.2.1:63482 203.0.113.1:50001 
SQL DISCONNECT 
"" 0000-00-00-00-000000:0 ""

b) 操作ログの取得

AUDIT_SQL_READ=INFOとして、JDBCを用いて以下のSQLを実行します。

SELECT * FROM table1 A, table2 B WHERE A.col1 = B.col2

この場合、以下の監査ログが記録されます。アクセスログと同様の接続情報に加え、実行したSQLのSQL文字列(SELECT * FROM table1 A, …)、SQL種別(SELECT), 操作識別子(282d7b10-…)およびアクセス対象となるテーブル名のリスト(table1, table2)が監査ログとして記録されますので、それら操作ログを分析します。

2023-03-24T17:06:53.848+09:00 TDSL1234 16812 INFO AUDIT_SQL_READ [200909:SQL_EXECUTION_INFO]
user1 user db1 app1
192.0.2.1:63482 203.0.113.1:50001 
SQL SELECT "SELECT * FROM table1 A, table2 B WHERE A.col1 = B.col2"
282d7b10-f7f0-4dd8-bef-25eb30e5c2f4:5
"'tableName'=['table1','table2']"

c) エラーログの解析

AUDIT_SQL_READ=INFOもしくはERRORとして、JDBCを用いて以下のSQLを実行します。table1にnotFoundColumnカラムがないためエラーとなるクエリです。

SELECT notFoundColumn FROM table1

この場合、以下のエラーログが出力されます。

2023-03-24T17:24:23.278+09:00 TDSL1234 25464 ERROR AUDIT_SQL_READ
[240008:SQL_COMPILE_COLUMN_NOT_FOUND]
user1 user db1 app1
192.0.2.1:63482 203.0.113.1:50001 SQL
SELECT "SELECT notFoundColumn FROM table1"
282d7b10-f7f0-4dd8-bef-25eb30e5c2f4:6 
"'tableName'=['table1']
Column not found (name=notFoundColumn) on executing statement..."

d) 対象カテゴリ以外の解析

AUDIT_SQL_READ=CRITICALとして同様に以下を実施します。

SELECT notFoundColumn FROM table1

この場合、c)と違ってエラー発生時も監査ログに出力は記録されません。

サイト間データベースレプリケーション【EE限定】

目的

サイト間データベースレプリケーション機能を利用することで、障害発生時のディザスタリカバリや、複数サイトを横断したリードレプリカの作成が可能です。この機能には、以下の2つの構成方式があります。稼働系クラスタを「プライマリ」、待機系クラスタを「スタンバイ」と呼びます。

1. コールドスタンバイ方式

コールドスタンバイ方式では、スタンバイ側のサーバ群（クラスタ）は通常非稼働状態で運用されます。障害が発生した際に、スタンバイ側がレプリケーションデータを読み込み、その後プライマリとして切り替わります。この方式は、障害復旧時間に余裕があるディザスタリカバリに適しています。

2. ホットスタンバイ方式

ホットスタンバイ方式では、スタンバイ側のデータベースが常に稼働状態で運用されます。スタンバイ側はプライマリからのレプリケーションデータを継続的に受け取り、最新の状態を維持します。このため、コールドスタンバイ方式と比較して、障害復旧時間を大幅に短縮できます。

さらに、GridDBではスタンバイ側をリードレプリカとして運用することも可能です。本章では、このホットスタンバイ方式を用いた運用方法について詳しく説明します。

機能概要

サイト間データベースレプリケーションにおけるホットスタンバイ方式には、以下の2つの方法があります。どちらを選択するかは、障害復旧時間、復旧時点、レプリケーションラグ、運用コストなどの要件に基づいて決定します。

1. ファイルベースレプリケーション

プライマリサーバで生成されたトランザクションログファイルをスタンバイサーバに転送し、それを適用することでレプリケーションを実現する方式です。この方式では、トランザクションログファイルの生成、転送、適用はサーバ間で自動的に行われません。代わりに、サーバが提供するレプリケーション機能を活用して手動で実施します。

2. メモリベースレプリケーション

プライマリサーバとスタンバイサーバ間で、トランザクションログをメモリベースで直接レプリケーションする方式です。この方式では、トランザクションログの生成、転送、適用がサーバ間で自動的に行われます。

どちらの方式も、それぞれの特性を理解した上で、システム要件に最適な方法を選択してください。

ファイルベースレプリケーション

ファイルベースレプリケーションでは、トランザクションログファイルを使用してデータのレプリケーションを行います。この方式に必要なサーバ機能は以下の通りです。それぞれの詳細については、次節で説明します。

a) ベースDB作成と自動アーカイブ機能 ベースラインとなるデータベースファイル（ベースDB）を作成し、その後に生成されたトランザクションログを指定フォルダに自動的に複製する機能です。この機能により、レプリケーションに必要なデータを効率的に管理できます。

b) スタンバイモード機能 クラスタをリードオンリー（参照専用）として稼働させる機能です。このモードでは、クライアントからの更新要求はエラーとなり、データの整合性を保ちながらスタンバイ環境を維持できます。

c) トランザクションログ適用機能 指定されたトランザクションログをサーバに適用する機能です。この機能を使用することで、スタンバイサーバに対してプライマリサーバの更新内容を反映させることができます。

ベースライン生成と自動アーカイブ機能

自動アーカイブ機能は、以下の特徴を持つ機能です：

設定パラメータ

以下は、自動アーカイブ機能に関連する設定パラメータです：

パラメータ名 データ型 デフォルト値 説明
/dataStore/enableAutoArchive bool false 自動アーカイブ機能を有効にするかどうかを指定します。
/dataStore/autoArchiveName string "" 自動アーカイブの出力先フォルダ名を指定します。
/dataStore/enableAutoArchiveOutputInfo bool true 自動アーカイブ時に追加情報を出力するかどうかを指定します。
/dataStore/enableAutoArchiveOutputInfoPath string cluster 追加情報の出力先フォルダ名を指定します。

使用例

自動アーカイブ機能を有効にするには、以下の手順を実行してください：

  1. ノード定義ファイルで以下の設定を行います： 
      {
          "dataStore": {
                  "enableAutoArchive": true,
                  "autoArchiveName": "arch",
                  "enableAutoArchiveOutputInfo": true,
                  "enableAutoArchiveOutputInfoPath": "cluster"
          }
  }
  2. 設定後、gs_autoarchive コマンドを実行してアーカイブを開始します： 
      $ gs_autoarchive -u admin/admin --start
  3. アーカイブデータは、指定したフォルダ（例: /var/lib/gridstore/backup/arch）に保存されます。

注意事項

自動アーカイブ機能の有効化

自動アーカイブ機能を有効にするには、以下の手順でノード定義ファイルを設定します：

  1. /dataStore/enableAutoArchive を true に設定します。
  2. /dataStore/autoArchiveName にアーカイブ名（保存先ディレクトリ名）を指定します。

設定後、gs_autoarchive コマンドを実行することで、自動アーカイブを開始できます。

# 自動アーカイブが保存されるディレクトリ（バックアップディレクトリ）を確認
$ cat /var/lib/gridstore/conf/gs_node.json
{
    "dataStore": {
        "dbPath": "/var/lib/gridstore/data",
        "transactionLogPath": "/var/lib/gridstore/txnlog",
        "backupPath": "/var/lib/gridstore/backup",
        "storeMemoryLimit": "1024MB",
        "concurrency": 4,
        "logWriteMode": 1,
        "persistencyMode": "NORMAL",
        "autoArchiveName": "arch"
    }
    ...
}

# 自動アーカイブの開始
$ gs_autoarchive -u admin/admin --start

自動アーカイブ有効時のファイル構成

自動アーカイブを有効にすると、以下のようなファイル構成になります：

/var/lib/gridstore
    └── backup                               # バックアップ/アーカイブ基点ディレクトリ (/dataStore/backupPath)
            ├── arch                             # アーカイブ名 (/dataStore/autoArchiveName)
            │   ├── gs_backup_info.json          # アーカイブ情報ファイル
            │   ├── gs_backup_info_digest.json   # アーカイブダイジェスト情報ファイル
            │   ├── gs_lsn_info.json             # アーカイブLSN情報ファイル
            │   ├── gs_auto_archive_command_param.json # アーカイブ実行コマンドパラメータファイル
            │   ├── data                         # データフォルダ (/dataStore/dbPath)
            │   │   ├── 0                        # パーティション番号0
            │   │   │   ├── 0_part_0.dat         # データファイルアーカイブ
            │   │   │   ├── 0_4.cplog            # チェックポイントログアーカイブ
            │   │   │   └── ...
            │   │   ├── 1                        # パーティション番号1
            │   │   │   └── ...
            │   │   └── ...
            │   ├── txnlog                       # トランザクションログフォルダ (/dataStore/transactionLogPath)
            │   │   ├── 0                        # パーティション番号0
            │   │   │   ├── 0_5.xlog             # トランザクションログアーカイブ
            │   │   │   ├── 0_6.xlog
            │   │   │   └── ...
            │   │   ├── 1                        # パーティション番号1
            │   │   │   └── ...
            │   │   └── ...
            │   ├── cluster                      # クラスタメタ情報ディレクトリ (/dataStore/autoArchiveOutputClusterInfoPath)
            │   │   ├── RECOVERY_0_1_100.info    # クラスタリカバリ情報ファイル
            │   │   ├── ROLE_0_1_100_0_OWNER.info # クラスタロール情報ファイル
            │   │   ├── CP_0_1_100_200.info      # クラスタチェックポイント情報ファイル
            │   │   └── ...
            │   └── ...
            ├── backup1                          # 別のバックアップ名
            │   └── ...
            └── backup2                          # 別のバックアップ名
                    └── ...

注意事項

スタンバイモード機能

スタンバイモード機能は、クラスタをリードオンリー（参照専用）として稼働させるための機能です。このモードでは、クライアントからの更新要求はすべてエラーとなります。

主な特徴:

設定パラメータ:

パラメータ データ型 デフォルト値 説明
/cluster/enableStandbyMode bool false スタンバイモード機能を有効にするかどうかを指定します。

スタンバイモードの有効化: スタンバイモード機能を有効にするには、ノード定義ファイルで以下の設定を行います。

/cluster/enableStandbyMode=true

この設定はスタンバイモード機能を有効にするだけであり、実際のモード変更は運用コマンド gs_standby を使用して行います。デフォルトでは無効（false）となっています。

スタンバイモードの設定手順:

以下は、gs_standby コマンドを使用した一連の操作例です。

# スタンバイモードを有効化
$ gs_standby -u admin/admin --true

# 現在のスタンバイモードの確認
$ gs_standby -u admin/admin
{
    "standby": true  # スタンバイモードが有効
}

# 全ノードにスタンバイモードを設定

# クラスタ構成
$ gs_joincluster -u admin/admin -c cluster1 -n 5

# アプリケーションを起動し、参照専用アクセスであることを確認

# 設定変更のためクラスタを一時停止
$ gs_stopcluster -u admin/admin

# スタンバイモードを無効化
$ gs_standby -u admin/admin --false

# スタンバイモードの確認
$ gs_standby -u admin/admin
{
    "standby": false  # スタンバイモードが無効
}

# 全ノードに設定を適用

# クラスタを再構成
$ gs_joincluster -u admin/admin -c cluster1 -n 5

# アプリケーションを起動し、参照および更新アクセスが可能であることを確認

注意事項:

トランザクションログ適用機能

トランザクションログ適用機能は、指定されたトランザクションログファイルを待機系サーバに適用し、プライマリサーバの更新内容をスタンバイサーバに反映させるための機能です。

主な特徴:

設定パラメータ:

パラメータ データ型 デフォルト値 説明
/sync/redoLogErrorKeepInterval int (秒) 600秒 トランザクションログ適用エラーが表示される保持期間を指定します。
/sync/redoLogMaxMessageSize int (バイト) 2097152 (2MB) トランザクションログ適用の分割実行時の読み込みサイズを指定します。

トランザクションログ適用手順:

  1. ログ適用の依頼
    • gs_redo コマンドを使用して、適用対象のログを指定します。
    • コマンド実行時にリクエストID (uuid, requestId) が返されます。
     $ gs_redo -u admin/admin --redo --partitionId 0 --logFilePath /var/lib/gridstore --logFileName=0_1.xlog
 {
      "requestId": 1,
      "uuid": "3238cc45-a265-4825-b45f-30e9ce8dd3d2"
 }
  2. 適用状況の確認
    • gs_redo コマンドの --show オプションを使用して、進捗状況を確認します。
    • ステータス (status) は以下のいずれかです:
      • WAIT: REDO要求は受理されたが、まだ実行されていない。
      • RUNNING: 現在実行中。
      • FAIL: 実行結果がエラー。
     $ gs_redo -u admin/admin --show --uuid 3238cc45-a265-4825-b45f-30e9ce8dd3d2 --partitionId 0 --requestId 1
 {
      "backupErrorList": [],
      "counter": 0,
      "logFileDir": "/var/lib/gridstore",
      "logFileName": "0_1.xlog",
      "partitionId": 0,
      "requestId": 1,
      "startTime": "2024-03-08T15:22:04.939+09:00",
      "status": "RUNNING",
      "uuid": "3238cc45-a265-4825-b45f-30e9ce8dd3d2"
 }
  3. エラー発生時の対応
    • ステータスが FAIL の場合、エラー内容は /sync/redoLogErrorKeepInterval で指定された期間保持されます。
    • エラー内容を確認し、原因を修正した後、再度ログ適用を実行してください。

注意事項:

以下の図は、トランザクションログ適用の流れを示しています。

トランザクションログ適用
トランザクションログ適用の流れ

運用手順

以下の4つの運用について順次説明します。

  1. スタンバイ準備
  2. 定常運用
  3. フェイルオーバ
  4. スイッチオーバ

以下では、3台構成の例を用いて説明します。コマンド実行例では、$ をプロンプトとして使用し、プライマリ側の操作を [primary*]、スタンバイ側の操作を [standby*] として表記します。

サイト間データベースレプリケーション
サイト間データベースレプリケーション

ノード構成 (3台構成)

役割 ホスト名 IPアドレス
プライマリ primary0 192.168.10.11
  primary1 192.168.10.12
  primary2 192.168.10.13
スタンバイ standby0 192.168.11.11
  standby1 192.168.11.12
  standby2 192.168.11.13

ディレクトリ構成

プライマリ側

/primary/cluster/
    ├── conf
    │   ├── gs_node.json
    │   ├── (gs_stable_goal.json) # 自動生成
    │   └── (gs_standby.json)     # 自動生成
    ├── data
    │   ├── 0
    │   └── ...
    ├── txnlog
    │   ├── 0
    │   └── ...
    └── backup
        └── arch                # スタンバイ時は不要
            ├── data
            │   ├── 0
            │   └── ...
            └── txnlog
                ├── 0
                └── ...

スタンバイ側

/standby/cluster/
    ├── conf
    │   ├── gs_node.json
    │   ├── gs_stable_goal.json  # 自動生成
    │   └── gs_standby.json      # 自動生成
    ├── data
    │   ├── 0
    │   └── ...
    ├── txnlog
    │   ├── 0
    │   └── ...
    ├── backup                   # スタンバイ時は不要
    └── tmp_txnlog               # 適用対象ログの一時保存フォルダ (運用側で事前に作成)
        ├── 0
        └── ...
スタンバイ準備

以下の手順でスタンバイ準備を行います。

順序 対象 手順
1 プライマリ
スタンバイ		 ノード定義ファイルの設定
2 プライマリ ベースラインの生成
3 スタンバイ 転送先の決定
4 プライマリ ベースラインの転送
5 スタンバイ スタンバイクラスタの開始
スタンバイ準備
スタンバイ準備

1. ノード定義ファイルの設定（プライマリ/スタンバイ）

運用開始前に、プライマリおよびスタンバイのノード定義ファイル（gs_node.json）に以下の設定を行います。この設定は、プライマリとスタンバイの役割が途中で変更される可能性を考慮したものです。

以下は、設定例です：

{
    "dataStore": {
        ...
        "enableAutoArchive": true,
        "autoArchiveName": "arch",
        ...
    },
    ...
    "cluster": {
        ...
        "enableStandbyMode": true,
        "enableStableGoal": true,
        "initialGenerateStableGoal": true,
        ...
    }
}

これらの設定を適用することで、プライマリとスタンバイの切り替えや運用がスムーズに行えるようになります。

2. ベースラインの生成（プライマリ）

プライマリのベースラインを生成します。この操作により、指定したフォルダ（例: /primary/cluster/backup/arch）にベースラインデータとトランザクションログが自動的に出力されます。 以下のコマンドを実行してください：

[primary*]$ gs_autoarchive -u admin/admin --start

実行が成功すると、指定フォルダにベースラインデータが保存され、以降のレプリケーションに使用可能な状態となります。

3. 転送先の決定（スタンバイ）

プライマリで出力されるトランザクションログを、スタンバイ側のどのノードに転送・適用するかを決定します。これには、スタンバイクラスタのクラスタパーティション配置表が必要です。以下の手順で配置表を生成します。

1) スタンバイ側のノードを起動し、クラスタを構成します。

```bash
[standby*]$ gs_startnode -u admin/admin
[standby*]$ gs_joincluster -c cls1 -n -3 -u admin/admin
```

クラスタ構成が成功すると、各ノードのノード定義ファイルと同じディレクトリに `gs_stable_goal.json` というファイルが自動的に作成されます。このファイルは、クラスタパーティションのオーナーおよびバックアップ情報を記録しています。**このファイルは削除せずに残しておいてください。**

2) クラスタを停止し、不要なデータを削除する

`gs_stable_goal.json` ファイルの存在を確認した後、クラスタを停止します。クラスタ停止後、データファイルやトランザクションログなどの不要なファイルを削除します。

```bash
[standby*]$ gs_stopcluster -u admin/admin
[standby*]$ gs_stopnode -u admin/admin
[standby*]$ rm -r -f /standby/cluster/data
[standby*]$ rm -r -f /standby/cluster/txnlog
```

3) gs_stable_goal.json の内容を確認する

`gs_stable_goal.json` ファイルには、各パーティションのオーナーおよびバックアップノードの情報が記録されています。以下はサンプル内容です。この例では、スタンバイ側のクラスタパーティション番号0のオーナーはアドレス `192.168.11.10`、バックアップはアドレス `192.168.11.11` となります。ポート番号はいずれも`10010`となります。

```json
[
    {
        "backup": [{"address": "192.168.11.11", "port": 10010}],
        "owner": {
                "address": "192.168.11.10",
                "port": 10010
        },
        "pId": "0"
    },
    ...
]
``` この情報を基に、プライマリからスタンバイへのトランザクションログ転送先を決定します。

4. ベースラインの転送[プライマリ]

スタンバイクラスタの起動に必要なベースラインデータを転送します。以下に、クラスタパーティション0に対する一連の処理の流れを示します。

ベースライン転送
ベースライン転送

1) プライマリ側のクラスタパーティション情報を取得

プライマリ側で `gs_partition` コマンドを実行し、各クラスタパーティションのオーナノード情報を取得します。

```bash
[primary*]$ gs_partition -u admin/admin
[
    {
        "backup": [{"address": "192.168.10.11", "port": 10010}],
        "owner": {
                "address": "192.168.10.10",
                "port": 10010
        },
        "pId": "0"
    },
    ...
]
```

2) スタンバイ側のクラスタパーティション情報を確認

スタンバイ側で、事前に生成した `gs_stable_goal.json` を確認し、各クラスタパーティションのオーナおよびバックアップノード情報を取得します。

```json
# スタンバイ側の gs_stable_goal.json の内容
[
    {
        "backup": [{"address": "192.168.11.11", "port": 10010}],
        "owner": {
                "address": "192.168.11.10",
                "port": 10010
        },
        "pId": "0"
    },
    ...
]
```

3) 転送情報の整理

上記の情報を基に、パーティション0に対する転送情報を以下のように整理します。

- **転送元**
- アドレス: `192.168.10.10` (primary0, オーナ)
- 対象ディレクトリ: `/primary/cluster/backup/arch/data/0`, `/primary/cluster/backup/arch/txnlog/0`
- **転送先**
- オーナノード: `192.168.11.10` (standby0)
- バックアップノード: `192.168.11.11` (standby1)
- 対象ディレクトリ: `/standby/cluster/data`, `/standby/cluster/txnlog`

4) データの転送

以下のコマンドを使用して、プライマリからスタンバイへデータを転送します。

    # プライマリ -> スタンバイ (オーナノード)
    [primary*]$ rsync -avz /primary/cluster/backup/arch/data/0 user@standby0:/standby/cluster/data
    [primary*]$ rsync -avz /primary/cluster/backup/arch/txnlog/0 user@standby0:/standby/cluster/txnlog

    # プライマリ -> スタンバイ (バックアップノード)
    [primary*]$ rsync -avz /primary/cluster/backup/arch/data/0 user@standby1:/standby/cluster/data
    [primary*]$ rsync -avz /primary/cluster/backup/arch/txnlog/0 user@standby1:/standby/cluster/txnlog

5) 全クラスタパーティションへの適用

上記の手順を、すべてのクラスタパーティションに対して繰り返し実施してください。

5. スタンバイクラスタの開始[スタンバイ]

以下の手順でスタンバイクラスタを開始します。

1) 各ノードの起動

各ノードを起動します。

```bash
[standby*]$ gs_startnode
```

2) スタンバイモードの設定

各ノードをスタンバイモードに設定します。

```bash
[standby*]$ gs_standby --true -u admin/admin
```

3) クラスタの稼働

クラスタを構成します。これ以降は、\[2. 定常運用\]の手順に従って運用を行います。

```bash
[standby*]$ gs_joincluster -c cls1 -n -3 -u admin/admin
```

GridDBサービスを利用したクラスタ構成

スタンバイモードの設定はクラスタ離脱状態で行う必要があります。しかし、GridDBサービス経由で起動する場合、クラスタが自動構成されますのでクラスタ構成後、gs_stopclusterを行って実施した後にgs_joinclusterで再度クラスタを構成するか、以下の方法を実施してください。

1) gs_standby.json ファイルの作成

以下の内容で `gs_standby.json` ファイルを作成します。

```json
{"standby": true}
```

2) ファイルの配置

作成した `gs_standby.json` ファイルをノード定義ファイルと同じディレクトリに配置します。

```bash
cp gs_standby.json /standby/cluster/conf
```

3) GridDBサービスの起動

GridDBサービスを利用してクラスタを構成します。

```bash
[standby*]$ sudo systemctl start gridstore
```
定常運用

以下は、定常運用時の手順を示します。順序に従って操作を実行してください。

順序 対象 手順
1 プライマリ
スタンバイ		 クラスタ構成の確認と更新
2 プライマリ トランザクションログの転送
3 スタンバイ トランザクションログの適用（REDO）
定常運用
定常運用の流れ

1. クラスタ構成の確認と転送情報の更新[プライマリ/スタンバイ]

各パーティションのプライマリ（転送元）のオーナーノードから、スタンバイ（転送先）のオーナーノードへトランザクションログファイルを転送します。この操作では、プライマリとスタンバイの両方で gs_partition コマンドを使用してクラスタパーティション配置表を確認します。通常、障害が発生していない限り、[1. スタンバイ準備]で転送したアドレスと同じになりますが、必ず現在の状態を確認してください。

1) プライマリのクラスタパーティション構成確認

以下のコマンドを実行して、プライマリのクラスタパーティション構成を確認します。

```bash
# プライマリのクラスタパーティション構成を確認
[primary*]$ gs_partition -u admin/admin
```

実行結果の例：

```json
[
    {
        "backup": [{"address": "192.168.10.11", "port": 10010}],
        "owner": {
            "address": "192.168.10.10",
            "port": 10010
        },
        "pId": "0"
    },
    ...
]
```

2) スタンバイのクラスタパーティション構成確認

以下のコマンドを実行して、スタンバイのクラスタパーティション構成を確認します。

```bash
# スタンバイのクラスタパーティション構成を確認
[standby*]$ gs_partition -u admin/admin
[
    {
        "backup": [{"address": "192.168.11.11", "port": 10010}],
        "owner": {
            "address": "192.168.11.10",
            "port": 10010
        },
        "pId": "0"
    },
    ...
]
```

**注意点**

- プライマリとスタンバイのクラスタパーティション構成を比較し、転送元（プライマリのオーナーノード）と転送先（スタンバイのオーナーノード）が正しいことを確認してください。
- 障害や構成変更が発生している場合、転送元・転送先のアドレスが変更されている可能性があります。その場合は、最新の構成に基づいて転送を行ってください。
- 転送元・転送先のアドレスが一致している場合でも、必ず最新の状態を確認することを推奨します。

2. トランザクションログの転送（プライマリ）

スタンバイへ未転送（差分）のトランザクションログを特定し、転送します。転送元および転送先のアドレスは、手順1で取得した情報を使用します。スタンバイ側でトランザクションログを適用する際には、gs_redo コマンドを使用します。そのため、適用先となる一時保存ディレクトリを事前に作成しておきます。

[standby*]$ mkdir -p /standby/cluster/tmp_txnlog/0
[standby*]$ mkdir -p /standby/cluster/tmp_txnlog/1
...

以下は、パーティション0に対する転送情報の例です。転送先ディレクトリが /standby/cluster/txnlog ではないことに注意してください。

転送先情報に従い、データを転送します。

[primary0]$ rsync -avz /primary/cluster/backup/arch/txnlog/0/0_1.xlog user@standby0:/standby/cluster/tmp_txnlog/0

同様の手順をすべてのクラスタパーティションに対して実施します。以下は例です。

[primary0]$ rsync -avz /primary/cluster/backup/arch/txnlog/0/0_1.xlog user@standby0:/standby/cluster/tmp_txnlog/0
[primary1]$ rsync -avz /primary/cluster/backup/arch/txnlog/1/1_1.xlog user@standby1:/standby/cluster/tmp_txnlog/1
...

以下の図は、クラスタパーティション0に着目した一連の処理の流れを示しています。

定常運用時の手順
定常運用時の手順

3. トランザクションログの適用（REDO）（スタンバイ）

プライマリから送信されたトランザクションログがスタンバイに到着した後、gs_redo コマンドを使用してトランザクションログを適用します。コマンド実行時にリクエストが受理されると、対応するリクエストIDが発行されます。

[standby*]$ gs_redo -u admin/admin --redo --partitionId 0 --logFilePath /standby/cluster/tmp_txnlog/0 --logFileName 0_1.xlog
{"uuid":"3238cc45-a265-4825-b45f-30e9ce8dd3d2","requestId":1}

トランザクションログの適用は非同期で実行されるため、進捗状況を確認する必要があります。以下の例では、status が RUNNING であり、処理が継続中であることを示しています。

[standby*]$ gs_redo -u admin/admin --show --uuid 3238cc45-a265-4825-b45f-30e9ce8dd3d2 --partitionId 0 --requestId 1
{
 "partitionId": 0,
 "requestId": 1,
 "uuid": "3238cc45-a265-4825-b45f-30e9ce8dd3d2",
 "status": "RUNNING"
 ...
}

一定時間経過後に再度確認します。結果が表示されない場合は、正常終了を意味します。この場合、次の未適用トランザクションログが存在する場合は、その適用を行います。

[standby*]$ gs_redo -u admin/admin --show --uuid 3238cc45-a265-4825-b45f-30e9ce8dd3d2 --partitionId 0 --requestId 1
# 結果なしの場合は正常終了を意味する

# 次の未適用トランザクションログの適用
[standby*]$ gs_redo -u admin/admin --redo --partitionId 0 --logFilePath /standby/cluster/tmp_txnlog/0 --logFileName 0_2.xlog
{"uuid":"3238cc45-a265-4825-b45f-30e9ce8dd3d2","requestId":2}
...

エラーが発生した場合、status が FAIL となります。errorCode や errorName を確認し、原因を特定して修正した後、再実行してください。

[standby*]$ gs_redo -u admin/admin --show --uuid 3238cc45-a265-4825-b45f-30e9ce8dd3d2 --partitionId 0 --requestId 1
{
 "partitionId": 0,
 "requestId": 1,
 "uuid": "3238cc45-a265-4825-b45f-30e9ce8dd3d2",
 "status": "FAIL",
 "errorCode": 20050,
 "errorName": "REDO_INVALID_READ_LOG",
 ...
}

トランザクションログの適用が成功すると、スタンバイクラスタ内のバックアップノードにも自動的にレプリケーションが行われます。

以上の手順（1～3）を定期的に実行することで、定常運用を維持できます。実行間隔は、データ更新量、ネットワーク性能、チェックポイント時間（ログ出力単位）を考慮して決定してください。

フェイルオーバ

プライマリ障害時のフェイルオーバ手順

以下は、プライマリ障害時に実施するフェイルオーバ手順です。順序に従って操作を実行してください。

順序 対象 手順
1 プライマリ
アプリケーション		 アプリケーションを停止します。
2 プライマリ 未適用のトランザクションログを適用します。
3 スタンバイ プライマリクラスタへの昇格を判定します。
4 スタンバイ スタンバイモードを解除します。
5 スタンバイ→新プライマリ 新プライマリクラスタを開始します。
6 アプリケーション アプリケーションを再開します。
7 新プライマリ
旧プライマリ→新スタンバイ		 旧プライマリクラスタをスタンバイとして準備し再開します。
フェイルオーバ
フェイルオーバ手順の概要

1. アプリケーションの停止[プライマリ/アプリケーション]

プライマリクラスタが稼働していないことを確認し、アプリケーションをすべて停止します。これにより、データの整合性を保ちながら切り替え作業を進めることができます。

2. 未適用トランザクションログの適用[スタンバイ]

スタンバイ側で、プライマリから受信済みの未適用トランザクションログがある場合、それらをすべて適用します。以下のコマンドを使用して、ログを順番に適用してください。

[standby*]$ gs_redo -u admin/admin --redo --partitionId 0 --logFilePath /standby/cluster/tmp/0 --logFileName=0_142.xlog
# 最終ログ(例: 0_143.xlog)を適用
[standby*]$ gs_redo -u admin/admin --redo --partitionId 0 --logFilePath /standby/cluster/tmp/0 --logFileName=0_143.xlog

3. プライマリクラスタへの昇格判定[スタンバイ]

プライマリ障害時点の状態にできるだけ近づけるため、プライマリ側のアーカイブフォルダにアクセス可能か再確認します。アクセス可能であれば、未適用のトランザクションログをさらに適用してください。

適用可能なトランザクションログがすべて処理された場合、スタンバイをプライマリに昇格させる準備を進めます。以降の手順に従って、スタンバイをプライマリとして稼働させます。

4. スタンバイモードの解除[スタンバイ]

スタンバイクラスタを一時的に離脱状態にするため、gs_stopcluster コマンドを使用してクラスタを停止します。

[standby*]$ gs_stopcluster -u admin/admin

その後、スタンバイ側の全ノードに対して gs_standby コマンドを実行し、スタンバイモードを解除します。

[standby*]$ gs_standby --false -u admin/admin

5. 新プライマリクラスタの開始[スタンバイ→新プライマリ]

旧プライマリが復帰した場合に備え、自動アーカイブ機能を有効にしてベースラインとそれ以降のトランザクションログを保持します。

[standby*]$ gs_autoarchive -u admin/admin --start

全ノードの設定が完了したら、新プライマリクラスタを構成します。

[standby*]$ gs_joincluster -c cls1 -n -3 -u admin/admin

6. アプリケーションの再開[アプリケーション]

旧プライマリに接続していたアプリケーションの接続先を新プライマリクラスタに変更します。その後、アプリケーションを再起動し、サービスを再開します。この時点で新プライマリ側でのサービスが稼働状態となります。

7. 旧プライマリクラスタのスタンバイ準備と再開[新プライマリ/旧プライマリ→新スタンバイ]

旧プライマリが復旧した場合、旧プライマリに存在するデータファイルおよびトランザクションログファイルを削除し、新スタンバイとしての準備を行います。この準備手順は、[1. スタンバイ準備]と同じ手順に従います。

準備が完了すると、旧プライマリは新スタンバイとして稼働し、旧スタンバイは新プライマリとして運用を継続します。この状態で、通常の運用手順（[2. 定常運用]）に戻ります。

なお、旧プライマリを再びプライマリとして復帰させる場合は、[3. フェイルオーバ]手順ではなく、[4. スイッチオーバ]手順を実施することを推奨します。

スイッチオーバ

スイッチオーバ手順

スイッチオーバは予期せぬ障害に対応するフェイルオーバとは異なり、計画的に実施することが可能です。そのため、プライマリとスタンバイのデータベース状態を完全に一致させることができます。以下にスイッチオーバ手順を示します。

順序 対象 手順
1 アプリケーション アプリケーションの停止
2 プライマリ レプリケーション対象データの確定
3 プライマリ プライマリクラスタを停止
4 プライマリ 全トランザクションログの転送
5 スタンバイ 全トランザクションログの適用 (REDO)
6 スタンバイ クラスタ一致の確認
7 スタンバイ スタンバイクラスタを停止
8 プライマリ プライマリクラスタのスタンバイクラスタへの移行準備
9 スタンバイ スタンバイクラスタをプライマリクラスタへの移行準備
10 スタンバイ→新プライマリ 新プライマリクラスタの稼働
11 プライマリ→新スタンバイ 新スタンバイクラスタの稼働
12 アプリケーション アプリケーションの再開
スイッチオーバ
スイッチオーバ

1. アプリケーションの停止[アプリケーション]

スイッチオーバ作業中は短時間のサービス停止が発生するため、事前に利用者へ告知を行い、アプリケーションを一時停止します。スイッチオーバ後は接続先がスタンバイ側に変更されるため、事前にアプリケーションの接続先を変更しておきます。

2. レプリケーション対象データの確定[プライマリ]

プライマリの現時点での各クラスタパーティションのオーナーノードを取得し、オーナーのLSNを記録します。このLSNがスイッチオーバ時点の最終値となります。

次に、チェックポイントを実行してレプリケーション対象データを確定させます。

# チェックポイントを実行
[primary*]$ gs_checkpoint -u admin/admin

チェックポイント完了後、各オーナーノードのLSN情報を記録します。

# 完了時点のLSN情報を記録
[primary*]$ gs_partition -u admin/admin > primary_latest.json

3. プライマリクラスタの停止[プライマリ]

プライマリクラスタを停止します。以下のコマンドを実行してください。

[primary*]$ gs_stopcluster -u admin/admin

停止後、以降の作業で自動アーカイブ機能は不要となるため、無効化します。

[primary*]$ gs_autoarchive --stop

4. 全トランザクションログの転送[プライマリ]

プライマリで出力されたすべてのトランザクションログをスタンバイに転送します。以下のコマンドを使用して、漏れなく転送してください。

# トランザクションログの転送
[primary0]$ rsync -avz /primary/cluster/backup/arch/txnlog/0/0_240.xlog user@standby0:/standby/cluster/tmp/0
# 最終トランザクションログの転送
[primary0]$ rsync -avz /primary/cluster/backup/arch/txnlog/0/0_241.xlog user@standby0:/standby/cluster/tmp/0

すべてのトランザクションログが転送されたことを確認してください。

5. トランザクションログの適用 (REDO) [スタンバイ]

スタンバイ側で、すべてのトランザクションログを漏れなく適用します。以下のコマンドを使用して、順番にトランザクションログを適用してください。

# トランザクションログの適用
[standby*]$ gs_redo -u admin/admin --redo --partitionId 0 --logFilePath /standby/cluster/tmp/0 --logFileName=0_240.xlog

# 最終トランザクションログの適用
[standby*]$ gs_redo -u admin/admin --redo --partitionId 0 --logFilePath /standby/cluster/tmp/0 --logFileName=0_241.xlog

6. クラスタ状態の確認 [スタンバイ]

スタンバイ側で、各パーティションのオーナーノードのLSNが、手順 2 で取得した primary_latest.json に記録されたプライマリ側のオーナーLSNと一致しているか確認します。一致していれば、レプリケーションが正常に完了したことを意味します。

7. スタンバイクラスタの停止 [スタンバイ]

スタンバイクラスタを停止します。以下のコマンドを実行してください。

[standby*]$ gs_stopcluster -u admin/admin

これで、スタンバイクラスタの停止が完了します。

8. プライマリクラスタをスタンバイクラスタへ移行する準備[プライマリ]

スイッチオーバの場合、フェイルオーバとは異なり、スタンバイ側のデータファイルやトランザクションログファイルを削除する必要はありません。

プライマリクラスタにスタンバイモードを設定します。以下のコマンドを実行してください。

[primary*]$ gs_standby --true -u admin/admin

9. スタンバイクラスタをプライマリクラスタへ移行する準備[スタンバイ]

スタンバイクラスタのスタンバイモードを解除します。以下のコマンドを実行してください。

[standby*]$ gs_standby --false -u admin/admin

スイッチオーバの場合、フェイルオーバとは異なり、ベースラインの再生成は不要です。そのため、この手順をスキップし、自動アーカイブを有効化します。以下のコマンドを実行してください。

[standby*]$ gs_autoarchive -u admin/admin --start --skipBaseline

これでスタンバイクラスタが新しいプライマリクラスタとして稼働する準備が整いました。

10. 新プライマリクラスタの稼働[スタンバイ→新プライマリ]

新しいプライマリクラスタを稼働させるには、以下のコマンドを実行します。

[standby*]$ gs_joincluster -c cls1 -n -3 -u admin/admin

これにより、スタンバイ側のクラスタが新しいプライマリクラスタとして稼働を開始します。

11. 新スタンバイクラスタの稼働[プライマリ→新スタンバイ]

旧プライマリクラスタを新しいスタンバイクラスタとして稼働させるには、以下のコマンドを実行します。

[primary*]$ gs_joincluster -c cls1 -n -3 -u admin/admin

これにより、旧プライマリクラスタが新しいスタンバイクラスタとして動作を開始します。

12. アプリケーションの再開[アプリケーション]

アプリケーションの接続先を新しいプライマリクラスタに変更した後、アプリケーションを再起動してサービスを再開します。これにより、通常の運用が再開されます。

以降は、[2. 定常運用] の手順に従って運用を継続してください。

メモリベースレプリケーション

メモリベースレプリケーションでは、プライマリで生成されたトランザクションログをメモリベースで直接スタンバイにレプリケーションします。この方式に必要なサーバ機能は以下の通りです。それぞれの詳細については、次節で説明します。

必要なサーバ機能

  1. ベースライン生成機能
    • スタンバイのベースDBを作成する機能です。オプションとしてアーカイブを作成することも可能です。
  2. スタンバイモード機能
    • クラスタをリードオンリー（参照専用）として稼働させる機能です。このモードでは、クライアントからの更新要求はすべてエラーとなります。
  3. サイト間連携機能
    • プライマリとスタンバイをオンライン状態で相互接続および監視します。プライマリで生成されたトランザクションログをスタンバイに自動的にレプリケーションする機能です。

ベースライン生成機能

メモリベース方式の主な特徴は以下の通りです：

自動アーカイブ機能の詳細については、こちらをご参照ください。

初期DB生成手順

以下に、メモリベース方式を利用する際の初期DB生成手順を示します。

1) バックアップディレクトリの確認
自動アーカイブが保存されるディレクトリを確認します。

```bash
$ cat /var/lib/gridstore/conf/gs_node.json
```

2) 自動アーカイブの開始
自動アーカイブを開始してベースDBを生成します。

```bash
$ gs_autoarchive -u admin/admin --start
```

  1. ベースDBの確認
    ベースDBが正常に生成されていることを確認します。

     $ gs_backuplist -u admin/admin

 BackupName   Status   StartTime                EndTime
 ------------------------------------------------------------------------
 arch         OK       2014-09-25T05:30:02+0900 2014-09-25T05:59:03+0900

  2. アーカイブの停止（オプション）
    メモリベース方式では、以降のトランザクションログは自動的にレプリケーションされるため、アーカイブを停止することも可能です。ただし、必要に応じて継続して保存することもできます。

     $ gs_autoarchive -u admin/admin --stop

    gs_autoarchive の代わりに gs_backup を使用してベースラインを生成する場合、以下の手順を実行してください。

  3. バックアップの作成
    以下のコマンドを実行して、バックアップを作成します。

     $ gs_backup -u admin/admin arch

  4. バックアップの確認
    作成されたバックアップが正常であることを確認するには、以下のコマンドを実行します。

     $ gs_backuplist -u admin/admin

 BackupName   Status   StartTime                EndTime
 ------------------------------------------------------------------------
 arch         OK       2014-09-25T05:30:02+0900 2014-09-25T05:59:03+0900

これにより、指定した名前（例: arch）でバックアップが作成され、ベースラインとして利用可能になります。

ファイル構成

メモリベース方式では、スタンバイのベースDBとして使用するデータフォルダが必須です。以下に、ファイル構成の例を示します。 以下の構成例では、/backup/archive/dataのフォルダがベースDBとなり、これをスタンバイのベースDBとして利用します。

/var/lib/gridstore
    ├── backup                               # バックアップ/アーカイブの基点ディレクトリ (/dataStore/backupPath)
    │   ├── archive                          # アーカイブ名 (/dataStore/autoArchiveName)
    │   │   ├── gs_backup_info.json              # アーカイブ情報ファイル
    │   │   ├── gs_backup_info_digest.json       # アーカイブダイジェスト情報ファイル
    │   │   ├── gs_lsn_info.json                 # アーカイブLSN情報ファイル
    │   │   ├── gs_auto_archive_command_param.json # アーカイブ実行コマンドパラメータファイル
    │   │   ├── data                            # データフォルダ (/dataStore/dbPath) - スタンバイのベースDBとして利用
    │   │   │   ├── 0                          # パーティション番号0
    │   │   │   │   ├── 0_part_0.dat               # データファイルアーカイブ
    │   │   │   │   ├── 0_4.cplog                  # チェックポイントログアーカイブ
    │   │   │   │   └── ...                        # その他のファイル
    │   │   │   ├── 1                          # パーティション番号1
    │   │   │   │   └── ...                        # その他のファイル
    │   │   │   └── ...                        # その他のパーティション
    │   │   ├── txnlog                         # トランザクションログフォルダ (/dataStore/transactionLogPath)
    │   │   │   ├── 0                          # パーティション番号0
    │   │   │   │   ├── 0_5.xlog                   # トランザクションログアーカイブ
    │   │   │   │   ├── 0_6.xlog
    │   │   │   │   └── ...                        # その他のログ
    │   │   │   ├── 1                          # パーティション番号1
    │   │   │   │   └── ...                        # その他のログ
    │   │   │   └── ...                        # その他のパーティション
    │   │   ├── cluster                        # クラスタメタ情報ディレクトリ (/dataStore/autoArchiveOutputClusterInfoPath)
    │   │   │   ├── RECOVERY_0_1_100.info         # クラスタリカバリ情報ファイル
    │   │   │   ├── ROLE_0_1_100_0_OWNER.info     # クラスタロール情報ファイル
    │   │   │   ├── CP_0_1_100_200.info           # クラスタチェックポイント情報ファイル
    │   │   │   └── ...                           # その他のメタ情報
    │   │   └── ...                            # その他のアーカイブ
    │   ├── backup1                           # 別のバックアップ名
    │   │   └── ...                            # バックアップ内容
    │   ├── backup2                           # 別のバックアップ名
    │   │   └── ...                            # バックアップ内容
    │   └── ...                                # その他のバックアップ
スタンバイモード機能

スタンバイモードの概要はファイルベース、メモリベースいずれでも共通となります。 詳細は、こちらをご参照ください。

サイト間レプリケーション連携機能

サイト間レプリケーション連携機能とは、プライマリとスタンバイをオンライン状態で接続し、相互に監視しながら、プライマリで生成されたトランザクションログをスタンバイにリアルタイムで自動レプリケーションする機能です。概要は以下の通りです。

設定に必要なパラメータ

以下の表に、メモリベース方式の設定に必要なパラメータを示します。本機能を利用する際に必須となる設定は、enable と siteConnectionId です。これら以外の項目については、デフォルト設定のまま（設定ファイルに記載しない状態）でも動作可能です。一部の項目はオンラインで変更することもできます。keepLogFileCount は、提供するサービスが定義する障害復旧時間に応じて適切に設定することを推奨します。

パラメータ名 データ型 デフォルト値 説明 オンライン変更 必須項目
/transaction/siteReplication/enable bool false サイト間レプリケーション連携機能を有効にするかを指定します 可 あり
/transaction/siteReplication/siteConnectionId string "" サイト間レプリケーション連携機能のキーとなる接続IDを指定します 不可 あり
/transaction/siteReplication/heartbeatInterval int 15s サイト間接続のハートビート間隔（秒）を指定します 不可 なし
/transaction/siteReplication/heartbeatRetryCount int 1 ハートビートの再試行回数を指定します 不可 なし
/transaction/siteReplication/partitionCheckInterval int 15s 各パーティションの状態監視間隔（秒）を指定します 不可 なし
/transaction/siteReplication/keepLogFileCount int 5 トランザクションログファイルの保持数を指定します 可 なし
/transaction/siteReplication/syncWaitTime int 0ms ログ欠損時の同期処理実行間隔（ミリ秒）を指定します 不可 なし
/transaction/siteReplication/limitUpdateDelayTime int 300s スタンバイ側の更新異常判定時間（秒）を指定します 可 なし
/transaction/siteReplication/limitLsnDifference int 100000000 スタンバイ側の更新異常判定のLSN差分閾値を指定します 可 なし
/transaction/siteReplication/replicationMember json "" 相手サイトのノード構成情報（アドレスとポート番号リスト）を指定します 不可 なし

設定例

以下は、クラスタ定義ファイル（gs_cluster.json）の設定例です。運用開始時に必須で決定するのは、サイト間接続IDと相手サイトのアドレスリストです。

"transaction": {
    ...
    "siteReplication": {
        "enable": true,
        "siteConnectionId": "R3QGnWlGg6Lseujf0EtbNomgOB1P1wfo",
        "keepLogFileCount": 10,
        "replicationMember": [
            {"address": "192.168.10.11", "port": 10001},
            {"address": "192.168.10.12", "port": 10001},
            {"address": "192.168.10.13", "port": 10001}
        ]
    }
}

サイト間接続機能の状態は、メタテーブル #replication_stats を使用して確認できます。このメタテーブルをSQLクエリで参照することで、サイト間レプリケーションの状態やエラー情報を簡単に把握できます。なお、この操作はプライマリおよびスタンバイの両方で実行可能ですが、通常はプライマリ側の情報を参照して状態確認を行うことを推奨します。

メタテーブル #replication_stats のカラム詳細

カラム名 データ型 説明
CLUSTER_PARTITION_INDEX int クラスタパーティション番号。情報はクラスタパーティション単位で1レコードとして出力されます。オーナーが未決定の場合は出力されません。
CLUSTER_REPLICATION_ROLE string サイト間レプリケーションのロール。PRIMARY または STANDBY のいずれか。
PRIMARY_ADDRESS string プライマリのオーナーアドレス。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。
PRIMARY_PORT short プライマリのオーナーポート。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。
STANDBY_ADDRESS string スタンバイのオーナーアドレス。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。
STANDBY_PORT short スタンバイのオーナーポート。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。
PRIMARY_LSN long プライマリのLSN。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。
STANDBY_LSN long スタンバイのLSN。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。
PRIMARY_LAST_UPDATED_TIME timestamp プライマリの最終更新時刻。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。
STANDBY_LAST_UPDATED_TIME timestamp スタンバイの最終更新時刻。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。
REPLICATION_STATUS string レプリケーション状態。以下のいずれかが表示されます：
- NODE_DISCONNECTED（未接続）
- NODE_CONNECTED（接続済）
- REPLICATION_SYNC（同期中）
- REPLICATION_REALTIME（リアルタイムレプリケーション中）
- REPLICATION_LOSS（レプリケーション欠損）
LAST_ERROR_CODE int 最後に発生したエラーコード。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。
LAST_ERROR_TIME timestamp 最後に発生したエラー時刻。未決定、またはサイト間レプリケーション連携機能が無効の場合は NULL。

以下のSQLを実行して、サイト間レプリケーションの状態を確認します。

SELECT * FROM "#replication_stats";

以下は、クラスタパーティション数に応じた出力例です。通常、プライマリ側で進捗状況を確認することが推奨されますが、スタンバイ側でも実行可能です。プライマリ側で取得するスタンバイ側の情報や、スタンバイ側で取得するプライマリ側の情報には一定のタイムラグが生じる点に注意してください。

CLUSTER_PARTITION_INDEX CLUSTER_REPLICATION_ROLE PRIMARY_ADDRESS PRIMARY_PORT STANDBY_ADDRESS STANDBY_PORT PRIMARY_LSN STANDBY_LSN PRIMARY_LAST_UPDATED_TIME STANDBY_LAST_UPDATED_TIME REPLICATION_STATUS LAST_ERROR_CODE LAST_ERROR_TIME
1 PRIMARY 192.168.10.11 10001 192.168.11.12 10001 4104 4104 Thu Mar 27 15:05:16 JST 20 Thu Mar 27 15:05:19 JST 20 REPLICATION_REALTIME    
2 PRIMARY 192.168.10.12 10001 192.168.11.13 10001 7004 6900 Thu Mar 27 15:05:16 JST 20 Thu Mar 27 15:05:19 JST 20 REPLICATION_REALTIME    

注意事項

運用手順

以下の4つの運用について、メモリベース方式のサイト間データベースレプリケーションを用いた手順を示します。

  1. スタンバイ準備
  2. 定常運用
  3. フェイルオーバ
  4. スイッチオーバ

以下では、3台構成の例を用いて説明します。コマンド実行例では、$ をプロンプトとして使用し、プライマリ側の操作を [primary*]、スタンバイ側の操作を [standby*] として表記します。

メモリベース方式では、トランザクションログが自動的にレプリケーションされるため、ここでは継続的なログ出力を行わずに運用する方式を示します。

サイト間データベースレプリケーション_メモリベース
サイト間データベースレプリケーション(メモリベース)

ノード構成 (3台構成)

役割 ホスト名 IPアドレス
プライマリ primary0 192.168.10.11
  primary1 192.168.10.12
  primary2 192.168.10.13
スタンバイ standby0 192.168.11.11
  standby1 192.168.11.12
  standby2 192.168.11.13

ディレクトリ構成

プライマリ側

/primary/cluster/
    ├── conf
    │   ├── gs_node.json
    │   ├── (gs_stable_goal.json) # 自動生成
    │   └── (gs_standby.json)     # 自動生成
    ├── data
    │   ├── 0
    │   └── ...
    ├── txnlog
    │   ├── 0
    │   └── ...
    └── backup
        └── arch
            ├── data             # スタンバイで用いるベースDB
            │   ├── 0
            │   └── ...
            └── txnlog           # メモリベースでは必須ではなくオプション
                ├── 0
                └── ...

スタンバイ側

/standby/cluster/
    ├── conf
    │   ├── gs_node.json
    │   ├── (gs_stable_goal.json) # 自動生成
    │   └── (gs_standby.json)     # 自動生成
    ├── data
    │   ├── 0
    │   └── ...
    ├── txnlog
    │   ├── 0
    │   └── ...
    ├── backup                  # スタンバイ時は不要
    └── tmp_txnlog              # メモリベースではオプション
        ├── 0
        └── ...
スタンバイ準備

スタンバイ準備の手順を以下に示します。以下の順序で実行してください。

順序 対象 手順
1 プライマリ
スタンバイ		 ノード定義ファイルの設定
2 プライマリ ベースラインの生成
3 スタンバイ 転送先の決定
4 プライマリ ベースラインの転送
5 スタンバイ スタンバイクラスタの開始
スタンバイ準備の手順_メモリベース
スタンバイ準備の手順(メモリベース)

  1. 定義ファイルの設定[プライマリ/スタンバイ]

    運用開始前に、プライマリ側およびスタンバイ側のクラスタ定義ファイル (gs_cluster.json) とノード定義ファイル (gs_node.json) に以下の設定を行ってください。

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

    • サイト間連携機能の有効化
      • サイト間連携機能を有効にします。 
        "/transaction/siteReplication/enable": true
    • サイト間接続用の接続キー設定
      • プライマリとスタンバイで共通の接続キーを設定します。 
        "/transaction/siteReplication/siteConnectionId": "R3QGnWlGg6Lseujf0EtbNomgOB1P1wfo"
    • トランザクションログの保持期間設定
      • 想定する障害発生期間に合わせて設定します。この値はオンラインで変更可能です。 
        "/transaction/siteReplication/keepLogFileCount": 10
    • 接続対象ノードのアドレスリスト設定

      • プライマリの場合はスタンバイのアドレスリストを、スタンバイの場合はプライマリのアドレスリストを設定します。

        • プライマリの設定例: 
            "/transaction/siteReplication/replicationMember": [
  {"address": "192.168.11.11", "port": 10001},
  {"address": "192.168.11.12", "port": 10001},
  {"address": "192.168.11.13", "port": 10001}
  ]
        • スタンバイの設定例: 
            "/transaction/siteReplication/replicationMember": [
  {"address": "192.168.10.11", "port": 10001},
  {"address": "192.168.10.12", "port": 10001},
  {"address": "192.168.10.13", "port": 10001}
  ]
    • その他の設定
      • 必要に応じて追加設定を行ってください。

    以下に上記設定を行った例を記載します。

    プライマリの設定

     "transaction": {
     "siteReplication": {
         "enable": true,
         "siteConnectionId": "R3QGnWlGg6Lseujf0EtbNomgOB1P1wfo",
         "keepLogFileCount": 10,
         "replicationMember": [
             {"address": "192.168.11.11", "port": 10001},
             {"address": "192.168.11.12", "port": 10001},
             {"address": "192.168.11.13", "port": 10001}
         ]
     }
 }

    スタンバイの設定

     "transaction": {
     "siteReplication": {
         "enable": true,
         "siteConnectionId": "R3QGnWlGg6Lseujf0EtbNomgOB1P1wfo",
         "keepLogFileCount": 10,
         "replicationMember": [
             {"address": "192.168.10.11", "port": 10001},
             {"address": "192.168.10.12", "port": 10001},
             {"address": "192.168.10.13", "port": 10001}
         ]
     }
 }

    ノード定義ファイル (gs_node.json) の設定

    • 自動アーカイブ機能の有効化
      • メモリベース方式では必須ではありませんが、必要時に備えて設定します。 
        "/dataStore/enableAutoArchive": true
"/dataStore/autoArchiveName": arch"
    • スタンバイモード設定の有効化
      • スタンバイモードの設定を有効化します。 
        "/cluster/enableStandbyMode": true
    • クラスタパーティション配置固定化の有効化
      • クラスタパーティション配置固定化を有効化します。 
        "/cluster/enableStableGoal": true
"/cluster/initialGenerateStableGoal": true

        以下に上記設定を行った例を記載します。

     {
     "dataStore": {
         "enableAutoArchive": true,
         "autoArchiveName": "arch"
     },
     "cluster": {
         "enableStandbyMode": true,
         "enableStableGoal": true,
         "initialGenerateStableGoal": true
     }
 }

  2. ベースラインの生成[プライマリ]

プライマリのベースラインを生成するには、以下の手順を実行してください。

  1. ベースラインの生成
    以下のコマンドを実行し、指定フォルダ（例: /primary/cluster/backup/arch）にベースラインとなるデータベースファイル（ベースDB）が出力されることを確認します。

     [primary*]$ gs_autoarchive -u admin/admin --start

  2. ベースライン生成の確認
    ベースDBが正常に生成されたかを確認するには、以下のコマンドを実行してください。

     [primary*]$ gs_backuplist -u admin/admin

 BackupName   Status   StartTime                EndTime
 ------------------------------------------------------------------------
 arch         OK       2014-09-25T05:30:02+0900 2014-09-25T05:59:03+0900

  3. アーカイブの停止
    メモリベース方式では、以降のトランザクションログファイルは自動的にレプリケーションされるため、この時点でアーカイブを停止します。以下のコマンドを実行してください。

     [primary*]$ gs_autoarchive -u admin/admin --stop

以上の手順で、プライマリのベースライン生成が完了します。同様の手順はgs_backupでフルバックアップ生成でも可能です。

3. 転送先の決定[スタンバイ]

スタンバイクラスタの準備

スタンバイクラスタを構成するために、ベースラインの配置先を事前に準備します。配置先はgs_stableGoal.jsonを作成して起動することで固定化することができます。 設定時にクラスタパーティション配置固定化を有効化した場合は以下のように容易にこのファイルを作成することができます。

  1. スタンバイ側ノードの起動とクラスタ構成

    スタンバイ側のノードを起動し、クラスタを構成します。この際、スタンバイ側のデータは空の状態で起動します。以下のコマンドを実行してください。

     [standby*]$ gs_startnode -u admin/admin
 [standby*]$ gs_joincluster -c cls1 -n -3 -u admin/admin

  2. クラスタパーティション配置表の生成

    クラスタ構成が成功すると、各ノードのノード定義ファイルと同じディレクトリに gs_stable_goal.json というファイルが自動生成されます。このファイルにはクラスタパーティションの配置情報が記録されています。このファイルは削除せずに保存してください。

  3. クラスタの停止と不要データの削除

    gs_stable_goal.json の生成を確認した後、以下のコマンドを実行してクラスタを停止し、不要なデータファイルを削除します。

     [standby*]$ gs_stopcluster -u admin/admin
 [standby*]$ gs_stopnode -u admin/admin
 [standby*]$ rm -r -f /standby/cluster/data
 [standby*]$ rm -r -f /standby/cluster/txnlog

    この操作により、スタンバイ側ベースDBの配置準備が整います。

  4. gs_stable_goal.json の内容確認

    gs_stable_goal.json ファイルには、各パーティションのオーナーおよびバックアップノードの情報が記録されています。以下はそのサンプルです。この例では、クラスタパーティション番号 0 のオーナーノードのアドレスは 192.168.11.10、バックアップノードのアドレスは 192.168.11.11 です。

    この情報を基に、オーナーノードに対応するデータフォルダへプライマリのベースラインを配置します。

     [
     {
         "backup": [{"address": "192.168.11.11", "port": 10010}],
         "owner": {
             "address": "192.168.11.10",
             "port": 10010
         },
         "pId": "0"
     }
 ]

4. ベースラインの転送[プライマリ]

スタンバイに必要なベースラインであるベースラインを転送します。クラスタパーティション0に対する一連の処理概略をまとめると以下のようになります。

ベースライン転送_メモリベース
ベースライン転送(メモリベース)

以下にその手順を示します。まず、転送元となる、プライマリにおける各クラスタパーティションのオーナノードを取得します。これはプライマリにおいてgs_partitionを実行します。

[primary*]$ gs_partition -u admin/admin
  [
      {
          "backup": [{"address": "192.168.10.11","port": 10010}],
          "owner": {
              "address": "192.168.10.10",
              "port": 10010
          },
          "pId": "0",
      },
          ：
  ]

次に、転送先となる、スタンバイにおける各クラスタパーティションのオーナおよびバックアップを取得します。これは、3.で生成したgs_stale_goal.jsonを用います。スタンバイ準備フェーズではオーナだけでなく、ノードへの転送も必要となります。

# スタンバイ側のgs_stable_goal.jsonの内容
  [
      {
          "backup": [{"address": "192.168.11.11","port": 10010}],
          "owner": {
              "address": "192.168.11.10",
              "port": 10010
          },
          "pId": "0",
      },
          ：
  ]

上記より、パーティション0に対する転送情報は以下の通りです。

転送先情報に従い、以下のコマンドを使用してデータを転送してください。

# 192.168.10.10 (primary0) -> 192.168.11.10 (standby0, オーナーノード)
[primary*]$ rsync -avz user@primary0:/primary/cluster/backup/arch/data/0 user@standby0:/standby/cluster/data
[primary*]$ rsync -avz user@primary0:/primary/cluster/backup/arch/txnlog/0 user@standby0:/standby/cluster/txnlog

# 192.168.10.10 (primary0) -> 192.168.11.11 (standby1, バックアップノード)
[primary*]$ rsync -avz user@primary0:/primary/cluster/backup/arch/data/0 user@standby1:/standby/cluster/data
[primary*]$ rsync -avz user@primary0:/primary/cluster/backup/arch/txnlog/0 user@standby1:/standby/cluster/txnlog

同様の手順をすべてのクラスタパーティションに対して実施してください。これにより、ベースDBの配置が完了します。

5. スタンバイクラスタの開始[スタンバイ]

スタンバイクラスタの開始手順

  1. 各ノードの起動
    スタンバイクラスタを構成する各ノードを起動します。

     [standby*]$ gs_startnode

  2. スタンバイモードの設定
    各ノードをスタンバイモードに設定します。

     [standby*]$ gs_standby --true -u admin/admin

  3. クラスタの稼働開始
    クラスタを稼働させます。これ以降は定常運用の手順に従って運用を行います。

     [standby*]$ gs_joincluster -c cls1 -n -3 -u admin/admin

GridDBサービスを利用したクラスタ構成手順

スタンバイモードの設定はクラスタ離脱状態で行う必要がありますが、GridDBサービス経由で起動する場合、クラスタが自動的に構成されるため、以下の手順を実施してください。

  1. gs_standby.json ファイルの作成
    以下の内容で gs_standby.json ファイルを作成します。

     {"standby": true}

  2. ファイルの配置
    作成したファイルをノード定義ファイルと同じディレクトリに配置します。

     cp gs_standby.json /standby/cluster/conf

  3. GridDBサービスの起動
    GridDBサービスを利用してクラスタを構成します。

     [standby*]$ sudo systemctl start gridstore
定常運用

定常運用時の手順を以下に示します。以下の順序で実行してください。

順序 対象 手順
1 プライマリ
スタンバイ		 定常時のレプリケーション状態を確認します。
定常運用
定常運用

1. 定常時のレプリケーション状態の確認[プライマリ/スタンバイ]

メモリベースレプリケーション方式では、定常時のレプリケーションが自動的に実行されます。以下のSQLを使用してレプリケーション状態を確認してください。

SELECT * FROM "#replication_stats";

以下は出力例です：

CLUSTER_PARTITION_INDEX CLUSTER_REPLICATION_ROLE PRIMARY_ADDRESS PRIMARY_PORT STANDBY_ADDRESS STANDBY_PORT PRIMARY_LSN STANDBY_LSN PRIMARY_LAST_UPDATED_TIME STANDBY_LAST_UPDATED_TIME REPLICATION_STATUS LAST_ERROR_CODE LAST_ERROR_TIME
1 PRIMARY 192.168.10.11 10001 192.168.11.12 10001 4104 4104 Thu Mar 27 15:05:16 JST 20 Thu Mar 27 15:05:19 JST 20 REPLICATION_REALTIME    
2 PRIMARY 192.168.10.12 10001 192.168.11.13 10001 7004 6900 Thu Mar 27 15:05:16 JST 20 Thu Mar 27 15:05:19 JST 20 REPLICATION_REALTIME    

レプリケーション状態の確認

レプリケーションラグの確認

障害時の対応

プライマリおよびスタンバイがクラスタ構成を取っている場合、通常の障害ではサイト間レプリケーションが継続されるため、特別な対応は不要です。 ただし、プライマリサイト全体に障害が発生した場合は、必要に応じてフェイルオーバを実施し、スタンバイをプライマリに昇格させる必要があります。フェイルオーバは自動では実行されないため、事前にフェイルオーバの基準を設定し、必要に応じて以下の章で述べるフェイルオーバ手順に従って対応してください。 また、障害復旧に必要なトランザクションログの保持期間を事前に設定しておくことが重要です。運用中はレプリケーション状態を定期的に確認し、問題が発生した場合には迅速に対応できるよう備えてください。

フェイルオーバ

フェイルオーバ手順を以下に示します。

順序 対象 手順
1 プライマリ
アプリケーション		 アプリケーションを停止します。
2 スタンバイ プライマリクラスタへの昇格を判定します。
3 スタンバイ スタンバイモードを解除します。
4 スタンバイ→新プライマリ 新プライマリクラスタを開始します。
5 アプリケーション アプリケーションを再開します。
6 新プライマリ
旧プライマリ→新スタンバイ		 旧プライマリクラスタをスタンバイとして準備し再開します。
フェイルオーバ_メモリベース
フェイルオーバ手順の概要(メモリベース)

1. アプリケーションの停止[プライマリ/アプリケーション]

プライマリクラスタが稼働していないことを確認し、可能であればアプリケーションをすべて停止してください。

2. プライマリクラスタへの昇格判定[スタンバイ]

スタンバイをプライマリに昇格させるかどうかの判断は自動では行われません。そのため、サイト障害時のフェイルオーバを実施するかは運用者が基準を設けて判断する必要があります。

メモリベースレプリケーションの場合、プライマリ障害直前までのデータがスタンバイにレプリケーションされているため、これを基準に検討します。

3. スタンバイモードの解除[スタンバイ]

スタンバイクラスタを一時的に離脱状態にするには、以下のコマンドを実行してください。

[standby*]$ gs_stopcluster -u admin/admin

その後、スタンバイ側の全ノードに対して以下のコマンドを実行し、スタンバイモードを解除します。

[standby*]$ gs_standby --false -u admin/admin

4. 新プライマリクラスタの開始[スタンバイ→新プライマリ]

新しいプライマリクラスタの構成が完了したら、クラスタを再開してサービスを復旧させます。この手順では、アーカイブ機能（gs_autoarchive によるログの継続生成）を使用せず、旧プライマリサイトが復旧した際に新たにベースラインを生成する方式を採用します。そのため、クラスタを再開した時点でサービスを再開できます。なお、サイト障害の期間が短期間である場合は、障害復旧を見越して一時的にログ保持期間をオンラインで変更して運用することを推奨します。

以下のコマンドを実行して、新しいプライマリクラスタを稼働させてください：

[standby*]$ gs_joincluster -c cls1 -n -3 -u admin/admin

5. アプリケーションの再開[アプリケーション]

アプリケーションの接続先を旧プライマリから新プライマリクラスタに変更し、アプリケーションを再起動します。この操作により、新プライマリクラスタでのサービスが稼働状態となります。

6. 旧プライマリクラスタのスタンバイ準備と再開[新プライマリ/旧プライマリ→新スタンバイ]

アプリケーションの再開後、旧プライマリが復旧した場合は、旧プライマリに存在するデータファイルおよびトランザクションログファイルを削除し、新しいスタンバイとしての準備を行います。この準備手順は、[1. スタンバイ準備]の手順と同様であるため、詳細な説明は省略します。準備が完了すると、旧プライマリは新しいスタンバイとして、旧スタンバイは新しいプライマリとして運用を継続します。この状態で、通常の運用手順（[2. 定常運用]）に戻ります。

なお、旧プライマリを再びプライマリとして復帰させる場合は、[3. フェイルオーバ]手順ではなく、[4. スイッチオーバ]手順を実施することを推奨します。

また、手順4でサイト障害復帰用にログ保持期間を一時的に延長していた場合は、レプリケーションが完了した時点で適切な値に再設定してください。これは、長期間のログ保持がトランザクションログファイルによるディスク容量の圧迫を引き起こす可能性があるためです。

以上の処理により、新しいプライマリへのスタンバイの昇格が完了し、サービスの再開が可能となります。また、旧プライマリを新しいスタンバイとして運用に組み込むことができます。

スイッチオーバ

スイッチオーバ手順について以下に示します。

スイッチオーバは、予期せぬ障害に対応する「フェイルオーバ」とは異なり、計画的に実施することが可能です。そのため、プライマリとスタンバイのデータベース状態を完全に一致させた上で切り替えを行うことができます。

順序 対象 手順
1 アプリケーション アプリケーションを停止します。
2 プライマリ クラスタの状態が一致していることを確認します。
3 プライマリ プライマリクラスタを停止します。
4 スタンバイ スタンバイクラスタを停止します。
5 プライマリ プライマリクラスタをスタンバイクラスタへ移行する準備を行います。
6 スタンバイ スタンバイクラスタをプライマリクラスタへ移行する準備を行います。
7 スタンバイ→新プライマリ 新しいプライマリクラスタを稼働させます。
8 プライマリ→新スタンバイ 新しいスタンバイクラスタを稼働させます。
9 アプリケーション アプリケーションを再開します。
スイッチオーバ_メモリベース
スイッチオーバ手順の概要(メモリベース)

1. アプリケーションの停止[アプリケーション]

スイッチオーバ作業中は短時間のサービス停止が発生します。そのため、事前に利用者へ切替作業の実施を告知し、該当期間中はアプリケーションを一時停止してください。また、スイッチオーバ後はアプリケーションの接続先が旧スタンバイ側に変更されるため、事前に接続先の変更を行っておく必要があります。

2. クラスタ一致の確認[プライマリ]

プライマリとスタンバイの状態が一致していることを確認します。以下のSQLを実行して、全パーティションのLSNが一致しているか確認してください。

SELECT COUNT(*) AS MATCHED_PARTITIONS 
FROM "#replication_stats" 
WHERE REPLICATION_STATUS = 'REPLICATION_REALTIME' 
    AND PRIMARY_LSN = STANDBY_LSN;

このクエリの結果がクラスタのパーティション数（デフォルトでは128）と一致している場合、プライマリとスタンバイの状態が完全に一致していることを示します。

注意事項:

状態の一致が確認できたら、次の手順に進んでください。

3. プライマリクラスタを停止[プライマリ]

プライマリクラスタを停止するには、以下のコマンドを実行してください。

[primary*]$ gs_stopcluster -u admin/admin

この操作により、プライマリクラスタを構成するすべてのノードがクラスタから切り離されます。

4. スタンバイクラスタを停止[スタンバイ]

スタンバイクラスタを停止するには、以下のコマンドを実行してください：

[standby*]$ gs_stopcluster -u admin/admin

この操作により、スタンバイクラスタを構成するすべてのノードがクラスタから切り離されます。

5. プライマリクラスタのスタンバイクラスタへの移行準備[プライマリ]

スイッチオーバの場合、フェイルオーバとは異なり、スタンバイ側のデータファイルやトランザクションログファイルを削除する必要はありません。

プライマリクラスタにスタンバイモードを設定するには、以下のコマンドを実行してください：

[primary*]$ gs_standby --true -u admin/admin

6. スタンバイクラスタをプライマリクラスタへの移行準備[スタンバイ]

スタンバイクラスタのスタンバイモードを解除するには、以下のコマンドを実行してください。

[primary*]$ gs_standby --false -u admin/admin

この操作により、スタンバイクラスタがスタンバイモードから解除され、新しいプライマリクラスタとしての準備が整います。

7. 新プライマリクラスタの稼働[スタンバイ→新プライマリ]

新しいプライマリクラスタを稼働させるには、以下のコマンドを実行してください。

[standby*]$ gs_joincluster -c cls1 -n -3 -u admin/admin

このコマンドにより、スタンバイ側のクラスタが新しいプライマリクラスタとして稼働を開始します。以降は、アプリケーションの接続先を新しいプライマリクラスタに変更し、サービスを再開してください。

8. 新スタンバイクラスタの稼働[プライマリ→新スタンバイ]

新しいスタンバイクラスタを稼働させるには、以下のコマンドを実行してください：

[primary*]$ gs_joincluster -c cls1 -n -3 -u admin/admin

このコマンドにより、旧プライマリクラスタが新しいスタンバイクラスタとして稼働を開始します。

9. アプリケーションの再開[アプリケーション]

アプリケーションの接続先を新しいプライマリクラスタに変更した後、アプリケーションを再起動してサービスを再開します。その後は、定常運用の手順に従って運用を継続してください。

稼働状況の確認機能

性能・統計情報

GridDBの性能・統計情報は、運用コマンドのgs_statを利用して確認できます。gs_statはクラスタで共通の情報とノード独自の性能情報・統計情報を表示します。

gs_statコマンドでの出力のうち、performance構造が、性能・統計情報に関連する項目です。

出力例を以下に示します。出力される内容はバージョンによって異なります。

-bash-4.1$ gs_stat -u admin/admin -s 192.168.0.1:10040
{
    ：
    "performance": {
        "batchFree": 0,
        "dataFileSize": 65536,
        "dataFileUsageRate": 0,
        "checkpointWriteSize": 0,
        "checkpointWriteTime": 0,
        "currentTime": 1428024628904,
        "numConnection": 0,
        "numTxn": 0,
        "peakProcessMemory": 42270720,
        "processMemory": 42270720,
        "recoveryReadSize": 65536,
        "recoveryReadTime": 0,
        "sqlStoreSwapRead": 0,
        "sqlStoreSwapReadSize": 0,
        "sqlStoreSwapReadTime": 0,
        "sqlStoreSwapWrite": 0,
        "sqlStoreSwapWriteSize": 0,
        "sqlStoreSwapWriteTime": 0,
        "storeDetail": {
            "batchFreeMapData": {
                "storeMemory": 0,
                "storeUse": 0,
                "swapRead": 0,
                "swapWrite": 0
            },
            "batchFreeRowData": {
                "storeMemory": 0,
                "storeUse": 0,
                "swapRead": 0,
                "swapWrite": 0
            },
            "mapData": {
                "storeMemory": 0,
                "storeUse": 0,
                "swapRead": 0,
                "swapWrite": 0
            },
            "metaData": {
                "storeMemory": 0,
                "storeUse": 0,
                "swapRead": 0,
                "swapWrite": 0
            },
            "rowData": {
                "storeMemory": 0,
                "storeUse": 0,
                "swapRead": 0,
                "swapWrite": 0
            }
        },
        "storeMemory": 0,
        "storeMemoryLimit": 1073741824,
        "storeTotalUse": 0,
        "swapRead": 0,
        "swapReadSize": 0,
        "swapReadTime": 0,
        "swapWrite": 0,
        "swapWriteSize": 0,
        "swapWriteTime": 0,
        "syncReadSize": 0,
        "syncReadTime": 0,
        "totalLockConflictCount": 0,
        "totalReadOperation": 0,
        "totalRowRead": 0,
        "totalRowWrite": 0,
        "totalWriteOperation": 0
    },
    ：
}

性能・統計情報に関連する情報を説明します。storeDetail構造は、内部のデバッグ情報のため説明は省きます。

出力パラメータ 種別 説明 監視すべき事象
dataFileSize c データファイルサイズ(バイト)  
dataFileUsageRate c データファイル利用率  
checkpointWrite s チェックポイント処理のデータファイルへの書き込み回数  
checkpointWriteSize s チェックポイント処理のデータファイルへの書き込みサイズ(バイト)  
checkpointWriteTime s チェックポイント処理のデータファイルへの書き込み時間(ミリ秒)  
checkpointWriteCompressTime s チェックポイント処理のデータファイルへの書き込みデータ圧縮時間(ミリ秒)  
dataFileAllocateSize c データファイルに割り当てられたブロックの総サイズ(バイト)  
currentTime c 現在時刻  
numConnection c 現在のコネクション数。トランザクション処理で使用している接続数であり、クラスタ処理で使用している接続数は含まれない。クライアントの数+保有するパーティション＊レプリカ数の値となる。 ログの監視でコネクション不足が発生している場合はノード構成のconnectionLimitの値を見直します。
numSession c 現在のセッション数  
numTxn c 現在のトランザクション数  
peakProcessMemory p プロセス最大使用メモリ量(バイト) storememoryの値を含め、GridDBサーバの利用したメモリのピーク値 peakProcessMemory、processMemoryがノードの実装メモリより大きくOSのスワップが発生している場合、メモリの追加や一時的にstorememoryLimitの値を下げるなどの検討が必要
processMemory c プロセス使用メモリ量(バイト)  
recoveryReadSize s リカバリ処理でデータファイルを読み込んだサイズ(バイト)  
recoveryReadTime s リカバリ処理でデータファイルを読み込んだ時間(ミリ秒)  
sqlStoreSwapRead s SQLストアスワップ処理のファイルからの読み込み回数  
sqlStoreSwapReadSize s SQLストアスワップ処理のファイルからの読み込みサイズ(バイト)  
sqlStoreSwapReadTime s SQLストアスワップ処理のファイルからの読み込み時間(ミリ秒)  
sqlStoreSwapWrite s SQLストアスワップ処理のファイルへの書き込み回数  
sqlStoreSwapWriteSize s SQLストアスワップ処理のファイルへの書き込みサイズ(バイト)  
sqlStoreSwapWriteTime s SQLストアスワップ処理のファイルへの書き込み時間(ミリ秒)  
storeMemory c インメモリデータベースでの使用メモリ量(バイト)  
storeMemoryLimit c インメモリデータベースでの使用メモリ量制限(バイト)  
storeTotalUse c データベースファイル内のデータ容量を含めたノードが保有する全データ容量(バイト)  
swapRead s スワップ処理のファイルからの読み込み回数  
swapReadSize s スワップ処理のファイルからの読み込みサイズ(バイト)  
swapReadTime s スワップ処理のファイルからの読み込み時間(ミリ秒)  
swapWrite s スワップ処理のファイルへの書き込み回数  
swapWriteSize s スワップ処理のファイルへの書き込みサイズ(バイト)  
swapWriteTime s スワップ処理のファイルへの書き込み時間(ミリ秒)  
swapWriteCompressTime s スワップ処理のファイルへの書き込みデータ圧縮時間(ミリ秒)  
syncReadSize s 同期処理データファイルからの読み込みサイズ(バイト)  
syncReadTime s 同期処理データファイルからの読み込み時間(ミリ秒)  
totalLockConflictCount s ロウロック競合発生回数  
totalReadOperation s 検索処理回数  
totalRowRead s ロウ読み出し回数  
totalRowWrite s ロウ書き込み回数  
totalWriteOperation s 登録更新処理回数  

【メモ】

コンテナ(テーブル)の配置情報確認

GridDBクラスタ上のコンテナ(テーブル)は、各ノードに自動的に分散して配置されます。 運用機能やSQLを用いることで、コンテナ(テーブル)がどのノードに配置されているかを確認することができます。

この機能は次の場合に役立ちます。

【メモ】

次の方法で、コンテナ(テーブル)が属するパーティションのオーナが配置されているノードを確認できます。

ノード上のコンテナ(テーブル)一覧確認【EE限定】

1つのノード上に配置されているコンテナ(テーブル)一覧を確認するには、統合運用管理GUI(gs_admin)のコンテナ一覧画面を使用します。

  1. gs_adminにログインします。

  2. 左画面のツリービューで「ClusterTree」タブを選択してノードを選択した後、右画面で「Container」タブをクリックします。

  3. ノードに配置されているコンテナ一覧が表示されます。

【メモ】

コンテナ(テーブル)配置ノードの確認

特定のコンテナ(テーブル)が配置されているノードを確認するには、gs_shとパーティション情報取得コマンド(gs_partition)を使用します。

  1. gs_shのshowcontainerサブコマンドでコンテナが格納されているパーティションのIDを確認します。 パーティションIDが”Partition ID”に表示されます。

  2. gs_shのconfigclusterサブコマンドでマスタノードを確認します。 “Role”に”M”と表示されるノードがマスタノードです。

  3. マスタノードに対して、1で確認したパーティションIDを引数に指定してgs_partitionを実行します。 表示されたJSONの/owner/addressのノードが、コンテナが配置されているノードです。

【実行例】

$ gs_partition -u admin/admin -n 5
[
    {
        "backup": [],
        "catchup": [],
        "maxLsn": 300008,
        "owner": {
            "address": "192.168.11.10",    -> IPアドレス:192.168.11.10のノードに格納されている
            "lsn": 300008,
            "port": 10010
        },
        "pId": "5",
        "status": "ON"
    }
]

【注意】

【メモ】

データパーティション配置ノードの確認

パーティショニングされたコンテナ(テーブル)は、複数の内部コンテナ(データパーティション)にデータを分割して格納します。 これらのデータパーティションがどのノードに配置されているかを確認することで、パーティショニングされたコンテナ(テーブル)のデータ配置を知ることができます。

配置確認の流れとしては、該当コンテナ(テーブル)のデータパーティションが格納されているパーティションのIDを調べて、そのIDを基にして配置されているノードを調べます。以下に手順を説明します。

  1. 該当コンテナ(テーブル)のデータパーティションが格納されているパーティションのIDを確認する
  1. パーティションIDから、配置されているノードを確認する

【例】

select DATABASE_NAME, TABLE_NAME, CLUSTER_PARTITION_INDEX from "#table_partitions" where TABLE_NAME='hashTable1';

DATABASE_NAME,TABLE_NAME,CLUSTER_PARTITION_INDEX
public,hashTable1,1
public,hashTable1,93
public,hashTable1,51
public,hashTable1,18
public,hashTable1,32  →'hashTable1'のデータパーティションは5個で、格納されているパーティションのIDは1, 93, 51, 18, 32。

$ gs_partition -u admin/admin -n 1
[
    {
        "backup": [],
        "catchup": [],
        "maxLsn": 200328,
        "owner": {
            "address": "192.168.11.15",    -> IPアドレス:192.168.11.15のノードに格納されている
            "lsn": 200328,
            "port": 10010
        },
        "pId": "1",
        "status": "ON"
    }
]

【注意】

【メモ】

運用ツール

GridDBでは、クラスタ操作やノード操作、コンテナ作成などのデータ操作、エクスポート/インポートなどを行うための以下のツールを提供しています。

運用ツール一覧
運用ツール一覧
名称 内容
サービス Linuxのサービス管理で、GridDBノードの起動/停止などを行います。
統合運用管理GUI(gs_admin) GridDBクラスタの運用機能を統合したWebベースの統合運用管理GUIツールです。
クラスタ運用管理コマンド・インタプリタ(gs_sh) GridDBクラスタの運用管理機能、およびデータ操作を行うCUIツールです。
運用コマンド GridDBクラスタの運用機能を行うコマンド群です。機能ごとに様々なコマンドがあります。
エクスポートツール/インポートツール データをエクスポート/インポートします。

運用コマンド

GridDBの運用動作を指示するコマンドには以下があります。GridDBの運用コマンドはすべてgs_で始まります。

種類 コマンド 機能
ノード操作 gs_startnode ノードの起動
  gs_stopnode ノードの停止
クラスタ操作 gs_joincluster 指定ノードをクラスタ構成へ参加させる。クラスタを構成する際に使用
  gs_leavecluster クラスタから特定ノードを切り離す。メンテナンス等で特定ノードを切り離す際に利用する。切り離したノードに配置されているパーティションは再配置(リバランス）される
  gs_stopcluster クラスタを構成する全ノードをクラスタから切り離す。全ノードを停止する際に利用する。ノード切り離しに伴うパーティションのリバランスは発生しない
  gs_config クラスタを構成するノードの情報を取得
  gs_stat ノードやクラスタの稼働情報や性能情報を情報取得
  gs_appendcluster【EE限定】 STABLE状態のクラスタに対してノードを増設する
  gs_failovercluster【EE限定】 クラスタのフェイルオーバーを手動で通知する。データロストを許容してサービスを開始する際にも利用
  gs_partition パーティションのクラスタ内での配置（マスタ／バックアップ）情報や更新情報を取得
  gs_loadbalance【EE限定】 クラスタの自律的データ配置機能の有効無効の設定、設定情報の取得
管理ユーザ操作 gs_adduser 管理ユーザの登録
  gs_deluser 管理ユーザの削除
  gs_passwd 管理ユーザのパスワードの変更
ログ情報 gs_logs ノードのメモリに保持する最新のログ情報の表示
  gs_logconf イベントログおよび監査ログの操作カテゴリと出力レベルの表示と変更
バックアップ／リストア gs_backup バックアップの取得指示
  gs_backuplist バックアップデータの確認
  gs_restore バックアップデータのリストア
インポート／エクスポート gs_import ディスクに保持しているコンテナやデータベースのexportデータを指定してインポート
  gs_export コンテナやデータベースを指定して、ディスク上にデータをCSV形式またはzip形式でエクスポート
保守 gs_paramconf 稼働パラメータの表示と稼働パラメータのオンライン変更
  gs_authcache【EE限定】 一般ユーザの認証やLDAP認証の高速化のためのユーザ情報キャッシュの一覧表示と削除
  gs_rollingupdate【EE限定】 ローリングアップデートを行う一連の処理手順の支援

統合運用管理機能【EE限定】

統合運用管理機能(gs_admin)はGridDBのクラスタ運用機能を統合したWebアプリケーションです。gs_adminは直観的なインターフェースで、クラスタの稼働情報を1画面で把握できます（ダッシュボード画面）。また、クラスタを構成する個々のノードへの起動停止操作や性能情報の確認などができます。

gs_admin　ダッシュボード画面
gs_admin　ダッシュボード画面

gs_adminは、上記運用操作とともに、開発を支援する以下の機能もサポートしており、システムの開発段階でも有効に利用できます。

クラスタ運用管理コマンド・インタプリタ（gs_sh）

GridDBのクラスタ操作やデータ操作のためのコマンドラインインターフェースです。運用コマンドが個別のノードに対して操作するのに対して、クラスタを構成するノードに一括した処理を行うインターフェースを提供しています。また、ユーザ管理操作に加え、データベース、コンテナやテーブルの作成、TQLやSQLによる検索などのデータ操作も提供します。

gs_shは、対話形式でサブコマンドを指定して処理を実行する方法と、一連の操作をサブコマンドで記載したスクリプトファイルをバッチで実行する方法の２つの起動方法があります。バッチスクリプトを利用することで、システム構築の省力化や開発時の動作検証の自動化などができます。

//対話形式
$ gs_sh
//サブコマンド「version」の実行
gs> version

//バッチ形式 コマンドの引数にサブコマンドを記載したファイルを指定する
$gs_sh test.gsh

gs_shでは、ノード起動やクラスタ開始などのクラスタ操作や、コンテナ作成などのデータ操作が実行できます。

時系列データ自動集計

IoTの活用が広がる中で、時間とともに時系列データは大量に発生し、データベースに蓄積されます。
時系列データを参照・利用する際は、データ量を削減し扱いやすくするために、一定時間間隔での最大値、最小値、平均値などの集計を行うことがあります。 しかし、大量の時系列データに対する集計演算は重く、結果取得までの待ち時間が長くなる傾向になります。
そこで、収集された大量の時系列データから、あらかじめバックグラウンドで自動的に集計演算を行い集計結果を蓄積する、自動集計が一般的に用いられます。 これにより、ユーザは計算済みの集計結果にアクセスできるため、処理時間を短くできます。

以下の手順で、運用ツールを用いた時系列データ自動集計を行います。

処理概要

あらかじめ集計対象のコンテナと出力先のコンテナを作成し、作成した集計対象のコンテナに対して、 時系列データを登録します。登録した時系列データに対して集計を行い、出力先のコンテナに登録を行います。 集計処理はクラスタ運用管理コマンド・インタプリタ（gs_sh）のバッチモードを用いて実現します。 自動集計はgs_shでスクリプトファイルを定期実行して実現します。 定期実行については、Linuxのcronを利用します。

処理の流れについて説明します。

生データの登録先である入力コンテナをetl_input、集計データの登録先である出力コンテナをetl_outputとします。

①コンテナ生成
入力コンテナを作成します。

CREATE TABLE IF NOT EXISTS etl_input (
  ts TIMESTAMP PRIMARY KEY,
  value DOUBLE
) PARTITION BY RANGE (ts) EVERY (30, DAY);

一定期間でデータを自動削除する場合はGridDBの期限解放を設定します。 入力コンテナに期限解放を設定します。

CREATE TABLE IF NOT EXISTS etl_input (
  ts TIMESTAMP PRIMARY KEY,
  value DOUBLE
) USING TIMESERIES WITH (
  expiration_type='PARTITION',
  expiration_time=90,
  expiration_time_unit='DAY'
) PARTITION BY RANGE (ts) EVERY (30, DAY);

出力コンテナを作成します。

CREATE TABLE IF NOT EXISTS etl_output (
  ts TIMESTAMP PRIMARY KEY,
  value DOUBLE
) PARTITION BY RANGE (ts) EVERY (30, DAY);

②時系列データ登録
集計対象のコンテナに時系列データを登録します。

③データ取得と集計、集計結果の登録
登録した時系列データを取得して集計を行います。

一定期間に対する集計を行う際は、GROUP BY RANGEと集計演算を組み合わせて、集計を行います。

例を以下に示します。

【例1】一定時間間隔の最大値を取得する例

名前: etl_input

  ts                     value
-----------------------+-------
  2024-01-01T00:00:00       10
  2024-01-01T00:00:10       30
  2024-01-01T00:00:20       30
  2024-01-01T00:00:30       50
  2024-01-01T00:00:40       50
  2024-01-01T00:00:50       70


○集計演算
SELECT ts,max(value) FROM etl_input
  WHERE ts BETWEEN TIMESTAMP('2024-01-01T00:00:00Z') AND TIMESTAMP('2024-01-01T00:01:00Z')
  GROUP BY RANGE(ts) EVERY (20,SECOND)

  ts                     value
-----------------------+-------
  2024-01-01T00:00:00       30
  2024-01-01T00:00:20       50
  2024-01-01T00:00:40       70

【例2】一定時間間隔の最小値を取得する例

名前: etl_input

  ts                     value
-----------------------+-------
  2024-01-01T00:00:00       10
  2024-01-01T00:00:10       30
  2024-01-01T00:00:20       30
  2024-01-01T00:00:30       50
  2024-01-01T00:00:40       50
  2024-01-01T00:00:50       70


○集計演算
SELECT ts,min(value) FROM etl_input
  WHERE ts BETWEEN TIMESTAMP('2024-01-01T00:00:00Z') AND TIMESTAMP('2024-01-01T00:01:00Z')
  GROUP BY RANGE(ts) EVERY (20,SECOND)

  ts                     value
-----------------------+-------
  2024-01-01T00:00:00       10
  2024-01-01T00:00:20       30
  2024-01-01T00:00:40       50

【例3】一定時間間隔の平均値を取得する例

名前: etl_input

  ts                     value
-----------------------+-------
  2024-01-01T00:00:00       10
  2024-01-01T00:00:10       30
  2024-01-01T00:00:20       30
  2024-01-01T00:00:30       50
  2024-01-01T00:00:40       50
  2024-01-01T00:00:50       70


○集計演算
SELECT ts,avg(value) FROM etl_input
  WHERE ts BETWEEN TIMESTAMP('2024-01-01T00:00:00Z') AND TIMESTAMP('2024-01-01T00:01:00Z')
  GROUP BY RANGE(ts) EVERY (20,SECOND)

  ts                     value
-----------------------+-------
  2024-01-01T00:00:00       20
  2024-01-01T00:00:20       40
  2024-01-01T00:00:40       60

その他の集計関数は『GridDB SQLリファレンス』を参照してください。

集計した結果を出力コンテナに登録します。

INSERT INTO etl_output ts,value;

上記のデータ取得と集計、集計結果の登録を定期的に実行することで、自動集計を実現します。
定期実行については、Linuxのcronを利用します。

gs_sh スクリプトファイル

集計処理をクラスタ運用管理コマンド・インタプリタ（gs_sh）のバッチモードを用いて実現します。

gs_shで以下のようなバッチモードのスクリプトファイル(sample.gsh)を作成します。

【例1】実行時点で未集計の全データを処理対象にする

# gs_shスクリプトファイル(sample.gsh)

# 存在しない場合はインターバルを30日としたパーティショニングテーブルを出力先として作成する
CREATE TABLE IF NOT EXISTS etl_output (ts TIMESTAMP PRIMARY KEY, value DOUBLE)
 PARTITION BY RANGE (ts) EVERY (30, DAY);

# 登録済みの最終実行時刻を取得する。存在しない場合は今から1時間前の時刻を取得する。
SELECT case when MAX(ts) ISNULL THEN TIMESTAMP_ADD(HOUR,NOW(),-1) else MAX(ts)
 end AS lasttime FROM etl_output;

# 取得した時刻を変数に格納する
getval LastTime

# 取得した時刻と今の時刻を集計範囲として20秒ごとの平均値を取得して、出力コンテナに登録または更新する
INSERT OR REPLACE INTO etl_output (ts, value)
 SELECT ts,avg(value) FROM etl_input
 WHERE ts BETWEEN TIMESTAMP('$LastTime') AND NOW()
 GROUP BY RANGE(ts) EVERY (20, SECOND);

【例2】集計範囲を時間単位に揃えて処理対象にする

# gs_shのスクリプトファイル(sample.gsh)

# 存在しない場合はインターバルパーティショニング30日の出力コンテナを作成する
CREATE TABLE IF NOT EXISTS etl_output (ts TIMESTAMP PRIMARY KEY, value DOUBLE)
 PARTITION BY RANGE (ts) EVERY (30, DAY);

# 登録済みの最終実行時刻を取得する。存在しない場合は時間単位(HH:00:00)に揃えて今から1時間前の時刻を取得する。
SELECT case when MAX(ts) ISNULL THEN TIMESTAMP_TRUNC(HOUR, TIMESTAMP_ADD(HOUR,NOW(),-1)) else MAX(ts)
 end AS lasttime FROM etl_output;

# 取得した時刻を変数に格納する
getval LastTime

# 取得した時刻と時間単位に揃えた今の時刻を集計範囲として20秒ごとの平均値を取得して、出力コンテナに登録または更新する
INSERT OR REPLACE INTO etl_output (ts, value)
 SELECT ts,avg(value) FROM etl_input
 WHERE ts BETWEEN TIMESTAMP('$LastTime') AND TIMESTAMP_TRUNC(HOUR, NOW())
 GROUP BY RANGE(ts) EVERY (20, SECOND);

【例3】集計範囲を最終時刻+1時間にして処理対象にする

# gs_shのスクリプトファイル(sample.gsh)

# 存在しない場合はインターバルパーティショニング30日の出力コンテナを作成する。
CREATE TABLE IF NOT EXISTS etl_output (ts TIMESTAMP PRIMARY KEY, value DOUBLE)
 PARTITION BY RANGE (ts) EVERY (30, DAY);

# 登録済みの最終実行時刻を取得する。存在しない場合は時間単位(HH:00:00)に揃えて今から1時間前の時刻を取得する。
SELECT case when MAX(ts) ISNULL THEN TIMESTAMP_TRUNC(HOUR, TIMESTAMP_ADD(HOUR,NOW(),-1)) else MAX(ts)
 end AS lasttime FROM etl_output;

# 取得した時刻を変数に格納する
getval LastTime

# 取得した時刻と取得した時間+1時間を集計範囲として20秒ごとの平均値を取得して、出力コンテナに登録または更新する
INSERT OR REPLACE INTO etl_output (ts, value)
 SELECT ts,avg(value) FROM etl_input
 WHERE ts BETWEEN TIMESTAMP('$LastTime') AND  TIMESTAMP_ADD(HOUR, TIMESTAMP_TRUNC(HOUR, TIMESTAMP('$LastTime')),1)
 GROUP BY RANGE(ts) EVERY (20, SECOND);

定期実行

cronを用いて、定期実行を行います。 1時間ごとに実行する場合はgsadmユーザで以下のようなcronを作成します。

$ su - gsadm
$ crontab -e

0 * * * * gs_sh /var/lib/gridstore/sample.gsh

上記のようにcronとgshスクリプトを組み合わせて定期実行を実現します。

パラメータ

GridDBの動作を制御するパラメータについて説明します。GridDBのパラメータにはノードの設定情報や利用できるリソースなどの設定を行うノード定義ファイルと、クラスタの動作設定を行うクラスタ定義ファイルがあります。 定義ファイルの項目名と初期状態での設定値とパラメータの意味を説明します。

設定値の単位は以下のように指定します。

　

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

クラスタ定義ファイルは、クラスタを構成する全ノードで同一の設定にしておく必要があります。partitionNum,storeBlockSizeパラメータはデータベースの構造を決める重要なパラメータのため、GridDBの初期起動後は値の変更ができません。

クラスタ定義ファイルの各設定項目の意味を以下に説明します。

初期状態で含まれていない項目も項目名を追加することでシステムに認識させることができます。 変更の欄ではパラメータの値の変更可否と変更タイミングを示します。

　

GridDBの構成 初期値 パラメータの意味と制限値 変更  
/notificationAddress 239.0.0.1 マルチキャストアドレスの標準設定です。cluster,transactionの同じ名前のパラメータが省略された場合、本設定が有効になります。異なる値が設定されている場合、個別設定のアドレスが有効です。 起動  
/dataStore/partitionNum 128 パーティション数を構成するクラスタ台数で分割配置できる公倍数で指定します。 整数: 1以上、10000以下で指定します。 変更不可  
/dataStore/storeBlockSize 64KB ディスクI/Oのサイズ(64KB,1MB,4MB,8MB,16MB,32MB)を指定します。ブロックサイズを大きくすると１ブロックに格納できるレコードが増えるため、大規模テーブルのフルスキャンに向きますが、競合が発生する可能性が高くなります。システムにあったサイズを十分に検討して設定してください。サーバ起動後は変更できません。 変更不可  
/cluster/clusterName なし クラスタを識別するための名称を指定します。必須入力のパラメータです。 起動  
/cluster/replicationNum 2 レプリカ数を指定します。レプリカ数が2の場合、パーティションが2重化されます。 起動  
/cluster/notificationAddress 239.0.0.1 クラスタ構成用マルチキャストアドレスを指定します。 起動  
/cluster/notificationPort 20000 クラスタ構成用マルチキャストポート番号を指定します。 ポート番号として指定可能な範囲の値を指定します。 起動  
/cluster/notificationInterval 5秒 クラスタ構成用マルチキャスト周期です。 1s以上、231s未満の値を指定します。 起動  
/cluster/heartbeatInterval 5秒 クラスタ間でのノードの生存確認チェック周期（ハートビート周期）です。 1s以上、231s未満の値を指定します。 起動  
/cluster/loadbalanceCheckInterval 180秒 クラスタを構成するノード間の負荷バランス調整のため、バランス処理を実施するか否かのデータ採取周期を指定します。 1s以上、231s未満の値を指定します。 起動  
/cluster/notificationMember なし クラスタ構成方式を固定リスト方式にする際に、アドレスリストを指定します。 起動  
/cluster/notificationProvider/url なし クラスタ構成方式をプロバイダ方式にする際に、アドレスプロバイダのURLを指定します。 起動  
/cluster/notificationProvider/updateInterval 5秒 アドレスプロバイダからリストを取得する間隔を指定します。1s以上、231s未満の値を指定します。 起動  
/sync/timeoutInterval 30秒 クラスタ間のデータ同期時のタイムアウト時間を指定します。　タイムアウトが発生した場合、システムの負荷が高い、障害発生などの可能性があります。 1s以上、231s未満の値を指定します。 起動  
/cluster/rackZoneAwareness なし ラックゾーンアウェアネス機能を利用するかどうかを指定します。 起動  
/transaction/notificationAddress 239.0.0.1 クライアントが初期に接続するマルチキャストアドレスです。クライアントにはマスタノードが通知されます。 起動  
/transaction/notificationPort 31999 クライアントが初期に接続するマルチキャストポートです。ポート番号として指定可能な範囲の値を指定します。 起動  
/transaction/notificationInterval 5秒 クライアントへのマスタ通知用マルチキャスト周期。1s以上、231s未満の値を指定します。 起動  
/transaction/replicationMode 0 トランザクションでデータ更新をする時のデータの同期（レプリケーション）方法を指定します。文字列または整数で、 “ASYNC”または0(非同期)、”SEMISYNC”または1(準同期)を指定します。 起動  
/transaction/replicationTimeoutInterval 10秒 トランザクションが準同期レプリケーションでデータを同期する際のノード間通信のタイムアウト時間を指定します。1s以上、231s未満の値を指定します。 起動  
/transaction/authenticationTimeoutInterval 5秒 認証タイムアウト時間を指定します。 起動  
/transaction/useMultitenantMode false データベース統計情報(#database_stats)におけるデータ管理情報に関する項目を表示させる場合に指定します。指定しない場合は該当項目は未設定値として表示されます。 起動  
/transaction/siteReplication/enable false サイト間レプリケーション連携機能を有効にするかを指定します オンライン  
/transaction/siteReplication/siteConnectionId ”” サイト間レプリケーション連携機能のキーとなる接続IDを指定します 起動  
/transaction/siteReplication/heartbeatInterval 15秒 サイト間接続のハートビート間隔（秒）を指定します 起動  
/transaction/siteReplication/heartbeatRetryCount 1 ハートビートの再試行回数を指定します 起動  
/transaction/siteReplication/partitionCheckInterval 15秒 各パーティションの状態監視間隔（秒）を指定します 起動  
/transaction/siteReplication/keepLogFileCount 5 トランザクションログファイルの保持数を指定します オンライン  
/transaction/siteReplication/syncWaitTime 0ミリ秒 ログ欠損時の同期処理実行間隔（ミリ秒）を指定します 起動  
/transaction/siteReplication/limitUpdateDelayTime 300秒 スタンバイ側の更新異常判定時間（秒）を指定します オンライン  
/transaction/siteReplication/limitLsnDifference 100000000 スタンバイ側の更新異常判定のLSN差分閾値を指定します オンライン  
/transaction/siteReplication/replicationMember ”” 相手サイトのノード構成情報（アドレスとポート番号リスト）を指定します 起動  
/sql/notificationAddress 239.0.0.1 JDBC/ODBCクライアントが初期に接続するマルチキャストアドレスです。クライアントにはマスタノードが通知されます。 起動  
/sql/notificationPort 41999 JDBC/ODBCクライアントが初期に接続するマルチキャストポートです。ポート番号として指定可能な範囲の値を指定します。 起動  
/sql/notificationInterval 5秒 JDBC/ODBCクライアントへのマスタ通知用マルチキャスト周期です。1s以上、231s未満の値を指定します。 起動  
/sql/costBasedJoin true SQLプラン生成の際、ジョイン順序の決定にコストベースによる方法を用いるかどうかを指定します。用いない(false)場合は、ルールベースによる方法でジョイン順を決定します。 起動  
/sql/costBasedJoinDriving true SQLプラン生成の際、ジョイン駆動表の決定にコストベースによる方法を用いるかどうかを指定します。用いない(false)場合は、ルールベースによる方法で駆動表を決定します。 起動  
/security/authentication INTERNAL 認証方式として、INTERNAL(内部認証) / LDAP(LDAP認証)のいずれかを指定。 起動  
/security/ldapRoleManagement USER GridDBのロールとマッピングする対象として、USER(LDAPユーザ名でマッピング) / GROUP(LDAPグループ名でマッピング)のいずれかを指定。 起動  
/security/ldapUrl   LDAPサーバを次の形式で指定。ldaps://host[:port] 起動  
/security/ldapUserDNPrefix   ユーザのDN（識別子）を生成するために、ユーザ名の前に連結する文字列を指定。 起動  
/security/ldapUserDNSuffix   ユーザのDN(識別子)を生成するために、ユーザ名の後に連結する文字列を指定。 起動  
/security/ldapBindDn   LDAP管理ユーザのDNを指定。 起動  
/security/ldapBindPassword   LDAP管理ユーザのパスワードを指定。 起動  
/security/ldapBaseDn   検索を開始するルートDNを指定。 起動  
/security/ldapSearchAttribute uid 検索対象となる属性を指定。 起動  
/security/ldapMemberOfAttribute memberof ユーザが所属するグループDNが設定された属性を指定。(ldapRoleManagement=GROUPの場合に有効) 起動  
/system/serverSslMode DISABLED SSL接続設定として、DISABLED(SSL無効)、PREFERRED(SSL有効、ただし非SSL接続も許容)、REQUIRED(SSL有効、非SSL接続は不可)のいずれかを指定。 起動  
/system/sslProtocolMaxVersion TLSv1.2 TLSプロトコルバージョンとして、TLSv1.2, TLSv1.3のいずれかを指定。 起動 　

ノード定義ファイル(gs_node.json)

ノード定義ファイルでは、クラスタを構成するノードのリソースを初期設定します。オンライン運用では、配置されているリソース、アクセス頻度などから、オンラインで値を変更できるパラメータもあります。

ノード定義ファイルの各設定項目の意味を以下に説明します。

初期状態で含まれていない項目も項目名を追加することでシステムに認識させることができます。 変更の欄ではパラメータの値の変更可否と変更タイミングを示します。

ディレクトリの指定は、フルパスもしくは、GS_HOME環境変数からの相対パスで指定します。相対パスは、GS_HOMEの初期ディレクトリが基点となります。GS_HOMEの初期設定ディレクトリは、/var/lib/gridstoreです。

GridDBの構成 初期値 パラメータの意味と制限値 変更
/serviceAddress なし cluster,transaction,syncの各サービスアドレスの初期値を設定。3項目のアドレスを設定せずに本アドレスの設定のみで各サービスアドレスの初期値を設定できる。 起動
/dataStore/dbPath data データファイル、チェックポイントログファイルの配置ディレクトリをフルパスもしくは、相対パスで指定する。 起動
/dataStore/transactionLogPath txnlog トランザクションログファイルの配置ディレクトリをフルパスもしくは、相対パスで指定する。 起動
/dataStore/dbFileSplitCount 0 (分割無し) データファイルの分割数。 不可
/dataStore/backupPath backup バックアップファイルの配置ディレクトリのパスを指定。 起動
/dataStore/syncTempPath sync データ同期用一時ファイルの配置ディレクトリのパスを指定。 起動
/dataStore/storeMemoryLimit 1024MB データ管理用メモリの上限。 オンライン
/dataStore/concurrency 4 処理の並列度を指定。 起動
/dataStore/recoveryConcurrency (上記concurrencyと同じ値) リカバリ処理の並列度を指定。 起動
/dataStore/logWriteMode 1 ログ書き出しモード・周期を指定。 -1または0の場合トランザクション終了時にログ書き込み、1以上231未満の場合、秒単位の周期でログ書き込み 起動
/dataStore/persistencyMode 1(NORMAL) 永続化モードでは、データ更新時の更新ログファイルの保持期間を指定する。1(NORMAL)、2(KEEP_ALL_LOG)　のいずれかを指定。”NORMAL” は、チェックポイントにより、不要になったトランザクションログファイルは削除されます。”KEEP_ALL_LOG”は、全てのトランザクションログファイルを残します。 起動
/dataStore/affinityGroupSize 4 アフィニティグループ数 起動
/dataStore/storeCompressionMode NO_COMPRESSION データブロック圧縮モードの指定。以下の値を設定可能。
　・”NO_COMPRESSION”：圧縮機能を無効にします。
　・”COMPRESSION_ZLIB”、”COMPRESSION”：ZLIB圧縮を有効にします。
　・”COMPRESSION_ZSTD”：ZSTD圧縮を有効にします。		 起動
/dataStore/enableAutoArchive false 自動アーカイブ機能を利用するか 起動
/dataStore/autoArchiveName ”” 自動アーカイブ名 起動
/dataStore/enableAutoArchiveOutputInfo true 自動アーカイブ実行時のクラスタやチェックポイント実行に付随するメタ情報を出力するか。自動アーカイブ有効な場合のみ有効化 起動
/dataStore/enableAutoArchiveOutputInfoPath cluster 自動アーカイブ実行時のクラスタやチェックポイント実行に付随するメタ情報を出力先フォルダ名 起動
/checkpoint/checkpointInterval 300秒 メモリ上のデータ更新ブロックを永続化するチェックポイント処理の実行周期 起動
/checkpoint/partialCheckpointInterval 10 チェックポイント実行時に、チェックポイントログファイルへブロック管理情報を書き込む処理の分割数 起動
/cluster/serviceAddress 上位のserviceAddressに従う クラスタ構成用待ち受けアドレス 起動
/cluster/servicePort 10010 クラスタ構成用待ち受けポート 起動
/cluster/notificationInterfaceAddress ”” マルチキャストパケットを送信するインターフェースのアドレスを指定 起動
/cluster/rackZoneId ”” 同一の可用性レベルを持つノードとしてグルーピングするための識別子 起動
/cluster/goalAssignmentRule DEFAULT 新規構成検出時のクラスタパーティション配置表の割当規則。デフォルト(DEFAULT)、ラウンドロビン(ROUNDROBIN)のいずれかを指定 起動
/cluster/enableStableGoal false クラスタパーティション配置表外部指定機能の利用有無 起動
/cluster/enableStandbyMode false スタンバイモードを有効にするか 起動
/sync/serviceAddress 上位のserviceAddressに従う クラスタ間でデータ同期のための受信アドレス 起動
/sync/servicePort 10020 データ同期用待ち受けポート 起動
/sync/redoLogErrorKeepInterval 600s REDOエラー発生時の表示内容の保持期間(この期間を過ぎると自動削除)  
/sync/redoLogMaxMessageSize 2097152 REDO分割実行となるファイルサイズ単位。指定サイズを超えるまで対象ファイルからログ読み出し、レプリケーション、REDOを行う操作手順が分割実行される　  
/sync/enableKeepLog false ノード障害発生後にトランザクションログを指定期間保持する機能を有効にするか 　オンライン
/sync/keepLogInterval 1200s トランザクションログ保持期間の上限。 オンライン
/system/serviceAddress 上位のserviceAddressに従う 運用コマンド用待ち受けアドレス 起動
/system/servicePort 10040 運用コマンド用待ち受けポート 起動
/system/eventLogPath log イベントログファイルの配置ディレクトリのパス 起動
/system/securityPath security サーバ証明書、秘密鍵の配置ディレクトリをフルパスもしくは、相対パスで指定。 起動
/system/serviceSslPort 10045 運用コマンド用待ち受けSSLポート 起動
/transaction/serviceAddress 上位のserviceAddressに従う デフォルトトランザクション処理用待ち受けアドレス 起動
/transaction/publicServiceAddress 上位のserviceAddressに従う クライアント専用トランザクション処理用待ち受けアドレス 起動
/transaction/servicePort 10001 トランザクション処理用待ち受けポート 起動
/transaction/connectionLimit 5000 トランザクション処理接続数の上限 起動
/transaction/totalMemoryLimit 1024MB トランザクション処理用メモリエリアのサイズ上限値 起動
/transaction/transactionTimeoutLimit 300秒 トランザクションタイムアウト時間の上限値 起動
/transaction/reauthenticationInterval 0s(無効) 再認証間隔。(指定時間を超えると再認証が行われ、既に接続中の一般ユーザに対する権限等の変更が反映される。) デフォルト(0s)の場合、再認証は無効。 オンライン
/transaction/workMemoryLimit 128MB トランザクション処理でのデータ参照(get、TQL)時のメモリの上限サイズ(並列度ごと) オンライン
/transaction/notificationInterfaceAddress ”” マルチキャストパケットを送信するインターフェースのアドレスを指定 起動
/sql/serviceAddress 上位のserviceAddressに従う デフォルトNewSQL I/Fアクセスの処理用待ち受けアドレス 起動
/sql/publicServiceAddress 上位のserviceAddressに従う 　クライアント専用NewSQL I/Fアクセスの処理用待ち受けアドレス 起動
/sql/servicePort 20001 NewSQL I/Fアクセスの処理用待ち受けポート 起動
/sql/storeSwapFilePath swap SQL中間ストアのスワップファイルの配置ディレクトリのパス 起動
/sql/storeSwapFileSizeLimit INT32_MAX (2PB) SQL中間ストアのスワップファイルのサイズ上限値(単位:MB) 起動
/sql/storeSwapSyncSize 1024MB SQL中間ストアのスワップファイルのsyncおよび物理メモリキャッシュ消去を行うサイズ 起動
/sql/storeMemoryLimit 1024MB SQL処理でメモリ上に保持する中間データの最大値 起動
/sql/workMemoryLimit 32MB SQL処理でオペレータが使用するメモリの最大値 起動
/sql/workCacheMemory 128MB SQL処理でオペレータが使用するメモリのうち、使用後に解放せずにキャッシュするメモリサイズ 起動
/sql/connectionLimit 5000 NewSQL I/Fアクセスの処理接続数の上限 起動
/sql/concurrency 4 同時実行スレッド数 起動
/sql/traceLimitExecutionTime 300秒 スロークエリをイベントログに残す実行時間の下限値 オンライン
/sql/traceLimitQuerySize 1000 スロークエリに残るクエリ文字列のサイズ上限(バイト) オンライン
/sql/notificationInterfaceAddress ”” マルチキャストパケットを送信するインターフェースのアドレスを指定 起動
/sql/addBatchMaxCount 1000 バッチ更新件数上限値 起動
/sql/tablePartitioningMaxAssignNum 10000 テーブルパーティショニング分割個数最大数 起動
/trace/fileCount 30 イベントログファイルの上限数 起動
/security/userCacheSize 1000 キャッシュする一般ユーザ/LDAPユーザエントリ数を指定。 起動
/security/userCacheUpdateInterval 60 キャッシュの更新間隔（秒）を指定。 起動

監査ログに関する設定

GridDBの構成 初期値 パラメータの意味と制限値 変更
/trace/auditLogs false 監査ログ機能の有効化 起動
/trace/auditLogsPath ”” 監査ログファイルの出力先パス 起動
/trace/auditFileLimit ”” 監査ログファイルの1ファイルのサイズ上限値 起動
/trace/auditMessageLimit ”” 監査ログファイルの1監査イベントのメッセージサイズ上限値 起動
/trace/auditConnect INFO 接続(接続、切断、認証)に関する監査ログの出力レベル オンライン
/trace/auditSqlRead CRITICAL SQL(SELECT)に関する監査ログの出力レベル オンライン
/trace/auditSqlWrite CRITICAL SQL(DML)に関する監査ログの出力レベル オンライン
/trace/auditDdl CRITICAL SQL(DDL)に関する監査ログの出力レベル オンライン
/trace/auditDcl CRITICAL SQL(DCL)に関する監査ログの出力レベル オンライン
/trace/auditNosqlRead CRITICAL NoSQL(参照系)に関する監査ログの出力レベル オンライン
/trace/auditSqlWrite CRITICAL NoSQL(更新系)に関する監査ログの出力レベル オンライン
/trace/auditSystem CRITICAL 運用コマンド(STAT以外)に関する監査ログの出力レベル オンライン
/trace/auditStat CRITICAL 運用コマンド(STAT)に関する監査ログの出力レベル オンライン

システムの制限値

数値に関する制限

ブロックサイズ 64KB 1MB～32MB
文字列型/空間型のデータサイズ 31KB 128KB
BLOB型のデータサイズ 1GB - 1Byte 1GB - 1Byte
配列長 4000 65000
カラム数 1024個 約7K～32000個(※1)
索引数(コンテナ1個あたり) 1024個 16000個
ユーザ数 128 128
データベース数 128個 128個
アフィニティグループ数 10000 10000
解放期限付き時系列コンテナの分割数 160 160
GridDBノードが管理する通信バッファのサイズ 約2GB 約2GB
ブロックサイズ 64KB 1MB 4MB 8MB 16MB 32MB
パーティションサイズ 約4TB 約64TB 約256TB 約512TB 約1PB 約2PB

ネーミングに関する制限

名前 使用可能な文字 長さの上限
管理ユーザ 先頭が”gs#“で始まる。それ以外の文字は英数字、’_’ 64文字
一般ユーザ 英数字、’_‘、’-‘、’.’、’/’、’=’ 64文字
ロール 英数字、’_‘、’-‘、’.’、’/’、’=’ 64文字
パスワード Unicodeコードポイントを文字とする
任意個数の文字の列(NULL文字(U+0000)は不可)		 64バイト(UTF-8エンコード換算)
クラスタ名 英数字、’_‘、’-‘、’.’、’/’、’=’ 64文字
データベース名 英数字、’_‘、’-‘、’.’、’/’、’=’ 64文字
コンテナ名
テーブル名
ビュー名		 英数字、’_‘、’-‘、’.’、’/’、’=’
(ノードアフィニティを指定する場合のみ’@’)		 16384文字(ブロックサイズ64KB)
131072文字(ブロックサイズ1MB～32MB)
カラム名 英数字、’_‘、’-‘、’.’、’/’、’=’ 256文字
索引名 英数字、’_‘、’-‘、’.’、’/’、’=’ 16384文字(ブロックサイズ64KB)
131072文字(ブロックサイズ1MB～32MB)
バックアップ名 英数字、’_’ 12文字
データアフィニティ 英数字、’_‘、’-‘、’.’、’/’、’=’ 8文字

付録

ディレクトリ構成(EE)

GridDBのサーバやクライアントをインストールした時のディレクトリ構成を以下に示します。X.x.xはGridDBのバージョンを表します。

(サーバ／クライアントをインストールしたマシン)
/usr/griddb-ee-X.X.X/                                    GridDBインストールディレクトリ
                     Readme.txt
                     bin/
                         gs_xxx                          各種コマンド
                         gsserver                        サーバモジュール
                         gssvc                           サーバモジュール
                     conf/
                     etc/
                     lib/
                         gridstore-tools-X.X.X.jar
                         XXX.jar                         フリーソフトウェア
                     license/
                     misc/
                     prop/
                     sample/

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

/usr/griddb-ee-webui-X.X.X/                              統合運用管理GUIディレクトリ
                           conf/
                           etc/
                           griddb-webui-ee-X.X.X.jar

/usr/griddb-ee-webui/griddb-webui.jar -> /usr/griddb-ee-webui-X.X.X/griddb-webui-ee-X.X.X.jar

/var/lib/gridstore/                                      GridDBホームディレクトリ(作業ディレクトリ)
                   admin/                                統合運用管理GUIホームディレクトリ(adminHome)
                   backup/                               バックアップファイル格納ディレクトリ
                   conf/                                 定義ファイルの格納ディレクトリ
                        gs_cluster.json                  クラスタ定義ファイル
                        gs_node.json                     ノード定義ファイル
                        password                         ユーザ定義ファイル
                   data/                                 データベースファイル格納ディレクトリ
                   txnlog/                               トランザクションログ格納ディレクトリ
                   expimp/                               Export/Importツールディレクトリ
                   log/                                  イベントログ格納ディレクトリ
                   webapi/                               Web APIディレクトリ

/usr/bin/
         gs_xxx -> /usr/griddb-ee-X.X.X/bin/gs_xxx                       各種コマンドへのリンク
         gsserver -> /usr/griddb-ee-X.X.X/bin/gsserver                   サーバモジュールへのリンク
         gssvc -> /usr/griddb-ee-X.X.X/bin/gssvc                         サーバモジュールへのリンク

/usr/lib/systemd/system
            gridstore.service                            systemd ユニットファイル

/usr/griddb-ee-X.X.X/bin
            gridstore                                    サービススクリプト

(ライブラリをインストールしたマシン)
/usr/griddb-ee-X.X.X/                                    インストールディレクトリ
                     lib/
                         gridstore-X.X.X.jar
                         gridstore-advanced-X.X.X.jar
                         gridstore-call-logging-X.X.X.jar
                         gridstore-conf-X.X.X.jar
                         gridstore-jdbc-X.X.X.jar
                         gridstore-jdbc-call-logging-X.X.X.jar
                         gridstore.h
                         libgridstore.so.0.0.0
                         libgridstore_advanced.so.0.0.0
                         python/                         Pythonライブラリディレクトリ
                         nodejs/                         Node.jsライブラリディレクトリ
                             sample/
                             griddb_client.node
                             griddb_node.js
                         go/                             Goライブラリディレクトリ
                             sample/
                             pkg/linux_amd64/griddb/go_client.a
                             src/griddb/go_client/       Goライブラリのソースディレクトリ
                         conf/                           
                         javadoc/                           

/usr/griddb-ee-webapi-X.X.X/                             Web APIディレクトリ
                     conf/
                     etc/
                     griddb-webapi-ee-X.X.X.jar

/usr/girddb-webapi/griddb-webapi.jar -> /usr/griddb-ee-webapi-X.X.X/griddb-webapi-ee-X.X.X.jar

/usr/share/java/gridstore.jar -> /usr/griddb-ee-X.X.X/lib/gridstore-X.X.X.jar
/usr/share/java/gridstore-advanced.jar -> /usr/griddb-ee-X.X.X/lib/gridstore-advanced-X.X.X.jar
/usr/share/java/gridstore-call-logging.jar -> /usr/griddb-ee-X.X.X/lib/gridstore-call-logging-X.X.X.jar
/usr/share/java/gridstore-conf.jar -> /usr/griddb-ee-X.X.X/lib/gridstore-conf-X.X.X.jar
/usr/share/java/gridstore-jdbc.jar -> /usr/griddb-ee-X.X.X/lib/gridstore-jdbc-X.X.X.jar
/usr/share/java/gridstore-jdbc-call-logging.jar -> /usr/griddb-ee-X.X.X/lib/gridstore-jdbc-call-logging-X.X.X.jar


/usr/include/gridstore.h -> /usr/griddb-ee-X.X.X/lib/gridstore.h

/usr/lib64/                                             ※CentOSの場合は/usr/lib64、Ubuntu Serverの場合は/usr/lib/x86_64-linux-gnu
           libgridstore.so -> libgridstore.so.0
           libgridstore.so.0 -> libgridstore.so.0.0.0
           libgridstore.so.0.0.0 -> /usr/griddb-ee-X.X.X/lib/libgridstore.so.0.0.0
           libgridstore_advanced.so -> libgridstore_advanced.so.0
           libgridstore_advanced.so.0 -> libgridstore_advanced.so.0.0.0
           libgridstore_advanced.so.0.0.0 -> /usr/griddb-ee-X.X.X/lib/libgridstore_advanced.so.0.0.0