`Ctrl`+`K`

# 7.1.1. `grndb`

## 7.1.1.1. 概要

バージョン 4.0.9 で追加.

`grndb` はGroongaのデータベースを管理します。

機能は次の通りです。

> - データベースが壊れているかどうかをチェックする。

> - 壊れたデータベースが復旧可能なら自動でデータベースを復旧する。

## 7.1.1.2. 構文

`grndb` にはコマンドとデータベースのパスを渡します。:

    grndb COMMAND [OPTIONS] DATABASE_PATH

利用可能なコマンドは以下の通りです。

> - `check` - データベースが壊れているかどうかをチェックします。

> - `recover` - データベースを復旧します。

## 7.1.1.3. 使い方

以下は `/var/lib/groonga/db/db` にあるデータベースをチェックする例です:

    % grndb check /var/lib/groonga/db/db

以下は `/var/lib/groonga/db/db` にあるデータベースを復旧する例です:

    % grndb recover /var/lib/groonga/db/db

## 7.1.1.4. コマンド一覧

このセクションでは利用可能なコマンドについて説明します。

### 7.1.1.4.1. `check`

既存のGroongaデータベースをチェックします。もし、データベースが壊れていたら `grndb` は詳細を報告し、 `0` 以外の終了ステータスで終了します。

注釈

このコマンドを他のプロセスが開いているデータベースに対しては使ってはいけません。もし、データベースが他のプロセスから開かれていると、このコマンドは間違った結果を報告する可能性があります。

`check` にはいくつかオプションがあります。

#### 7.1.1.4.1.1. `--target`

バージョン 5.1.2 で追加.

チェック対象のオブジェクトを指定します。

もし、データベースが大きく、かつ、信頼できないオブジェクトがわかっているなら、このオプションが役に立つでしょう。 `check` は大きなデータベースほど処理に時間がかかります。 `--target` オプションでチェック対象を限定することでチェック時間を削減できます。

`check` はチェック対象を再帰的にチェックします。なぜなら、信頼できないオブジェクトに関連するオブジェクトも信頼できないことが多いからです。

チェック対象がテーブルの場合、そのテーブルのすべてのカラムも再帰的にチェックします。

チェック対象がテーブルでテーブルのキーの型が他のテーブルの場合、他のテーブルも再帰的にチェックします。

チェック対象がカラムで値の型がテーブルの場合、そのテーブルも再帰的にチェックします。

チェック対象がインデックスカラムの場合、値の型に指定したテーブルとすべてのソースも再帰的にチェックします。

以下は `Entries` テーブルとそのカラムだけをチェックする例です。:

    % grndb check --target Entries /var/lib/groonga/db/db

以下は `Entries.name` カラムだけをチェックする例です。:

    % grndb check --target Entries.name /var/lib/groonga/db/db

#### 7.1.1.4.1.2. `--log-level`

バージョン 7.0.4 で追加.

`grndb` のログレベルを指定します。

以下は `--log-level` オプションを指定する例です。

    % grndb check --log-level info --log-path /var/log/groonga/grndb.log /var/lib/groonga/db/db

サポートされているログレベルについては log_level を参照してください。

#### 7.1.1.4.1.3. `--log-path`

バージョン 7.0.4 で追加.

`grndb` のログ出力先のパスを指定します。

以下は `--log-path` オプションを指定する例です。

    % grndb check --log-path /var/log/groonga/grndb.log /var/lib/groonga/db/db

#### 7.1.1.4.1.4. `--log-flags`

バージョン 9.0.3 で追加.

`grndb` のログに出力する内容をフラグで指定します。 `--log-flags` のデフォルト値は `time|message` です。 `grndb` のログにタイムスタンプとログメッセージを出力することを意味します。

以下は `--log-flags` オプションを指定する例です。

    % grndb check --log-path /var/log/groonga/grndb.log --log-flags "time|pid|message" /var/lib/groonga/db/db

サポートされているログフラグについては groonga 実行ファイル を参照してください。

#### 7.1.1.4.1.5. `--since`

バージョン 9.0.4 で追加.

チェックすべきオブジェクトの更新時刻を指定します。もしオブジェクトの更新時刻が指定したものよりも新しければ、 `grndb` のチェックの対象となります。更新時刻は ISO 8601形式か -3days や -2.5weeksといった `-NUNIT` 形式で指定します。

以下は `--since` オプションをISO 8601形式で指定する例です。

    % grmdb check --since=2019-06-24T18:16:22 /var/lib/groonga/db/db

上記の例では `2019-06-24T18:16:22` 以降に更新されたオブジェクトをチェックします。

以下は `--since` オプションを `-NUNIT` 形式で指定する例です。

    % grmdb check --since=-7d /var/lib/groonga/db/db

上記の例では、直近7日で更新されたものがチェックされます。

`-NUNIT` は以下の単位を受け付けます。

