phpPgAdminにログインできないときの解決法
phpで書かれたWebベースのPostgreSQL管理ツール、phpPgAdminのレスキューtipsです。 「phpPgAdmin :: Web Based PostgreSQL Administration Toolで、ちゃんと設置したはずなのにログインできない！」 というときのために、検索用の覚え書き。 それらをWEBブラウザ上で操作できるようにするPHPプログラムが、phpMyAdminとphpPgAdmin。 そのうち、phpPgAdminはPostgreSQL用のそれ。phpPgAdminはphpMyAdminよりもインストールでハマる可能性が高いと思います。 以下、「ログインできない！」と焦ったときのチェックポイント。 １．そのユーザにパスワードはあるか？ 初期状態では、パスワードのないユーザではログインできません。phpPgAdminの設定を編集するか、ユーザにパスワードを
PostgreSQLを使っている人が使いたい外部ツール | 独り言v6
前作 PostgreSQLを本当に高速化したい人のための10のポイント が結構受けたようなのと、外部ツールの話が書ききれなかったので次回作を。まあこっちは受けないと思うが、ついでに備忘録をかねて。内容としては「RDBMSだけ使ってもどうしようもないよね」というのは多い。しかし残念ながらL.starは、PostgreSQL本体に比べてこの種のツールの組み合わせについて精通しているとはいいがたい。なので、「PostgreSQLとしては、こんな部分は外部ツールに任せたいよね！」という思いをまとめるように書いてみた。 外部キャッシュ 最近のRDBMSはとても早くて、シンプルなselect * from table where id=? ぐらいだと、10000tps位平然とこなしちゃう。このくらい早いと、web server数台分ぐらいのバックエンドになれるので、それで十分ではないかすら思ってしまう
Synchronous Log Shipping Replication: Project Home Page
ossc_pg_replication は PostgreSQL 向けの高可用ソリューションです。 ossc_pg_replication プロジェクトは NTT OSS センタから PostgreSQL のコミュニティへ貢献するものとして pgFoundry に登録されているプロジェクトの一つです。 pgFoundry のページはこちらです: http://pgfoundry.org/projects/syncreplicator ここでダウンロード、 ドキュメントの入手、バグレポート、メーリングリストの閲覧・購読などが行えます。 インストールと利用 ossc_pg_replication は 利用マニュアル v1.1.0 を参考にインストール・利用してください。 ossc_pg_replication の RPM や、設定ファイルのテンプレートは pgFoundry から ダウンロー
PostgreSQL FAQ in Japanese
PostgreSQL(ポストグレス・キュー・エル)についてよくある質問とその解答(FAQ) 原文最終更新日: Wed Jun 25 23:54:14 EDT 2008 現在の維持管理者: Bruce Momjian (bruce@momjian.us) Maintainer of Japanese Translation: Jun Kuwamura (juk at postgresql.jp) この文書の最新版は http://www.postgresql.org/docs/faqs.FAQ.html で見ることができます。 プラットホームに特有の質問については: http://www.postgresql.org/docs/faq/ に解答があります。 (以下、訳者による注釈を [訳注： と ] とで囲んで記します。) [訳注： 日本語版のFAQは、 http://www.postg
NTT OSSセンタ ＞ OSSセンタの取り組み ＞ 研究開発 ＞ PostgreSQL
NTT OSSセンタでは、OSSデータベースソフトウェアであるPostgreSQLをターゲットに、エンタープライズ適用にとって必要不可欠な性能、可用性向上の研究・開発活動を積極的に行っております。同時に、周辺機能の充実、ユーザー利便性の向上なども視野に入れ、様々の取り組みを実施しております。 ■性能向上に対する取り組み →PostgreSQL8.3性能安定性改善 PostgreSQL8.3にて、性能安定化の処理の自動化開発を行いました。これまで複雑なチューニングが不要になり、運用設計の手間が大幅に軽減されます。 従来は、VACUUM※1と CHECKPOINTのチューニングには手間がかかり、更新で生じるガベージを回収するために、テーブルごとに適切な頻度での VACUUM 処理が必要でした。また、CHECKPOINT の際に I/O が集中しないよう、書き出しプロセスを負荷に応じて調
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
ホーム | Let's POSTGRES
メインコンテンツに移動 お知らせ Let’s Postgres 運営管理についてのお知らせ コンテンツメニュー 導入検討 と 入門 インストール 運用管理 チューニング 新機能: 16 / 15/ 14 / 13 / 12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 トラブルシュート サポートとFAQ 事例紹介 イベントレポート リンク集 レプリケーション / クラスタ構成 XML / PostGIS / 拡張モジュール パーティショニング / テキスト検索 Window関数 / 再帰SQL / 外部データ連携 文書: 15 / 14 / 13 / 12 / 11 / 10 / 9.6 / 9.5 Let's PostgreSQL は特定非営利活動法人日本PostgreSQLユーザ会が運営しています。 RSS feed
[メモ] PostgreSQL+pgpool-II+heartbeat でクラスタリング／中編 | Ikeda->Weblog();
さて。前編からかな～～～り時間が経ってしまいました。 ということで今回は実際のインストールから設定内容をメモっておきたいと思います。 用意したもの DBサーバ2台(検証環境：Fedora6(古) 実機：RHEL3(こっちも古)) PostgreSQL(都合により 7.4.x) pgpool-II 2.1 pgpool-ha 1.1.0 heartbeat 2.1.3 libnet 当初はRPMでインストールしていましたが、最新バージョンにしたかったためソースからビルドすることにしました。設定ファイルやバイナリの場所は(個人的趣味により)基本的に /usr/local 以下としています。RPMインストールされる方や prefix を変更した場合は適宜読み替えてください。 インストール。 ということで、まずはガンガンインストールします。手順としては基本的に tarball解凍→ configu
[メモ][Linux] PostgreSQL pgpool-II heartbeat でクラスタリング／前編
仕事でPostgreSQLデータベースサーバの冗長化について調査と実験を行っていたんですが、昨日やっと設定が仕上がりました。忘れないようにメモっときますね(メモの割に長い。。)。 某ケーブルテレビ局のWebサーバ群なんですが、導入時から ファイアウォール(FW)→ロードバランサ(LB)→サーバ群 という経路は冗長化構成にしていました。しかし、データベース(DB)サーバのみ1台で、ここがシングルポイント(冗長化されていない個所)だったんですね。ケーブルテレビ局のWebサイトということで、DBには重要なデータも蓄積されます(問合せやプレゼントの応募などの個人情報とかですね)。 今回、このデータの損失を最大限防ぎ、なおかつシステム全体のダウンを最小限に抑えよ、とのお達しがお代官様上司より下りました。 要件としてはこんな感じ。 データの損失を防ぐ → レプリケーション DBサーバダウンによるWeb
![[メモ][Linux] PostgreSQL pgpool-II heartbeat でクラスタリング／前編](https://cdn-ak-scissors.b.st-hatena.com/image/square/a88c58092b9ab9df8ff5ff39e18538050e4f65a1/height=288;version=1;width=512/https%3A%2F%2Fblog.toor.jp%2Fwp-content%2Fuploads%2F2008%2F07%2F03%2F.thumbs%2F.idea_01.png)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSD based storage tuning for databases
ProGains Foundry | Great Supplements, Great Results
PostgreSQLとMySQ タグ表 大阪演劇情報センター + 未知座小劇場
MOVION.net » PostgreSQL
データベースエラー
heartbeatとDRBDとPostgreSQLでデータベースのクラスタを構築する