不正にシャットダウンした場合、postgresql起動障害の解決(愚痴版)
2444 ワード
skylove
不正にシャットダウンした場合、postgresql起動障害の解決(愚痴版)
今日、ネットのシャットダウンは強制的にシャットダウンされました(ある同僚のしたこと...なぜlinux管理者ではない同僚がlinuxサーバーを操作する権利があるのかと聞くと、私はあなたにしか言えません--これは中国で、これは中国の大学です)
そして、直接的な結果はpostgresqlサービスが起動できないことです...私は10分近くかけてこのお尻を拭く問題を解決しました...
サービスpostgresql startで直接サービスを開始しようとしましたが、失敗しました.そしてtail/var/log/messageの結果は、start postgresql faileを簡単に教えてくれただけです....私は頼りにしています.これは言わないほうがいいです.(典型的なwindowsログスタイルは、完全に正しいのに何の役にも立たないニュースを教えてくれます)
それからgoogleに行って、キーワードpostgreql修復をキーワードとして検索して、n多結果を見つけましたが、私が望んでいるものはありません...うん、自分で何とかするしかないようだ.
suはpostgresアイデンティティに到達し、postmaster-Dデータベースを実行する....起動できませんが、今回postgerでエラーメッセージが表示されました.
うん、これで分かった...前回機械を止めた時、直接電源を切ったからだったのか...(かわいそうに...あのマシンのパスワードがある以上、rebootにログインしてみましょう...このコマンドは彼に書いたことがありますよ)ので、postgresql実行プロセスのpidファイルは削除されていません...再起動後、postgresqlサービスを起動すると、postgresqlがpidファイルの存在をクエリーしたため、サービスが起動したと思って、再ロードしないように自分を起動しなくなった...
原因が見つかった以上、そのpidファイルを直接削除します...あとでやってみると、やっぱり普通ですね...
このような悲劇の再発を防ぐために、私は/etc/rcしかありません.localに1本加える
rm -rf/var/lib/pgsql/data/postmaster.pid 2 >;/dev/null
postgresqlサービスを開始します...
この間、電気通信はネットワークを調整しているので、たまにインターネットができない場合やサーバーが接続できない場合がある.残念なことに、同僚はいつも電気通信を信用しすぎて、私のしたゲートウェイを信じないで、そこで愚かで何度もゲートウェイを再起動します...
今日の午後に行くと、同僚から「なぜ旧区のサーバーはすべて外部からアクセスできないのか」と聞かれるだろう.お愿いします、サーバーはすべて公网ipアドレスを使って、上级のゲートウェイは直接电信を指して、本日内にいかなるサーバーのネットの设置に対していかなる修正をしていないで、突然すべての外部は接続することができなくて、自然に电信のあちらの调整の间违いが招いたのです...どうして私の内部ネットワークnatのゲートウェイの問題ですか?まさかこの普通の配置のゲートウェイは他の同じ公网ipのサーバーを一绪にダウンしたり、外部からアクセスできなくなったりする威力がありますか??唯一の可能性のあるarp欺瞞とスロールーティング攻撃の問題を排除した(あなたがnatゲートウェイサーバーをオフにしても、他のサーバーは外部でもアクセスできないのではないか、natサーバーと一緒に、外部にアクセスできる--しかし外部にアクセスできない)、ここまで来ても、なぜ私のかわいそうなnatが何かよくできないのではないかと疑って、電信を疑わないのだろうか.電信はどうして間違いを犯すことができませんか.毎月たくさんのお金をあげたので、私の給料は低いですか.お金をあげると間違いないの?お金をもらったのは誰ですか.電気通信が本当にネットワークを維持する第一線の人員とは限らないし、その維持する人員が能力によって電気通信に入ったとは限らない.ネットのメンテナンスは文字资料の処理などではなく、レベルが足りないと原形が现れる...無知とは何ですか.問題を真剣に分析しないで、むやみに処理して腐った屋台を残しておくのは無知だ.
変換元:
http://bbs.chinaunix.net/archiver/tid-484595.html
不正にシャットダウンした場合、postgresql起動障害の解決(愚痴版)
今日、ネットのシャットダウンは強制的にシャットダウンされました(ある同僚のしたこと...なぜlinux管理者ではない同僚がlinuxサーバーを操作する権利があるのかと聞くと、私はあなたにしか言えません--これは中国で、これは中国の大学です)
そして、直接的な結果はpostgresqlサービスが起動できないことです...私は10分近くかけてこのお尻を拭く問題を解決しました...
サービスpostgresql startで直接サービスを開始しようとしましたが、失敗しました.そしてtail/var/log/messageの結果は、start postgresql faileを簡単に教えてくれただけです....私は頼りにしています.これは言わないほうがいいです.(典型的なwindowsログスタイルは、完全に正しいのに何の役にも立たないニュースを教えてくれます)
それからgoogleに行って、キーワードpostgreql修復をキーワードとして検索して、n多結果を見つけましたが、私が望んでいるものはありません...うん、自分で何とかするしかないようだ.
suはpostgresアイデンティティに到達し、postmaster-Dデータベースを実行する....起動できませんが、今回postgerでエラーメッセージが表示されました.
FATAL: pre-existing shared memory block (key 5432001, ID 0) is still in use
HINT: If you're sure there are no old server processes still running, remove the shared memory block with the command "ipcrm", or just delete the file "/var/lib/pgsql/data/postmaster.pid".
うん、これで分かった...前回機械を止めた時、直接電源を切ったからだったのか...(かわいそうに...あのマシンのパスワードがある以上、rebootにログインしてみましょう...このコマンドは彼に書いたことがありますよ)ので、postgresql実行プロセスのpidファイルは削除されていません...再起動後、postgresqlサービスを起動すると、postgresqlがpidファイルの存在をクエリーしたため、サービスが起動したと思って、再ロードしないように自分を起動しなくなった...
原因が見つかった以上、そのpidファイルを直接削除します...あとでやってみると、やっぱり普通ですね...
このような悲劇の再発を防ぐために、私は/etc/rcしかありません.localに1本加える
rm -rf/var/lib/pgsql/data/postmaster.pid 2 >;/dev/null
postgresqlサービスを開始します...
この間、電気通信はネットワークを調整しているので、たまにインターネットができない場合やサーバーが接続できない場合がある.残念なことに、同僚はいつも電気通信を信用しすぎて、私のしたゲートウェイを信じないで、そこで愚かで何度もゲートウェイを再起動します...
今日の午後に行くと、同僚から「なぜ旧区のサーバーはすべて外部からアクセスできないのか」と聞かれるだろう.お愿いします、サーバーはすべて公网ipアドレスを使って、上级のゲートウェイは直接电信を指して、本日内にいかなるサーバーのネットの设置に対していかなる修正をしていないで、突然すべての外部は接続することができなくて、自然に电信のあちらの调整の间违いが招いたのです...どうして私の内部ネットワークnatのゲートウェイの問題ですか?まさかこの普通の配置のゲートウェイは他の同じ公网ipのサーバーを一绪にダウンしたり、外部からアクセスできなくなったりする威力がありますか??唯一の可能性のあるarp欺瞞とスロールーティング攻撃の問題を排除した(あなたがnatゲートウェイサーバーをオフにしても、他のサーバーは外部でもアクセスできないのではないか、natサーバーと一緒に、外部にアクセスできる--しかし外部にアクセスできない)、ここまで来ても、なぜ私のかわいそうなnatが何かよくできないのではないかと疑って、電信を疑わないのだろうか.電信はどうして間違いを犯すことができませんか.毎月たくさんのお金をあげたので、私の給料は低いですか.お金をあげると間違いないの?お金をもらったのは誰ですか.電気通信が本当にネットワークを維持する第一線の人員とは限らないし、その維持する人員が能力によって電気通信に入ったとは限らない.ネットのメンテナンスは文字资料の処理などではなく、レベルが足りないと原形が现れる...無知とは何ですか.問題を真剣に分析しないで、むやみに処理して腐った屋台を残しておくのは無知だ.
変換元:
http://bbs.chinaunix.net/archiver/tid-484595.html