12/03/06 00:24:37.48
顕正新聞 平成24年2月5日号「原発全廃特集号」
原発は日本を滅ぼす、即時全廃せよ
人のDNAを破壊、国土を居住不能にする
代替は天然ガス・コンバインドサイクルで十分
惨禍もたらすを知って推進するは犯罪
URLﾘﾝｸ(d.hatena.ne.jp)
806:NAME IS NULL
12/03/08 23:08:21.19 AaYThp7J
2000万件入っているテーブルAに行単位に動作するトリガーが付いています。
このトリガの中身は別テーブルBへのレコード追加処理となります。
で、テーブルAにDELETE文を発行するとレスポンスが返るまでに50秒かかります。
トリガを無効にするとレスポンスは1秒もかかりません。
トリガの中の処理を何も無しにしてもトリガが有効だとレスポンスはまた50秒でした。
この場合、どのような対処が必要でしょうか？
807:NAME IS NULL
12/03/09 09:25:53.99
トリガーを直すか外して自力でBへの処理を行う
808:NAME IS NULL
12/03/09 09:52:45.70
もっと高性能なPCに買い換える。
809:NAME IS NULL
12/03/09 12:28:38.76
>>807
トリガを空にしても遅くなるみたいだから前者は無理だろう
トリガの実行までの速度が件数に依存してるんだろうか。割と予想外
810:NAME IS NULL
12/03/10 00:04:35.57
delete文が1件deleteではなくて実は全件だったとか
811:NAME IS NULL
12/03/11 11:42:02.86
通常のDELETEとトリガあるときのDELETEの違いを
ソースおっかけて調べるとか
812:NAME IS NULL
12/03/11 22:43:21.98
試すのが一番かと。
813:NAME IS NULL
12/03/12 08:02:49.84 ExxOdv/p
関数定義読んでも
pg_start_backupの処理が何やってるのか明確にわからない
わかっている人いたら教えて頂けませんか
814:NAME IS NULL
12/03/16 03:30:07.86 6NdHTG36
9.xにしたら、bytea型に対するLIKE検索ができなくなった
815:NAME IS NULL
12/03/17 05:40:41.42
>>813
pg_start_backup以降に更新されたデータは
バックアップされない。直前の更新データは
バックアップされる。
少し前に簡単なテストをしたことがあるのだが、その記憶だけど。
テストしてみて、PITRバックアップのスタートポイントとしてマークする
イメージを持った。
816:NAME IS NULL
12/03/17 05:44:05.00
postgreSQLの管理とチューニングで参考本は何ですか？
817:NAME IS NULL
12/03/17 08:40:03.43
日本語でおｋ
818:NAME IS NULL
12/03/18 00:58:06.29
>>815 pg_start_backup以降に更新されたデータはバックアップされない。
はちょっと違う。どこまで復旧できるかはむしろ pg_stop_backup で決まる。
pg_stop_backup までにバックアップしたDBデータとアーカイブログを使って、
少なくとも pg_stop_backup 直後の状態までリストアできる。
それ以降は残りのアーカイブログ次第。
819:NAME IS NULL
12/03/18 07:06:28.41
>>818
あれ、そうだっけ？
手元にテストしたときの資料がないので、あいまいな記憶で
書いてしまいました。
818が本当ならば、pg_start_backup したときに書かれる
日時（どっかのテキストファイルに記録するよね）って、
何の意味があるんだろ。。。
pg_stop_backupの時点の日時を記録すべきだね。
820:NAME IS NULL
12/03/18 09:36:20.17
SSDをデータベースの記録装置にするのは危険ですか？
821:NAME IS NULL
12/03/18 17:57:23.14
>>820
ふつ～にやってる
822:NAME IS NULL
12/03/18 18:00:13.39
RAMDISKにデータベース置いてる
823:NAME IS NULL
12/03/18 21:53:50.55 zffLo6VO
>>815
レスありがとう。
ストリーミングレプリケーション勉強してて疑問に思ったんだ
マスタ側でpg_start_backupして
それをtarとかでまとめてスレーブ側のサーバーに転送して
pg_stop_backupする
でスレーブとして立ち上げる
こういう手順がネット上にいっぱい転がってて実際にそれで動いたんだけど
なんでpg_start_backupするのかとか意味がわかってないから
トラブル発生した時うろたえちゃうんだ
例えばマスタでpg_stop_backupする前にスレーブを起動すると
FATAL: the database system is starting upて出て起動できなくなるとか。
どっかに詳しい本とかないかなあ。
824:NAME IS NULL
12/03/21 23:12:00.28 Gb9w0WNu
ログにこのようなものがでるんだけれど
FATALのところがどういう意味のエラーなのかわからない。
Mar 21 21:32:58 AEEms-Ba52E-EASTdebugB postgres[22750]: [3-1] LOG: entering
standby mode
Mar 21 21:32:58 AEEms-Ba52E-EASTdebugB postgres[22750]: [4-1] LOG: redo
starts at 0/D8000020
Mar 21 21:32:58 AEEms-Ba52E-EASTdebugB postgres[22750]: [5-1] LOG: record
with zero length at 0/D80000B0
Mar 21 21:32:58 AEEms-Ba52E-EASTdebugB postgres[22750]: [6-1] LOG: trigger
file found: /home/postgres/data/trigger_file
Mar 21 21:32:58 AEEms-Ba52E-EASTdebugB postgres[22750]: [7-1] LOG: redo
done at 0/D8000058
Mar 21 21:32:58 AEEms-Ba52E-EASTdebugB postgres[22750]: [8-1] FATAL: WAL
ends before consistent recovery point
Mar 21 21:32:58 AEEms-Ba52E-EASTdebugB postgres[22662]: [2-1] LOG: startup
process (PID 22750) exited with exit code 1
Mar 21 21:32:58 AEEms-Ba52E-EASTdebugB postgres[22662]: [3-1] LOG:
terminating any other active server processes
825:NAME IS NULL
12/03/22 00:22:16.63
pg_stop_backup()しなかったんじゃないかとか書かれてるけど
URLﾘﾝｸ(archives.postgresql.org)