slf4j + logback でログを毎時ローテートするsolrのwarファイルを作成する
概要
solr (tomcat6) のロギングはデフォルトがJDK loggingみたいなのだけど、こいつだと毎時ログのローテートをするのが困難なのでslf4j + logbackを使って毎時ローテートできるwarファイルを作る手順。JAVA関係のロギングは
の組み合わせで成り立ってる場合が多いみたいで、API、Utilityともにいくつか種類があるみたい。
少し前までは commons-logging + log4j という組み合わせが主流だったみたいだけど、昨今は slf4j + logback という流れになってきてる様子。
solr自体はslf4j + JDK loggingをデフォルトで採用しているようなので JDK logging -> logbackを行えば良いという事になる
手順
wget http://ftp.riken.jp/net/apache/lucene/solr/3.4.0/apache-solr-3.4.0-src.tgz wget http://logback.qos.ch/dist/logback-1.0.0.tar.gz tar zxvf apache-solr-3.4.0-src.tgz tar zxvf logback-1.0.0.tar.gz mkdir apache-solr-3.4.0/solr/webapp/web/WEB-INF/classes cp logback-1.0.0/logback-core-1.0.0.jar apache-solr-3.4.0/solr/lib/ cp logback-1.0.0/logback-classic-1.0.0.jar apache-solr-3.4.0/solr/lib/
logbackの設定ファイルを作成。出力先は/var/log/tomcat6/solr.YYYY-MM-DD_HH.log
------ apache-solr-3.4.0/solr/webapp/web/WEB-INF/classes/logback.xml ------/var/log/tomcat6/solr.%d{yyyy-MM-dd_HH}.log 72 %-4relative [%thread] %-5level %logger{35} - %msg%n
warファイルを作成する
cd apache-solr-3.4.0 ant compile cd solr ant dist
apache-solr-3.4.0/solr/dist/apache-solr-3.4-SNAPSHOT.war が毎時ローテートに対応したsolrのwarファイルになる。
rails開発関連で使えそうなものメモ
ここ数ヶ月ほぼ0知識からRails(というかRailsでサイトを動かすための環境)を色々調べる機会があったんだけど、中々情報が俯瞰的にまとまってるとこがない(すぐに情報が古くなるからだろうか...)。折角だから概要とか実際使ってみた感じとか説明してくれてるページへのリンクとか書いて後でどっかにまとめられたら良いなと思ってる。とりあえずは自分のためってのも含めてざっとメモ。定番のものとかもあんまりしらないので(passengerとかthinとかmongrelも使ったことねーし!)主に触った&興味があるベースになっております。
実行環境、ライブラリ管理
rbenv
RVM
RubyGem
bundler
運用ツール
bluepill
rbenvでrailsの動作環境を構築
rbenvインストール
git clone git://github.com/sstephenson/rbenv.git .rbenv echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc echo 'eval "$(rbenv init -)"' >> ~/.bashrc
ruby-buildインストール
cd /usr/local/src sudo git clone git://github.com/sstephenson/ruby-build.git cd ruby-build sudo ./install.sh
ruby(今回は1.9.3-p0)をインストールしてデフォルトに指定
rbenv install 1.9.3-p0 rbenv global 1.9.3-p0
Railsで利用するライブラリ郡は各プロジェクト毎にbundlerで管理するようにしたいので
- GEMでbundlerのみをインストール
- bundlerを一旦使ってrailsをインストール
- railsでプロジェクト(example)を作成
- railsをインストールするために使ったbundlerの環境を削除
- example内で必要なライブラリをインストール
という手順を踏む
bundlerインストール
rbenv exec gem install bundler
一旦rails (3.1.1) をインストールしてexampleを作成
cat << EOS > Gemfile source "http://rubygems.org" gem "rails", "3.1.1" EOS bundle install --path vendor/bundle bundle exec rails new example rm -f Gemfile rm -f Gemfile.lock rm -rf .bundle rm -rf vendor/bundle
bundle installする際に--path vendor/bundleすることで本来$GEM_HOMEに入るライブラリがvendor/bundle下に配備される。vendor/bundleに入ったファイルを使ってコマンドを実行したい場合は上記のようにbundle exec 〜のようにすればよい。
後はexample内でインストールを行う際も--path vendor/bundleオプションをつけてbundle installすることでプロジェクト内に閉じた状態でライブラリ郡をインストールすることができる。
exampleでライブラリをインストールしてサーバを起動
cd example bundle install --path vendor/bundle bundle exec rails server
こんな感じ
solr 3.4 インストール
ちょっと前にリリースされたsolr 3.4をインストールしてチュートリアルをやってみるメモ。環境はubuntu 10.04
動作に必要なパッケージをインストール
aptitude -y install openjdk-6-jdk aptitude -y install sun-java6-jdk aptitude -y install ant
solr 3.4 をソースからコンパイル
wget http://ftp.riken.jp/net/apache//lucene/solr/3.4.0/apache-solr-3.4.0-src.tgz tar zxvf apache-solr-3.4.0-src.tgz cd apache-solr-3.4.0 ant compile cd solr ant dist
付属のexample on jettyにsolrをdeployして起動
cp dist/apache-solr-3.4-SNAPSHOT.war example/webapps/solr.war cd example java -jar start.jar
solrに向けてxmlデータをpostすることでインデキシングができる様子。
付属のシェルスクリプトで簡単に追加ができるが中を見るとcurlでデータを送ってるだけ。
kyototycoon 他ホストにホットバックアップする
バックアップというのはこんなこともあろうかとのためにやるのでローカルより別のホストに転送しておいた方が良い。ということでrsyncd+バックアップ用のスクリプトをいじって他のホストにそのままホットバックアップしたファイルを転送する方法
バックアップファイルを置くホストにrsyncdを準備する
※debianの場合です /etc/rsyncd.confを以下のようにする
uid = root gid = root log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid [kt_backup] comment = rsync server path = /backkup/ ※ バックアップ先にしたいディレクトリ hosts allow = 192.168.0.0/16 read only = false
/etc/default/rsyncで以下のようにしておく
RSYNC_ENABLE=true
rsyndが起動するようにしておく
/etc/init.d/rsyncd start update-rc.d rsync defaults
KTが動いてるサーバのバックアップスクリプトをrsyncバージョンにする
/ktbin/dbbackupスクリプトをこんな感じにする
#!/bin/sh HOST=backup_host ※まあ適当に srcfile="$1" destfile="$1.$2" /bin/ln -s $srcfile $destfile /usr/bin/rsync -lrptgoDzL "$destfile" "${HOST}::kt_backup/" /bin/rm -f $destfile
rsyncdでリネームして保存する方法がいまいちわかんなかったからシンボリックリンク作ってその先の実態をコピーする(rsync -Lオプション)ってやったけど、鍵作ってscpの方がいい気がした。
kyototyconn ulogの削除
更新頻度が高いとulog(更新ログファイル)がどんどん肥大化してしまうのでいわゆるpurge的な事がしたいなと思うわけだけど、ktremotemgr slave -ur -ts xxxxxxxxxxxxxxxxxxxで出来るみたい。例えば1日以上前のログを削除した場合は以下のようにやればできるぽい。
time=`date -d '1 days ago' +%s`000000000; /usr/bin/ktremotemgr slave -ur -ts $time
kyototycoon レプリケーションテスト
masterの起動
ホットバックアップの時と同じでulogを出力+sid(server id)にユニークな数字をつけて起動することでレプリケーションできる。
ktserver -pid master.pid -ulog master -sid 1 master.kct &
slaveの起動
自動でレプリケーションが始まるか試したいので一旦master側にデータを入れてからslaveを立ち上げる
ktremotemgr set key1 value1 ktserver -pid slave.pid -ulog slave -sid 2 -mhost localhost -mport 1978 -rts slave.rts -port 1979 slave.kct & ※ -mhost, -mportでマスターのホスト、ポートを指定 -rtsはrplication timestamp ktremotemgr get -port 1979 key1 -> value1
スレーブでも値が取れてるので立ち上げると自動でレプリケーションが走る様子。rtsは一時的にslaveだけ止まった時用に更新位置を保持してるファイルかな。
いくつか気になる点
- ulogが複数あって最初からじゃなくて中途半端なところからある場合(古いulogを削除した状態)でslaveを立ち上げた時はどうなるか
- stop slave的な事はできるのか
- 差分(遅延)の確認はできるのか -> 公式のドキュメント見る限りktremotemgr list -pvして全部のデータを出力して確認してるぽい...
追記
差分は
ktremotemgr report -port 1979
を実行するとrepl_delayという項目がでた。データの更新をしてなくても常に値が変わってるので時間そのもののズレをあらわしてるのだろうか。同じコマンドでアイテム数もチェックできるみたいなので、軽い整合性の確認くらいには使えそう。