パスワードを忘れた? アカウント作成
8509 story

PostgreSQL用レプリケーションの大本命? Slony-I 1.0.0リリース 46

ストーリー by yoosee
個人用からエンタープライズまで 部門より

L.star 曰く、 "PostgreSQLのレプリケーションはこれと言った決定打が無く混沌としているが、PostgreSQL開発チームのコアメンバーの一人でもあるJan Weickが中心となり、9ヶ月の開発期間を経て、新しいレプリケーションソフトである「Slony-I」の最初のメジャーリリースである 1.0.0 がリリースされた。本家開発者が中心になっている事もあり、これから注目したいソフトウェアの一つだ。

このソフトウェアは非同期・シングルマスター・マルチスレーブのレプリケーションであるが、WANでの使用もある程度考慮されており、スレーブサーバーをカスケードしてデータの転送を最小限に抑える、途中のサーバーがダウンしても下位のサーバーが受け取り元に自動的に切り替わる、回線障害時などに備えて更新をキューイングしておく機能などが特徴にあげられる。
なお、このソフトウェアは富士通、PostgreSQLデータベース新機能の開発費を援助にも少し出ているとおり、Janの所属するAfilias社の援助の元に開発されている。

他のソフトウェアの動向では、最近では、コネクションプールの実装に機能を追加してレプリケーション機能を手に入れた石井達夫氏のpgpoolもバージョン2.0が、またpgpoolと一部コードを共有する、マルチマスター同期型で負荷分散機能も有するPGClusterもバージョン1.0.7がリリースされている。これらも注目だ。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by SteppingWind (2654) on 2004年07月06日 22時48分 (#583806)

    DBのレプリケーション機能って, 確かに宣伝文句としては非常に魅力的なんですが, 実際にシステムとして使う場合に

    • 特にトランザクション処理などで一定の性能が確保できるか?
    • 操作ミス, プログラムバグ等も含めた障害発生時の復旧手順を簡素化(できれば自動化)できるか?

    なんてことを検討していくと, 最終的にはファイル転送+バッチ更新で十分だし確実. なんて話しに落ち着くことが多い, というか私の経験的にはほとんどそうなんですけど, 何か実例(特に今回のPostgreSQL程度の規模で)ってありますかね?

    • PGCluster が最近お気に入りです。

      PGCluster はマルチマスタ(みんな親でどれが死んでも良い)同期レプリケーション(トランザクション毎に全サーバのデータの同期が取れる)方式のレプリケーションで、これは運用側から見てとてもメリットがあると思います。

      以下に使っていてここが良いと実感できたことをざっと挙げてみました。

      • サーバに障害が起こってもサービスが停止しない。(これが一番重要だと思ってます

      • 同期レプリケート方式なのでサーバが完全に死んでも定期バックアップなどまでデータがロールバックされてしまうこともありません。(とは言え定期バックアップも当然取りますが

      • マルチマスタなのでどのサーバに障害が発生した場合も同じ手順で対応できます。(マスタとスレーブがある方式だと、障害が発生したのがマスターなのかスレーブなのかにより、対応方法や復旧手順も少なくとも2通りは考慮する必要があります

      • トランザクションの整合も負荷テストである程度ベンチが取れており、運用しているものでは問題はおきていません。

      • 障害発生時のクラスタサーバの切り離しは自動化されています。

      • 復旧処理も自動化されています。(起動時に稼働中の他クラスタサーバからrsyncで同期を取り、その間のトランザクションもレプリケートされ、その後再びクラスタリングに参加します。これらは全て自動的に行われます

      • 操作ミス、プログラムバグに関してはレプリケーションで対応する問題ではなく PostgreSQL 7.5 で実装される PITR(Point in time recovery)機能などで対応することかと思います。(当然ベースの PostgreSQL でこの機能が実装されれば PGCluster も同様にその恩恵を得られるようになるでしょう


      一口にレプリケーションと言っても、マルチマスタかどうか、同期か非同期(遅延同期など)とか、これらの組み合わせ等で色々な実装があります。それぞれパフォーマンス面や運用面で一長一短があり、何を重視するかによって選択肢は変わってきます。

      PGCluster の場合は運用面のメリットが大きく、パフォーマンスに関してはクラスタサーバの数が増えるほど、参照系では負荷分散による性能は向上し、更新系のパフォーマンスは悪くなる。
      という特徴があります。

      >最終的にはファイル転送+バッチ更新で十分だし確実. なんて話しに落ち着くことが多い
      と言うのよりは一つ上の確実さなどがあると感じています。
      親コメント
    • 特にトランザクション処理などで一定の性能が確保できるか?
      レプリケーションは基本的にデータを複数回書き込む技術なので、それだけ遅くなるのは理の当然ですが。バッチと比べて、性能面より、むしろ更新間隔がどの程度許されるか、と言う方が比較のポイントと思います。
      操作ミス, プログラムバグ等も含めた障害発生時の復旧手順を簡素化(できれば自動化)できるか?
      これはレプリケーションとは直接は何の関係もありません。あなたがこのような状況を処理するのに必要なのは、Point In TIme Recovery(と、Recovery to Point In Time)技術で、これはPostgreSQLの次期バージョンでサポートされる予定です。
      最終的にはファイル転送+バッチ更新で十分だし確実
      毎回作り込むコストって馬鹿にならないような気もしますが・・・
      親コメント
  • by akonno (9001) on 2004年07月07日 1時07分 (#583916)
    記事中に出てくるAfiliasという会社は、何でPostgreSQL関係の開発をサポートしてるんでしょうか。
    ドメインのレジストリサービスって直接データベースをいじるんですか? そうじゃないような気がしていたけどよく分からん。
    • by jester (10005) on 2004年07月07日 3時04分 (#583985) 日記
      PostgreSQLの開発者がAfiliasと言う会社に所属しているだけです。
      PostgreSQLの開発者は意図的に会社と言う組織に集まってで開発やサポートをすると言う体制をとってないと言うのをどっかで読んだ記憶があります。
      親コメント
      • Re:Afilias (スコア:1, 参考になる)

        by Anonymous Coward on 2004年07月07日 7時14分 (#584033)
        シーラカンス本第3版(H13年刊行)に、こんな記述があります。

            コアメンバーの中にはPostgreSQLに関連する事業を行う会社に所属する人
            もいますが、コアメンバー全員が同じ会社に固まってしまうようなことが
            ないように自主規制しているようです。

        # そういえば第4版でてますね。
        親コメント
    • by L.star (163) on 2004年07月07日 8時47分 (#584075) ホームページ
      JanがSlony-Iを作ったのは、Afiliasがそういうレプリケーションソフトを欲しがったから、と言うのが一番大きかったはずです。

      ドメインのレジストリサービスって直接データベースをいじるんですか?
      いじるようですね。PostgreSQLで最大規模を誇るサービスは実際Afiliasの持っている.orgのレジストリサービスで、容量なんと2TBだと聞いています。
      親コメント
      • by akonno (9001) on 2004年07月07日 9時29分 (#584110)
        情報ありがとうございます。
        2TBのデータベースとはちょっと想像できない大きさだ。

        改めて考えると、ネームサービスはシングルマスターマルチスレーブで非同期のデータベースですよね(合ってますか?)。Slony-Iがそっちの方向なのも、Afiliasのニーズからってことなんでしょうね。
        親コメント
  • 引用より (スコア:0, おもしろおかしい)

    by Anonymous Coward on 2004年07月06日 13時42分 (#583414)
    > Berkus氏によると、富士通は昨年、$450億ドルを投入しており、

    そんなにあげるくらいなら、ボーナス増やしてください。
    • Re:引用より (スコア:2, おもしろおかしい)

      by Anonymous Coward on 2004年07月06日 15時33分 (#583492)
      かいしゃはPostgreSQLに$450おくつかった。
      しゃいんぜんいんのぼーなすがさがった。
      しゃいんぜんいんのしきがさがった。
      かいしゃのぎょうせきがさがった。
      かいしゃのかぶかがさがった。

      ぼすがあらわれた。

      どうする?
      ┏━━━━━━┓
      ┃>たたかう   ┃
      ┃ ぼうぎょ   ┃
      ┃ にげる    ┃
      ┗━━━━━━┛

      ACのこうげき。
      ACはぼすのせきにんをついきゅうした。
      しかしぼすはついきゅうをかわした。
      ぼす「くだらないしつもんだ。しゃいんがはたらかないからいけない」

      どうする?
      ┏━━━━━━┓
      ┃ たたかう   ┃
      ┃ ぼうぎょ   ┃
      ┃>にげる    ┃
      ┗━━━━━━┛

      ACはてんしょくした。
      親コメント
    • by Anonymous Coward
      投資と社員の給与を一緒にするなよぉ.
      何らかの形で回収するのが投資ってもんなのだし.

      というか,あなたへのボーナスって富士通にとってPostgreSQLコミュニティに突っ込むより有用?

      # 冗談だと分かってますが,少し不愉快な気分になりました.
      • by Anonymous Coward
        社員が働かないから、PostgreSQLに働かせるのです。
      • by Anonymous Coward
        もとACですが、この考察 [srad.jp]を読むとあなたのお腹立ちも治まると思います。
        あなたを不愉快にさせる意図はありませんでした。ごめんなさい…
      • by Anonymous Coward
        いやいや、ボーナスだって一種の投資ですよ。
        現在抱えている人材と、将来抱える人材に対する投資。

        450億ドルだっけ?
        日本の国家予算の12%ぐらいですかね?
        その半分を株主への配当に当て、
        残り半分を全社員にボーナスとして分配すれば、
        日本経済に対する刺激も大きいと思います。
    • by Anonymous Coward
      これって、富士通が450億ドルを去年一年でPostgreSQL開発チーム/コミュニティに投資したということ? なんだか信じがたい金額なのだけれど。誤訳かと思ったけれど、原文みてもあってるようで。
    • by Anonymous Coward
      > Berkus氏によると、富士通は昨年、$450億ドルを投入しており、
      投資にしたって、5兆円弱も突っ込むのは、やりすぎだと思う。
    • by Anonymous Coward
      株式会社なんだから資本主義の原則に則って配当金に回して下さい。
      (頑張って利益出したのに株主の親会社様に配当金で持っていかれたのでA.C.)
  • by Anonymous Coward on 2004年07月06日 14時30分 (#583448)
    何?
    • by Fuyuki (221) on 2004年07月06日 18時04分 (#583588)
      なぜ荒らしの評価? 普通に知らなかっただけでは?

      レプリケーション 【replication】
      [e-words.jp]
      DBの複製の事ですね。

      DB方面ではあたりまえの表現かもしれませんが、別方面の人はは知らなかったりすると思います。
      このくらいは教えてあげてもいいと思うんですが…。
      --
      # 数学は科学の女王にして奴隷
      親コメント
      • >DB方面ではあたりまえの表現かもしれませんが、別方面の人はは知らなかったりすると思います。
        >このくらいは教えてあげてもいいと思うんですが…。

        マイナスモデしたの私ですが(とACで語る意味の無さ)、理由はそんなんここで聞く前に、レプリケーションというキーワードでぐぐれっちゅー話です。
        • > そんなんここで聞く前に、レプリケーションというキーワードでぐぐれ

          私には有益な質問だったけどな。

          おぼろげに「まー複製とかバックアップのことだろう」ぐらいに思ってたから、ぐぐらずにいたけど、こうして質問してくれた人のおかげで、実際にDBやってる人から解答を得られて、おぼろげなのが晴れた。こういう質問がなかったら、ずっとおぼろげな
          • by Anonymous Coward
            > 私には有益な質問だったけどな。

            あれげ魂を感じない文面 [geocities.co.jp]なのが問題かと。1行だし。

            >モデレート権をどのように使うのも自由だと思うので、責めるつもりはないけれどね。

            だったら、こゆこと書かないほうが。

            # AC (*'-')只~~~
    • スタトレでレプリケータって出てくるだろ? あれの動詞形。
  • by Anonymous Coward on 2004年07月06日 15時49分 (#583505)
    EJBで使えるようにしてください。
    Javaとの連携はMySQLが無難ですか。でもあちらはUnicodeがあやしいんだなぁ。
  • by Anonymous Coward on 2004年07月06日 22時30分 (#583790)
    まぁ金突っ込むってブチ上げるのは勝手なんだけど、その金がどこに流れて、実際誰がコード書いてるの?
    そういう話がまったく聞こえてこないのはどうなってんのかね。
    • by L.star (163) on 2004年07月07日 0時35分 (#583890) ホームページ
      その金がどこに流れて、実際誰がコード書いてるの?
      金の流れについては私もよく分かってない(少なくとも、コアメンバーは把握しているようですが)けど、コードを書いているのは本家のメーリングリストをちゃんと読んでいれば分かります。

      彼らは頑張ってコード書いているし、コアメンバーの面々もちゃんとレビューしたりして、みんなが品質の高いコードと出来るように努力しています、少なくとも今回のfundingについて、富士通が後ろめたいようなことは(品質面においては)何もないと思います。

      そういう話がまったく聞こえてこないのはどうなってんのかね。
      別に今回に限らず、英語のメーリングリストをきっちり読まなければ、PostgreSQL界隈の開発活動なんて聞こえてきませんから、それだけのことではないでしょうか。
      親コメント
      • by Anonymous Coward
        コアチームがコード書いてます、レビューしてます、なんて当たり前の話じゃ・・・。何が変わったの? いくら金を積まれたって、一人が10人分働けるわけじゃないでしょうに。

        富士通の支援を受けたのが誰で、誰がコードに対して責任を負っているのかってことを聞きたいのだけれど。「開発で金をもらう」ってのはそういうことじゃないの?
        • by L.star (163) on 2004年07月07日 11時15分 (#584228) ホームページ
          原文の微妙な表現が分からないので、あえてfundという英語をそのまま使っています。注意。
          コアチームがコード書いてます、レビューしてます、なんて当たり前の話じゃ・・・。何が変わったの?
          直接的には、何も変わってないですね。ただし、今回のfundingを受けて、当該機能の実装を取り込むため、7.5 feature freezeは1ヶ月延長されました。
          富士通の支援を受けたのが誰で、誰がコードに対して責任を負っているのかってことを聞きたいのだけれど。
          だーかーら、fundingを受けたのもコードに(BSD Licenseでの配布に必要な程度の)責任を持つのもcore team。Nested Transactionの実装をやったAlvaroや、TablespaceのGavinがどれだけコードを書こうが、最後にcommitするのはcore teamの誰かだろうから。
          親コメント
        • by Anonymous Coward
          金を出した富士通が納得していればよいだけの話で、金を
          一銭たりとも払っていないあなたに教える義務はないですよね。

          あ、富士通の株主なら別にいいけど、でもそれは PostgreSQL
          の人じゃなくて富士通に聞くのが筋。
typodupeerror

普通のやつらの下を行け -- バッドノウハウ専門家

読み込み中...