Kouhei Sutou
kou****@clear*****
2015年 7月 23日 (木) 23:14:07 JST
須藤です。 In <20150****@orega*****> "[groonga-dev,03379] Re: PGROONGAで障害発生" on Thu, 23 Jul 2015 09:13:36 +0900, 高見 直輝 <takam****@orega*****> wrote: >> https://www.postgresql.jp/document/9.4/html/sql-vacuum.html >> >> を見ると対象テーブル・カラムを指定できるようなので、これを使 >> えるかもしれません。 > > pgroongaスキーマにダミーのテーブルを作っておいて、それに対してVACUUMを実 > 行すると削除漏れファイルの処理だけが実行される・・・みたいな感じだと気楽 > に実行できますね。 あ、たぶんそれでも大丈夫ですよ。 PGroongaに「バキュームしたよー！」イベントが通知されたら、 PGroongaはデータベース内のすべてのテーブルについて削除済みか どうかを確認しにいくのです。なので、ダミーのテーブルでも動く と思います。 > 差し当たり、“ログファイルへの出力を完全に停止する”設定方法がわかれば問 > 題ありません。 であれば、↓でいけます。設定ファイルに書いても大丈夫です。 SET pgroonga.log_level = 'none'; > 運用段階でログを入手する場合、ログファイルを色んな場所から集めるのは結構 > な手間なので、あると助かります。 なるほど。であれば、 >> データベース単位ではなくPostgreSQLのインスタンス単位でまとめ >> てログを管理したい場合はあるとうれしそうですが、そっちの方が >> うれしそうならデフォルトをそうしてデータベース単位ではログを >> 出さない方がいいかなぁと思っています。 としてしまった方がいいかもしれませんね。 >> PostgreSQL本体のログはどのように運用するものなのか知っていた >> ら教えて欲しいです。参考にしたいです。 > > 当方の例で言うと、PostgreSQLのログは、Windowsのイベントログに出力するよ > うにしています。 あぁ、イベントログですか。情報ありがとうございます。 Groonga本体でイベントログ出力をサポートして、PGroongaからそ の機能を使うようにするのがよさそうな気がしてきました。