対応している単位 | 説明
--- | ---
`s`, `sec`, `secs`, `second`, `seconds` | 直近N秒を指定します。例えば、 `--since=-100s` は直近100秒以内のものをチェックします。
`m`, `min`, `mins`, `minute`, `minutes` | 直近N分を指定します。例えば、 `--since=-10m` は直近10分以内のものをチェックします。
`h`, `hour`, `hours` | 直近N時間を指定します。例えば、 `--since=-10h` は直近10時間以内のものをチェックします。
`d`, `day`, `days` | 直近N日を指定します。例えば、 `--since=-10d` は直近10日以内のものをチェックします。
`w`, `week`, `weeks` | 直近N週を指定します。例えば、 `--since=-10w` は直近10週以内のものをチェックします。
`month`, `months` | 直近10ヶ月を指定します。例えば、 `--since=-10month` は直近10ヶ月以内のものをチェックします。
`year`, `years` | 直近N年を指定します。例えば、 `--since=-1year` は直近1年以内のものをチェックします。

### 7.1.1.4.2. `recover`

既存の壊れたGroongaデータベースを復旧します。

もしデータベースが壊れていなかったら、 `grndb` は何もせず終了ステータス `0` で終了します。

もしデータベースが壊れていて、壊れているのがインデックスカラムだけなら、 `grndb` は壊れているインデックスカラムを復旧して終了ステータス `0` で終了します。インデックス対象のデータが大きい場合は復旧に長時間かかることもあります。

もしデータベースが壊れていて、壊れているのがテーブルまたはデータカラムの場合は、 `grndb` は壊れている原因を報告して `0` 以外の終了ステータスで終了します。データベースを復旧可能かどうかは `check` コマンドで確認できます。

注釈

このコマンドを他のプロセスが開いているデータベースに対しては使ってはいけません。もし、データベースが他のプロセスから開かれていると、このコマンドはデータベースを壊してしまう可能性があります。

`recover` にはいくつかオプションがあります。

#### 7.1.1.4.2.1. `--force-truncate`

バージョン 7.0.4 で追加.

壊れたデータベースオブジェクトを強制的に初期化します。

以下は `--force-truncate` オプションを指定する例です。

    % grndb recover --force-truncate --log-level info --log-path /var/log/groonga/grndb.log /var/lib/groonga/db/db

このオプションが指定されたとき、 `grndb` は次のことを実行します。:

- 壊れたデータベースオブジェクト(テーブル、カラム、インデックス)がないかチェックします

- 壊れたデータベースオブジェクト(テーブル、カラム、インデックス)を初期化します

- 大量のデータをロードしたときに作られる増分ファイル(末尾に.00Nがつきます)を削除します

`--force-truncate` は破壊的なオプションです。ロックが残留していても、 `grndb` は構わず対象となる壊れたデータベースオブジェクトを初期化します。

`grndb recover` の処理が終わったら、データベースを再構築するために初期化されたテーブルやカラムに対して再びデータをロードする必要があります。

注釈

このオプションは必要なときのみ使用します。つまりデータベースのメタ情報と実際に存在するデータベースのオブジェクトファイルの情報が食い違っているときです。 他にデータベースを復旧する方法がないときのみ使うべきです。

#### 7.1.1.4.2.2. `--force-lock-clear`

バージョン 7.1.1 で追加.

データベース・テーブル・データカラムのロックをクリアーします。インデックスカラムのロックはクリアーしません。インデックスカラムにロックが残っている場合はロックをクリアーするのではなく作り直します。

通常、ロックをクリアーするのではなく、初期化（truncate）してデータをロードし直すべきです。なぜならロックが残留しているオブジェクトは壊れているかもしれないからです。このオプションは「データベースは壊れているかもしれないけどそのまま使い続けたい」というリスクをわかったユーザーだけのために用意されています。

以下は `--force-lock-clear` オプションを指定する例です。

    % grndb recover --force-lock-clear --log-level info --log-path /var/log/groonga/grndb.log /var/lib/groonga/db/db

このオプションが指定されたとき、 `grndb` は次のことを実行します。:

- ロックが残留したデータベース・テーブル・データカラムがないかチェック

- これらのオブジェクトのロックをクリアー

注釈

このオプションは必要なときのみ使用するべきです。なぜならこのデータベースは実は復旧できていないかもしれないからです。ロックが残留しているデータベースは壊れているかもしれませんし壊れていないかもしれません。このオプションを使うことでデータベースを使い続けることはできますが、もしデータベースが壊れていたらGroongaがクラッシュするかもしれません。

#### 7.1.1.4.2.3. `--log-level`

バージョン 7.0.4 で追加.

`grndb` のログレベルを指定します。

以下は `--log-level` オプションを指定する例です。

    % grndb recover --log-level info --log-path /var/log/groonga/grndb.log /var/lib/groonga/db/db

サポートされているログレベルについては log_level を参照してください。

#### 7.1.1.4.2.4. `--log-path`

バージョン 7.0.4 で追加.

`grndb` のログ出力先のパスを指定します。

以下は `--log-path` オプションを指定する例です。

    % grndb recover --log-path /var/log/groonga/grndb.log /var/lib/groonga/db/db

#### 7.1.1.4.2.5. `--log-flags`

バージョン 9.0.2 で追加.

`grndb` のログに出力する内容をフラグで指定します。 `--log-flags` のデフォルト値は `time|message` です。 `grndb` のログにタイムスタンプとログメッセージを出力することを意味します。

以下は `--log-flags` オプションを指定する例です。

    % grndb check --log-path /var/log/groonga/grndb.log --log-flags "time|pid|message" /var/lib/groonga/db/db

サポートされているログフラグについては groonga 実行ファイル を参照してください。