[ThinkIT] 第4回：データベースレプリケーション (4/4)

TOP＞システムトレンド＞グループコミュニケーション

近未来データベース

近未来データベース

第４回：データベースレプリケーション
著者：NTTデータ先端技術鈴木幸市 2005/9/9

前のページ 1 2 3 4

グループコミュニケーション

マルチマスターでは、3台以上のサーバに同時に通信をする必要があります。実際には2台でもいいのですが、技術的には2台と3台ではかなり難しさが異なってきます。

現在のネットワークプロトコルは、1：1の通信、あるいはn：1の通信が前提です。図7に示すように、サーバクライアント型の通信はできますが、複数のサーバに一斉にデータを送ったりするには、これをたくさん組み合わせなければならなくなります。

現在の通信は1：1かn：1のサーバクライアント型

図7：現在の通信は1：1かn：1のサーバクライアント型

複数のサーバに一斉にデータを送信する方法には、ブロードキャストあるいはマルチキャストという方法があり、これは、LANの基本であるCSMA/CDでも定められています。また上位のプロトコルの研究もなされるようになってきました。複数のコンピュータ間で、データの送達確認やデータの順序が保証される、いわゆる信頼性のある通信を行う技術は「グループコミュニケーション」と呼ばれています（文献1）。

グループコミュニケーションでは、データを送る際に、あて先を複数のコンピュータに設定することができます。この複数のコンピュータ群には、いろいろなところからデータが送られてきます。重要なことは、すべてのコンピュータで受信するデータは、同じ順序になることが保証されているということです。図8にこの様子を示します。

グループコミュニケーションを使った複数コンピュータ間の通信

図8：グループコミュニケーションを使った複数コンピュータ間の通信

グループコミュニケーションを提供するソフトウェアをGCS（Group Communication System）と呼びます。まだプロトタイプですが、いくつかの提案がなされるようになってきました。これを使うと、Slony-IIのすべてのマスターでは、同じ順序でデータを受け取ることが保証されるので、2台のサーバでレプリケーションができる方式で、そのまま3台以上のサーバのレプリケーションも実現できることになります。

参考文献1： Group Communication Specifications：A Comprehensive Study、GV.Chockler、ACM Computing Surveys、2001、pp.427

提案中の方式

分散ロックでは、データベースのタプル1つを変更しようとするたびに全部のサーバで同じロックを確保しようとします。この方式では効率を上げるのが難しいので、Slony-IIでは先にあげたライトセットをいくつかまとめて処理しようとしています。具体的には、図9のようになります（少し単純にしてあります）。

Slony-IIの基本処理方式

図9：Slony-IIの基本処理方式
（画像をクリックすると別ウィンドウに拡大図を表示します）

自分のサーバに直接入ってきたSQLは、まず自分のサーバで処理を実行してしまいます。ただし、トランザクションは完了していないので、後でこれを確定したり取り消したりできるようにしておきます（前回の記事をご覧下さい）。トランザクションの完了時、あるいは、サブトランザクション（トランザクションの中を部分的に分けたもの）を契機に、これまでの変更が他のサーバの処理と矛盾しないかを調べます
矛盾がないかを調べるために、1で実行したSQL文のライトセット（ローカル更新）を他のすべてのマスターサーバにGCSを使って送ります
すべてのマスターサーバでは、他のサーバから送られてきたライトセットで、実行中のローカル更新と矛盾するものがないかどうかを調べます。矛盾したものがあると、ローカル更新を破棄します。つまり、実行中のトランザクションはアボートします。そして、送られてきたライトセットを実行します
3の結果が2に返されますので、ここでトランザクションを完了することができます

   かなり複雑で微妙な方式ですが、こうすることでサーバ間のやり取りの回数を少なくして、性能を落ちないようにしながら、すべてのサーバのデータベースが同じに保たれるようにしてあるのです。

   この方式で注意していただきたいことは、他のトランザクションの都合で、自分のトランザクションが取り消されてしまう危険があるということです。また、トランザクションの終わりにならないと、他のトランザクションとの矛盾があったかどうかもわからないことがあるということです。

   このようなトランザクション制御の方法は、楽観的な方法（optimisitic transaction management）と呼ばれているものの一種で、90年代にオブジェクト指向データベースなどでも用いられた方法です（文献2）。

   アプリケーションの設計では、新たな工夫が必要になるかもしれません。この方式は、トランザクション間の衝突が少ない場合は大変効率な方法なのですが、衝突が多く発生しだすと効率の低下も激しいといわれています。

参考文献2：トランザクション処理−概念と技法（上）（下）、ジム・グレイ、アンドレアス・ロイター、喜連川他（翻訳）、2001、日経BP社、ISBN：4822281027

Slony-IIの状況とむすび

現在Slony-IIは、アーキテクチャの検討と平行してプロトタイプの試作も行われております。意欲的なプロジェクトですが、年度内にはきちんと公開できるものが完成するものと期待しています。この実装では、グループコミュニケーション（GCS）の機能に多くを依存しています。GCSがどの程度の品質と性能をもたらしてくれるのか、この検証ができることにも期待したいと思います。

データベースレプリケーションは、データベースのスケールアウトを行い、かつ、データベースの可用性や信頼性を高める重要な方法です。Slony-II以外にもいくつもの試みがなされており、今後の発展が期待される領域です。

前のページ 1 2 3 4

NTTデータ先端技術株式会社　鈴木幸市

著者プロフィール
NTTデータ先端技術株式会社鈴木幸市
Unixにおける日本語ハンドリング、Oracleの移植、オブジェクトリレーショナルデータベースのエンジンの開発などに携わる。現在、NTTデータ先端技術にてLinux、PostgreSQLなどのオープンソースソフトウェアに関する技術を統括している。著書に「RDBMS解剖学」(翔泳社)、訳書に「オブジェクト指向データベース入門」(共立出版)など。

INDEX
第4回：データベースレプリケーション
	はじめに
	データベースレプリケーションの方式
	データベースのレプリケーションを考えるために
	グループコミュニケーション