<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Ikeda-＞Weblog() &#187; Linux</title>
	<atom:link href="http://blog.toor.jp/category/memo/linux/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.toor.jp</link>
	<description>ikeda の徒然書き殴り Blog</description>
	<lastBuildDate>Mon, 02 Jan 2012 12:57:48 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>[TIPS] lsyncd が2.0にバージョンアップしていた</title>
		<link>http://blog.toor.jp/2011/07/31/lsyncd_version_2_with_lua/</link>
		<comments>http://blog.toor.jp/2011/07/31/lsyncd_version_2_with_lua/#comments</comments>
		<pubDate>Sun, 31 Jul 2011 05:35:53 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[ソフトウェア]]></category>
		<category><![CDATA[仕事的メモ]]></category>
		<category><![CDATA[lsyncd]]></category>
		<category><![CDATA[rsync]]></category>
		<category><![CDATA[同期]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/?p=1686</guid>
		<description><![CDATA[以前、『lsyncdとrsyncdでミラーリング』という記事を書きましたが、あれ以来lsyncdにはかなりお世話になっています。 で、RHETOLOサーバでもバックアップと負荷分散のために導入しようとしたところ、lsyncdのバージョンが上がっていました(遅) 現時点(2011/7/31)での最新バージョンは 2.0.4 で、こちらからダウンロードできます。 inotifyを利用してファイルの変更を検知し、rsyncdを起動する、、という本来の機能には変わりありませんが、最も大きな変更点としては設定ファイルのフォーマットが今までのXMLからLuaになったという点ですね。 ということで、早速使ってみました。 インストールっ &#160; インストールやrsyncd関連についてはほぼ今までと同様でOKですので、詳細は以前の記事をご覧頂きたい(手抜き)のですが、バージョン2.xからビルドにはLuaライブラリが必要となりますので、先にインストールしておきましょう。 現在の最新版は5.1.4で、公式サイトからtarballがダウンロードできますし、EPELリポジトリにRPMパッケージもあるようですね。 Lua 公式サイト &#8211; Download Fedora Project EPEL Project 今回はtarballからインストールしましたが、make &#38; make install でOKでした。 &#160; make 時にプラットフォーム指定が必要ですが、「make」とだけ叩くとリストが表示されます。 &#160; Lua がインストールできたらlsyncdをさくっとビルド＆インストールしましょう。Luaのヘッダの場所とライブラリを環境変数で指定しておくとハッピーになれるかもしれません。あと、CentOS5.5でビルドするには libm と libdl を追加指定する必要があるようです。 ※luaのインストール先に合わせてパスを変更してください &#160; これでインストールは完了です。あ、rsyncのインストールも忘れずに。 設定っ &#160; さて、では設定してみましょう。前回の記事にならって ファイル配布元サーバ &#8211; srchost : 192.168.254.1 ファイル配布先サーバ &#8211; dsthost : 192.168.254.2 ファイル格納場所はいずれも /home/www/htdocs ディレクトリ という前提にしておきますね。ファイルの配布先(＝受け取る方)サーバのrsyncとかsshの設定は前回の記事を御覧ください(手抜き)。 lsyncdの起動方法については今まで通りコマンドラインで指定する方法と設定ファイルを使用する方法があります。 [...]]]></description>
		<wfw:commentRss>http://blog.toor.jp/2011/07/31/lsyncd_version_2_with_lua/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[メモ] lsyncd が同期してくれなくなった時は・・</title>
		<link>http://blog.toor.jp/2011/07/22/lsyncd_not_sync/</link>
		<comments>http://blog.toor.jp/2011/07/22/lsyncd_not_sync/#comments</comments>
		<pubDate>Fri, 22 Jul 2011 09:00:52 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[ソフトウェア]]></category>
		<category><![CDATA[仕事的メモ]]></category>
		<category><![CDATA[inotify]]></category>
		<category><![CDATA[lsyncd]]></category>
		<category><![CDATA[同期]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/?p=1635</guid>
		<description><![CDATA[お久しぶりですー、毎度毎度超不定期更新ですいません＾＾； &#160; 「RHETOLO」の関連サービス「れとろ握り」や「レトロバッヂジェネレータ」、「あぷり握り」をガリガリ作りつつ、基幹システムの調整やら不具合対応やら新機能の構想やらで相変わらずバタバタしておりますが、このあたりのご紹介はまた後日、ということにしておいて。 &#160; 以前、「lsyncd＋rsyncでミラーリング」なる記事を書きましたが、あれからlsyncdには本当に色々なところで活躍してもらっています。今回のRHETOLOサーバでも使っているんですが、最近ディレクトリ同期が取れなくなる、という現象に悩まされていました。 ログを見ても特にエラーらしきものはなく、むしろ逆に「ファイルの変更が検知できていない」という感じ。 カーネルバージョンなどを疑っていましたが、どうやら原因は別のところにあったようです。。。 ずばり、原因は「ユーザマイページシステムを実装したこと」でした。 &#160; 。。。っていうとマイページシステムが悪いように聞こえますね＾＾； &#160; 同期できない不具合の引き金を引いたのはマイページシステムでした。 &#160; いや違うな &#160; 悪いのはマイページでした(￣▽￣) &#160; &#160; ・・・いい加減にマイページ開発者から首を締められそうなのでやめときますが、ともかく、マイページシステムを実装したあたりから同期がとれなくなっていたようです。 &#160; lsyncdがディレクトリ内の変更を検知するために使う「inotify」には、「1ユーザが監視できる最大ディレクトリ数」というものがあり、デフォルトで8192に設定されています。そして、マイページシステムでは、レトロコードに紐付くアイコンや画像をアップロード・加工するため、大量のディレクトリを切っていたんです。 &#160; そう、この「大量のディレクトリ」を見張ろうとしたために、監視するディレクトリ数がMAXを超えてしまっていたのです。 &#160; ということで、原因がわかったら早速対処対処。 &#160; この「監視できる最大ディレクトリ数」はカーネルパラメータ fs.inotify.max_user_watches で設定されています。 なので、これを変更すれば万事OK！ですな！ とりあえず、、キリのいいとこで # sysctl fs.inotify.max_user_watches = 32768 に設定しておきました。 マシン再起動時にも再設定されるよう、/etc/sysctl.conf にも fs.inotify.max_user_watches = 32768 を追記しておくと後々ハッピーかと。 ちなみにsysctlコマンドを使わず、procファイルを更新する方法もあります。 # echo 32768 &#62; /proc/sys/fs/inotify/max_user_watches 念のため lsyncd を再起動し、動作確認しておきましょう(^_^)b &#160; ということで、今回はこの辺で。 あー、そうだlsyncdのバージョンが上がってて設定ファイル形式も変わってるんだこの辺も記事にしなきゃしなきゃしなきゃ・・・・]]></description>
		<wfw:commentRss>http://blog.toor.jp/2011/07/22/lsyncd_not_sync/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[メモ] lsyncd+rsync でミラーリング</title>
		<link>http://blog.toor.jp/2009/10/02/sync_directory_with_lsyncd/</link>
		<comments>http://blog.toor.jp/2009/10/02/sync_directory_with_lsyncd/#comments</comments>
		<pubDate>Fri, 02 Oct 2009 07:20:24 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[ソフトウェア]]></category>
		<category><![CDATA[仕事的メモ]]></category>
		<category><![CDATA[lsyncd]]></category>
		<category><![CDATA[rsync]]></category>
		<category><![CDATA[同期]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/?p=1343</guid>
		<description><![CDATA[仕事先でサーバリプレイスを行うことになり、まずは最も単純構成である動画ストリーミングサーバから手をつけることにしました。 現状、サーバは各々2台ずつの冗長構成になっており、従って動画ファイルもそれぞれに配布する必要があります。以前から面倒だなーとは思っていたんですが、このリプレイスのタイミングで動画ファイルの格納ディレクトリを同期させてやることに^^)b 最初に思いついたのはDRBD+heartbeat。しかし、YouTubeのような動画アップロードサイトではありませんし、そこまで頻繁に動画ファイルの更新があるわけではありません。リアルタイム性もそこまで必要というわけではないし。。 そもそもDRBDはアクティブ－スタンバイ式なので、両サーバから同時に読み出しを行うにはさらにNFSかiSCSI+CLVMを組み合わせるしかなさそうです(間違い・勘違いでしたらご指摘下さいm(_ _)m） で、ググっていたら lsyncd なるソフトウェアを発見。 lsyncdをつかって簡単にファイル同期を &#8211; Unix的なアレ うわ、これいいかも！ ということで、早速仮想環境にて試してみましたのでメモ。 まずは環境設定 では配布元と配布先のサーバそれぞれに設定を行っていきます。 便宜上、実際に動画ファイルの原本(?)を保持する側＝配布元を「プライマリ」、配布を受ける側を「セカンダリ」としますね。 仮想環境の設定はこんな感じ。 プライマリサーバ &#8211; hostA： 192.168.254.1 セカンダリサーバ &#8211; hostB: 192.168.254.2 動画ファイルの格納場所はいずれも  /home/streams ディレクトリ ファイルのオーナー・グループは  stream/stream インストーーーールッ プライマリサーバ側 さて、このサーバに社内の各部署から動画ファイルがアップロードされることになります。また、公開終了となった動画ファイルは削除されます。ということで、こちら側に lsyncd をインストールします。 下記からTarballをダウンロード。 lsyncd: リソース &#8211; SourceForge.JP $ tar xvfz lsyncd-1.25.tar.gz $ cd lsyncd-1.25 $ ./configure $ make &#38;&#38; sudo make install [...]]]></description>
		<wfw:commentRss>http://blog.toor.jp/2009/10/02/sync_directory_with_lsyncd/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[メモ] USBメモリをブートメディアにしてCentOSをインストールしてみる</title>
		<link>http://blog.toor.jp/2009/10/02/install_centos_from_usbmemory/</link>
		<comments>http://blog.toor.jp/2009/10/02/install_centos_from_usbmemory/#comments</comments>
		<pubDate>Fri, 02 Oct 2009 05:49:19 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[TIPS]]></category>
		<category><![CDATA[仕事的メモ]]></category>
		<category><![CDATA[CentOS]]></category>
		<category><![CDATA[USBメモリ]]></category>
		<category><![CDATA[メモ]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/?p=1342</guid>
		<description><![CDATA[会社で古いPCにCentOSを入れることにしました。ちょうどインストールDVDを作ってたので、さくっと起動。 あれ・・・・・・・・・・・・・・・・・・・・読みませんよ？ って、このマシンCD-ROMドライブじゃん！！！ 気を取り直して。今からCD焼き直していると時間が勿体無い。自分のPCにCD-Rが無い。 ということで、USBメモリをインストールメディアにしてみたので簡単にメモ。 用意したのはその辺に転がっていた128MのUSBメモリ。あとは適当なマシンと、インストールＤＶＤ。 まずはインストールDVDから起動イメージをWindowsへ引っこ抜いておきます。 &#60;&#60;MEDIA-ROOT&#62;&#62;/images/diskboot.img が起動イメージですね。 続いて、インストールDVDを別マシンに突っ込みます。 このマシンではFTPデーモンを起動しておき、なおかつanonymousアクセスを許可しておきました。手元のマシンでは /var/ftp が anonymous アクセスのrootとなります。この下に cent5 としてディレクトリを切り、ここにインストールメディアをマウントしておきます。 インストール先としてCentOSのミラーサーバ等を使う場合、この辺の作業は不要です。 さて、ではWindowsに戻り、USBメモリをぶち込みます。この段階では単にWindowsのリムーバブルディスクでしかありません。ここにイメージを書き込むわけですが、今回はさくっと「DDforWindows」というツールを使いました。 DDforWindows &#8211; Silicon Linux 2009/09/30時点での最新バージョンはこちら(Ver0994)。 圧縮ファイルを解凍し、おもむろにDDWin.exeを起動。こんな感じの画面になります。 (Ver0994ではmd5サムも算出されるようになりました) あとは「ディスク選択」でUSBメモリのドライブを、「ファイル選択」で先程のdiskboot.imgを選択。 ↓ 軽く息を整えて「南無」と心でつぶやいた後、「書込」ボタンを押します。 ↓ 確認ダイアログが表示され、さらに「南無」ポチ。で書き込みが開始されます。 ↓ 終了後、念のため「照合」しておくと精神衛生上いいかもしれません。 ともかく、これでUSBのブートメディアが完成しました＾＾ 対象マシンにぶち込み、BIOS設定からUSBブートできるようにしておきます。 あとは基本的に通常のインストールと同じです。インストールメディアをFTPで先程セットアップしたマシンにするくらい、でしょうか。 あ、でもUSBメディアがルートデバイスとして認識されているので、インストール最中に何度か「フォーマットする？無視する？」と聞かれます。さくっと無視させておきましょう。 追記: この方法だとGRUBブートローダがHDDに書き込まれない場合がありました。 その場合、インストールに使ったUSBメモリから「レスキューモード」でインストーラを起動し、 boot: linux rescue その後のプロンプトで sh-3.2# chroot /mnt/sysimage/ sh-3.2# grub-install /dev/hda とかやるとハッピーになれるかもしれません(^_^)b]]></description>
		<wfw:commentRss>http://blog.toor.jp/2009/10/02/install_centos_from_usbmemory/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Acer Aspire One D250 に Ubuntu9.04 入れました。</title>
		<link>http://blog.toor.jp/2009/05/19/ubuntu_904_on_aspire_one_d250/</link>
		<comments>http://blog.toor.jp/2009/05/19/ubuntu_904_on_aspire_one_d250/#comments</comments>
		<pubDate>Tue, 19 May 2009 09:22:50 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[戯言]]></category>
		<category><![CDATA[Aspire One]]></category>
		<category><![CDATA[D250]]></category>
		<category><![CDATA[Ubuntu]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/2009/05/19/20090519_182250/</guid>
		<description><![CDATA[で、インストールされていた「ブログ投稿ツール」からの投稿テスト。 どんなもんかなーっと。 追記 ポストに結構時間がかかる ステータス(公開・下書き)の指定ができない。いきなり公開状態。 タグが使えないっぽい？ カテゴリ指定も出来ないっぽい？ てことで、Firefox+ScribeFireの方がいいかも。重いかもだけど。]]></description>
		<wfw:commentRss>http://blog.toor.jp/2009/05/19/ubuntu_904_on_aspire_one_d250/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
		<item>
		<title>[メモ] channel-bonding～縛って縛って縛り倒せ</title>
		<link>http://blog.toor.jp/2009/03/23/memo_channel-bonding/</link>
		<comments>http://blog.toor.jp/2009/03/23/memo_channel-bonding/#comments</comments>
		<pubDate>Mon, 23 Mar 2009 03:35:08 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[仕事的メモ]]></category>
		<category><![CDATA[bonding]]></category>
		<category><![CDATA[メモ]]></category>
		<category><![CDATA[冗長化]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/?p=1165</guid>
		<description><![CDATA[先日からずっとL2 SW冗長化に関して調べていたんですが、ネットワークの偉い人から 「それって接続する機器も冗長化されてないと意味なくね？」 というツッコミを頂きまして。 考えてみりゃそりゃそうだわな(　-人-) ということで、SWに接続する機器そのもの・・というより、機器とSWを接続する回線の冗長化と併せて行うことにしました。 で、ふと思い出したのが「bonding」という機能。これは「複数の回線を１つの仮想回線にまとめる」というものなんです。なんと好都合。 ということで、早速テスト環境にて試してみましたのでメモメモ。 VMWare上のFedora 9に設定を行いますが、これらにはもともと eth0: 192.168.254.101 (サービス用) eth1: 192.168.250.11  (Heartbeat／DBレプリケーション用) と、２つのNICを設定していました。ここにもう1枚NICをeth2として追加します。 ちょっとeth番号が飛んでしまいますが、既存の設定をできるだけ変えたくなかったのでこのまんま。 NIC設定を変更する ということで、eth0 と eth2 のNIC設定ファイルを変更していきます。 こんな感じ。 /etc/sysconfig/network-scripts/ifcfg-eth[0&#124;2] DEVICE=eth0  # ここは設定するNICに合わせる BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no んでもって、ボンディングした結果(?)の仮想NICについても設定ファイルを記述します。 /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 BOOTPROTO=none ONBOOT=yes IPADDR=192.168.254.101 NETMASK=255.255.255.0 BROADCAST=192.168.254.255 USERCTL=no 今までeth0に割り当てていたIPアドレスをbond0に指定し、eth0とeth2にはIPアドレス等を設定せず、「キミは bond0 というMASTERに従属(SLAVE)するのだ！」と指定するわけですね。 さて、設定ファイルはこんな感じでOKなんですが、bondingを実現するにはカーネルにモジュールを突っ込む必要があります。毎回、手でinsmodするのもなんなので、/etc/modprobe.d/bonding というファイルを作ってしまいましょう。 とりあえずbondインタフェースは１つだけなので alias bond0 bonding options bonding mode=2 miimon=100 [...]]]></description>
		<wfw:commentRss>http://blog.toor.jp/2009/03/23/memo_channel-bonding/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[メモ] PostgreSQL 7.4でpgpool-IIのリカバリ機能を使う～設定編</title>
		<link>http://blog.toor.jp/2009/03/17/pgpool_recovery_on_pgsql74/</link>
		<comments>http://blog.toor.jp/2009/03/17/pgpool_recovery_on_pgsql74/#comments</comments>
		<pubDate>Tue, 17 Mar 2009 08:42:13 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[TIPS]]></category>
		<category><![CDATA[ソフトウェア]]></category>
		<category><![CDATA[仕事的メモ]]></category>
		<category><![CDATA[DBクラスタ]]></category>
		<category><![CDATA[pgpool-II]]></category>
		<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[リカバリ]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/?p=1092</guid>
		<description><![CDATA[ほんっとにメモです＾＾； pgpool-II 公式ページのドキュメントによると、行うべきことは pgpoolの設定 C言語関数のインストール リカバリスクリプトの配置   の3点。   pgpoolの設定   pgpool.confの以下の値を設定します。 backend_data_directory バックエンドのデータディレクトリ($PGDATA)。 recovery_user リカバリに使用するユーザID。 recovery_password ログインパスワード。 recovery_1st_stage_command recovery_2nd_stage_command pgpoolでは2つのステージに分けてオンラインリカバリが行われます。ここにそれぞれのステージで実行すべきコマンドを指定します。   C言語関数のインストール   リカバリを実施するためのC言語関数を全ノードの template1 データベースにインストール。関数のソースコードはpgpool-IIに付属されています。 んがしかし。 Makefile で &#8220;pg_config ––pgxs&#8221; が実行されるのですが、7.4.xに付属するpg_configコマンドには「––pgxs」オプションがありませんのでエラーになってしまいます。   しかしご安心を。pgpool-generalメーリングリストのアーカイブに対処法がありました！＾＾   PostgreSQLのソースコードを展開し、configure &#38; make まで済ませておきます。 pgpool に付属の pgpool-recovery を、ディレクトリごと PostgreSQLソースの contrib 下にコピー。 cp -r pgpool-recovery ../../postgresql-7.4.xx/contrib  contrib配下にコピーしたpgpool-recoveryにあるMakefileを下記の内容に修正します。 subdir = contrib/pgpool-recovery [...]]]></description>
		<wfw:commentRss>http://blog.toor.jp/2009/03/17/pgpool_recovery_on_pgsql74/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>[メモ] FlareをRHEL3にインストールしてみた</title>
		<link>http://blog.toor.jp/2009/01/22/flare_on_rhel3/</link>
		<comments>http://blog.toor.jp/2009/01/22/flare_on_rhel3/#comments</comments>
		<pubDate>Thu, 22 Jan 2009 04:23:35 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[仕事的メモ]]></category>
		<category><![CDATA[boost]]></category>
		<category><![CDATA[flare]]></category>
		<category><![CDATA[RHEL3]]></category>
		<category><![CDATA[メモ]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/?p=964</guid>
		<description><![CDATA[ホントに単なる備忘録です＾＾； インストールしたいもの flare 1.0.5 必要なもの boost libevent 対象マシン Red Hat Enterprise Linux 3 / 2.4.x kernel   ってことで作業開始。 それぞれ必要なtarballをサイトから落としてきます。libeventはRPMforgeにあったので、yumでインストール。 続いてBoostのインストール。 手順としては毎度おなじみ configure &#38; make &#38; make install でOKなはず。 install 前に make check しておくといいとは思いますが、テストで生成されたファイル類が物凄くディスク容量を食うので注意(お陰で夜中にALERT来ちゃったよ・・・)。   さて、いよいよ本命のflareをインストール。手順は同じく configure ＆ make install で一発。   ・・・・・なはずが、「Boostのﾎﾆｬﾗﾗってファイルが見つからない」と configure に怒られてしまいます。   これは、boost を tarball からビルドしインストールした場合、ライブラリファイルに gcc32 等の種別が付加されてしまうため。flare 側は種別ナシのファイル名で探しに行きますから、そりゃ見つからないのは当然ですね。 とりあえずシンボリックリンクを使って、種別のついていないファイル名も作成しておきます。   あと、ヘッダファイル類が /usr/local/boost/boost/ [...]]]></description>
		<wfw:commentRss>http://blog.toor.jp/2009/01/22/flare_on_rhel3/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>[メモ] PostgreSQL+pgpool-II+heartbeat でクラスタリング／プログラム対応編</title>
		<link>http://blog.toor.jp/2009/01/08/postgres_clustering_part3/</link>
		<comments>http://blog.toor.jp/2009/01/08/postgres_clustering_part3/#comments</comments>
		<pubDate>Thu, 08 Jan 2009 06:55:25 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[ソフトウェア]]></category>
		<category><![CDATA[仕事的メモ]]></category>
		<category><![CDATA[DBクラスタ]]></category>
		<category><![CDATA[HashDB]]></category>
		<category><![CDATA[heartbeat]]></category>
		<category><![CDATA[pgpool-II]]></category>
		<category><![CDATA[PostgreSQL]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/?p=937</guid>
		<description><![CDATA[中編から数ヶ月が経過してしまいました^^; 今までなにをやっていたかと言うと、「既存プログラムの改修」作業です。 まだ完全には終了していませんが、覚書として「プログラム対応編」をお送りします。 もともと書かれていたコードがタコだったり用途が限定されたりしてあまり参考にはならないかもしれませんが・・・。   さて、なぜ既存プログラムの改修が必要か、ということなんですが、最大の原因は   LOB(ラージオブジェクト)を使用しているサブシステムがある   これに尽きます。 LOBについての詳細は他に詳しく解説されているページがあるはずです(他力本願)ので割愛しますが、レプリケーションミドルウェアとして選定したpgpool-IIの制限事項として、 乱数やトランザクションID，OID，SERIAL， シーケンス，CURRENT_TIMETSTAMPのようなものに関してはレプリケーショ ンはしますが，2台のホストでまったく同じ値がコピーされる保証はありません とあり、LOBはもともと扱いが特殊な上OIDを直接使用する形になりますので、pgpool-IIを経由して使うことはできません。 というか pg_lo_* 関数を実行した時点でpgpool-IIから怒られます^^;   ということで、まずはLOBを使用しないようシステムを改修する必要があります。 他にもOIDやシーケンスなど、制限事項に触れそうな機能を利用しているプログラムを洗い出し、必要に応じて修正していく必要があります。 チェックすべき点として以下の４つを想定しました。   既存のデータベースアクセスライブラリを使用せず、直接pg_*関数を利用してアクセスしているか 発行しているクエリに危険そうなもの(シーケンスやnow()等)は利用しているか LOBを使用しているか OIDを利用しているか   ざっとプログラムファイルを洗い出してみました。その数、約1500。気が遠くなりますね&#60;丶´Д｀&#62;げっそり 全てのファイルをチェックするだけで1ヵ月半以上かかってしまいました。この作業だけに専念できるわけではなく、随時他の作業や障害対応などの割り込みが発生しますから、仕方ないっちゃー仕方ないかもしれませんが。。。ちょっと引っ張りすぎちゃったかな。   結論として、 LOBを利用しているシステムは他の格納手段に変更する。 now()等日付・タイムスタンプ関連はこの際ほっとく。後々はライブラリで置換処理を行う等、対応を取るかも。しかし、ちょっとしたタイムスタンプの違いでpgpool-IIに異常発生と判断されても困るので、pgpool-IIのオプション&#8221;replication_stop_on_mismatch&#8221;はFALSEで運用することとします。 直接アクセスについても今回は危険なクエリが見つからなかったため後回し。   ということになりました。 最大の難関「LOB」ですが、今回対象となったサブシステムでは画像データの格納に使用されていました。もともと自分で書く時はLOBを使わず   データそのものはファイルに ファイルパス(URL)などの情報を保持するインデクステーブルをＤＢに   というスタンスだったのですが、、、このシステムは外部委託して開発したものでした(T-T*) 愚痴っていても仕方ないので他の方法を考えます。さくっと思いついたのはこの３つ。 今までの方法(データはファイル、インデクスをDB) 画像データをエンコードしDBに突っ込む HashDB等、全く別のDBシステムを使う まず(1)ですが、方法としては今まで行ってきたことなので、仕組みそのものは枯れています。が、対象システムのコードを調査した結果、かなりの修正量になってしまう恐れが出てきました。 となると(2)か(3)・・ということになります。   そんな中、「Web屋のネタ帳」さんで見つけたこんなエントリ。 画像もDBに格納して管理する －扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含め   決まった。(2)で行きましょう。ライブラリを作る手間はかかりますが、一度作ってしまえば他システムでも応用できますしね。 [...]]]></description>
		<wfw:commentRss>http://blog.toor.jp/2009/01/08/postgres_clustering_part3/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Webサーバ・ダウン</title>
		<link>http://blog.toor.jp/2009/01/05/webserver_down/</link>
		<comments>http://blog.toor.jp/2009/01/05/webserver_down/#comments</comments>
		<pubDate>Mon, 05 Jan 2009 06:49:30 +0000</pubDate>
		<dc:creator>ikeda</dc:creator>
				<category><![CDATA[Linux]]></category>
		<category><![CDATA[仕事的メモ]]></category>
		<category><![CDATA[Apache]]></category>
		<category><![CDATA[障害]]></category>

		<guid isPermaLink="false">http://blog.toor.jp/?p=931</guid>
		<description><![CDATA[と言ってもTOOR.JPではなく。 昨年末の12/29、納会でちょっと酒も入り気分よく帰宅している道中、上司より着信。 「サイトにアクセスできないらしい。」 はい、一気に酒が抜けました＾＾； オフィスへ戻るより自宅へ帰ったほうが速い、と判断し急いで帰宅。 調べてみると確かにWebサーバが2台ともハングアップ状態で、pingは戻ってくるもののHTTPやSSHその他諸々のサービスは完全に無反応。ポートは開いておりパケットは受け付けるものの応答なし、ってのが厄介。どうせならポートまで完全に閉じてくれればタイムアウトまで待たなくてもいいのにﾌﾞﾂﾌﾞﾂとか言いつつ、あれやこれやの方法を裏側から試してみる・・・・・・も、完全にダウンしているらしい。   仕方ないので社内の別チームに電源再投入を依頼。これでダメなら(酒が抜けるのを待って)データセンターへ行くしかないなーと思いつつ、祈るような気持ちで待つこと数分。 その後様子を見ていると、またもや2号機のロードアベレージが急上昇。なんと15を越えています！トラフィックが片肺に流入したせいか、またほかの原因があるのか、続いて1号機の負荷も急上昇！ きゃーーー、やばいやばいやばい サービス全体のダウンを防ぐことが最優先、と判断し、急遽2号機のHTTP接続を絞ることにしました。タイムアウトも短くし、MAXのコネクション数を絞ります。 そして問答無用でプロセス再起動。 徐々に、徐々にではありますがロードアベレージが低下し始めてくれました。 この日はこのまま様子を見ることにしました。 年が明けて今日、1月5日。仕事始めと同時に、年末のサーバダウンについて調査を開始しました。 まずは定番のログ分析。 ・・・・・・・・・・・・・・なーーーんも残ってねーし。 いや正確には、ログは残っていてもなぜハングアップしたか、という原因に関するログが一切無いのです。ハングアップするほんの数分前までは正常に動作しているらしい、ということはわかりましたが、実際に何が引き金となって過負荷に陥ったのかさっぱりわかりません。 かなり急激な負荷の上昇により、一気にプロセスが回らなくなってしまったようです。 っと、ひとつ気になるログを発見しました。 最初にハングアップした2号機のdmesgによると、 Out of Memory: Killed process 870 (httpd).&#60;br /&#62;Out of Memory: Killed process 888 (httpd).&#60;br /&#62;Out of Memory: Killed process 884 (httpd).&#60;br /&#62;TCP: Treason uncloaked! Peer ***.***.***.***:39660/80 shrinks window 3584164780:358&#60;br /&#62;4164970. Repaired.&#60;br /&#62;Out of Memory: [...]]]></description>
		<wfw:commentRss>http://blog.toor.jp/2009/01/05/webserver_down/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

