From nagayasus ＠ nttdata.co.jp Mon May 14 18:59:00 2007 From: nagayasus ＠ nttdata.co.jp (Satoshi Nagayasu) Date: Mon, 14 May 2007 18:59:00 +0900 Subject: [postgresforest-users 33] =?iso-2022-jp?b?NC4wLjIbJEIlaiVqITwlOSQ3JF4kNyQ/ISMbKEI=?= Message-ID: <464832E4.3000809@nttdata.co.jp> 永安です。 当初の予定よりだいぶ遅くなりましたが、いろいろ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に対応。 よろしければ、お試しくださいませ。 ではでは。 -- NAGAYASU Satoshi Phone: +81-50-5546-2496 From kantomi ＠ nifty.com Tue May 15 18:36:36 2007 From: kantomi ＠ nifty.com (kantomi ＠ nifty.com) Date: Tue, 15 May 2007 18:36:36 +0900 Subject: [postgresforest-users 34] =?iso-2022-jp?b?UG9zdGdyZXNGb3Jlc3QgGyRCJE48QkBTJEskRCQkJEYbKEI=?= Message-ID: <20070515181506.08D2.KANTOMI@nifty.com> メーリングリストの皆様 はじめまして 生島と申します。 PostgresForest のテーブルのパーティション化機能を利用して 全文検索システムを構築しようと考えている者です。 そこで、PostgresForest でパーティションテーブルで１つの 論理テーブルの限界値が分からないと検討、提案できない 状態になっています。 できれば、論理値ではなく実績として教えていただければ幸いです。 また、３台のＤＢサーバにパーティションしていたときに４台目を 加えることは問題ありませんでしょうか。 現状では、それほど大きくありませんが、スケーラビリティを 確保しておきたいので、ご経験がある方、何卒、よろしくお願い いたします。 From nagayasus ＠ nttdata.co.jp Wed May 16 17:06:55 2007 From: nagayasus ＠ nttdata.co.jp (Satoshi Nagayasu) Date: Wed, 16 May 2007 17:06:55 +0900 Subject: [postgresforest-users 35] Re: =?iso-2022-jp?b?UG9zdGdyZXNGb3Jlc3QgGyRCJE48QkBTJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: <20070515181506.08D2.KANTOMI@nifty.com> References: <20070515181506.08D2.KANTOMI@nifty.com> Message-ID: <464ABB9F.3090606@nttdata.co.jp> 生島さま、 初めまして、永安です。 > そこで、PostgresForest でパーティションテーブルで１つの > 論理テーブルの限界値が分からないと検討、提案できない > 状態になっています。 ハードウェアの性能などに依存する話になりますので、 「限界」というのは一概には言えませんが、 我々の手元では数十GBから200GB程度で動かしていたケースがあります。 その際のパーティション数は10〜数十程度です。 環境としては、一般的なPCサーバだったと思います。 DBの性能限界はAPの作りに大きく依存しますので、 個別のケースにおいてはまた変わってくるかとは思いますが。 どれくらいのサイズを想定されていますでしょうか？ > また、３台のＤＢサーバにパーティションしていたときに４台目を > 加えることは問題ありませんでしょうか。 お聞きする限りでは特に問題はないと思います。 取り急ぎ。 ＃どこかにテラバイト級の実績があったりしないでしょうか。。。 kantomi ＠ nifty.com wrote: > メーリングリストの皆様 > > はじめまして > 生島と申します。 > > PostgresForest のテーブルのパーティション化機能を利用して > 全文検索システムを構築しようと考えている者です。 > > そこで、PostgresForest でパーティションテーブルで１つの > 論理テーブルの限界値が分からないと検討、提案できない > 状態になっています。 > > できれば、論理値ではなく実績として教えていただければ幸いです。 > > また、３台のＤＢサーバにパーティションしていたときに４台目を > 加えることは問題ありませんでしょうか。 > > 現状では、それほど大きくありませんが、スケーラビリティを > 確保しておきたいので、ご経験がある方、何卒、よろしくお願い > いたします。 > > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users -- NAGAYASU Satoshi Phone: +81-50-5546-2496 From kantomi ＠ nifty.com Wed May 16 17:25:55 2007 From: kantomi ＠ nifty.com (kantomi ＠ nifty.com) Date: Wed, 16 May 2007 17:25:55 +0900 Subject: [postgresforest-users 36] Re: =?iso-2022-jp?b?UG9zdGdyZXNGb3Jlc3QgGyRCJE48QkBTJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: <464ABB9F.3090606@nttdata.co.jp> References: <20070515181506.08D2.KANTOMI@nifty.com> <464ABB9F.3090606@nttdata.co.jp> Message-ID: <20070516171244.CFE2.KANTOMI@nifty.com> 永安 様 お世話になっております。 生島です。 > 我々の手元では数十GBから200GB程度で動かしていたケースがあります。 > その際のパーティション数は10〜数十程度です。 数十台ですか。 そのケースで考えると、各ＤＢのファイルサイズは１台に付き５Ｇぐらい でしょうか。 ちなみに各ＤＢのメモリーはどれぐらいですか？ 全文検索で６０Ｇを３台ぐらいで出来ればと思ったのですが甘い考えで したね。 From nagayasus ＠ nttdata.co.jp Wed May 16 17:49:16 2007 From: nagayasus ＠ nttdata.co.jp (Satoshi Nagayasu) Date: Wed, 16 May 2007 17:49:16 +0900 Subject: [postgresforest-users 37] Re: =?iso-2022-jp?b?UG9zdGdyZXNGb3Jlc3QgGyRCJE48QkBTJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: <20070516171244.CFE2.KANTOMI@nifty.com> References: <20070515181506.08D2.KANTOMI@nifty.com> <464ABB9F.3090606@nttdata.co.jp> <20070516171244.CFE2.KANTOMI@nifty.com> Message-ID: <464AC58C.7070000@nttdata.co.jp> 永安です。 > 数十台ですか。 > そのケースで考えると、各ＤＢのファイルサイズは１台に付き５Ｇぐらい > でしょうか。 > ちなみに各ＤＢのメモリーはどれぐらいですか？ すいません、さっきのメールは個別の検証時の情報などを まとめてお送りしてしまったので、あのような書き方になりました。 我々が検証する際のマシンは、場合にもよりますが、 だいたい2GB〜4GB程度のメモリを積んでいるケースが多いです。 実際にネックになるのは、おそらくはPostgresForestというよりは、 各ノードに配置されたPostgreSQL単体でどの程度処理可能か、という 点なのではないかと思います。 基本的な考え方としては、 「PostgreSQL単体の限界性能×ノード数＝PostgresForestの限界性能」 と考えていただければいいかと思います。 > 全文検索で６０Ｇを３台ぐらいで出来ればと思ったのですが甘い考えで > したね。 特に甘くはないと思います。 実際に上記に近い数値で試したことがないので何とも言えないのですが、 PostgreSQL単体で20GB程度を処理することは、PostgreSQLなら十分可能だと 思いますので。 ＃あと、先ほども書きましたが、APの作りに依存する部分が大きいです。 あと、全文検索というお話ですと、「Ludia」というものもありますので、 こちらも検討してみてはいかがでしょうか。 http://sourceforge.jp/projects/ludia/ http://www.thinkit.co.jp/free/article/0612/8/3/ 以上、よろしくお願いいたします。 kantomi ＠ nifty.com wrote: > 永安 様 > > お世話になっております。 > 生島です。 > >> 我々の手元では数十GBから200GB程度で動かしていたケースがあります。 >> その際のパーティション数は10〜数十程度です。 > > 数十台ですか。 > そのケースで考えると、各ＤＢのファイルサイズは１台に付き５Ｇぐらい > でしょうか。 > ちなみに各ＤＢのメモリーはどれぐらいですか？ > > 全文検索で６０Ｇを３台ぐらいで出来ればと思ったのですが甘い考えで > したね。 > > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users -- NAGAYASU Satoshi Phone: +81-50-5546-2496 From kantomi ＠ nifty.com Wed May 16 19:59:23 2007 From: kantomi ＠ nifty.com (kantomi ＠ nifty.com) Date: Wed, 16 May 2007 19:59:23 +0900 Subject: [postgresforest-users 38] Re: =?iso-2022-jp?b?UG9zdGdyZXNGb3Jlc3QgGyRCJE48QkBTJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: <464AC58C.7070000@nttdata.co.jp> References: <20070516171244.CFE2.KANTOMI@nifty.com> <464AC58C.7070000@nttdata.co.jp> Message-ID: <20070516194712.CAD2.KANTOMI@nifty.com> 永安 様 お世話になっております。 生島です。 丁寧な解説、ありがとうございました。 > 「PostgreSQL単体の限界性能×ノード数＝PostgresForestの限界性能」 そのイメージで考えていたので、６０Ｇを３台ぐらいなら何とかなる かと思っていました。 数〜十Ｇの経験はあるので２０Ｇぐらいなら単体でも、それを超えると PostgresForest のような機能が必要との考えでした。 最初からハッキリと書かず、申し訳ございませんでした。 もう少し台数は増やそうと思いますが提案できそうです。 ありがとうございました。 On Wed, 16 May 2007 17:49:16 +0900 Satoshi Nagayasu wrote: > 永安です。 > > > 数十台ですか。 > > そのケースで考えると、各ＤＢのファイルサイズは１台に付き５Ｇぐらい > > でしょうか。 > > ちなみに各ＤＢのメモリーはどれぐらいですか？ > > すいません、さっきのメールは個別の検証時の情報などを > まとめてお送りしてしまったので、あのような書き方になりました。 > > 我々が検証する際のマシンは、場合にもよりますが、 > だいたい2GB〜4GB程度のメモリを積んでいるケースが多いです。 > > 実際にネックになるのは、おそらくはPostgresForestというよりは、 > 各ノードに配置されたPostgreSQL単体でどの程度処理可能か、という > 点なのではないかと思います。 > > 基本的な考え方としては、 > > 「PostgreSQL単体の限界性能×ノード数＝PostgresForestの限界性能」 > > と考えていただければいいかと思います。 > > > 全文検索で６０Ｇを３台ぐらいで出来ればと思ったのですが甘い考えで > > したね。 > > 特に甘くはないと思います。 > 実際に上記に近い数値で試したことがないので何とも言えないのですが、 > PostgreSQL単体で20GB程度を処理することは、PostgreSQLなら十分可能だと > 思いますので。 > > ＃あと、先ほども書きましたが、APの作りに依存する部分が大きいです。 > > あと、全文検索というお話ですと、「Ludia」というものもありますので、 > こちらも検討してみてはいかがでしょうか。 > > http://sourceforge.jp/projects/ludia/ > http://www.thinkit.co.jp/free/article/0612/8/3/ > > 以上、よろしくお願いいたします。 > > kantomi ＠ nifty.com wrote: > > 永安 様 > > > > お世話になっております。 > > 生島です。 > > > >> 我々の手元では数十GBから200GB程度で動かしていたケースがあります。 > >> その際のパーティション数は10〜数十程度です。 > > > > 数十台ですか。 > > そのケースで考えると、各ＤＢのファイルサイズは１台に付き５Ｇぐらい > > でしょうか。 > > ちなみに各ＤＢのメモリーはどれぐらいですか？ > > > > 全文検索で６０Ｇを３台ぐらいで出来ればと思ったのですが甘い考えで > > したね。 > > > > > > _______________________________________________ > > postgresforest-users mailing list > > postgresforest-users ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users > > > -- > NAGAYASU Satoshi > Phone: +81-50-5546-2496 > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users From tsutomu.matsushita ＠ uniadex.co.jp Fri May 18 12:08:01 2007 From: tsutomu.matsushita ＠ uniadex.co.jp (tsutomu.matsushita ＠ uniadex.co.jp) Date: Fri, 18 May 2007 12:08:01 +0900 Subject: [postgresforest-users 39] =?iso-2022-jp?b?GyRCPmMzMkgvQDg7fiROJTklRiE8JT8lOUBaJGpCWCRvGyhC?= =?iso-2022-jp?b?GyRCJGo+cjdvJE4+XDpZJHIkNDY1PHg0aiQkJF4kORsoQg==?= Message-ID: プロジェクト管理者様 はじめまして松下と申します。 PostgresForest　4.0.1を利用すべくテストを行っております。 現在DB障害発生時の切り替えテストを行っており、 インスタンスのステータスが稼動中から障害中へ変更されるタイミングが 把握できておりません。 ご教授願います。 以下の構成、設定でテストを実施しております。 ＝＝＝＝＝＝＝ ・2台のサーバでDBレプリケーションを実施 ・コンフィグレーション設定 　refresh ：1 　retry ：0 　timeout ：30 □テスト項目 １：1台のDB(サーバID1)をDB停止コマンド(forest_ctl)にて停止 ２：select文を利用して接続確認(Jpsql.shを利用) □テスト結果 　１：selectコマンド成功 　３：インスタンスステータス確認 　　サーバID0：稼動中 　　サーバID1：稼動中 　４：selectコマンド失敗 　　※エラー出力結果 　　FATAL: terminating connection due to administrator command 　５：インスタンスステータス確認 　　サーバID0：稼動中 　　サーバID1：稼動中 　６：selectコマンド成功 　７：インスタンスステータス確認 　　サーバID0：稼動中 　　サーバID1：稼動中 　８：インスタンスステータス確認 　　サーバID0：稼動中 　　サーバID1：稼動中 　９：selectコマンド失敗 　　※エラー出力結果 　　Error retry over. 　１０：インスタンスステータス確認 　　サーバID0：稼動中 　　サーバID1：障害中 ＝＝＝＝＝＝＝ 上記のテストではretryカウントを超えたため障害中へ状態遷移したと見受けられます。 ですが、retryカウントは"0"と設定していますが、何度かアクセスしているように見受けられます。 retryカウントの設定値は、どのように動作するのでしょうか。 また、タイムアウトを30secと設定していますが、DB停止から30sec以上経過した場合でも インスタンスの状態が稼動中から遷移いたしません。 retryとtimeoutの設定値についてご教授願います。 よろしくお願いいたします。 以上 ********************************************************** 　ユニアデックス株式会社 　　ICTソリューション事業グループ　コンサルティング＆デザイン統括部 　　ソリューション統括部　第二グループ 　　松下　勉　　TEL:03-6204-1833(ダイヤルイン) FAX:03-3660-9807 　　　　　　　　　 E-mail tsutomu.matsushita ＠ uniadex.co.jp ********************************************************** From nagayasus ＠ nttdata.co.jp Mon May 21 17:34:28 2007 From: nagayasus ＠ nttdata.co.jp (Satoshi Nagayasu) Date: Mon, 21 May 2007 17:34:28 +0900 Subject: [postgresforest-users 40] Re: =?iso-2022-jp?b?GyRCPmMzMkgvQDg7fiROJTklRiE8JT8lOUBaJGobKEI=?= =?iso-2022-jp?b?GyRCQlgkbyRqPnI3byROPlw6WSRyJDQ2NTx4NGokJCReJDkbKEI=?= In-Reply-To: References: Message-ID: <46515994.9050207@nttdata.co.jp> 松下様、 永安です。 テストの前提がまだすべて見えておりませんので、確かなことは言えないのですが。 「４」のエラーで出ているメッセージ「FATAL: terminating connection due to administrator command」は、「PostgreSQLが接続を終了しようとしている」という 意味のメッセージですので、おそらくはテスト項目の「forest_ctlでの停止」でも バックエンドが停止していないのではないかと思います。 つまり、forest_ctlで停止をしようとしても、接続が張られたままで実際には シャットダウンされておらず、「４」のメッセージにつながっているのではないかと。 そして、その後、バックエンドがシャットダウンされた結果、「９」では 接続ができずにSELECTが失敗している、というように見えます。 forest_ctlでシャットダウンしたバックエンドのプロセスが、 確かに終了しているかどうかを、一度確認してみていただけませんでしょうか。 （プロセスの状態を確認する、など） よろしくお願いします。 tsutomu.matsushita ＠ uniadex.co.jp wrote: > プロジェクト管理者様 > > はじめまして松下と申します。 > > PostgresForest　4.0.1を利用すべくテストを行っております。 > 現在DB障害発生時の切り替えテストを行っており、 > インスタンスのステータスが稼動中から障害中へ変更されるタイミングが > 把握できておりません。 > ご教授願います。 > > 以下の構成、設定でテストを実施しております。 > ＝＝＝＝＝＝＝ > ・2台のサーバでDBレプリケーションを実施 > ・コンフィグレーション設定 > 　refresh ：1 > 　retry ：0 > 　timeout ：30 > > □テスト項目 > １：1台のDB(サーバID1)をDB停止コマンド(forest_ctl)にて停止 > ２：select文を利用して接続確認(Jpsql.shを利用) > > □テスト結果 > 　１：selectコマンド成功 > 　３：インスタンスステータス確認 > 　　サーバID0：稼動中 > 　　サーバID1：稼動中 > 　４：selectコマンド失敗 > 　　※エラー出力結果 > 　　FATAL: terminating connection due to administrator command > 　５：インスタンスステータス確認 > 　　サーバID0：稼動中 > 　　サーバID1：稼動中 > 　６：selectコマンド成功 > 　７：インスタンスステータス確認 > 　　サーバID0：稼動中 > 　　サーバID1：稼動中 > 　８：インスタンスステータス確認 > 　　サーバID0：稼動中 > 　　サーバID1：稼動中 > 　９：selectコマンド失敗 > 　　※エラー出力結果 > 　　Error retry over. > 　１０：インスタンスステータス確認 > 　　サーバID0：稼動中 > 　　サーバID1：障害中 > ＝＝＝＝＝＝＝ > > 上記のテストではretryカウントを超えたため障害中へ状態遷移したと見受けられます。 > ですが、retryカウントは"0"と設定していますが、何度かアクセスしているように見受けられます。 > retryカウントの設定値は、どのように動作するのでしょうか。 > また、タイムアウトを30secと設定していますが、DB停止から30sec以上経過した場合でも > インスタンスの状態が稼動中から遷移いたしません。 > > retryとtimeoutの設定値についてご教授願います。 > > よろしくお願いいたします。 > > 以上 > > ********************************************************** > 　ユニアデックス株式会社 > 　　ICTソリューション事業グループ　コンサルティング＆デザイン統括部 > 　　ソリューション統括部　第二グループ > > 　　松下　勉　　TEL:03-6204-1833(ダイヤルイン) FAX:03-3660-9807 > 　　　　　　　　　 E-mail tsutomu.matsushita ＠ uniadex.co.jp > ********************************************************** > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users -- NAGAYASU Satoshi Phone: +81-50-5546-2496 From impreza7889 ＠ gmail.com Sat May 26 16:34:24 2007 From: impreza7889 ＠ gmail.com (T.Kuroda) Date: Sat, 26 May 2007 16:34:24 +0900 Subject: [postgresforest-users 41] =?iso-2022-jp?b?QW4gZWZmZWN0aXZlIGdsb2JhbCBzeXN0ZW0gY2F0YWxvZyBk?= =?iso-2022-jp?b?b2VzIG5vdCBleGlzdBskQiROJSglaSE8JEskRCQkJEYbKEI=?= Message-ID: お世話になります、黒田と申します。 PostgresForestを使用したシステムを運用しているのですが、 そのシステムでSELECTを実行した際にExceptionが発生したのを確認できたのですが、 エラーの原因がわからなかったため、MLに投げさせていただきました。 エラーの内容は java.sql.SQLException: An effective global system catalog does not exist. at org.apache.commons.dbutils.QueryRunner.rethrow(QueryRunner.java:330) at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:213) at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:279) となっており、実際に実行しているクエリは SELECT user_id, fax_number FROM usr_tbl WHERE user_id=? OR user_id=? (省略) です。 上記のクエリの OR user_id = ? が約6000個ほど連続で存在するクエリとなっています。 OR user_id = ?を100個ほどになる設定で実行すると、特にエラーもなく実行できます。 エラーの内容的にはGSC関連のエラーかなと思えるのですが、それ以上の事は わからない状態です。 現象としては上記のようになっているのですが、もしなにか原因となるものが ありましたらご教授いただきたいと思います。 以上、よろしくお願いいたします。 From tsutomu.matsushita ＠ uniadex.co.jp Tue May 29 09:35:34 2007 From: tsutomu.matsushita ＠ uniadex.co.jp (tsutomu.matsushita ＠ uniadex.co.jp) Date: Tue, 29 May 2007 09:35:34 +0900 Subject: [postgresforest-users 42] Re: =?iso-2022-jp?b?GyRCPmMzMkgvQDg7fiROJTklRiE8JT8lOUBaJGobKEI=?= =?iso-2022-jp?b?GyRCQlgkbyRqPnI3byROPlw6WSRyJDQ2NTx4NGokJCReGyhC?= =?iso-2022-jp?b?GyRCJDkbKEI=?= Message-ID: <601548237B2F1B4CB35C5762600B517625E4C9@ZZ01X1MB11.ixas.unisys.co.jp> 永安様 お世話になります。松下です。 ご連絡が遅くなってしまい申し訳ありません。 > 「４」のエラーで出ているメッセージ「FATAL: terminating connection due to > administrator command」は、「PostgreSQLが接続を終了しようとしている」と > いう意味のメッセージですので、おそらくはテスト項目の「forest_ctlでの停止」 > でもバックエンドが停止していないのではないかと思います。 ご指摘いただいたとおり、バックエンドでプロセスが動いておりました。 ご迷惑をおかけしました。ありがとうございます。 > -----Original Message----- > From: Satoshi Nagayasu [mailto:nagayasus ＠ nttdata.co.jp] > Sent: Monday, May 21, 2007 5:34 PM > To: postgresforest-users ＠ lists.sourceforge.jp > Subject: [postgresforest-users 40] Re: 障害発生時のステータス切り替わり > 条件の詳細をご教授願います > > > 松下様、 > > 永安です。 > > テストの前提がまだすべて見えておりませんので、確かなことは言えないので > すが。 > > 「４」のエラーで出ているメッセージ「FATAL: terminating > connection due to > administrator command」は、「PostgreSQLが接続を終了しようとしている」と > いう > 意味のメッセージですので、おそらくはテスト項目の「forest_ctlでの停止」 > でも > バックエンドが停止していないのではないかと思います。 > > つまり、forest_ctlで停止をしようとしても、接続が張られたままで実際には > シャットダウンされておらず、「４」のメッセージにつながっているのではな > いかと。 > > そして、その後、バックエンドがシャットダウンされた結果、「９」では > 接続ができずにSELECTが失敗している、というように見えます。 > > forest_ctlでシャットダウンしたバックエンドのプロセスが、 > 確かに終了しているかどうかを、一度確認してみていただけませんでしょうか > 。 > （プロセスの状態を確認する、など） > > よろしくお願いします。 > > tsutomu.matsushita ＠ uniadex.co.jp wrote: > > プロジェクト管理者様 > > > > はじめまして松下と申します。 > > > > PostgresForest　4.0.1を利用すべくテストを行っております。 > > 現在DB障害発生時の切り替えテストを行っており、 > > インスタンスのステータスが稼動中から障害中へ変更されるタイミングが > > 把握できておりません。 > > ご教授願います。 > > > > 以下の構成、設定でテストを実施しております。 > > ＝＝＝＝＝＝＝ > > ・2台のサーバでDBレプリケーションを実施 > > ・コンフィグレーション設定 > > 　refresh ：1 > > 　retry ：0 > > 　timeout ：30 > > > > □テスト項目 > > １：1台のDB(サーバID1)をDB停止コマンド(forest_ctl)にて停止 > > ２：select文を利用して接続確認(Jpsql.shを利用) > > > > □テスト結果 > > 　１：selectコマンド成功 > > 　３：インスタンスステータス確認 > > 　　サーバID0：稼動中 > > 　　サーバID1：稼動中 > > 　４：selectコマンド失敗 > > 　　※エラー出力結果 > > 　　FATAL: terminating connection due to administrator command > > 　５：インスタンスステータス確認 > > 　　サーバID0：稼動中 > > 　　サーバID1：稼動中 > > 　６：selectコマンド成功 > > 　７：インスタンスステータス確認 > > 　　サーバID0：稼動中 > > 　　サーバID1：稼動中 > > 　８：インスタンスステータス確認 > > 　　サーバID0：稼動中 > > 　　サーバID1：稼動中 > > 　９：selectコマンド失敗 > > 　　※エラー出力結果 > > 　　Error retry over. > > 　１０：インスタンスステータス確認 > > 　　サーバID0：稼動中 > > 　　サーバID1：障害中 > > ＝＝＝＝＝＝＝ > > > > 上記のテストではretryカウントを超えたため障害中へ状態遷移したと見受け > られます。 > > ですが、retryカウントは"0"と設定していますが、何度かアクセスしている > ように見受けられます。 > > retryカウントの設定値は、どのように動作するのでしょうか。 > > また、タイムアウトを30secと設定していますが、DB停止から30sec以上経過 > した場合でも > > インスタンスの状態が稼動中から遷移いたしません。 > > > > retryとtimeoutの設定値についてご教授願います。 > > > > よろしくお願いいたします。 > > > > 以上 > > > > ********************************************************** > > 　ユニアデックス株式会社 > > 　　ICTソリューション事業グループ　コンサルティング＆デザイン統括部 > > 　　ソリューション統括部　第二グループ > > > > 　　松下　勉　　TEL:03-6204-1833(ダイヤルイン) FAX:03-3660-9807 > > 　　　　　　　　　 E-mail tsutomu.matsushita ＠ uniadex.co.jp > > ********************************************************** > > > > _______________________________________________ > > postgresforest-users mailing list > > postgresforest-users ＠ lists.sourceforge.jp > > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users > > > -- > NAGAYASU Satoshi > Phone: +81-50-5546-2496 > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users >