Kimura A
a.kim****@live*****
2014年 6月 16日 (月) 15:06:27 JST
木村です。 村上さんご回答ありがとうございます。 > 本件について、ストレージエンジンのMroongaでMySQLのクライアント > コマンドのmysqldumpをどうこうするってのは、できなそうだなーって > 感じました。 やはりベクターカラムを持つテーブルを生成する際は、連携先のテーブルの存在を自動的に確認する処理が不可欠なんですね。 実は最初、ベクターカラムの挙動をテストした際も、先に本体テーブルを作ろうとしてエラーが出て、「？？」となった経緯がありました。 なので、いっそのこと、この自動確認処理はなくてもよいんじゃあるまいか…？とちょっと思っていました。 > 案２ > ・データのみダンプ、テーブル定義のみダンプ、特定テーブルを除くといった > mysqldumpのオプションを駆使して、参照関係にあるテーブルのみが先に > 作られるように実行するスクリプトを作る。 この案2を軸に考えてみようと思います。 ありがとうございましたm(_ _)m ---------------------------------------- > Date: Sat, 14 Jun 2014 23:18:33 +0900 > From: visio****@gmail***** > To: groon****@lists***** > Subject: [groonga-dev,02430] Re: ベクターカラム使用時のダンプファイルからのDB復旧について > > Groongaユーザの村上です。 > > ベクターカラムがあるテーブルを含むDBを、mysqldumpで生成したSQLファイルから復旧する際に問題が発生しました。 >> >> >> このうち、postsはMroongaストレージエンジンのテーブル、vector_tagsはposts.vector_tagsカラムをベクターカラムとして使うための従属的なMroongaテーブルとします。 >> このDBをダンプして復旧しようとすると、CREATE TABLE postsが走る時点でエラーになってしまいます。 >> > > Groongaのダンプ系のコマンドでは参照関係を考慮してダンプしてくれ > ますが、MySQLではGroongaの構造までは考慮しないのでこうなり > うるでしょうね。 > > 本件について、ストレージエンジンのMroongaでMySQLのクライアント > コマンドのmysqldumpをどうこうするってのは、できなそうだなーって > 感じました。 > （感じただけで、調べたわけではないのでできるかどうかはわかりません。） > > 私には根本的な解決方法は示せませんが、私ならきっと以下のどちらかで > アプローチすると思います。 > > 案１ > ・mysqldumpでダンプされるテーブルの順番の規則をソースなり > 実行してみるなりして調べる。 > その規則にのっとって、リファレンスベクター用の参照先テーブルは、 > 参照元のテーブルよりもダンプ時に後に来るようにつくる。 > たとえば、テーブル名順にダンプされるなら、かならず後ろに来るように > 適当な接頭辞つけるとか。 > > 案２ > ・データのみダンプ、テーブル定義のみダンプ、特定テーブルを除くといった > mysqldumpのオプションを駆使して、参照関係にあるテーブルのみが先に > 作られるように実行するスクリプトを作る。 > > http://dev.mysql.com/doc/refman/5.1/ja/mysqldump.html > > http://dev.mysql.com/doc/refman/5.6/en/mysqldump.html > > 一ユーザの意見で参考になるかはわかりませんが、よければご検討ください。 > > 以上、よろしくお願いします。 > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev
