 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||
|
||||||||||||||
| Federatedエンジンの動作 | ||||||||||||||
|
次に、Federatedエンジンがどのような動作にてリモートテーブルにアクセスし処理しているかを説明します。 図2は、アプリケーションがローカルサーバのFederatedテーブルに対してSQL文を実行した際の、ローカルサーバとリモートサーバの動作を示したものです。表3は動作の流れです。  図2：Federatedエンジンの動作
表3：Federatedエンジンの流れ Federatedエンジンは、通常のクライアントと同様にリモートサーバに接続してSQL文を送信します。なおこの処理をリモートサーバから見ると、Federatedエンジンが動作するローカルサーバからの処理要求は通常のクライアントからのものと何ら変わりません。リモートサーバは、通常のクライアントと同様にローカルサーバからの処理要求を実行しているだけです。この時、実際のデータ処理を実行するのは、MyISAMやInnoDBなどのリモートテーブルを格納するストレージエンジンです。よって、リモートサーバはFederatedエンジンをサポートする必要がないのです。 |
||||||||||||||
| Federatedエンジンの使い道 | ||||||||||||||
|
Federatedエンジンの使い道には様々なものが考えられると思いますが、MySQLのWebサイトにちょっと変わった用途が載っていましたので、ここではそれを簡単に紹介します。それは、Federatedエンジンを利用して同期型のレプリケーション環境を作るといったものです。 図3に示すように、サーバA内のテーブル「SampleTable」をマスタ、サーバB内のテーブル「SampleTable」をスレーブとします。それぞれのテーブルのエンジンはMyISAMとします。サーバAはFederatedエンジンをサポートします。  図3：Federatedエンジンを使用した同期型レプリケーション そこで、サーバA内にサーバBの「SampleTable」をリモートテーブルとするFederatedテーブル「Rep_SampleTable」を作成します。次に、サーバA内に「SampleTable」更新時のトリガーを作成します。このトリガーは「SampleTable」への更新と同じ内容の更新を「Rep_SampleTable」に行います。 このような環境を構築すると、アプリケーションによるサーバA内の「SampleTable」への更新内容は、同時にサーバB内の「SampleTable」へ反映されます。よって、何時サーバA、サーバBどちらの「SampleTable」を検索しても常に同じ結果を得ることが可能になります。あたかも、サーバAとサーバBの「SampleTable」が同期型レプリケーションによって構築されているようです。 MySQLには、標準機能として非同期型のレプリケーション機能があります。この機能を用いれば比較的簡単に2つのデータベースをレプリケーションすることができます。しかし、非同期型ですのでマスタの更新結果がスレーブに反映されるまで、場合によっては多少時間が必要になります。 そこから上記のような同期型レプリケーションの必要性がでてきます。ただし、上記の例は障害発生時の考慮などがまったくなされていませんので、適用対象はかなり限定されると思います。 |
||||||||||||||
| まとめ | ||||||||||||||
|
Federatedエンジンは、他のストレージエンジンと異なり、それ単独で動作するものではなく、複数のMySQLサーバを使用して動作するところが最大の特長です。それも、比較的簡単な設定で複数サーバを連携できるため、用途は非常に多いと思います。 しかし、リリースされて間もないこともあり、まだまだ洗練されていない部分もあると思います。今後の更なる発展に期待したいところです。 |
||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
