Naoya Murakami
visio****@gmail*****
2014年 5月 3日 (土) 15:29:31 JST
こんにちは。ユーザの村上と申します。 たんなる予測ですが、以下の手順を確認してみてはいかがでしょうか。 なお、問題が起きるのは特定のDBだけで、新たに別のDBを作って試すとエラーは発生しません。 > しかし、問題のDBをいったん消して、同名のDBを作り直した場合には、同じエラーが起きてしまいます。 > つい先日まで正常にできていたはずの処理なんですが（上掲「ALTER > TABLE～」を含むユニットテストが完走していました）、何がきっかけでこの状態になったのかも判然としません。 > > 強いていえば、ユニットテストがいつになっても完走しないケースがあって、やむなくDB再起動で打ち切ったことがありましたが、その際に何か問題が残ってしまったのかもしれません。 > 特定のDBというのは、MySQL(MariaDB)でいうデータベースということでいいですよね？ テーブルではなく。 MySQLのデータベースとすると、特定のファイル名のGroongaデータベースのみが作れ ないということになるので、Groongaのオブジェクト管理用のキーがロックされているか、 何らかの不正な状態になっていることが推測されます。 ロックとかだと、groonga.logを見ればメッセージがでていると思います。ロックの場合、 ***.mrn.001とかじゃなければ、Groongaコマンドのclearlockで解除すれば、うまくいく 可能性があります。 あ、あと、テーブル削除したときは、FLUSH TABLESするかmysqldを再起動して、 Groongaのデータベースを一端離してやらないと、うまくいかないことがあります。 特定のデータベースのみだめということなので、可能であれば、対象のデータベースに 対応する.mrnファイルをOSコマンドで消してしまってはいかかでしょうか。 もし、データベースではなく特定のテーブルだけだめとなると、MySQL上のテーブル定義 情報は消えていて、Groongaデータベース上で同じ名前のテーブルが残ってしまっている 可能性がある気がしました。その場合は、GroongaのデータベースからGroongaのテーブル を削除したらうまくいく可能性があります。 この場合も、groonga.logを見るとだいたい推測がつくような気がします。 たぶん、GroongaのDDL作成が失敗している系のメッセージがでるでしょう。 WindowsのMariaDBではMroongaを使ったことがないので、それ以外の原因かもしれま せん。解決のヒントになればと思います。 ちょっと情報を書きすぎて、わけがわからないかもしれません。わからなければ、 どこがわからないか教えていただければ、私が理解している範囲ならば、解説 できるかもしれません。 以上、よろしくお願いします。
