DB

2012.11.17

PostgreSQL全機能バイブル

PostgreSQL9.2対応。

それはさておき、ストリーミングレプリケーションに関する説明などもあり、運用面においてもそれなりに有用なのではないかと。

先日、同期レプリケーションを行っているPostgreSQLで、スレーブ側の端末でトラブルが発生してしまったわけでして。ディスク障害やメモリ障害、CPU障害といった致命的な内容ではなさそう(端末およびPostgreSQLは稼働し続けていたので)なのですが、かといって放置するわけにも行かず、スレーブ端末をシャットダウンする必要がでてきてしまいました。単純にスレーブを停止させると、マスター側のトランザクションが止まってしまうのは知っていたので、さてさて、どうしたものか?

同期レプリケーションの設定方法や、マスターに障害が発生したときの資料はWebでも結構見つかるのですが、スレーブ側に障害が発生したときの資料ってのがなかなか見当たらず・・・で、いろいろと調べてたどり着いたのが、この書籍でした(笑)。
PostgreSQL 9.1 - 同期レプリケーションの障害対応 のところで、この書籍が紹介されていたので。

まずは、テスト機で検証してみるかな・・・。


| | Comments (0) | TrackBack (0)

2012.05.30

I/Oバリア機能

最近のLinuxで有効になっているI/Oバリア機能と、RDBへの影響

I/Oバリア機能ってのは初めて知りました。RHEL6でデフォルトで有効なのであれば、CentOS6でもデフォルトで有効なんでしょうかね?

マウント時の設定で無効化することができるとのことなので、データベースファイルを保管するディレクトリーを別パーティションとして作成しておいてマウントするようにする(システム領域は有効のままとする)、ってのがいいのかもしれませんね。

※というか、データベースサイズが巨大化しすぎてシステム領域に影響を及ぼさないためにも別パーティションとしておくべきですね。

| | Comments (0) | TrackBack (0)

2012.05.29

PostgreSQL9.1.3のストリーミングレプリケーション

PostgreSQL9.1.3で、ストリーミングレプリケーションの環境構築・・・一応、動作しているように思える環境は構築できましたが、果たしてこれでいいのやら?

気になっているのは、「WALアーカイブを行うか否か?」というところでしょうか。

ストリーミング・レプリケーションの構築では、スタンバイDBの反映処理が追いつかない場合や長時間の停止後に再開した場合などに、マスタDBに追いつけることが利点、とありますが・・・そもそも、反映処理が追いつかなかったり、長時間の停止がある時点で「ホットスタンバイサーバ」と呼んで良いのかどうか、微妙な気がしないでもないです。

もちろん、「万全を期す」という観点から行くと、(PITRにも利用することなどから)WALアーカイブは行うべき何でしょうけど。ただ、設定の仕方がイマイチよくわからない・・・。archive_commandの方はわかったのですが、restore_commandは単にファイルのコピー処理だけで良い?(ウォームスタンバイの時はpg_standbyを実行するケースもあったようですが)

#「同期モード」だと、スタンバイが落ちた場合にプライマリのトランザクションも止まってしまうというのが悩ましいですね・・・。

| | Comments (0) | TrackBack (0)

2011.02.16

DB処理に特化したサーバー

日本IBM、DB処理に特化したブレードサーバー事前構成モデル

ストレージとして、320GBの半導体ボードを2枚搭載、ですか。半導体ってことはミラーなどではなく、単純に640GB×1のストレージとして扱うような感じでしょうかね?(RAID0に近い使い方?)

x86サーバーってことは、Windows/Linux + DB2での使用を想定した構成かな(ただ、DB2の場合、搭載CPUなどからすると、ライセンス費用がすごいことになりそう・・・)。大量の更新系処理が行われるようなアプリの場合、効果ありそうですね。

| | Comments (0) | TrackBack (0)

2010.04.08

DB2のアクティブログ

DB2のアクティブログの書き込みタイミングは以下の通りとのこと。
1.コミットを実行した
2.ログバッファーがいっぱいになった

しかしながら、何らかの更新を行っても、アクティブログ・ファイルのタイムスタンプは特に変化なし(環境はWindows)。「??」ってことで、以下の方法で、アクティブログ・ファイルが更新されていることを確認。

1.SQL実行前のアクティブログ・ファイルを別フォルダにコピー⇒ファイル1
2.オートコミットを無効にした状態で更新処理を実行
3.この状態のアクティブログ・ファイルを別フォルダにコピー(上書きしてしまわないように注意)⇒ファイル2
4.コミット実行
5.この状態のアクティブログ・ファイルを別フォルダにコピー(上書きしてしまわないように注意)⇒ファイル3

