PHPのテクメモ

最近PostGIS関連の話題に触れる機会があった。前々から手をつけなくてはいけない、と思いつつ、データベースのこみいったこととか得意ではないので放置していたが少しがんばることにした。まずはローカルのWindowsマシンに新ストールするところからはじめた。

以前WindowsマシンにPostgreSQLをインストールしようとしたときに、pgAdminから接続できなかったりいろいろてこずった記憶があった（Windowsマシンには残骸が残っていた）。しかし今回はスムーズにインストールできた。まず最初に残骸を一式削除し、PostgreSQLのサイトから8.3系をダウンロードした。最新はPostgreSQL8.4だけど（公開ほやほや）、最新である必要もないので今回は8.3にしておいた。ダウンロードは以下のページから。

http://www.postgresql.jp/

すごく久々にPostgreSQLのサイトを見たけど、リニューアルされた感じ。わかりやすいかどうかといわれると、それはなんともいえないけれど、ダウンロードページへの導線がわかりやすくてよかったかも。

インストーラを起動し、適宜必要な項目を入力。メインのインストールが完了したら、アプリケーションスタックビルダなるユーティリティが起動した。ここからPostGISをインストールできるらしい。なんとも簡単になったものだ。しかしPostGISを選択してインストールを続行していると、「要求された操作には管理者特権が必要です」なんてメッセージが表示されてどうしてもインストールできない。

とりあえず悩むのも面倒だったので、メッセージ中に書かれているPostGISインストーラ（上記操作の中でダウンロードだけは完了している）を直接起動したらうまくインストールできた。この後pgAdminを起動し、PostgreSQLサーバにうまく接続できることを確認した。pgAdminから確認して、データベース「postgis」とか、PostGISのテンプレートとかができていることは確認できたからたぶん大丈夫なんだろう。興味本位でいろいろ見てみたら、関数がたくさん用意されているようだ（674個）。これがPostGISの本体に相当するものだろうか・・・。

さて、作業はここまででいったん終了。これからどうしようか・・・。途方にくれる。

お客さんに貸してるサーバのディスク容量が残りわずかになってしまった。原因はわかっている。PostgreSQLのメンテナンスが不十分だったからだ。サーバの中にはいくつかのPostgreSQLデータベースが稼動しているが、果たしてどれが原因なのか。どのデータベースがどれだけの容量を使用しているのか調べたのでメモ。

まずPostgreSQLのデータがあるディレクトリに移動する。RedHat系OSでは以下の場所に存在する。

/var/lib/pgsql/

おなじみ、設定ファイル等が設置されている場所だ。この中の奥の階層にデータは格納されている。

/var/lib/pgsql/data/base/

上記の中に入ると、数字だけで構成されたディレクトリが多数存在する。しかも多段の階層で。これだけでは意味がわからない。まずここで、直下の階層についてのみ容量をチェックする。

du –max-depth=1 -h

階層を一つ下って、人間が理解しやすい形式でデータを出力させる。これでひとまず、どのディレクトリがディスクを浪費しているのか把握できる。しかしこのディレクトリ名は何を意味しているのか。

どうやらこれはoidを意味しているらしい。そこでoidとデータベース名を関連付けることさえできれば、どのデータベースがどれだけ容量を使用しているか把握できることになる。それを把握するためのSQL文がコレ。

select datid,datname from pg_stat_database;

これでoidとデータベース名の関連付けができる。
さて、どのデータベースに問題があるのかはすぐにわかったが、どうやって処理しようか。それを現在考え中。頭の痛い課題だ。

とあるクライアントから「データベースのソート結果が変なんだけど」という連絡をいただいた。自分が構築したシステムではないので完全にお気楽モードで調べて差し上げることにした。データベースはPostgreSQL、プログラム言語はPHP。他人が作ったデータベースを触るのは基本的に嫌だが、それでも頼っていただける、というのはありがたい。ということで・・・。
まずはプログラムのバグを疑った。しかし、それらしい問題というのは見当たらない。SQL出力を確かめたり、取得したデータを確かめたり。しかしいずれも整合性が取れている（整合性が取れているにもかかわらず、データの並びがおかしいとはこれ如何に）。
データベースのダンプも預かっていたので、画面に出力させたSQLを自分の環境でも実行してみた。

ん？、ん？、ん？？？。

先方のサーバと自分のサーバで表示される順番が違う？？？。なぜ？？？。
バージョンもほとんど同じなのだからこんなことないはずなのに、と思ったら思いついた点がひとつ。ロケール（locale）の設定だ。データベースで日本語を使用する場合はロケール設定を無効（というかCを指定）にしなければいけない、とかなんとかいう設定があったはず。

で、現在の状態を調べるにはどうすればよいのか調べてみた。
pg_controldata /var/lib/pgsql/data/

このコマンドでいろいろわかる！。ちなみに引数ではデータの場所を指定する。結果として、表示される値のうち「LC_CTYPE:」の値が「C」ではなかった。どうやら、データベースの初期化をきっちりやっていないことが原因らしい。「忘れた」のか「知らなかった」のかわからないけど、クライアントにはいちおう状態を説明。どんな反応をされるのか・・・。少しクライアントがかわいそう。構築した業者さん・・・ハズレだったんだなぁ。

また久々にPostgreSQLを使う必要に迫られた。
まずユーザの追加・・・パスワードを聞いてくれるようにするのはどうするんだったか・・・。

createuser -P

ユーザpostgresになって、-Pオプションをつけてコマンドを実行。
これで使用したいユーザ名、パスワード、データベース追加の可否、ユーザ追加の可否を問われるので答えるだけでいい。

先日の大雨＆雷の影響で、我が家のサーバが落ちた。
今日まで気づかなかったのだが（普段使わないから当然わからないのだけれど）、データベースが動いてない！。データベースには請求処理関連の全データがはいっていて請求書が作れないし、決算が・・・（驚愕）。
しばし悩んだあと、バックアップがあることを思い出しだ（笑）。バックアップがあることはわかっていたけれど、新たにマシンを用意してインストール・復元する元気がなかったのでなんとか動くようにできないかと悩んでいただけだったのだが。
まずPostgreSQLのデータフォルダをきれいにして、データベースの初期化を実行（以下のコマンド）。

initdb –no-locale –encoding=EUC_JP -D /var/lib/pgsql/data

この状態でPostgreSQLが動くことを確認できた（ほっ）。
次にバックアップからの復元。実はつまんないことだけど、バックアップからの復元方法がわからなかった。だってpg_dumpall（データベース丸ごとバックアップ）から復元する機会なんてそうそうないですから・・・。検索してやっと見つけたよ。

psql template1 < data.dump

template1に対してレストアするのか・・・知らなかった。何はともあれ、これで復元完了。あと設定関連を以前のものに戻して無事復旧終了。つくづく「バックアップって必要なんだ」と思った瞬間であった。