ログ解析にパーティショニングを利用してみよう | Let's POSTGRES
Hitoshi Harada ここまでで一通り分析を終えました。ある時点での分析を行うことももちろんのこと、継続的にログを分析していき結果を比較していきたいものです。今回のデータは6日ばかりを対象にしているためデータサイズは大きくありませんでしたが、1ヶ月、1年と経過するにつれてサイズが増大します。ここでは、分析を継続していくために必要なテーブルパーティショニング（分割）の技術についてご紹介します。パーティショニングについてはこちらでも紹介しています。併せてお読み下さい。 PostgreSQLにおけるパーティショニング 9.0 現在、PostgreSQLにおけるパーティショニング機能とは、単一ノードにおける水平分割です。つまり、1マシン上において、行を選り分けることでテーブルを分割します。世の中のRDBMSには垂直分割（列による選り分け）をサポートしたり複数ノード（複数のマシン上にテーブル
PostgreSQLのトラブルシュートとチューニング | Let's POSTGRES
NTT オープンソースソフトウェアセンタ 笠原 辰仁 この記事は、gihyo.jp & Let's Postgres 連動企画「今こそ！PostgreSQL」の第6回記事です。第6回目は、PostgreSQLのエラーメッセージや内部情報を見て、発生している問題の特定とその対策となるチューニングを紹介します。なお、トラブルの発生・予兆を適切に捕捉するためにも、ログの設定や稼動統計情報の監視をしておきましょう。 エラーメッセージについて トラブルと対策の前にエラーメッセージのレベルについて説明しておきます。PostgreSQLは複数のエラーレベルを影響範囲や深刻度によって使い分けています。エラーレベルそれぞれの解釈の仕方を下記の表にまとめてみました。 データベース管理者は、深刻な状況である PANIC と、性能情報を含む LOG レベルのメッセージに注意しましょう。一方、アプリケーション開発者
PostGISのインストール | Let's Postgres
農業・食品産業技術総合研究機構 近畿中国四国農業研究センター 寺元 郁博 はじめに 今回は PostGIS のインストール方法と、インストールが適正に行われたかをチェックする方法について説明します。 インストール方法には色々ありますが、今回は Windows 用の PostgreSQL インストーラに付属しているスタックビルダから入れる方法と、ソースからインストールする方法を紹介します。 スタックビルダを使ったインストール まず、PostgreSQL の本家 FTP サイトからインストーラをダウンロードします。 本記事では、PostgreSQL 8.4 を例にしています。 もし PostgreSQL がインストールされていなければ、こちらの記事を参考に PostgreSQL 本体をインストールしておきましょう。 また、pgAdmin III を入れておくと、データの操作や確認が簡単にできま
pg_upgrade | Let's POSTGRES
NTT オープンソースソフトウェアセンタ 笠原 辰仁 はじめに PostgreSQLでは、定期的なバージョンアップが行われます。バージョンアップには2種類あり、バージョン名 (x.y.z) の x または y が変化するメジャーリリース (8.3 → 8.4) と、z が変化するマイナーリリース (8.3.6 → 8.3.7) です。メジャーバージョンがアップするとDBクラスタの互換性がなくなるため、pg_dump等によるダンプを行い、新版のDBクラスタにデータをリストアする処理が必要です。 このダンプの取得とリストアは、非常に大きなデータを持つシステムでは長時間かかるため厄介でした。この作業が面倒で、古いバージョンを使い続けている方も多いのではないでしょうか？このようなダンプやリストア処理を不要にし、使用中のDBクラスタをそのまま新しいバージョンのPostgreSQLでも使い続けられるよ
接続トラブルの犯人を追う！ | Let's Postgres
NTT オープンソースソフトウェアセンタ 板垣 貴裕 PostgreSQL をきちんと設定をしたつもりでも、予想もしない原因で上手く動作しない場合があります。 本記事では、実際にユーザ会メーリングリストに投稿された事例を元に、PostgreSQLのトラブルシュートの手順を追ってみます。 接続トラブル時の調査の仕方に加えて、原因を見つけて貰いやすいトラブル報告の仕方を考えます。 状況 「接続エラー」という件名でメーリングリストにトラブルが報告されました。 この際、単にトラブルの有無だけでなく、使用環境と発生状況も記されていました。 使用環境は以下ということでした。 RHEL-5 (SELinux disabled) PostgreSQL-8.4.1 Python-3.1.1 py-postgresql-0.9.1 また、発生状況も正確に報告されました。 インストールしたマシンでは、psql
CentOS で PostgreSQL を使ってみよう！(3) | Let's POSTGRES
Appendix A: PostgreSQL のログ デフォルトでは、データベースクラスタの「pg_log」というディレクトリに、起動した日の曜日名のついたファイルを作ってログを書き込んでいます。 [root @server1 ~]# ls /var/lib/pgsql/data/pg_log/ postgresql-Tue.log しかし、「そのログがいつ記録されたか」という必須情報が、デフォルトの設定では出力されません。デフォルトでは、たとえば存在しないテーブルを参照する "SELECT * FROM abc;" という SQL を実行すると、エラーになりますが、 ERROR: relation "abc" does not exist というような形で記録され、エラー発生日時を確認できません。これを、記録日時が確認できるように設定してみましょう。 ★ 例：ログ記録日時の出力を設定する
目的別ガイド：チューニング編 | Let's POSTGRES
この記事では PostgreSQL のチューニングの概要を紹介します。まずは PostgreSQL のチューニングの勘所を掴んでください。各項目についての詳細はリンク先の記事で紹介していますので、そちらをご覧下さい。 チューニングの流れ PostgreSQLのチューニングとして必要な作業には何があるのでしょうか？ システムの開発状況やボトルネックによって必要な作業は変わってきますが、およそ以下の事項が挙げられます。 1. 情報収集と分析 チューニングを総当りで試すのは得策ではありません。まずは「ログ」や「稼動統計情報」を収集し、パフォーマンスのボトルネックを見つけることが先決です。特に良くあるトラブルは「トラブルシュートとチューニング」にも対処方法があります。 2. チューニングの実施 最も影響の大きなボトルネックから順にチューニングしていきます。 ボトルネックが解消されるまで、それ以外の
ログ解析にWindow関数を利用してみよう (遷移/離脱) | Let's Postgres
夏目 伸彦 前回までで、ログデータを扱いやすい形のテーブルにしました。今回は具体的に分析を進めていきます。分析すべき内容はニーズによって様々ですが、今回は詳細ページへの遷移率、及びその他の要因との関係を見ていくことにします。 遷移と離脱 遷移率は検索画面において大切な指標になります。検索において、ユーザーが結果を見て次の画面に遷移するか離脱するかは、検索結果の品質や操作性が優れているか否かにかかっていると言えるでしょう。従って遷移率は是非知っておきたい情報です。さらに遷移したユーザとそうでないユーザを特定したとき、「それぞれがどのぐらいサイトに滞在していたか」や「サーバからのレスポンス時間がどうだったか」を調べると、検索サイトの改善ポイントが見つかるのではないかと仮定します。 まとめると、遷移したユーザと離脱したユーザがどれだけいるのか、またユーザーの遷移と相関のある要因はないか、というこ
pgpool-II 3.2 の新機能 (3) Watchdog | Let's POSTGRES
watchdog とは 従来の pgpool-II で複数の PostgreSQL を連携させる場合、pgpool-II 自体、あるいは pgpool-II が動いているサーバや OS に障害が発生すると全体のサービスが停止してしまうため、ここが単一障害点（Single Point Of Failure: SPOF）となっていました。watchdog は、複数の pgpool-II の連携によってこの問題を解決し、pgpool-II の可用性を高める機能です。この機能により、サービスを提供する主系（アクティブ）の pgpool-II に障害が発生した場合でも、それを検知した待機系（スタンバイ）の pgpool-II が主系に取って代わって運用を継続する、すなわち pgpool-II のフェイルオーバが実現可能になりました。 今まではこのような構成をとるためには pgpool-HA というパ
Pgpool-II | Let's POSTGRES
メインコンテンツに移動 pgpool-II を使用した PostgreSQL の様々なクラスタ構成を紹介します。 ブックナビゲーション 入門向けの記事 技術的な記事 PostgreSQL13の新機能 PostgreSQL 8.4 の新機能 PostgreSQL 9.0 の新機能 PostgreSQL 9.1 の新機能 PostgreSQL 9.2 の新機能 PostgreSQL 9.3 の新機能 PostgreSQL 9.4の新機能 PostgreSQL 9.5の新機能 PostgreSQL 9.6の新機能 PostgreSQL10の新機能 PostgreSQL11の新機能 PostgreSQL12の新機能 PostgreSQL14の新機能 PostgreSQL15の新機能 PostgreSQL16の新機能 pgpool-II 3.2 の新機能 pgpool-II 3.3 の watchd
pgpool-II 3.2 の新機能 (2) オンメモリクエリキャッシュ | Let's POSTGRES
オンメモリクエリキャッシュとは？ 端的に言うと、SELECT の結果をメモリ上にキャッシュとして保存しておいて、 同じ SELECT がきたときに、即座にそのキャッシュした結果を返すしくみです。 キャッシュが存在する場合には、SELECT 文をパース（構文解析）したり実際に実行したりしなくなるので、非常に高速です。 以下は、この機能に関する文書です。 場合によっては、飛躍的な性能向上が見られます。 更新がそんなに頻繁でなく、apache など同じユーザが同じ SELECT をたくさん発行するようなシステムでは、 大きな効果が得られるかもしれません。 特に、それが重い SELECT である場合には、めざましい改善が期待できるでしょう。 以下はその一例のグラフで、横軸は pgbench -S -c 10 -T 10 を実行した回数、 縦軸は TPS（Transactions Per Secon
Pgpool-IIの簡単セットアップ機能を試してみよう | Let's POSTGRES
はじめに SRA OSS, Inc. 日本支社 石井 達夫 pgpool-IIは複数のPostgreSQLを使ったクラスタシステムを構築できるミドルウェアです。そこでpgpool-IIを実際の業務システムで動かすためには、通常、マシンを複数用意したり、それぞれにPostgreSQLをインストールすることが必要になります。それだけでなく、pgpool-II自体の設定ファイルや、フェイルオーバやオンラインリカバリのためのスクリプトも設定してあげないといけません。これらは結構敷居が高い要求で、「pgpool-IIがなんとなく良さそうなので試してみたい」と思ってもいる人も簡単には手が出せない原因となっていました。 pgpool_setupとは そこで今回ご紹介するのが、pgpool-II 3.3から同梱されるようになった「pgpool_setup」というツールです。pgpool_setupはコマン
pgpool-II 3.4の新機能 | Let's POSTGRES
SRA OSS, Inc. 日本支社 石井 達夫 はじめに 本記事は2014年のPostgreSQL Advent Calendar の 12/17 の記事です。2014年11月7日にリリースされた pgpool-II 3.4の新機能を紹介します。 pgpool-IIとは pgpool-IIは、複数のPostgreSQLを使ったクラスタシステムを構築できるミドルウェアです。pgpool-IIは、PostgreSQLクライアントと、複数のPostgreSQLの間に割り込む形でproxyのように動作します。既存のPostgreSQLアプリケーションを、ほとんど変更することなく利用することができます。 もっとも多いpgpool-IIの使い方としては、PostgreSQLを複数台使ったストリーミングレプリケーション構成によるクラスタの管理サーバとして使用するものです。以下のような機能が利用できます
ポイント・イン・タイム・リカバリ (PITR) | Let's POSTGRES
鈴木 幸市 オンライン・バックアップを利用して、データベースを故障直前の状態まで復旧させる手順を解説します。 オンライン・バックアップとポイント・イン・タイム・リカバリ (アーカイブ・リカバリ) を利用すると、pg_dump でのバックアップとは異なり、バックアップ時点ではなく、アーカイブログが残っている限り最新の状態までリカバリできるのが利点です。 6.3 オンライン・バックアップとアーカイブログを用いたリストア PostgreSQL 運転中に取得したベースバックアップとアーカイブログを使ってデータベースをリストアすることができます。 アーカイブログもベースバックアップも、PostgreSQL を運転しているサーバとは別な場所に保存できることが重要です。 アーカイブログとベースバックアップを安全な場所 (PostgreSQL を運転しているサーバとは別の場所) に保存しておくことで、サー
目的別ガイド：運用管理編 | Let's POSTGRES
本ページでは、PostgreSQLを運用していく上で必要な事柄を紹介します。「PostgreSQLの運用管理って何をしたら良いのだろう？」とお困りの方は、まず本ページでざっくりと運用の全体のイメージを掴んでみてください。各項目についてもっと掘り下げた情報は、リンク先の記事で紹介しています。 PostgreSQLの運用管理に必要なこと PostgreSQLの運用管理として必要な作業には何があるのでしょうか？運用要件によって必要な作業は変わってきますが、およそ以下の事項が挙げられます。 メンテナンス DBは、日々の運用により内部状態が変化していきます。常に一定のパフォーマンスを発揮するには、良い状態を保つためのメンテナンスが必要です。主に VACUUM や ANALYZE が該当します。 監視 異常を事前に察知する、もしくは発生後に原因を調査するために、DBやOSの状態を監視しておきます。適切
Microsoft PowerPoint - Explaining_Explain_ja.ppt
1 Explaining Explain PostgreSQL by Robert Treat (Inspired by Greg Sabino Mullane) PostgreSQL (2009-03-17 / 8.3 ) 2 Explain • Explain • • DML • • EXPLAIN ANALYZE 3 Explain Plan =# EXPLAIN SELECT * FROM pg_proc ORDER BY proname; QUERY PLAN ---------------------------------------------------- Sort (cost=181.55..185.92 rows=1747 width=322) Sort Key: proname -> Seq Scan on pg_proc (cost=0.00..87.47 row
論理バックアップ（pg_dump と pg_dumpall） | Let's POSTGRES
NTT オープンソースソフトウェアセンタ 鈴木 幸市 3. 論理バックアップとリストア 論理バックアップを行うツールは pg_dump 及び pg_dumpall です。 pg_dump は PostgreSQL データベースクラスタの各データベース単位にバックアップを行います。pg_dumpall はターゲットのデータベースクラスタに格納してある全データベースのバックアップを行います。 pg_dump も pg_dumpall も、バックアップデータはデータベースを復元するために必要な SQL 文で構成されます。 従って、pg_dump や pg_dumpall を使うと PostgreSQL データベースの内容を別なデータベースに移行したり、特定のテーブルだけをバックアップしたりすることが可能となります。 pg_dump, pg_dumpall を使うためには特別な用意はいりませんが、
PHPでのSQLインジェクション対策 - プレースホルダ編 | Let's POSTGRES
第四企画 坂井 潔 SQLインジェクションの脅威からシステムを守るために、プログラミング言語／スクリプトからSQLを発行するときには、パラメータを適切に処理しなくてはなりません。今回はプレースホルダ編と題し、SQLインジェクション対策として最も簡単で効果的な方法を、PHPで説明します。 SQLインジェクションとは？ まず「SQLインジェクション」とは何かおさらいしましょう。SQLインジェクションとは、アプリケーション（この場合はPHPスクリプト）に渡すパラメータの値を操作することで、元々は意図されていない処理をSQLとして実行させてしまうことです。 簡単な例をあげてみます。ユーザーから文字列「山田」が渡されたとき、以下のようなSELECT文を発行することにします。 SELECT * FROM users WHERE username LIKE '%山田太郎%'; ユーザーに入力された文字列
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
稼動統計情報を活用しよう(3) | Let's POSTGRES
HOTの活用 | Let's Postgres