Windowsに標準で入っているfc.exeをバイナリ比較モード(/bオプション)で実行し、ファイル1とファイル2、ファイル2とファイル3を比較。

【結果】
ファイル1とファイル2⇒一致
ファイル2とファイル3⇒何らかの差異あり

・・・ってことで、見た目のタイムスタンプは更新されないものの、ファイルそのものはきちんと更新されているみたいですね。

| | Comments (1) | TrackBack (0)

2009.12.11

新標準PostgreSQL

入門書というだけあり、データベースそのものの基礎やSQLの文法等に関しても軽く触れられています。ただ、それだけではなく、PostgreSQLを実際に運用する場合によく行われるであろう設定や、状態のチェックなどに関しても触れられており、

・これからPostgreSQLを使った開発を行う
・とりあえずPostgreSQLを使ったシステムの開発を行っている
・とりあえずPostgreSQLを使ったシステムの運用を行っている

といった人にもいい感じではないでしょうか。

ある程度、アプリケーションを作ったことのある人ならサンプルソースなどははっきり言って不要ですが、運用・管理面の部分だけでもそれなりに役に立つのではないかと思います。

| | Comments (0) | TrackBack (0)

2009.03.02

Windows上のSQLiteで.importを行う

 SQLiteに格納するデータは基本的にUTF-8となります(少なくとも、SQLite Java Wrapper/JDBC Driverでアクセスした場合、自動的にUTF-8となります)。

 WindowsのコマンドプロンプトはデフォルトはMS932なので、sqlite3.exeでテキストファイルを読み込むとき、どうやってUTF-8でimportするか・・・と悩んでいたのですが、実は、テキストファイルをUTF-8で保存しておくだけでOKなんですね。

 UTF-8で保存したテキストを .import した場合、コマンドプロンプトのエンコードに関係なく、テキストファイル内の文字コードとして取り込んでくれるようです(なので、chcp 65001 等の作業をすることなく、UTF-8で取り込むことが可能)。

 もちろん、その状態だと、コマンドプロンプトからsqlite3.exeで対話型でSQLを実行したときにはまりますが(^^;

#SQLite用のGUIフロントエンドは、基本的にUTF-8で処理をするようなので、UTF-8で取り込んでおいた方が何かと都合がいいかと。

| | Comments (0) | TrackBack (0)

2009.02.21

DB2の自動インストール

応答ファイルのキーワード(DB2 9.5)

応答ファイルを用いてインストールする場合、

setup.exe /m /u (応答ファイルのパス)

のような感じで実行。

もっとも、実際にはいきなり応答ファイルを作成するのではなく、setup.exeを通常(GUIモード)起動し、そこで応答ファイルを保存したものをベースに編集した方が楽だと思われます(ちょっとした修正をテキストエディタで行うような感じでしょうか)。

| | Comments (0) | TrackBack (0)

2009.02.15

byteaデータの書き込み

 PostgreSQLでbytea型のデータを書き込む処理のメモ。

1.PreparedStatementでSQLを構築する。
2.PreparedStatement#setBinaryStream(int, InputStream, int)でデータをセットする。なお、書き込むデータが既にbyte[]になっている場合は、setBytes(byte[])でも可(わざわざByteArrayInputStream()を作成しなくてもOK)。

 注意点としては、setBinaryStream(int, InputStream)や、setBinaryStream(int, InputStream, long)の場合は、is not yet implemented. ということでエラーになってしまうようです(postgresql-8.3-604.jdbc4のドライバで検証)。

 なお、bytea型のデータを読み込む場合は、ResultSet#getBinaryStream(int)を使用するか、あるいはbyte[]の状態のまま次の処理を行うのであればResultSet#getBytes(int)で取得してもOKのようです。

| | Comments (0) | TrackBack (0)

2009.02.11

copyでNULL値の読込

 PostgreSQLのCOPY を使うと、大量のデータを(SQLで処理する場合と比較し)高速に読み込ませることができます。

 ドキュメントによると、NULL値も取り込めるとのことですが、いくらやっても失敗してしまう・・・。と思ったら、何のことはない、テキスト中のNULL値が、\N(NULL値)ではなく\n(改行コード)になっていたことが原因でした・・・。

#ちなみに、psqlのセッションにおいて、

\pset null *NULL*

のような感じのコマンドを投げる(「*NULL*」の部分は表示させたい任意の文字列)と、selectした結果のNULL値の出力を切り替えることができます。

| | Comments (0) | TrackBack (0)