[pgsql-jp: 30009] Re: oid の同一性と生成ロジックについて

[HAYAKAWA Hiroshi]

おはようございます。早川＠名古屋です。

返信が遅れてすみません。

on 03.5.19 1:47 PM, Yutaka tanida at yutaka ＠ hi-net.zaq.ne.jp wrote:

>> ちなみに、いまは、ウェブアプリケーションにおいて、
>> 新規データの登録時に、INSERTの後にoidを取得し、
>> そのoidを用いてそのデータのシリアルなIDを取得する、
>> というロジックを多用しています。
> 
> そもそも、そのロジックがあまりよろしくないと思います。この場合のID取得に
> はcurrval()関数を使うとか、serial型を使わずに自前でsequence管理するのが
> 筋でしょう。

on 03.5.19 5:52 PM, mitani at mitani ＠ sraw.co.jp wrote:

>> だから、それがクエリベースのレプリケーションの欠点であり、最初の記事はそ
>> れを指摘しているのです。
> これもその通りでして，クエリーベースのレプリケーションではnow()のような
> ものをINSERTされても，その値を全部のDBで整合性を保障できないのです．

そうですね。記事を読ませていただいて「あぁ」と思ったのですが、
当初はUsogresを利用するつもりはなくて（というか、存在を知りませんでした）
いままで気がつきませんでした。
テーブル定義中で DEFAULT 'now' などとしているのもダメですね。

確認できてすっきりしました。ありがとうございました。


目的としては負荷分散ではなくフェールオーバのためを意図していましたので、
まずはRAID1にてサーバーを運用することと、ベタではありますが、
HDD以外のハードウェア障害に対しては代わりのサーバーを用意しておいて
障害時には切り替える（HDDを手で入れ替えorデータをコピー）という方法で、
また負荷分散はDBサーバー以外の機能を別のマシンに移すといった方法にて
間に合いそうです。

レプリケーションを利用しようと考える場合には
設計時からちゃんと考えておく必要がありますね。

 * * *

ところで、クエリベースではないレプリケーションの実装というのは
やはり相当複雑で難しいことなのですよね？
その関連でRAID1の処理ロジックを知りたいなと思ったのですが、
適当なページをみつけることができませんでした。
LinuxのソフトウェアRAIDのドキュメントかソースを追っかけると
少し理解が深められるかもしれないので、
機会をみてちょっとみてみたいと思っています。


-----
With your dreaming, with your smile.
Hayakawa, Hiroshi <hayakawa ＠ sam.hi-ho.ne.jp>
Nagoya,Aichi,JAPAN ☆彡