Blog
前のページ
|
次のページ
2007/05/21のBlog
[ 17:05 ]
[ Forest関連情報 ]
こちらのblogでは告知していませんでした。
PostgresForest Suiteのハンズオンセミナ(5月分)を開催いたします。
午後スタートの数時間の短いセミナとなっていますが、PostgresForest、Ludiaを直接いじって、基本的な使い方を習得していただけるチャンスですので、興味をお持ちの方はぜひご参加ください。
詳細はこちらをご覧ください。
「第3回 PostgresForest Suite ハンズオンセミナ 初級」開催のお知らせ
http://sourceforge.jp/forum/forum.php?forum_id=11826
ではまた。
(な)
PostgresForest Suiteのハンズオンセミナ(5月分)を開催いたします。
午後スタートの数時間の短いセミナとなっていますが、PostgresForest、Ludiaを直接いじって、基本的な使い方を習得していただけるチャンスですので、興味をお持ちの方はぜひご参加ください。
詳細はこちらをご覧ください。
「第3回 PostgresForest Suite ハンズオンセミナ 初級」開催のお知らせ
http://sourceforge.jp/forum/forum.php?forum_id=11826
ではまた。
(な)
2007/05/14のBlog
[ 19:26 ]
[ Forest開発状況 ]
当初の予定よりだいぶ遅くなりましたが、
いろいろfixした4.0.2をリリースしました。
http://sourceforge.jp/projects/postgresforest
変更点としては以下のようになります。
- 仮想化モジュールのexecuteBatch()メソッドの不具合を修正。
- 環境構築ツールのエラーチェックを強化。
- CREATE/ALTER/DROP TABLE/INDEX/VIEWコマンド時の不具合を修正。
- CREATE DB コマンドの FORCE オプションの処理を実装。
- GSCの整合性チェックの際に、更新時刻を比較対象から除外。
- 「開発者ガイド」を追加。
- 「管理者ガイド」を拡充。
- examplesのTableDiff.javaの不具合を修正。
- Red Hat Enterprise Linux 4/PostgreSQL 8.1.6に対応した
ロックタイムアウトパッチを追加。
- インストールスクリプトをSolarisに対応。
よろしければ、お試しくださいませ。
(な)
いろいろfixした4.0.2をリリースしました。
http://sourceforge.jp/projects/postgresforest
変更点としては以下のようになります。
- 仮想化モジュールのexecuteBatch()メソッドの不具合を修正。
- 環境構築ツールのエラーチェックを強化。
- CREATE/ALTER/DROP TABLE/INDEX/VIEWコマンド時の不具合を修正。
- CREATE DB コマンドの FORCE オプションの処理を実装。
- GSCの整合性チェックの際に、更新時刻を比較対象から除外。
- 「開発者ガイド」を追加。
- 「管理者ガイド」を拡充。
- examplesのTableDiff.javaの不具合を修正。
- Red Hat Enterprise Linux 4/PostgreSQL 8.1.6に対応した
ロックタイムアウトパッチを追加。
- インストールスクリプトをSolarisに対応。
よろしければ、お試しくださいませ。
(な)
2007/04/05のBlog
[ 17:30 ]
[ Forest関連情報 ]
ひさびさに技術ネタを書いてみます。
PostgresForestを冗長化目的で使用している際、複数のサーバが切り離された後に「どのサーバがどの順番で切り離されたのか」を確認したい場合があります。
例えば、4台構成(サーバ0,1,2,3)で動作させている場合に、「0→2→1→3」の順番で障害が起こったとします。
最後まで生きていたサーバは「サーバ3」ですから、これをベースとして復旧作業を行うわけですが、そもそも「最後まで生きていたサーバは、サーバ3だった」ということをどうやって調べればいいのでしょう?
GSCを冗長化していると、各ノードにGSCが保持されていますが、切り離されたサーバのGSCには障害ログ(brokenlog)が記録されませんので、どのGSCが最後まで生きていたのか、をきちんと切り分けてやらなければなりま
せん。
まぁ、一台ずつbrokenlogを見ていけば理屈としては分かるわけですが、ふと以下のような方法を思いつきました。
まず、以下のようなSQLを投げます。
gsc=#
gsc=# SELECT distinct on (b.serverid) datetime,b.serverid,url,b.status,msg
gsc-# FROM forest_brokenlog b, forest_server s
gsc-# WHERE s.serverid=b.serverid
gsc-# ORDER BY b.serverid,datetime;
datetime | serverid | url | status | msg
---------------------+----------+------------------------+--------+----------------------------------------------------
2007-04-05 15:20:51 | 0 | //172.19.188.33:15432/ | 08006 | An I/O error occured while sending to the backend.
2007-04-05 15:22:10 | 2 | //172.19.188.33:15434/ | 08006 | An I/O error occured while sending to the backend.
2007-04-05 15:22:56 | 3 | //172.19.188.33:15435/ | 08006 | An I/O error occured while sending to the backend.
(3 rows)
gsc=# SELECT count(*) FROM forest_brokenlog ;
count
-------
47
(1 row)
gsc=#
そうすると、brokenlogの中で、切り離された各DBノードについて「先頭のログのみ」が表示されます。
ここでは、「15:20:51にサーバ0が切り離し」、「15:22:10にサーバ2が切り離し」、「15:22:56にサーバ3が切り離し」となっていることが分かります。
ただし、ここで取得したbrokenlogは、接続しているGSCのものですから、それ以外の(冗長化されている)GSCの情報も併せて見なければなりません。つまり、上記の方法で取得したbrokenlogを、全サーバのGSCから集めてマージして、日付順にソートすればすべての切り離しイベントの時系列を把握することができます。
ということで、作ってみたのが以下のスクリプト。4台のインスタンスを使ってます。
$ cat check_brokenlog.sh
#!/bin/sh
PATH=/usr/local/pgsql816/bin:$PATH
export PATH
for p in {15432,15433,15434,15435};
do psql -F, -A -t -p ${p} gsc <<eof the s forest_brokenlog このスクリプトを実行することによって、障害(切り離し)が「0→2→1→3」の順番で発生していることが分かり、よってリカバリは「サーバ3」を元に復旧すればいいことが分かります。 sh uniq forest_server b.serverid,datetime where datetime,b.serverid,url,b.status,msg sort 15:22:56,1,//172.19.188.33:15433/,08006,an i/o on select 15:22:45,1,//172.19.188.33:15433/,08006,an eof by distinct s.serverid="b.serverid" check_brokenlog.sh 実行結果は以下のようになりました。 occured $ error done; from 15:22:10,2,//172.19.188.33:15434/,08006,an | (な) 2007-04-05 sending to while order 15:20:51,0,//172.19.188.33:15432/,08006,an 15:22:56,3,//172.19.188.33:15435/,08006,an (b.serverid) backend. b,>
PostgresForestを冗長化目的で使用している際、複数のサーバが切り離された後に「どのサーバがどの順番で切り離されたのか」を確認したい場合があります。
例えば、4台構成(サーバ0,1,2,3)で動作させている場合に、「0→2→1→3」の順番で障害が起こったとします。
最後まで生きていたサーバは「サーバ3」ですから、これをベースとして復旧作業を行うわけですが、そもそも「最後まで生きていたサーバは、サーバ3だった」ということをどうやって調べればいいのでしょう?
GSCを冗長化していると、各ノードにGSCが保持されていますが、切り離されたサーバのGSCには障害ログ(brokenlog)が記録されませんので、どのGSCが最後まで生きていたのか、をきちんと切り分けてやらなければなりま
せん。
まぁ、一台ずつbrokenlogを見ていけば理屈としては分かるわけですが、ふと以下のような方法を思いつきました。
まず、以下のようなSQLを投げます。
gsc=#
gsc=# SELECT distinct on (b.serverid) datetime,b.serverid,url,b.status,msg
gsc-# FROM forest_brokenlog b, forest_server s
gsc-# WHERE s.serverid=b.serverid
gsc-# ORDER BY b.serverid,datetime;
datetime | serverid | url | status | msg
---------------------+----------+------------------------+--------+----------------------------------------------------
2007-04-05 15:20:51 | 0 | //172.19.188.33:15432/ | 08006 | An I/O error occured while sending to the backend.
2007-04-05 15:22:10 | 2 | //172.19.188.33:15434/ | 08006 | An I/O error occured while sending to the backend.
2007-04-05 15:22:56 | 3 | //172.19.188.33:15435/ | 08006 | An I/O error occured while sending to the backend.
(3 rows)
gsc=# SELECT count(*) FROM forest_brokenlog ;
count
-------
47
(1 row)
gsc=#
そうすると、brokenlogの中で、切り離された各DBノードについて「先頭のログのみ」が表示されます。
ここでは、「15:20:51にサーバ0が切り離し」、「15:22:10にサーバ2が切り離し」、「15:22:56にサーバ3が切り離し」となっていることが分かります。
ただし、ここで取得したbrokenlogは、接続しているGSCのものですから、それ以外の(冗長化されている)GSCの情報も併せて見なければなりません。つまり、上記の方法で取得したbrokenlogを、全サーバのGSCから集めてマージして、日付順にソートすればすべての切り離しイベントの時系列を把握することができます。
ということで、作ってみたのが以下のスクリプト。4台のインスタンスを使ってます。
$ cat check_brokenlog.sh
#!/bin/sh
PATH=/usr/local/pgsql816/bin:$PATH
export PATH
for p in {15432,15433,15434,15435};
do psql -F, -A -t -p ${p} gsc <<eof the s forest_brokenlog このスクリプトを実行することによって、障害(切り離し)が「0→2→1→3」の順番で発生していることが分かり、よってリカバリは「サーバ3」を元に復旧すればいいことが分かります。 sh uniq forest_server b.serverid,datetime where datetime,b.serverid,url,b.status,msg sort 15:22:56,1,//172.19.188.33:15433/,08006,an i/o on select 15:22:45,1,//172.19.188.33:15433/,08006,an eof by distinct s.serverid="b.serverid" check_brokenlog.sh 実行結果は以下のようになりました。 occured $ error done; from 15:22:10,2,//172.19.188.33:15434/,08006,an | (な) 2007-04-05 sending to while order 15:20:51,0,//172.19.188.33:15432/,08006,an 15:22:56,3,//172.19.188.33:15435/,08006,an (b.serverid) backend. b,>
2007/02/16のBlog
[ 17:12 ]
[ Forest関連情報 ]
このたび、「PostgresForest Suite」のハンズオンセミナを開催することとなりました。
「PostgresForest Suite」とは、PostgresForestを中心として、PostgreSQLの機能や性能を強化するためのソフトウェアで、PostgreSQLそのものを強化するものになります。
開催時期は3月中旬と少し先の話になってしまうのですが、費用は無料となっていますので、興味のある方は以下のページのアナウンスをご覧いただき、ぜひご参加くださいませ~。
PostgresForest Suite ハンズオンセミナ開催のお知らせ
よろしくお願いします。
(な)
「PostgresForest Suite」とは、PostgresForestを中心として、PostgreSQLの機能や性能を強化するためのソフトウェアで、PostgreSQLそのものを強化するものになります。
開催時期は3月中旬と少し先の話になってしまうのですが、費用は無料となっていますので、興味のある方は以下のページのアナウンスをご覧いただき、ぜひご参加くださいませ~。
PostgresForest Suite ハンズオンセミナ開催のお知らせ
よろしくお願いします。
(な)
2007/02/08のBlog
[ 11:07 ]
[ Forest関連情報 ]
メーリングリストにもアナウンスしましたが、「管理者ガイド」を公開しました。4.0のリリースの際には間に合わなくて同梱できなかったのですが。
PostgresForest 4.0 管理者ガイド
最近はドキュメント作成ばかりをやっていましたが、ようやく一段落です。
さて、次はトラブルシューティングガイドを書かねば・・・。
(な)
PostgresForest 4.0 管理者ガイド
最近はドキュメント作成ばかりをやっていましたが、ようやく一段落です。
さて、次はトラブルシューティングガイドを書かねば・・・。
(な)
前のページ
|
次のページ
