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 は以下の単位を受け付けます。
対応している単位 |
説明 |
|---|---|
|
直近N秒を指定します。例えば、 |
|
直近N分を指定します。例えば、 |
|
直近N時間を指定します。例えば、 |
|
直近N日を指定します。例えば、 |
|
直近N週を指定します。例えば、 |
|
直近10ヶ月を指定します。例えば、 |
|
直近N年を指定します。例えば、 |
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 実行ファイル を参照してください。