Kimura A
a.kim****@live*****
2014年 8月 24日 (日) 19:49:27 JST
木村です。村上さんご回答ありがとうございます。 > 記事とはFULLTEXT INDEXの作り方が異なっています。 > (ちなみにこのQiitaの記事は以前誤っており編集されております。) ご示唆の通り、古いバージョン（Evernoteに保存した記事）を見て作業してました…。 しっかりメインテナンスされてるんですね。今後気をつけます。 > Qiitaの記事のインデックスの作成方法だと、bugsのFULLTEXT > インデックスにより、Groonga的にはインデックスカラムは1_tagsの > 方に作成されて、bugsテーブルのtagsカラムを対象にします。 > （たぶんわけがわからないと思います） たしかにあまり理解できていないのですが、さしあたり ◯CREATE TABLE時の構文を現在の記事のものに手直しして、テーブルを生成し、 ◯ダンプしたファイルからCONSTRAINT節を除去してインポート することで、ベクターカラムによる検索が可能になりました。ありがとうございます。 なお、インポートの際に /*!40000 ALTER TABLE `bugs` ENABLE KEYS */; の行で以下のエラーが出ました。 ERROR 1005 (HY000) at line 63 in file: '〜.sql': [table][remove] a column that references the table exists: <bugs.tags> -> <1_tags> 日本語にすると「そのテーブルを参照するカラムが存在する」でしょうか。 意味ははっきりわかりませんが、これには村上さんご指摘の「ALTER TABLE bugs DISABLE KEYSで全文インデックス用のインデックスカラムが削除され」る、という挙動が関係しているのかな、と憶測しています。つまり、 1. DISABLE KEYSでbugsテーブルのインデックスカラムが削除された際に、外部テーブル1_tagsを参照するインデックスカラムだけが削除されずに残る。 2. ENABLE KEYSでbugsテーブルのインデックスカラムを復元する際に、削除されていないtagsインデックスカラムまで復元しようとしてしまい、このエラーが出る。 という感じなのかな…と。 正直なところ、僕はまだ「インデックスカラム」という用語自体よくわかっていないのですが、「検索用に自動生成される隠しカラム」みたいな理解で合っているでしょうか。 何にせよ、エラーは出ているものの、結果としてはベクターカラムによる検索は機能しているので、MySQLDumpからの復旧はこれでよしとしようか、と考えています。 > Qiitaの記事の方法のように、テーブル参照型のインデックスを > 張ればいい思います。こうすれば、そのままダンプファイルを > リストアすることができました。 こちらも実験してみました。 まずベクターカラムによる検索が機能しなくなったDBにおいて、既存の全文インデックスに「table "tags"」コメントを追加しようとすると、MySQLが落ちました。 そこで、いったん全文インデックスを削除して付け直してみました。その際のコマンドは以下の通りです。 ALTER TABLE `test2`.`bugs` ADD FULLTEXT `tags` (`tags`)COMMENT 'table "tags"'; が、わずか計7件のレコードに対するインデックスにも関わらず、20分経っても終わる気配がなく（汗）killして終了としました。 Windowsに限った話かもしれないのですが、Mroongaのテーブルに対してALTER TABLEでインデックスをいじろうとすると、何かしらのトラブルが発生して、結局テーブルを作り直さざるを得なくなるケースが多い気がしています…。 再現条件を特定できればいいんですが、今回はちょっと余裕がないので、テーブル削除→作り直しという方向で対策することにしました。 どうもありがとうございましたm(_ _)m
