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

Yoichi Shimada yshim @ storgate.co.jp
2003年 5月 21日 (水) 21:01:56 JST


島田@Storgate と申します。


2003.05.21, 7:39, HAYAKAWA Hiroshi san Wrote;
>on 03.5.19 5:52 PM, mitani at mitani @ sraw.co.jp wrote:
>
>>> だから、それがクエリベースのレプリケーションの欠点であり、最初の記事はそ
>>> れを指摘しているのです。
>> これもその通りでして,クエリーベースのレプリケーションではnow()のような
>> ものをINSERTされても,その値を全部のDBで整合性を保障できないのです.
>
>そうですね。記事を読ませていただいて「あぁ」と思ったのですが、
>当初はUsogresを利用するつもりはなくて(というか、存在を知りませんでした)
>いままで気がつきませんでした。
>テーブル定義中で DEFAULT 'now' などとしているのもダメですね。
>
>確認できてすっきりしました。ありがとうございました。

それ以外に、trigger や select で関数を呼んでいて、その関数が
更新を行なうようなケースも、要注意です。(SQLベースレプリケーションの
実装方法によりますが。。)

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

 フェールオーバーした結果、データベースの中身が異なってしまうような
ケースは避ける必要があります。上記のような now() が derfault 句で
使われているケースなど。。
アプリケーション的(システム的)に、その程度の誤差は「無視OK」という
なら別ですが。。

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

 どんな場合でも、データベースシステム構築に限らず「設計時点から、
要件定義が確実に実装されているか、出来るかの確認」は重要ですね。
>
> * * *
>
>ところで、クエリベースではないレプリケーションの実装というのは
>やはり相当複雑で難しいことなのですよね?

 いえいえ、それほど難しいものでは無いでしょう。例えば、ログベースの
レプリケーションなど:この場合、非同期レプリケーションですが。

 難しいのは「マルチマスタでの同期レプリケーション」です。おまけに、
負荷分散まで。。それを実現する、たとえば一つの方法として「SQLベース
レプリケーション」があります。ただし、現時点では万能ではありません。
マルチマスタ 同期レプリケーションでは、常に、独立なインスタンス間で、
ACIDを保障しながらデータベース内容のリアルタイムな同期をとるというのが、
難しい〜。。?*+@「^-^。。

>その関連でRAID1の処理ロジックを知りたいなと思ったのですが、
>適当なページをみつけることができませんでした。
>LinuxのソフトウェアRAIDのドキュメントかソースを追っかけると
>少し理解が深められるかもしれないので、
>機会をみてちょっとみてみたいと思っています。

 どこまで、ご存知になられたいかによりますが、
 RAID level-1 (ミラーリング)のアルゴリズムは、単純です。原理は、
受け取ったディスク I/O 要求を、2つの独立なデバイスに渡すだけです。
また、この機能をどこで(system-call, device-driver, RAID-controller, etc..)
どのように実装するか。どこまで結果をチェックするか。キャッシングを
どうするか、等によって、さまざまの製品があります。

「1つのミラー化された(RAI Level-1)ディスクボリュームを複数のサーバーで
共有(接続)し、互いに同時に Read/Write する。かつ、データの一貫性を保障」
というのが、「マルチマスタでの同期レプリケーション」に似た状態でしょうか。。
 
>

---------------------------------
Y.shimada






pgsql-jp メーリングリストの案内