From horikawas ＠ n-tec.co.jp Wed Dec 12 16:49:58 2007 From: horikawas ＠ n-tec.co.jp (=?iso-2022-jp?B?IhskQktZQG4bKEIgGyRCQU8wbE8vGyhCIg==?=) Date: Wed, 12 Dec 2007 16:49:58 +0900 Subject: [postgresforest-users 99] =?iso-2022-jp?b?GyRCJUchPCU/Nz9AKThCO3Y5YBsoQg==?= Message-ID: <1197445798881114000037ef@ns.n-tec-web.jp> いつもお世話になっております。 PostgresForestの利用を検討しているものです。 PostgresForestの制限事項について確認させて下さい。 既存のテーブル構造をPostgresForest環境へ以降することを考えていますが 各テーブルのデータ型に制限はありますでしょうか。 SourceForgeに公開されているマニュアルによりますとSerial型は保障外と ありますが、Blob型等のラージオブジェクトの使用は可能でしょうか。 また使用可能データ型の一覧等の資料はありますでしょうか。 ご教示ください。 ------------------------------------------------- エヌシーエステクノロジー株式会社 第一システム部 堀川　創一朗 ◆TEL：06-6444-1002 ◇URL：http://www.n-tec.co.jp/ From nagatsumas ＠ nttdata.co.jp Tue Dec 18 10:40:46 2007 From: nagatsumas ＠ nttdata.co.jp (Satoshi.Nagatsuma) Date: Tue, 18 Dec 2007 10:40:46 +0900 Subject: [postgresforest-users 100] Re: =?iso-2022-jp?b?GyRCJSolcyVpJSQlcyVqJSslUCVqQ2YlKCVpITwbKEI=?= =?iso-2022-jp?b?GyRCISEbKEJhcHBseUxvZ1JlY29yZCgpIGZhaWxlZC4bJEIkSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: <4304b9d50711280430l67528e2er9fd88598290af11e@mail.gmail.com> References: <4304b9d50711280430l67528e2er9fd88598290af11e@mail.gmail.com> Message-ID: <4767251E.7060502@nttdata.co.jp> 長妻です。 >> オンラインリカバリを開始した際、phase1,phase2においてエラー >> org.postgresforest.tool.recovery.RecoveryException: applyLogRecord() >> failed.が発生しました。 > そちらの調査では、何か進展がありましたでしょうか。 リカバリーに関連するソースコード上の怪しそうな部分に ざっと目は通したのですが、特に上記のようなエラーが 起きそうな部分は見当たりませんでした。 リカバリーマネージャの改善は今後も行っていく予定なので その中でソースコード側から継続調査してみようと思っています。 永津 さんは書きました: > お世話になっております。 > 永津と申します。 > > 以前下記のような形で質問させて頂きました。 > >> オンラインリカバリ実行中のエラーについて質問があります。 >> >> マシン２台を用いて運用テストを行っています。 > 補足として、GSCをそれぞれのマシンに配置して冗長化の構成をとっております。 > >> それぞれにPostgresSQL4.0.2とPostgresSQL8.1.6をインストールしています。 >> >> 1つのデータベースに対して、毎秒約9000件のレコードをInsertしている状態で >> オンラインリカバリを開始した際、phase1,phase2においてエラー >> org.postgresforest.tool.recovery.RecoveryException: applyLogRecord() >> failed.が発生しました。 >> この後、start_vmまでオンラインリカバリを継続、終了いたしましたが、 >> データの差異は改善されませんでした。 >> >> エラーは同じ状況で再現します。 >> また、phase1終了後の時点でInsertを開始した場合は、 >> 正常にリカバリを終了します。 > > 上記の質問について次のようなご回答を頂きました。 > >> 長妻です。 >> >> 基本的にオンラインリカバリは、トランザクション（特に更新）が >> 少ない時間帯に行っていただくことを想定しています。 >> 例えばWEBアプリケーションのバックエンドであれば、 >> 夜間帯のトランザクションが少ない時間帯、 >> なおかつバッチなどが走っていない状態で・・・ >> といった具合です。 >> 秒間9000件の更新はなかなか激しいですね(^^； >> ちなみに、Phase1の時間に更新量が多いと、リカバリー最中に >> vmが停止している時間が長くなってしまいます。 >> >> >> さて、それはともかく、このエラーについてはこちらでも >> 調べてみましたが、今のところ根本的な原因がわかりません。 >> 追加で頂いたログも含め、同じ内容を2度INSERTしているという >> 現象面だけは見えているのですが・・・ >> リカバリマネージャの不具合の可能性もあるため >> もう少しこちらでも調べてみるつもりです。 >> >> もし永津さんのほうでもなにかわかりましたら、 >> 情報をいただけると助かります。 > > チューニングをしてPostgresSQLパフォーマンスの向上を行う、 > レコードのinsert件数をデータベース全体で約1200件/秒まで下げる、 > などの方法を試みましたが、同様のエラーが発生しています。 > > そちらの調査では、何か進展がありましたでしょうか。 > > -debugオプションを追加してリカバリコマンドを実行したときに出力された > メッセージログを今回追記いたします。 > > $ /usr/local/forest40/bin/ForestRecovery.sh -user forest -pass forest > -gsc_url jdbc:postgresql://192.168.0.165:5432/gsc -phase1 0 1 forest_db -debug > 2007-11-28 20:50:03.722 DEBUG: 2 GSC(s) found. > 2007-11-28 20:50:03.729 NOTICE: RECOVERING: > 2007-11-28 20:50:03.729 NOTICE: FROM > [0]jdbc:postgresql://192.168.0.165:5432/forest_db > 2007-11-28 20:50:03.729 NOTICE: TO > [1]jdbc:postgresql://192.168.0.134:5432/forest_db > 2007-11-28 20:50:03.729 DEBUG: jdbc:postgresql://192.168.0.165:5432/forest_db > 2007-11-28 20:50:03.729 DEBUG: jdbc:postgresql://192.168.0.134:5432/forest_db > 2007-11-28 20:50:03.736 DEBUG: Backend PID=17602 > 2007-11-28 20:50:03.736 NOTICE: SERVER STATUS: > 2007-11-28 20:50:03.737 NOTICE: Src: Server 0, Status 1 > 2007-11-28 20:50:03.738 NOTICE: Dst: Server 1, Status -1 > 2007-11-28 20:50:03.738 NOTICE: RECOVERY_MODE = 1 > 2007-11-28 20:50:03.739 NOTICE: RECOVERY / INITIALIZATION > 2007-11-28 20:50:03.74 NOTICE: TABLE(S) TO COPY: > 2007-11-28 20:50:03.74 NOTICE: test_table1 > 2007-11-28 20:50:03.74 NOTICE: test_table2 > 2007-11-28 20:50:03.74 NOTICE: test_table3 > 2007-11-28 20:50:03.74 NOTICE: test_table4 > 2007-11-28 20:50:03.74 NOTICE: RECOVERY / PHASE 1: start. > 2007-11-28 20:50:03.741 NOTICE: GSC CHECK: > 2007-11-28 20:50:03.742 NOTICE: forest_servdb, forest_db: OK > 2007-11-28 20:50:03.743 NOTICE: forest_tablepartdtl, test_table1: OK > 2007-11-28 20:50:03.744 NOTICE: forest_tablepartdtl, test_table2: OK > 2007-11-28 20:50:03.744 NOTICE: forest_tablepartdtl, test_table3: OK > 2007-11-28 20:50:03.745 NOTICE: forest_tablepartdtl, test_table4: OK > 2007-11-28 20:50:08.332 NOTICE: Log table already exists. > 2007-11-28 20:50:08.333 NOTICE: Log table already exists. > 2007-11-28 20:50:08.333 NOTICE: Log table already exists. > 2007-11-28 20:50:08.334 DEBUG: beginRecoveryLogging: test_table1 > 2007-11-28 20:50:08.334 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:50:08.335 DEBUG: CREATE TRIGGER test_table1_logger AFTER > INSERT OR UPDATE OR DELETE ON test_table1 FOR EACH ROW EXECUTE > PROCEDURE postgresforest.logger() > 2007-11-28 20:50:08.335 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:50:08.336 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:50:08.336 DEBUG: Logger started, table => test_table1 > 2007-11-28 20:50:08.336 DEBUG: beginRecoveryLogging: test_table2 > 2007-11-28 20:50:08.336 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:50:08.336 DEBUG: CREATE TRIGGER test_table2_logger AFTER > INSERT OR UPDATE OR DELETE ON test_table2 FOR EACH ROW EXECUTE > PROCEDURE postgresforest.logger() > 2007-11-28 20:50:08.336 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:50:08.337 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:50:08.337 DEBUG: Logger started, table => test_table2 > 2007-11-28 20:50:08.338 DEBUG: beginRecoveryLogging: test_table3 > 2007-11-28 20:50:08.338 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:50:08.338 DEBUG: CREATE TRIGGER test_table3_logger AFTER > INSERT OR UPDATE OR DELETE ON test_table3 FOR EACH ROW EXECUTE > PROCEDURE postgresforest.logger() > 2007-11-28 20:50:08.338 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:50:08.339 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:50:08.339 DEBUG: Logger started, table => test_table3 > 2007-11-28 20:50:08.339 DEBUG: beginRecoveryLogging: test_table4 > 2007-11-28 20:50:08.339 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:50:08.339 DEBUG: CREATE TRIGGER test_table4_logger AFTER > INSERT OR UPDATE OR DELETE ON test_table4 FOR EACH ROW EXECUTE > PROCEDURE postgresforest.logger() > 2007-11-28 20:50:08.339 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:50:08.34 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:50:08.34 DEBUG: Logger started, table => test_table4 > 2007-11-28 20:50:08.34 NOTICE: COPYING ALL TABLES: start. > 2007-11-28 20:50:08.341 NOTICE: CREATE SNAPSHOT: start. > 2007-11-28 20:50:08.341 DEBUG: getSnapshotXid: test_table1 > 2007-11-28 20:50:08.341 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:50:08.341 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:50:08.385 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:50:08.385 NOTICE: COPYING test_table1 > 2007-11-28 20:50:08.386 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:50:08.386 DEBUG: copyTableToFile(): test_table1 to > /tmp/test_table1.db > 2007-11-28 20:50:08.386 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:50:08.386 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:50:20.459 DEBUG: copyTableToFile(): done. > 2007-11-28 20:50:20.459 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:50:20.459 NOTICE: done. > 2007-11-28 20:50:20.459 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:50:20.459 NOTICE: COPYING test_table2 > 2007-11-28 20:50:20.459 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:50:20.459 DEBUG: copyTableToFile(): test_table2 to > /tmp/test_table2.db > 2007-11-28 20:50:20.459 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:50:32.554 DEBUG: copyTableToFile(): done. > 2007-11-28 20:50:32.554 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:50:32.554 NOTICE: done. > 2007-11-28 20:50:32.554 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:50:32.554 NOTICE: COPYING test_table3 > 2007-11-28 20:50:32.554 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:50:32.554 DEBUG: copyTableToFile(): test_table3 to > /tmp/test_table3.db > 2007-11-28 20:50:32.554 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:50:44.606 DEBUG: copyTableToFile(): done. > 2007-11-28 20:50:44.606 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:50:44.606 NOTICE: done. > 2007-11-28 20:50:44.606 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:50:44.607 NOTICE: COPYING test_table4 > 2007-11-28 20:50:44.607 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:50:44.607 DEBUG: copyTableToFile(): test_table4 to > /tmp/test_table4.db > 2007-11-28 20:50:44.607 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:50:56.662 DEBUG: copyTableToFile(): done. > 2007-11-28 20:50:56.662 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:50:56.662 NOTICE: done. > 2007-11-28 20:50:56.662 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:50:56.662 DEBUG: Snapshot xid=71776536 > 2007-11-28 20:50:56.662 NOTICE: CREATE SNAPSHOT: done. > 2007-11-28 20:50:56.662 NOTICE: REBUILD FROM SNAPSHOT: start. > 2007-11-28 20:51:01.677 DEBUG: rebuildTableFromFile(): test_table1 > from /tmp/test_table1.db > 2007-11-28 20:51:01.677 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:51:01.677 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:51:08.339 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:51:08.342 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:51:08.344 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:51:08.35 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:51:28.678 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:51:28.678 DEBUG: rebuildTableFromFile(): done. > 2007-11-28 20:51:28.678 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:51:33.002 DEBUG: rebuildTableFromFile(): test_table2 > from /tmp/test_table2.db > 2007-11-28 20:51:33.002 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:51:33.002 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:52:07.916 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:52:07.917 DEBUG: rebuildTableFromFile(): done. > 2007-11-28 20:52:07.917 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:52:12.239 DEBUG: rebuildTableFromFile(): test_table3 > from /tmp/test_table3.db > 2007-11-28 20:52:12.239 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:52:12.239 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:52:58.378 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:52:58.378 DEBUG: rebuildTableFromFile(): done. > 2007-11-28 20:52:58.378 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:53:02.695 DEBUG: rebuildTableFromFile(): test_table4 > from /tmp/test_table4.db > 2007-11-28 20:53:02.696 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been created. > 2007-11-28 20:53:02.696 DEBUG: CancelThread is going to wait 60 secs. > 2007-11-28 20:53:44.636 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db disabled. > 2007-11-28 20:53:44.636 DEBUG: rebuildTableFromFile(): done. > 2007-11-28 20:53:44.636 DEBUG: CancelThread: pid=17602, > url=jdbc:postgresql://192.168.0.165:5432/forest_db has been finished > without a cancel command. > 2007-11-28 20:53:45.046 NOTICE: REBUILD FROM SNAPSHOT: done. > 2007-11-28 20:53:45.046 NOTICE: COPYING ALL TABLES: done. > 2007-11-28 20:53:45.046 NOTICE: APPLYING LOG RECORD(S): start. > 2007-11-28 20:53:45.245 DEBUG: getMaxMinTimestamp(): Xid > [71776538...71842194] (input) > 2007-11-28 20:53:45.392 DEBUG: getMaxMinTimestamp(): Timestamp > [2007-11-28 20:50:04.853027...2007-11-28 20:50:04.853027] (result) > 2007-11-28 20:53:45.392 DEBUG: openLogRecords(): xid=[71776538...71842194] > 2007-11-28 20:53:46.241 DEBUG: # of log records = 65460 > org.postgresforest.tool.recovery.RecoveryException: applyLogRecord() > failed. - /* 71776540/2007-11-28 20:50:04.853027 */ INSERT INTO > test_table4(measure,login_id,ph_id,chs,aia_v1,conv_v1,aia_v2,conv_v2,rc,rc_ms,updt,correct,v_exe) > values ('2006-05-15 02:00:00','testsah28 ','testsah28 ','1 > ',null,'0',null,null,'2006-05-15 02:00:00','0','2006-05-15 > 02:00:00','0','0') > at org.postgresforest.tool.recovery.RecoveryManager.applyLogRecord(Unknown > Source) > at org.postgresforest.tool.recovery.ForestRecovery.applyAllRecords(Unknown > Source) > at org.postgresforest.tool.recovery.ForestRecovery.RecoveryPhase1(Unknown > Source) > at org.postgresforest.tool.recovery.ForestRecovery.main(Unknown Source) > $ > > また、障害インスタンス（オンラインリカバリ実行インスタンス）のサーバログには > 以下のようなメッセージが出力されていました。 > > LOG: unexpected EOF on client connection > ERROR: duplicate key violates unique constraint "test_table4_pkey" > STATEMENT: /* 71776540/2007-11-28 20:50:04.853027 */ INSERT INTO > test_table4(measure,login_id,ph_id,chs,aia_v1,conv_v1,aia_v2,conv_v2,rc,rc_ms,updt,correct,v_exe) > values ('2006-05-15 02:00:00','testsah28 ','testsah28 ','1 > ',null,'0',n > ull,null,'2006-05-15 02:00:00','0','2006-05-15 02:00:00','0','0') > LOG: unexpected EOF on client connection > LOG: unexpected EOF on client connection > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users > > From nagatsumas ＠ nttdata.co.jp Tue Dec 18 10:52:44 2007 From: nagatsumas ＠ nttdata.co.jp (Satoshi.Nagatsuma) Date: Tue, 18 Dec 2007 10:52:44 +0900 Subject: [postgresforest-users 101] Re: =?iso-2022-jp?b?GyRCJUchPCU/Nz9AKThCO3Y5YBsoQg==?= In-Reply-To: <1197445798881114000037ef@ns.n-tec-web.jp> References: <1197445798881114000037ef@ns.n-tec-web.jp> Message-ID: <476727EC.30501@nttdata.co.jp> 長妻です。 > 各テーブルのデータ型に制限はありますでしょうか。 create table 以外の特殊なDDLが必要になるようなデータ型は使用できません。 例えば複合型のようなものですね。 また、Blobについてですが、BYTEA型であれば使用できるはずです。 （PreparedStatementのsetBytesやResultSetのgetBytesは動作します） lo_*** 関連の関数を使ってのBlobに関しては、恐らく使用できません。 というのも、そもそもForestの仕様として関数がどのPostgreSQLサーバで 実行されるかは、SQLが参照系なのか更新系なのか、あるいは パーティションモードかどうか、などの状況によって変わってしまうためです。 > また使用可能データ型の一覧等の資料はありますでしょうか。 今のところマニュアルに載せているもの以外では特にそういった 資料はありません。その辺充実させるつもりではいるのですが、 なかなか整備が追いついていない状況です・・。 堀川 創一朗 さんは書きました: > いつもお世話になっております。 > > PostgresForestの利用を検討しているものです。 > > PostgresForestの制限事項について確認させて下さい。 > > 既存のテーブル構造をPostgresForest環境へ以降することを考えていますが > 各テーブルのデータ型に制限はありますでしょうか。 > > SourceForgeに公開されているマニュアルによりますとSerial型は保障外と > ありますが、Blob型等のラージオブジェクトの使用は可能でしょうか。 > > また使用可能データ型の一覧等の資料はありますでしょうか。 > > ご教示ください。 > > > ------------------------------------------------- > エヌシーエステクノロジー株式会社 第一システム部 > 堀川　創一朗 > > ◆TEL：06-6444-1002 > ◇URL：http://www.n-tec.co.jp/ > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users > > From kobari ＠ irvinesystems.co.jp Wed Dec 19 07:08:31 2007 From: kobari ＠ irvinesystems.co.jp (Yasunaga Kobari) Date: Wed, 19 Dec 2007 07:08:31 +0900 (JST) Subject: [postgresforest-users 102] =?iso-2022-jp?b?IBskQkxkJCQ5ZyRvJDsbKEIgU1FMPSAgICAgP0lTTy0yMDIy?= =?iso-2022-jp?b?LUpQP0I/R3lSQ1NqZ2tUa1E1SkRVa1N5UkVKQ1FrUmhzb1FnPT0/PQ==?= Message-ID: <1067.61.26.240.83.1198015711.squirrel@webmail.irvinesystems.co.jp> 小針です 2台で冗長化(GSCも冗長化しています)しているForestが縮退運転 になりました。切り離しログをみると、PrepareStatementにて 非常に長いSELECT文(長さおよそ1.8MB)が、I/Oエラーになってい ました。 MSG | STATUS An I/O error occured while sending to the backend. | 08006 Forest JDBCで問い合わせSQL文の長さ制限によって、上記現象が 発生することがあるでしょうか？ よろしくお願いいたします。 From ryo-kameoka ＠ k9.dion.ne.jp Fri Dec 21 12:13:27 2007 From: ryo-kameoka ＠ k9.dion.ne.jp (ryo-kameoka ＠ k9.dion.ne.jp) Date: Fri, 21 Dec 2007 12:13:27 +0900 Subject: [postgresforest-users 103] =?iso-2022-jp?b?UG9zdGdyZXNGb3Jlc3QgGyRCJEckTkZiSXRGMDpuJEsbKEI=?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= Message-ID: <1198206807.23800@125.29.8.221.DIONWebMail> お世話になります。亀岡と申します。 PostgresForestでの内部動作について質問させてください。 [環境] 　・PostgresForest Ver4.0.2 　・PostgreSQL Ver8.1.10 　・RHEL 4 update 6 　・DBサーバ台数：3台 ■■ 生存確認について 　▼インスタンスとして登録されたサーバ（今回の場合3台）について 　　1) お互いはどのように生存確認をしているのでしょうか。 　　　　# MSCSでいうハートビート信号のようなものがあるのでしょうか。 　　2) 上記に関係し、インスタンスStatusが「稼働中」から「障害中」に 　　　 変更されるのは、どのようなトリガー、タイミングになるのでしょうか。 ■■ GSCについて 　▼初期化（〜/forestadm 〜 -i）にてGSCが作成されますが、 　　1) GSCを持っているサーバが死んだ場合、どのような動作になるのでしょうか。 　　　 単純に、DBへの接続・参照等ができなくなるという認識で宜しいのでしょうか。 　　2) GSCを複数サーバに配置している場合、どのようなタイミングで 　　　 同期が行われるのでしょうか。 　　　　# ある一定期間での同期が行われているのか、 　　　　# もしくはGSCに対して変更があった場合に同期が行われるのか 　　3) GSCのバックアップ・リストアは通常のPostgreSQL DBとして 　　　 行なって問題ないのでしょうか。 　　　 また、推奨されるようなリストアの手順があればご教授ください。 　　　　# 個人的なイメージですが、ADのFSMOのようなものだと思っておりますので。。。 　以上、ご確認の程宜しくお願い致します。 ----- From : Ryo.Kameoka Mail : ryo-kameoka ＠ k9.dion.ne.jp From nagatsumas ＠ nttdata.co.jp Tue Dec 25 19:27:53 2007 From: nagatsumas ＠ nttdata.co.jp (Satoshi.Nagatsuma) Date: Tue, 25 Dec 2007 19:27:53 +0900 Subject: [postgresforest-users 104] Re: =?iso-2022-jp?b?GyRCTGQkJDlnJG8kOxsoQiBTUUw9ICAgICA/SVNPLTIw?= =?iso-2022-jp?b?MjItSlA/Qj9HeVJDU2pna1RrUTVKRFVrU3lSRUpDUWtSaHNvUWc9PT89?= In-Reply-To: <1067.61.26.240.83.1198015711.squirrel@webmail.irvinesystems.co.jp> References: <1067.61.26.240.83.1198015711.squirrel@webmail.irvinesystems.co.jp> Message-ID: <4770DB29.5090304@nttdata.co.jp> 長妻です。 Forestでは特にクエリの長さなどで制限は設けていません。 brokenlogを見ると、何らかの原因でバックエンド側から 処理を拒否されているように見えますね・・・。 ちなみにSELECT文で1.8MBのSQLというのは、具体的には どんなＳＱＬになるんでしょうか？ Yasunaga Kobari さんは書きました: > > 小針です > > 2台で冗長化(GSCも冗長化しています)しているForestが縮退運転 > になりました。切り離しログをみると、PrepareStatementにて > 非常に長いSELECT文(長さおよそ1.8MB)が、I/Oエラーになってい > ました。 > > MSG | STATUS > An I/O error occured while sending to the backend. | 08006 > > Forest JDBCで問い合わせSQL文の長さ制限によって、上記現象が > 発生することがあるでしょうか？ > > よろしくお願いいたします。 > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users > > From nagatsumas ＠ nttdata.co.jp Tue Dec 25 19:29:24 2007 From: nagatsumas ＠ nttdata.co.jp (Satoshi.Nagatsuma) Date: Tue, 25 Dec 2007 19:29:24 +0900 Subject: [postgresforest-users 105] Re: =?iso-2022-jp?b?UG9zdGdyZXNGb3Jlc3QgGyRCJEckTkZiSXRGMDpuGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <1198206807.23800@125.29.8.221.DIONWebMail> References: <1198206807.23800@125.29.8.221.DIONWebMail> Message-ID: <4770DB84.6000300@nttdata.co.jp> 長妻です。 > 　　1) お互いはどのように生存確認をしているのでしょうか。 > 　　2) 上記に関係し、インスタンスStatusが「稼働中」から「障害中」に > 　　　 変更されるのは、どのようなトリガー、タイミングになるのでしょうか。 PostgresForestの実体は、JDBCドライバです。 JDBCドライバが各PostgreSQLサーバにアクセスをした際に それぞれのサーバが生きているか、死んでいるかを確認します。 死んでいれば、その時点で死んだサーバのステータスを 「障害中」に変更することになります。 ですので、サーバ間でお互いに生存確認をするのではなく JAVAアプリケーションがアクセスした際に、生きているか どうかで判断する、ということになります。 > 　　2) GSCを複数サーバに配置している場合、どのようなタイミングで > 　　　 同期が行われるのでしょうか。 基本的にGSCはそれほど頻繁に書き換わるものではありません。 書き換わるタイミングとしては、障害が発生した場合や、 forestadmという専用ツールでDDLを流すときなどになります。 障害中に書き換わる際にはJDBCドライバが、またDDLを流す際は forestadmというツールが、全てのGSCに同時に書き込みを行うことで 同期した状態を保っています。 > 　　1) GSCを持っているサーバが死んだ場合、どのような動作になるのでしょうか。 > 　　　 単純に、DBへの接続・参照等ができなくなるという認識で宜しいのでしょうか。 > 　　3) GSCのバックアップ・リストアは通常のPostgreSQL DBとして > 　　　 行なって問題ないのでしょうか。 これら２つに関してはそのとおりで問題ありません。 ryo-kameoka ＠ k9.dion.ne.jp さんは書きました: > お世話になります。亀岡と申します。 > > PostgresForestでの内部動作について質問させてください。 > > > [環境] > 　・PostgresForest Ver4.0.2 > 　・PostgreSQL Ver8.1.10 > 　・RHEL 4 update 6 > 　・DBサーバ台数：3台 > > > ■■ 生存確認について > 　▼インスタンスとして登録されたサーバ（今回の場合3台）について > 　　1) お互いはどのように生存確認をしているのでしょうか。 > 　　　　# MSCSでいうハートビート信号のようなものがあるのでしょうか。 > > 　　2) 上記に関係し、インスタンスStatusが「稼働中」から「障害中」に > 　　　 変更されるのは、どのようなトリガー、タイミングになるのでしょうか。 > > > ■■ GSCについて > 　▼初期化（〜/forestadm 〜 -i）にてGSCが作成されますが、 > 　　1) GSCを持っているサーバが死んだ場合、どのような動作になるのでしょうか。 > 　　　 単純に、DBへの接続・参照等ができなくなるという認識で宜しいのでしょうか。 > > 　　2) GSCを複数サーバに配置している場合、どのようなタイミングで > 　　　 同期が行われるのでしょうか。 > 　　　　# ある一定期間での同期が行われているのか、 > 　　　　# もしくはGSCに対して変更があった場合に同期が行われるのか > > 　　3) GSCのバックアップ・リストアは通常のPostgreSQL DBとして > 　　　 行なって問題ないのでしょうか。 > 　　　 また、推奨されるようなリストアの手順があればご教授ください。 > 　　　　# 個人的なイメージですが、ADのFSMOのようなものだと思っておりますので。。。 > > > 　以上、ご確認の程宜しくお願い致します。 > > ----- > From : Ryo.Kameoka > Mail : ryo-kameoka ＠ k9.dion.ne.jp > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users > > From kobari ＠ irvinesystems.co.jp Wed Dec 26 07:56:23 2007 From: kobari ＠ irvinesystems.co.jp (Yasunaga Kobari) Date: Wed, 26 Dec 2007 07:56:23 +0900 (JST) Subject: [postgresforest-users 106] Re: =?iso-2022-jp?b?GyRCTGQkJDlnJG8kOxsoQiBTUUw9ICAgICA/SVNPLTIw?= =?iso-2022-jp?b?MjItSlA/Qj9HeVJDU2pna1RrUTVKRFVrU3lSRUpDUWtSaHNvUWc9PT89?= In-Reply-To: <4770DB29.5090304@nttdata.co.jp> References: <1067.61.26.240.83.1198015711.squirrel@webmail.irvinesystems.co.jp> <4770DB29.5090304@nttdata.co.jp> Message-ID: <1079.61.26.240.83.1198623383.squirrel@webmail.irvinesystems.co.jp> 長妻様 回答ありがとうございます。 > Forestでは特にクエリの長さなどで制限は設けていません。 > brokenlogを見ると、何らかの原因でバックエンド側から > 処理を拒否されているように見えますね・・・。 PostgreSQLあるいは、PostgreSQLのオリジナルのJDBCに 制限があるのでしょうか？ > ちなみにSELECT文で1.8MBのSQLというのは、具体的には > どんなＳＱＬになるんでしょうか？ SQL文を自動生成する処理で、Where節に繰り返し 同じパラメータが設定し、Where節が非常に大きい SQLを実行しました。 小針 > > Yasunaga Kobari さんは書きました: >> >> 小針です >> >> 2台で冗長化(GSCも冗長化しています)しているForestが縮退運転 >> になりました。切り離しログをみると、PrepareStatementにて >> 非常に長いSELECT文(長さおよそ1.8MB)が、I/Oエラーになってい >> ました。 >> >> MSG | STATUS >> An I/O error occured while sending to the backend. | 08006 >> >> Forest JDBCで問い合わせSQL文の長さ制限によって、上記現象が >> 発生することがあるでしょうか？ >> >> よろしくお願いいたします。 >> >> _______________________________________________ >> postgresforest-users mailing list >> postgresforest-users ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users >> >> > > _______________________________________________ > postgresforest-users mailing list > postgresforest-users ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/postgresforest-users >