JP2007241322A - 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム - Google Patents
多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム Download PDFInfo
- Publication number
- JP2007241322A JP2007241322A JP2004109106A JP2004109106A JP2007241322A JP 2007241322 A JP2007241322 A JP 2007241322A JP 2004109106 A JP2004109106 A JP 2004109106A JP 2004109106 A JP2004109106 A JP 2004109106A JP 2007241322 A JP2007241322 A JP 2007241322A
- Authority
- JP
- Japan
- Prior art keywords
- server
- database
- difference information
- database server
- snapshot
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】 少ない同期化用データで復旧後のデータベースサーバの同期化を図るとともに、システム全体をダウンさせることなく、データベースサーバのデータ記憶状況に拘わらずデータベースサーバを任意に切り離し又は組み込むことができる多重化データベースシステムを提供する。
【解決手段】 新規のサーバ100から組み込み要求があると、正常稼働中のサーバ100がスナップショットを作成し、新規のサーバ100に転送して該スナップショットからデータベース101を復元する。仲介装置200は、スナップショット作成後からクライアントからのクエリを差分情報として蓄積して、新規のサーバ100におけるスナップショットからのデータベースの復元後に差分情報を転送する。
【選択図】 図1
【解決手段】 新規のサーバ100から組み込み要求があると、正常稼働中のサーバ100がスナップショットを作成し、新規のサーバ100に転送して該スナップショットからデータベース101を復元する。仲介装置200は、スナップショット作成後からクライアントからのクエリを差分情報として蓄積して、新規のサーバ100におけるスナップショットからのデータベースの復元後に差分情報を転送する。
【選択図】 図1
Description
本発明は、障害などによりサービスが停止することなく常時連続したサービス提供が要求される多重化データベースシステムに関し、特に該システムを構成するデータベースサーバに障害が発生した場合の復旧処理や新規のデータベースサーバの組み込み処理を、サービス提供を継続したまま実施するためのデータ同期化技術に関する。
従来のデータベース同期化技術としては、例えば特許文献1に記載されているものが知られている。この従来技術では、それぞれデータベースを内蔵する複数のサーバがネットワーク等を介して相互接続されている。図36に示すように、特許文献1に記載されている実施例では、3個のサーバ1010,1020,1030を含み、それぞれネットワーク1040を介して相互接続されている。各サーバ1010,1020及び1030は、それぞれデータ更新制御部1011,1021,1031と、レプリケーション制御部1012,1022,1032と、データベース1013,1023,1033及び差分ファイル1014,1024,1034を含んでいる。
サーバ1010のデータ更新制御部1011は、データベースの更新処理を行う。レプリケーション制御部1012は、差分ファイル1014によりデータベース1013の同期化処理を行う。データベース1013は、データを一括管理する。差分ファイル1014は、データベース1013の差分情報を格納する。また、サーバ1020及び1030のデータ更新制御部1021,1031、レプリケーション制御部1022,1032、データベース1023,1033及び差分ファイル1024,1034は、それぞれ上述したデータ更新制御部1011,レプリケーション制御部1012,データベース1013及び差分ファイル1014と同様の機能を有する。
サーバ1010にデータ更新イベントが発生した場合、サーバ1010のデータ更新制御部1011は、自データベース1013の内容を更新した後、サーバ1020及びサーバ1030に対してデータ更新通知を送信する。サーバ1020及びサーバ1030のデータ更新制御部1021,1031は、自データベース1023,1033の内容を更新する。その後、サーバ1020及び1030は、それぞれサーバ1010に対してデータ更新完了通知を送信する。サーバ1010は、サーバ1020及びサーバ1030からのデータ更新完了通知がともに正常であれば、何も行わずに更新処理を終了する。差分ファイル1014,1024,1034には何も書き込まれない。
サーバ1030が障害などでダウンしている時にサーバ1010にデータ更新イベントが発生した場合、サーバ1020はデータ更新完了通知をサーバ1010へ送信するが、サーバ1030はデータ更新完了通知をサーバ1010へ送信できない。サーバ1010は、サーバ1030からのデータ更新完了通知を待ち続けるが、タイムアウトし、サーバ1030での更新が正常に終了しなかったことを知る。サーバ1010は、差分ファイル1014に更新が失敗した装置の情報(この場合、サーバ1030)と更新内容を保存する。以上で、サーバ1010は更新処理を終了する。
サーバ1020にデータ更新イベントが発生した場合も、サーバ1020は上述と同様の処理を行い、差分ファイル1024に更新が失敗した装置の情報と更新内容を保存し、更新処理を終了する。
以上のようにして、サーバ1030が復旧するまでの間、サーバ1010とサーバ1020は更新内容をそれぞれ差分ファイル1014,1024へ保存し続ける。
サーバ1030が障害から復旧すると、サーバ1030のレプリケーション制御部1032はサーバ1010に対してレプリケーション開始通知を送信する。サーバ1010のレプリケーション制御部1012は差分ファイル1014に保存されているデータを古い順に取り出し、サーバ1030へデータ更新通知を送信する。サーバ1030は自データベース1033の内容を更新した後、データ更新完了通知をサーバ1010へ送信する。サーバ1010は、データ更新完了通知を受信するたびに該当するデータを差分ファイル1014から削除する。
差分ファイル1014が空になったら、サーバ1020の差分ファイル1024のデータを上記と同様にしてサーバ1030に送信する。差分ファイル1024も空になったら、サーバ1030の同期化が完了する。
特開2001−290687号公報
しかしながら、上記特許文献1に記載のものでは、障害発生直後から正常稼働中のサーバがデータ更新内容を差分ファイルに蓄積しはじめるため、障害サーバの復旧までの時間が長くなると差分ファイルが巨大になってしまう。その結果、正常稼働中のサーバの記憶容量を食い潰してそのサーバが障害になってしまったり、障害から復旧したサーバの同期完了までに時間がかかるなどの問題がある。
また、同期化の手順は障害が発生した時点のデータベースに、障害が発生した後の更新内容を反映させるという方法である。このことは、同期化するサーバーは障害が発生する直前までのデータベースを正常に保持していることが前提となっていることを意味する。したがって、ハードディスクの故障などデータベースが破壊される障害が発生した場合、このサーバを同期化させることが不可能であるという問題がある。また、同じ理由から、サーバをアップグレードする場合など、データを全く保持していない新しいサーバを同期化することができないという問題もある。
さらに、同期化の手順は障害が発生した後の更新内容と障害が発生する直前までのデータベースを基に行う方式、つまり、障害発生時点をポイントとした方式であるため、障害復旧以外の目的にこの方式を使うことができない。すなわち、システム全体のサーバ台数を増やす目的で、新たなサーバを同期化させることはできないという問題がある。例えば、特許文献1の実施例では、システム全体のサーバ台数は3台であるが、これを4台に増やすために4台目のサーバを同期化させることはできない。
また、システム全体のサーバ台数を減らすことができないという問題点もある。その理由は、サーバを1台切り離すと、永遠に差分ファイルを蓄積するためである。
さらに、トランザクションが失敗した場合にその失敗したトランザクションの更新内容を取り消す方法が無いという問題もある。
さらに、障害でダウンしたサーバ以外の全てのサーバで、更新内容を分散して保存しているため、2台以上のサーバがダウンした場合には障害になったサーバを同期化できないという問題もある。
本発明は、上記事情に鑑みてなされたものであり、第1の目的とするところは、データベースサーバに障害が発生しても少ない同期化用データで復旧後のデータベースサーバの同期化を図ることができる多重化データベースシステムを提供することにある。また、第2の目的とするところは、システム全体をダウンさせることなく、データベースサーバのデータ記憶状況に拘わらずデータベースサーバを任意に切り離し又は組み込むことができる多重化データベースシステムを提供することにある。
上記目的を達成するために、本願発明では、複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正常な応答の1つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおいて、仲介装置は、クライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部を備える。そして、この仲介装置は、新規の又はこのシステムから切り離されたデータベースサーバ(以後「新規データベースサーバ」と言う)のシステムへの組み込み要求があると、(1a)正常稼働中のデータベースサーバに対してスナップショットの作成を指示し、(1b)組み込み要求受信時以降にクライアントコンピュータから受信する処理要求を差分情報として差分情報記憶部に順次記憶し、(1c)新規データベースサーバから差分情報転送要求を受信すると差分情報記憶部に記憶されている処理要求を新規データベースサーバに順次送出し、(1d)差分情報記憶部に記憶されている処理要求の送出が終了すると差分情報の記憶処理を終了するとともに新規データベースサーバをシステムに組み込む。
正常稼働中のデータベースサーバは、(2a)仲介装置からスナップショット作成指示を受信するとその時点でのデータベースのスナップショットの作成を開始し、(2b)作成したスナップショットを新規データベースサーバに転送する。
新規データベースサーバは、(3a)正常稼働中のデータベースサーバからスナップショットを受信すると該スナップショットを用いてデータベースを復元し、(3b)スナップショットに基づきデータベースの復元が完了すると仲介装置に差分情報要求を送出し、(3c)仲介装置から順次受信した処理要求に応じた処理を行う。
このようなシステムによれば、仲介装置では新規データベースサーバの同期化用の差分情報を差分情報記憶部に記憶するが、この差分情報は新規データベースサーバからの組み込み要求を契機として差分情報記憶部への記憶が開始される。したがって、データベースサーバを故障等によりシステムから切り離した後に再びシステムに組み込む場合、障害復旧までに長時間要しても、仲介装置に多大な差分情報が蓄積することがない。これにより、仲介装置の記憶容量を節約できるとともに差分情報の増大による仲介装置の負荷増大やダウンを防止できる。
また、正常稼働中のデータベースサーバにおけるスナップショット及び仲介装置で記憶された差分情報に基づき新規データベースサーバのデータが復元されるので、組み込み時の新規データベースにおけるデータ蓄積状況はどのようなものであっても構わない。したがって、ディスク故障により切り離されたデータベースサーバの復帰や、新規のデータベースサーバの組み込み(すなわちデータベースサーバの増強)を実現できる。すなわち、任意のデータベースサーバの組み込みが可能となる。
さらに、データベースサーバをシステムから切り離しただけでは差分情報の記憶やスナップショットの作成は行われないので、データベースのシステムからの切り離しを任意に行うことができる。
なお、ここでシステムへのデータベースサーバの組み込みとは、多重化データベースシステムを構成するデータベースサーバとして機能するよう仲介装置が当該データベースサーバを取り扱うようにすることを意味する。また、システムからのデータベースサーバからの切り離しとは、多重化データベースシステムを構成するデータベースサーバとして機能しないよう仲介装置が当該データベースサーバを取り扱うようにすることを意味する。したがって、システムに組み込まれているデータベースサーバにはクライアントコンピュータからの処理要求が仲介装置を介して届くが、システムから切り離されたデータベースサーバにはクライアントコンピュータからの処理要求が届かない状態となる。なお、データベースサーバがシステムに組み込まれていること又は切り離されていることと、データベースサーバが仲介装置と通信可能又は不能であることとは無関係である点に留意されたい。つまり、データベースサーバと仲介装置が通信可能な状態にある場合であっても、データベースサーバがシステムに組み込まれていない場合もあり得る。
また、スナップショットとは、その作成時点で確定している(COMMITされている)のデータベース全体の複製データやデータベースを復元するために必要なデータを意味する。したがって、スナップショットには、作成時点でCOMMITされていないデータは含まれないことに留意すべきである。
以上説明したように本発明によれば、データベースサーバに障害が発生しても少ない同期化用データで復旧後のデータベースサーバの同期化を図ることができる。また、システム全体をダウンさせることなく、データベースサーバのデータ記憶状況に拘わらずデータベースサーバを任意に切り離し又は組み込むことができる。
(第1の実施の形態)
本発明の第1の実施の形態に係る多重化データベースシステムについて図面を参照して説明する。図1は本実施の形態に係る多重化データベースシステムの全体構成を説明するブロック図である。
本発明の第1の実施の形態に係る多重化データベースシステムについて図面を参照して説明する。図1は本実施の形態に係る多重化データベースシステムの全体構成を説明するブロック図である。
この多重化データベースシステムは、図1に示すように、複数のデータベースサーバ(以下「サーバ」と言う)100と仲介装置200とをネットワーク300で接続したものであり、ネットワーク400を介して1以上のクライアントコンピュータ(以下「クライアント」と言う)500からアクセスされるものである。本実施の形態では、図1に示すように、2台のサーバ100a及び100bを有しており、2台のクライアント500a及び500bからアクセスされる。以降の説明において各サーバ100を他のサーバ100と区別する場合には添え字「a」「b」を付加するものとする。クライアント500についても同様である。なお、図1の例では、サーバ100とクライアント500はそれぞれ別々のネットワーク300,400に接続されているが、同じネットワークに接続されていてもよい。
図1に示すように、仲介装置200は、ネットワーク400側にIPアドレス172.17.1.1を持っており、これをデータベースサーバのIPアドレスとして公開している。クライアント500はデータベースにアクセスしたいときはIPアドレス172.17.1.1へクエリを送信し、IPアドレス172.17.1.1の仲介装置200からそのクエリに対する応答パケットを受信する。これは、クライアント500にとっては、IPアドレス172.17.1.1を持ったデータベースサーバとパケットを送受信していることと同じである。このIPアドレス172.17.1.1を持った仮想的なデータベースサーバを仮想サーバ800と呼ぶ。この仮想サーバ800の目的は、サーバ100が冗長化されていることを隠蔽するためである。つまり、サーバ100aとサーバ100b両方が稼働していようとサーバ100bがダウンしてサーバ100aのみが稼働していようとサーバ100aとサーバ100bの他に新たなサーバが追加されようとクライアントには影響は無く、動作を変更する必要がない。
サーバ100は、データを保存・管理するデータベース101と、データベース101の動作を制御するデータベース制御部102とを備えている。
データベース101は、SQL(Structured Query Language)を解して処理を行うRDBMS(Relational Database Management System)である。このようなデータベース101としては種々のものがあり、例えばThe PostgreSQL Global Development GroupによるPostgreSQL(http://www.postgres.org/)や、Oracle社によるOracle(登録商標)(http://www.oracle.com)などが挙げられる。
データベース制御部102は、ネットワーク300を介して仲介装置200から送られてくるパケットに基づき動作する。このパケットは、SQLなどデータベース101での処理に係るもの、同期化処理に係るものに大別される。SQLなどデータベース101での処理に係るものについては、データベース制御部102は、当該パケットをデータベース101に渡し、データベース101からの処理結果を仲介装置200に返す。
一方、同期化処理に係るものは、さらに自身が本システムに組み込まれている場合のものと、障害復旧時などこれからシステムに組み込む場合のものとに別れる。前者については、スナップショットの作成指示がある。データベース制御部102は、スナップショット作成指示を仲介装置200から受信すると、データベース101のスナップショットを作成する。そして、スナップショットの作成が完了すると、スナップショット作成完了を仲介装置200に通知する。そして、作成したスナップショットを、スナップショット作成指示で指示されている転送先の他のサーバ100に転送する。
他方、障害復旧時などこれからシステムに組み込む場合、データベース制御部102は、他のデータベースからスナップショットを受信すると、このスナップショットを用いて自身のデータベース101を復元する。データベース101の復元が完了すると仲介装置200に対して差分情報転送要求を送出する。後述するように、差分情報転送要求に応じて仲介装置200から差分情報が転送されるので、この差分情報を用いてデータベース101を復元する。
また、データベース制御部102は、本システムに組み込む際には、仲介装置200に対して組み込み要求を送信する。この組み込み要求は、サーバ100の起動時や、必要に応じて任意のタイミングで送出する。
仲介装置200は、本システム内のサーバ100を管理するサーバ管理表201と、トランザクションを管理するトランザクション管理表202と、同期化用に差分情報を蓄積する差分情報蓄積部203と、サーバ100に送信するクエリを一時保存する送信キュー204と、クライアント500・サーバ100間での処理の仲介やサーバ100の同期化制御などを行うサーバ制御部210とを備えている。
サーバ管理表201は、サーバが正常稼働中(active)か、障害などで停止している(down)か、という状態を保存している。図2にサーバ管理表の一例を示す。サーバ管理表201は、図2に示すように、サーバ100を識別するためのサーバIDと、サーバの稼働状態から構成されている。図2の例では、サーバ100aとサーバ100bとが登録されており、稼働状態は共に正常稼働を示すactiveである。また、本実施形態では、サーバIDとしてサーバ100に付されたIPアドレスを用いた。
トランザクション管理表202は、現在実行中の又は実行開始を保留されているトランザクションの有無を記憶する。図3にトランザクション管理表202の一例を示す。図3に示すように、トランザクション管理表202は、クライアントを一意に識別するクライアントIDとトランザクションを一意に識別するトランザクションIDから構成される。これらのペアは、トランザクション開始時にトランザクション管理表202に登録され、トランザクション終了時にトランザクション管理表202から削除される。クライアントIDは、例えばクライアント500のIPアドレスやポート番号である。トランザクションIDは新しいトランザクションが発生する毎にサーバ制御部210が新たに割り振る。
差分情報蓄積部203は、サーバ同期化時にクライアント500から受信する全てのクエリを蓄積する。図4に差分情報蓄積部203が蓄積している差分情報の一例を示す。差分情報蓄積部203の各データは、図4に示すように、クライアント500が送信したクエリと、このクエリが所属するトランザクションIDとから構成される。トランザクションIDはトランザクション管理表202から取得する。同期化処理時におけるクライアント500からの新たなクエリは、この差分情報蓄積部203の最後に追加される。つまり、上から古いクエリが蓄積されている。図4の例では、トランザクションID=1のBEGINが一番古く、COMMITが一番新しい。
送信キュー204は、各クライアント500から受信したクエリを各サーバ100に送信するまで一時的に保存するバッファメモリである。図5に送信キュー204の一例を示す。送信キュー204の各データは、図5に示すように、クライアント500が送信したクエリと、このクエリが所属するトランザクションIDと、サーバ100に送信したか否かを表す送信情報とから構成される。トランザクションIDはトランザクション管理表202から取得する。クライアント500からの新たなクエリは、この送信キュー204の最後に追加される。つまり、上から古いクエリが蓄積されている。図5の例では、トランザクションID=1のBEGINが一番古く、トランザクションID=2のBEGINが一番新しい。この送信キュー204の送信状態は、クライアント500からクエリを受信した際には「未送信」が設定され、正常稼働中の全てのサーバ100に送信されると「送信完了」が設定される。送信完了となったエントリは、直ちに又は所定期間経過後に送信キュー204から削除される。
サーバ制御部210は、通常の処理(同期化処理時以外の処理)として、クライアント500からのパケットをネットワーク400経由で受信し、サーバ管理表201を見て正常稼働している全てのサーバ100へ該パケットを転送する。ここで、サーバ100へ転送するパケットは、送信キュー204に「未送信」として記憶されているクエリが対象であり、送信キュー204に記憶されている古いクエリから順に転送される。そして、サーバ100からのパケットをネットワーク300経由で受信し後述するパケットの正当性判断方法により1つ以上の該パケットのうち1つを選出し1つの正しいパケットをネットワーク400を経由してクライアント500へ転送する。なお、同期化処理時には、「未送信」のクエリであっても新規トランザクションに属するクエリは送信せず、実行中のトランザクションに属するクエリのみを古い順に正常稼働中のサーバ100に送信する。
ここで、サーバ制御部210は、クライアント500からの処理要求を解析してトランザクションの開始と終了を検出してトランザクション管理表202を更新する。トランザクション開始と終了をサーバ制御部210が検出する方法は、DBMSの種類によって異なる。例えば前述のPostgreSQLの場合は、トランザクションの開始はクライアント500が「BEGIN」というSQLを送信した時であり、トランザクションの終了はクライアント500が「COMMIT」「ROLLBACK」というSQLを送信した時である。また、Oracleの場合は、トランザクションの開始はクライアント500が有効なSQLを送信したときであり(明示的なトランザクションの開始を宣言するSQLは無い)、トランザクションの終了はクライアント500が「COMMIT」「ROLLBACK」というSQLを送信した時である。また、AUTO COMMITモードで動作する場合には、クライアント500から受信したSQL文はそれぞれ1つの独立したトランザクションに属していると解釈できるので、クライアント500からSQLを受信する毎に、該SQL実行前にトランザクションが開始されるとともにSQL実行後に当該トランザクションが終了したこととして扱うことができる。
また、パケットの正当性判断方法は、例えば、多数決で決める方法や、受信したパケットを所定のルールに基づいて判断する方法がある。例えば、クライアント500からの「参照」要求に対して「更新成功」という応答が返ってきた場合、正常であればそのような応答はあり得ないので(参照成功など参照に関する応答のはず)、この応答パケットは正しくないと判断する。また、パケット中にデータ長フィールドがある場合、このデータ長フィールドの値と実際に受信したパケット長を比較し、異なる場合は正しくないと判断する。また、複数のサーバ100の中からMasterサーバを予め1台決めておき、このサーバ100からのパケットを常に正しいと判断する。また、上記複数の方法を併用する方法もある。例えば、3台で多数決を行った結果、パケットの中身が全てバラバラであり、多数派のパケットを決められない場合はMasterサーバのパケットを正しいと判断する。正常稼働しているサーバが1つだけの場合は、そのサーバからの応答パケットを正常と判断する。
サーバ制御部210は、正当ではない応答を送信したサーバ100は障害と判断し、そのサーバ100についてはサーバ管理表201から登録を削除することによりシステムから切り離す。なお、応答を返してこないサーバ100も障害と判断する。
さらに、サーバ制御部210は、ネットワーク300を介してサーバ100からシステムの組み込み要求を受信すると、この新規のサーバ100と、正常稼働中のサーバ100とを同期化させる処理を行う。以下にその処理について説明する。
サーバ制御部210は、サーバ100からシステムの組み込み要求を受信すると、正常稼働中のサーバ100に対してスナップショットの作成指示を送出する。ここで、スナップショットの作成指示を送出するタイミングは、サーバ100においてトランザクションが実行中でないことが求められる。これはスナップショット作成中にトランザクションがROLLBACKするとデータの同期化が図れない場合があることを防止するためや、COMMITされていないために更新データがスナップショットに反映されないことを防止するためである。このためサーバ制御部210は、処理中のトランザクションが終了するまでスナップショットの作成指示の送出を待つとともに、スナップショット作成完了通知をサーバ100から受信するまでは新規トランザクションを開始しないようにしている。そして、新規トランザクションに係るSQLについては、スナップショット作成完了通知の受信後に、正常稼働中のサーバ100で処理するとともに、差分情報蓄積部203に蓄積する。差分情報蓄積部203に蓄積するクエリは、トランザクション制御SQL、参照系SQL及び更新系SQLを含む全てのSQLが対象となる。
サーバ制御部210がスナップショットの作成指示を送出すると、当該スナップショットは新規のサーバ100に転送され、このサーバ100からサーバ制御部210に対して差分情報転送要求が送出される。サーバ制御部210は、差分情報転送要求を受信すると、新規のサーバ100に対して差分情報蓄積部203に蓄積されているクエリを古いものから順次送信する。差分情報蓄積部203に蓄積されているSQLを全て送出すると、サーバ制御部210は、新規サーバ100をシステムに組み込むべくサーバ管理表201を更新する。
ここで、サーバ制御部210は、差分情報の送出中にクライアント500から新たなクエリを受信する場合があるが、この場合は当該クエリを差分情報蓄積部203の最後に追加するとともに正常稼働中のサーバ100へ送信すれば良い。ただし、クライアント500のクエリ送出頻度が高い場合などには、差分情報の送出終了まで、すなわち同期化終了まで長時間要する場合が考えられる。そこで、差分情報蓄積部203における未送信の差分情報が所定件数以下となったら、クライアント500からのクエリを一時保留して差分情報の送出のみを行い、まず差分情報の送出を完了させる。そして、前述のように新規サーバ100をシステムに組み込むべくサーバ管理表201を更新した後に、保留していたクエリ処理を再開すると好適である。
クライアント500は、データベースサーバに対して更新クエリ(データベースを更新するリクエスト)や参照クエリ(データベースの内容を参照するリクエスト)などを発行するものである。
次に、本実施の形態に係る多重化データベースシステムの動作について図面を参照して説明する。まず、サーバ100aと100bが正常に動作している場合の動作を図6から図8を参照して説明する。
初期状態では、データベース101aと101bは完全に同一であり、サーバ管理表201は図7のようになっているものとする。また、トランザクション管理表202と差分情報蓄積部203は空であるとする。各サーバ100a,100bには、テーブルtest#tableが存在しているとする。
クライアント500aが172.17.1.1宛にトランザクション開始SQLを含んだパケットを送信すると、仲介装置200はそのパケットを受信する(ステップS1)。サーバ制御部210は、トランザクションが開始されたことを検知し、トランザクション管理表202にクライアント500aのIPアドレスとトランザクション番号を登録する(ステップS2)。図8にこのときのトランザクション管理表202を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー204に入れる。
サーバ制御部210は、送信キュー204から当該「未送信」のクエリを取り出し、サーバ管理表201を見て正常稼働している全てのサーバ100に該パケットを送信する。この場合、サーバ100aと100bが正常稼働しているので、サーバ制御部210はサーバ100aとサーバ100bへ該パケットを転送する(それぞれステップS3とS4)。そして、各サーバ100への送信が完了したので送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。仲介装置200は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ100aから受信するが(ステップS5)、この時点では、未だ全ての応答パケットが揃っているわけではないので(この場合、サーバ100bからの応答パケットが来ていない)、サーバ制御部210は何もせずにサーバ100bからの応答パケットを待つ。そして、トランザクションが正常に開始されたことを通知する応答パケットをサーバ100bから受信すると(ステップS6)、これで全ての応答パケットが揃ったので、サーバ制御部210はそれらの応答パケットを互いに比較することでサーバ100に障害が発生しているか否かをチェックする(ステップS7)。この場合、2つの応答パケットはともにトランザクションが正常に開始されたことを示すパケットであるため、障害は無いと判断し応答パケットの1つをクライアント500aへ転送する(ステップS8)。
次に、クライアント500aは、テーブルtest#tableを更新するSQL(UPDATE)を含んだパケットを172.17.1.1へ送信する(ステップS9)。サーバ制御部210は、受信したクエリを送信キュー204に入れる。そして、送信キュー204から当該クエリを取り出し、サーバ管理表201を見て正常稼働しているサーバ、この場合、サーバ100aと100bへ該パケットを転送する(それぞれステップS10とS11)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。サーバ100aは正常にUPDATE完了したことを通知する応答パケットを仲介装置200に送信し、仲介装置200がこの応答パケットを受信する(ステップS12)。この時点では全ての応答パケットが全て揃っているわけではないので、サーバ制御部210は何もせず待機する。そして、正常にUPDATE完了したことを通知する応答パケットをサーバ100bから受信すると(ステップS13)、これで応答パケットが全て揃ったので、サーバ制御部210はそれら応答パケットを互いに比較することでサーバ100に障害が発生しているか否かをチェックする(ステップS14)。この場合、2つの応答パケットはともにUPDATE成功したことを示すパケットであるため、障害は無いと判断し応答パケットの1つをクライアント500aへ転送する(ステップS15)。
次に、クライアント500aは、テーブルtest#tableへの更新を確定する(実際にデータベースを更新する)SQL(COMMIT)を含んだパケットを172.17.1.1へ送信する(ステップS16)。サーバ制御部210は、受信したクエリを送信キュー204に入れる。そして、送信キュー204から当該クエリを取り出し、サーバ管理表201を見て正常稼働しているサーバ、この場合、サーバ100aとサーバ100bへ該パケットを転送する(それぞれステップS17とS18)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。サーバ100aは正常にCOMMIT完了したことを通知するパケットを仲介装置200に送信し、仲介装置200がこの応答パケットを受信する(ステップS19)。この時点では全ての応答パケットが全て揃っているわけではないので、サーバ制御部210は何もせず待機する。そして、正常にCOMMIT完了したことを通知する応答パケットをサーバ100bから受信すると(ステップS20)、これで応答パケットが全て揃ったので、サーバ制御部210はそれら応答パケットを互いに比較することでサーバ100に障害が発生しているか否かをチェックする(ステップS21)。この場合、2つの応答パケットはともにCOMMIT成功したことを示すパケットであるため、障害は無いと判断する。COMMITが正常に完了したことから、トランザクションが終了したことが分かるので、サーバ制御部210はトランザクション管理表202からこのトランザクションの登録を削除する(ステップS22)。このときのトランザクション管理表202は再び初期状態(すなわち空)になる。サーバ制御部210は応答パケットの1つをクライアント500aへ転送する(ステップS23)。
次に、サーバ100bが故障などで障害になった場合の動作を図9から図11を参照して説明する。初期状態では、データベース101aと101bは完全に同一であり、サーバ管理表201は前述した図7のようになっているとする。また、トランザクション管理表202と差分情報蓄積部203は空であるとする。
クライアント500aが172.17.1.1宛にトランザクション開始SQL(BEGIN)を含んだパケットを送信すると、仲介装置200はそのパケットを受信する(ステップS30)。サーバ制御部210は、トランザクションが開始されたことを検知し、トランザクション管理表202にクライアント500aのIPアドレスとトランザクション番号を登録する(ステップS31)。図10にこのときのトランザクション管理表202を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー204に入れる。
サーバ制御部210は、送信キュー204から当該「未送信」のクエリを取り出し、サーバ管理表201を見て正常稼働している全てのサーバ100、この場合、サーバ100aと100bへ該パケットを転送する(それぞれステップS32とS33)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。仲介装置200は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ100aから受信するが(ステップS34)、この時点では、未だ全ての応答パケットが揃っているわけではないので(この場合、サーバ100bからの応答パケットが来ていない)、サーバ制御部210は何もせずにサーバ100bからの応答パケットを待つ。そして、トランザクションが正常に開始されたことを通知する応答パケットをサーバ100bから受信すると(ステップS35)、これで全ての応答パケットが揃ったので、サーバ制御部210はそれら応答パケットを互いに比較することでサーバ100に障害が発生しているか否かをチェックする(ステップS36)。この場合、2つの応答パケットはともにトランザクションが正常に開始されたことを示すパケットであるため、障害は無いと判断し応答パケットの1つをクライアント500aへ転送する(ステップS37)。
ここで、サーバ100bは、ステップS35で応答パケットを返した後、故障などの障害が発生してダウンしたものとする(ステップS38)。
次に、クライアント500aは、テーブルtest#tableを更新するSQL(UPDATE)を含んだパケットを172.17.1.1へ送信する(ステップS39)。サーバ制御部210は、受信したクエリを送信キュー204に入れる。そして、送信キュー204から当該クエリを取り出し、サーバ管理表201を見て正常稼働しているサーバ、この場合、サーバ100aと100bへ該パケットを転送する(それぞれステップS40とS41)。この時点では、サーバ制御部210はサーバ100bのダウンを知らないので、サーバ100bが正常稼働しているという情報がサーバ管理表201に格納されたままである。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。サーバ100aは正常にUPDATE完了したことを通知する応答パケットを仲介装置200に送信し、仲介装置200がこの応答パケットを受信する(ステップS42)。この時点では応答パケットが全て揃っているわけではないので、サーバ制御部210は何もせず待機する。しかし、サーバ100bはダウンしているのでサーバ100bからの応答パケットはいつまで経っても仲介装置200には届かない。これによりサーバ制御部210はタイムアウトし、サーバ100bのダウンを検知する。そして、サーバ制御部210はサーバ管理表201のサーバ100bをactiveからdown(サーバ停止状態)に書き換える(ステップS43)。そのときのサーバ管理表201を図11に示す。サーバ制御部210は応答パケットをクライアント500aへ転送する(ステップS44)。ここでは、クライアント500aにとって、サーバ100bが障害になったかどうかは認識せず、今までと同様に仮想サーバ800からサービスを受けることができることに注目すべきである。
次に、クライアント500aは、テーブルtest#tableへの更新を確定するSQL(COMMIT)を含んだパケットを172.17.1.1へ送信する(ステップS45)。サーバ制御部210は、受信したクエリを送信キュー204に入れる。そして、送信キュー204から当該クエリを取り出し、サーバ管理表201を見て正常稼働しているサーバ、この場合、サーバ100aのみへ該パケットを転送する(ステップS46)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。サーバ100aは正常にCOMMIT完了したことを通知する応答パケットを送信し、仲介装置200がこの応答パケットを受信する(ステップS47)。COMMITが正常に完了したことから、トランザクションが終了したことが分かるので、サーバ制御部210はトランザクション管理表202からこのトランザクションの登録を削除する(ステップS48)。このときのトランザクション管理表202は再び初期状態(すなわち空)になる。サーバ制御部210は応答パケットをクライアント500aへ転送する(ステップS49)。
ここで、ステップS46によって、サーバ100aのデータベース101aは、クライアント500aからのUPDATE(ステップS39)が反映されているのに対して、サーバ100bのデータベース101bにはクライアント500aからのUPDATE(ステップS39)が反映されていない、つまり、データベース101aとデータベース101bは非同期状態になったことに注目すべきである。
次に、サーバ100bが障害から復旧しシステムに組み込む(追加する)場合の動作を図12から図20を参照して説明する。このとき注目すべきポイントは、クライアント500a及び500bに対するサービスを続けたままサーバ100bを追加する、つまり、システムダウンさせずにデータベース101aと101bを同期させることである。
データベース101bはデータベース101aと同期がとれていない状態、つまり、同一ではない状態である。例えば、データベース101bは、図9のステップS38の障害が起きる直前のデータを保持しているかもしれないし、全く新しいサーバの場合には、データを全く持っていない状態かもしれない。本発明では、前者の場合でも古いデータは削除し、データベース101bはデータを全く保持していないものとしてシステムに組み込む。つまり、ステップS38以前の古いデータを保持している必要はない。
ここでは、サーバ管理表201は図15のようになっているとする。また、トランザクション管理表202と差分情報蓄積部203は空であるとする。
図12に示すように、クライアント500aが172.17.1.1宛のトランザクション開始SQL(BEGIN)を含んだパケットを送信すると、仲介装置200はそのパケットを受信する(ステップS60)。サーバ制御部210は、トランザクションが開始されたことを検知し、トランザクション管理表202にクライアント500aのIPアドレスとトランザクション番号を登録する(ステップS61)。図16にこのときのトランザクション管理表202を示す。サーバ制御部210は、受信したクエリを送信キュー204に入れる。そして、送信キュー204から当該クエリを取り出し、サーバ管理表201を見て正常稼働しているサーバ、この場合、サーバ100aへ該パケットを転送する(ステップS62)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。仲介装置200は、トランザクションが正常に開始されたことを通知する応答パケットをサーバ100aから受信すると(ステップS63)、応答パケットをクライアント500aへ転送する(ステップS64)。
ここで、サーバ100bは電源を投入し起動されたものとする。これにより、サーバ100bのデータベース制御部102bは、データベース同期化要求を仲介装置200へ送信する(ステップS65)。
データベース同期化要求を受信したサーバ制御部210は、トランザクション管理表202をチェックし現在実行中のトランザクションが存在するかどうかを確認するとともに、実行中トランザクションの情報を記録しておく(ステップS66)。図16より、クライアント500a,トランザクション番号3のトランザクションが実行中なので、データベース同期化動作はこのトランザクションの終了を待つと同時に、新しいトランザクション開始要求を受け取った場合は、その要求をサーバ100aへ転送することを遅らせる(ステップS67)。つまり、同期化動作は実行中のトランザクションが全くない状態で始める。この新規トランザクションの開始要求についての転送遅延処理は、送信キュー204での保留という手段で実現する。
次に、クライアント500aは、テーブルtest#tableを更新するSQL(UPDATE)を含んだパケットを172.17.1.1へ送信する(ステップS68)。サーバ制御部210は、受信したクエリを送信キュー204に入れる。このクエリは前記ステップS66で記憶したトランザクション情報から同期化要求時に実行していたトランザクションに属するものと判定できるので、サーバ制御部210は、送信キュー204から当該クエリを取り出し、サーバ管理表201を見て正常稼働しているサーバ、この場合、サーバ100aへ該パケットを転送する(ステップS69)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。サーバ100aは正常にUPDATE完了したことを通知する応答パケットを仲介装置200に送信し、仲介装置200がこの応答パケットを受信する(ステップS70)。サーバ制御部210は、応答パケットをクライアント500aへ転送する(ステップS71)。
次に、クライアント500bが172.17.1.1宛にトランザクション開始SQL(BEGIN)を含んだパケットを送信すると、仲介装置200はそのパケットを受信する(ステップS72)。サーバ制御部210は、このパケットによりトランザクションが開始されたことを検知し、トランザクション管理表202にクライアント500bのIPアドレスとトランザクション番号を登録する(ステップS73)。図17にこのときのトランザクション管理表202を示す。そして、このパケットに係るクエリを送信状態「未送信」で送信キュー204に入れる。しかし、この時点では同期化処理準備のため、新規トランザクション開始クエリは送信キュー204に保持したままサーバ100aへは転送しない(ステップS74)。
次に、クライアント500aは、テーブルtest#tableへの更新を確定するSQL(COMMIT)を含んだパケットを172.11.1.1へ送信する(ステップS75)。サーバ制御部210は、受信したクエリを送信キュー204に入れる。このクエリは前記ステップS66で記憶したトランザクション情報から同期化要求時に実行していたトランザクションに属するものと判定できるので、サーバ制御部210は、送信キュー204から当該クエリを取り出し、サーバ管理表201を見て正常稼働しているサーバ、この場合、サーバ100aのみへ該パケットを転送する(ステップS76)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。サーバ100aは正常にCOMMIT完了したことを通知する応答パケットを仲介装置200に送信し、仲介装置200がこの応答パケットを受信する(ステップS77)。COMMITが正常に完了したことから、トランザクションが終了したことが分かるので、サーバ制御部210はトランザクション管理表202からこのトランザクションの登録を削除する(ステップS78)。この時のトランザクション管理表202を図18に示す。サーバ制御部210は応答パケットをクライアント500aへ転送する(ステップS79)。
ここで、新規サーバ100bからの同期化要求時に実行していたトランザクションが全て無くなったので、サーバ制御部210は同期化動作を開始する(ステップS80)。具体的には、図13に示すように、まず、サーバ制御部210は、サーバ100aに対して同期化指示(スナップショット作成指示)のパケットを送信する(ステップS81)。なお、前記ステップ80において、トランザクション管理表202に記録されているトランザクションが同期化要求時に実行中であったものか、又は、その後にクライアント500から受信したものかを判定するには、前記ステップS66で記録しておいた同期要求時のトランザクション情報を参照すればよい。
同期化指示を受け取ったサーバ100aのデータベース制御部102aは、データベース101aのスナップショットを作り出す(ステップS82)。ここで、このスナップショットは、同期化指示を受け取った時点でのデータベース全体のバックアップデータやデータベースを復元するための情報であり、同期化指示後の更新は反映されていないことに注目すべきである。
サーバ100aのデータベース制御部102aは、スナップショット作成が完了すると(ステップS83)、その旨を仲介装置200へ通知する(ステップS84)。
データベース制御部102aは作成したスナップショットをサーバ100bへ転送し、サーバ100bのデータベース制御部102bは、サーバ100aから受信したスナップショットからデータベースを復元する(ステップS85)。このスナップショットの転送とデータベースの復元は、データベース101aのサイズが大きければ大きいほど時間がかかるが、クライアントからのデータベースアクセスと並行して実行されるのでクライアントに対するサービスを止めることはない。
スナップショット作成完了通知を受け取った仲介装置200のサーバ制御部210は、クライアント500へのサービスを再開する。この場合、処理せずに送信キュー204に保持していた、クライアント500bからのBEGINを含んだパケットの処理を再開する。すなわち、サーバ制御部210は、転送せずに保持していたクライアント500bからのBEGIN SQLを含んだパケットを送信キュー204から取り出して差分情報蓄積部203に保存するとともに(ステップS86)、サーバ100aへ転送する(ステップS87)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。
なお、ここではステップS87の処理をステップS85の後に説明したが、ステップS85の動作(スナップショットの転送)はクライアントへのサービスを妨げるものではないので、スナップショットの転送中にステップS87や後述のステップS88が行われてもよい。
サーバ100aは、トランザクションが正常に開始されたことを通知する応答パケットを仲介装置200に送信し、仲介装置200がこの応答パケットを受信する(ステップS88)。仲介装置200は、この応答パケットをクライアント500bへ転送する(ステップS89)。
次いで、クライアント500bがテーブルtest#tableの更新SQL(UPDATE)のパケットを仲介装置200に送信すると(ステップS90)、サーバ制御部210は、受信したクエリを送信キュー204に入れる。そして、送信キュー204から当該クエリを取り出し、当該クエリを差分情報蓄積部203に保存するとともに(ステップS91)、正常稼働中のサーバ100aに当該パケットを送信する(ステップS92)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。ここで、サーバ100aはUPDATEに失敗し、その旨を通知する応答パケットを仲介装置200に送信したものとする(ステップS93)。仲介装置200は、この応答パケットをクライアント500bに送信する(ステップS94)。
UPDATE失敗の応答パケットを受信したクライアント500bは、トランザクションを取り消すSQL(ROLLBACK)のパケットを仲介装置に送信する(ステップS95)。サーバ制御部210は、受信したクエリを送信キュー204に入れる。そして、送信キュー204から当該クエリを取り出し、当該SQLを差分情報蓄積部203に保存するとともに(ステップS96)、正常稼働中のサーバ100aに当該パケットを送信する(ステップS97)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。そして、サーバ100aから正常にトランザクションがROLLBACKされたことを通知する応答パケットを受信すると(ステップS98)、トランザクション管理表202から当該トランザクションの登録を削除するとともに(ステップS99)、この応答パケットをクライアント500bに送信する(ステップS100)。この時点での差分情報蓄積部203を図19に示す。また、トランザクション管理表202は空になる。
ここで、サーバ100bにおいてスナップショットからのデータベース101bの復元が完了したものとする(ステップS101)。サーバ100bはデータベース101bの復元が完了すると差分情報転送要求を仲介装置200に送信する(ステップS102)。仲介装置200のサーバ制御部210は、差分情報転送要求を受信すると、図14に示すように、差分情報蓄積部203に蓄積されているデータを古いものから順にサーバ100bに転送する処理を開始する(ステップS103)。
前記ステップS103で差分情報蓄積部203に蓄積されている全てのクエリが転送・処理されることでデータベース101aと101bは完全に一致した状態(同期状態)になるが、この転送処理中にクライアント500から新たなクエリを受信する場合がある。例えば、図14に例示するように、仲介装置200は、クライアント500bから新規トランザクションを開始するクエリ(BEGIN)を受信する(ステップS104)。仲介装置200は、当該新規トランザクションをトランザクション管理表202に登録する(ステップS105)。そして、当該クエリを送信キュー204に入れる。次いで、送信キュー204から当該クエリを取り出し、差分情報蓄積部203の最後に当該クエリを追加するとともに(ステップS106)、正常稼働中のサーバ100aに送信する(ステップS107)。そして、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。次いで、サーバ100aから応答パケットを受信すると(ステップS108)、当該応答パケットをクライアント500bに転送する(ステップS109)。
このように差分情報転送中にクライアント500から受信したクエリは、正常稼働中のサーバ100で処理するとともに、差分情報蓄積部203に蓄積していく。この処理を継続していくと、やがて差分情報蓄積部203に蓄積されているクエリは全て新規サーバ100bに転送され、差分情報蓄積部203は空になり、これを契機に差分情報転送処理が終了する(ステップS110)。これによりデータベース101aと101bは完全に一致した状態(同期状態)となるので、サーバ制御部210は、サーバ管理表201にサーバ100bを追加し稼働状態をactiveとすることでシステムにサーバ100bを追加する(ステップS111)。この時のサーバ管理表201を図20に示す。これにより、サーバ100bがシステムに組み込まれた状態となるので、以降の動作は図6を参照して前述したものと同様となる。
この手順を繰り返せば、もともとシステムに組み込まれていたが障害等のためにシステムから切り離されたサーバであっても、新規のサーバであっても、理論的にはいくらでも追加できる。つまり、追加できるサーバ数に制限はない。
以上のように本実施の形態に係る多重化データベースシステムによれば、サーバ100のデータベース101の記憶状況に拘わらず、サーバ100をシステムに組み込むことができる。すなわち、元々システムに組み込まれていたが障害により切り離されたサーバ(ディスク障害によりデータを失ってしまったものなども含む)であっても、全く新規のサーバであっても同様の手順でシステムに組み込むことができる。
また、仲介装置200においてデータ同期化用に差分情報蓄積部203に記憶する同期化用データは、これから組み込むサーバ100からの組み込み要求を受信してから蓄積を開始するので、仲介装置200において同期化用データが増大することがない。これにより、仲介装置200の記憶容量を節約でき、該記憶容量が溢れることによる障害発生を未然に防止できる。また、サーバ100の切り離しも任意に行うことができる。
したがって、本実施の形態に係る多重化データベースシステムでは、サーバの組み込み及び切り離しを任意に実施できるので、用途や予算などの要求に応じて柔軟なシステム設計を行うことができる。
本実施の形態の変形例について説明する。上記実施形態では、差分情報転送中にクライアント500から新たなクエリを受信すると、当該クエリを差分情報蓄積部203に追記していた。このような処理では、差分情報の処理に時間がかかる場合や、クライアントからの受信するクエリの受信間隔が短い場合には、差分情報蓄積部203のデータが何時までたっても空にならなかったり空になるまで長時間要することになり、結果として新規サーバ100bの組み込み処理完了まで長時間要することが考えられる。そこで、差分情報転送中に差分情報蓄積部203のエントリ数が所定数以下となったら、新規クエリの処理を一時保留して専ら差分情報の転送のみを行って差分情報蓄積部203を空にしてしまうと良い。以下、このような処理について図21を参照して説明する。
ここでは、新規のサーバ100bがスナップショットからデータベース101bの復元処理中であるとする(ステップS200)。そして、サーバ100bにおいてデータベース101bの復元処理が完了し(ステップS201)、サーバ100bが仲介装置200に差分情報転送要求を送信した時点で(ステップS202)、差分情報蓄積部203には所定件数以上の差分情報が蓄積されているものとする。図21の例では、ステップS203〜ステップS207によるUPDATEのクエリが最新の差分情報として差分情報蓄積部203に記憶されているものとする。
図21に示すように、仲介装置200のサーバ制御部210は、サーバ100bから差分情報転送要求を受信すると、前述したように、差分情報蓄積部203に記憶されている各クエリを古いものから順にサーバ100bに転送する処理を開始する(ステップS208)。
サーバ制御部210は、クライアント500bから新たなクエリを受信したとする。図21の例では、サーバ制御部210は、クライアント500bからデータを追加するSQL(INSERT)を含むパケットを受信する(ステップS209)。差分情報転送中に新規クエリを受信したサーバ制御部210は、受信したクエリを送信キュー204に入れる。そして、送信キュー204から当該クエリを取り出し、差分情報蓄積部203に蓄積されている未転送のクエリの件数が所定件数より多い場合には、このクエリを差分情報蓄積部203の最後に追記するとともに(ステップS210)、正常稼働中のサーバ100aに該パケットを転送する(ステップS211)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。サーバ制御部210は、INSERTが成功したことを示す応答パケットをサーバ100aから受信すると(ステップS212)、この応答パケットをクライアント500bに転送する(ステップS213)。
ここで、仲介装置200からサーバ100bへの差分情報の転送は並行して行われており、これにより差分情報蓄積部203に記憶されている未転送のクエリが所定数以下となったとする。
サーバ制御部210は、クライアント500bからデータを更新するSQL(UPDATE)を含むパケットを受信すると(ステップS214)、受信したクエリを送信キュー204に入れる。ここでは、差分情報蓄積部203に蓄積されている未転送のクエリの件数が所定件数以下となっているので、この新規クエリの処理は保留する(ステップS215)。すなわち、この新規クエリの差分情報蓄積部203への記憶及びサーバ100aへの転送は行わない。この保留処理は、差分情報蓄積部203に記憶されているクエリを全てサーバ100bに転送し、サーバ100bがシステムへ組み込まれるまで継続する。
差分情報の転送が終了すると(ステップS216)、差分情報蓄積部203に蓄積されている全てのクエリが転送・処理されることでデータベース101aと101bは完全に一致した状態(同期状態)になる。そこで、サーバ制御部210は、サーバ管理表201にサーバ100bを追加し稼働状態をactiveとすることでシステムにサーバ100bを追加する(ステップS217)。
ここで、サーバ制御部210は、前記ステップS215で保留していた新規クエリの処理を再開する。この時点では既に同期化が終了しているので、以降の処理は図6を参照して前述したものと同様となる。すなわち、サーバ制御部210は、当該クエリを送信キュー204から取り出して正常稼働中のサーバ、この場合サーバ100a及び100bに転送する(ステップS218,S219)。次いで、送信キュー204の送信状態を「送信完了」にして当該エントリを削除する。そして、各サーバ100a及び100bから受信した応答パケットを比較して障害発生の有無をチェックし(ステップS220〜S222)、正常な応答パケットの1つをクライアント500bへ転送する(ステップS223)。
このような処理により、差分情報の転送中にクライアントから受信したクエリは、未転送の差分情報が所定数より多い場合には差分情報蓄積部203への記憶及びサーバ100bへの転送が行われる。一方、未転送の差分情報が所定数以下の場合には新規クエリは保留される。これにより、差分情報の処理に時間がかかる場合やクライアントからの受信するクエリの受信間隔が短い場合であっても、データベースの同期を短時間に行うことができる。なお、閾値となる「所定件数」は、大きく設定すると新規クエリの保留時間が長くなる一方、小さく設定すると同期化処理完了までの時間が長引くことになるというトレードオフの関係にある。したがって、この「所定件数」は各装置の処理負荷やネットワーク速度などシステムの要件に応じて個々に最適な値を設定すればよい。また、本変形例において閾値を0以下に設定すれば、図12〜図20を参照して前述した実施例と同様の処理となる。
(第2の実施の形態)
本発明の第2の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第1の実施の形態と異なる点は、仲介装置から新規のサーバに転送する差分情報の内容にある。他の構成・動作等については第1の実施の形態と同様なので、ここでは相違点のみを説明する。
本発明の第2の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第1の実施の形態と異なる点は、仲介装置から新規のサーバに転送する差分情報の内容にある。他の構成・動作等については第1の実施の形態と同様なので、ここでは相違点のみを説明する。
第1の実施の形態では差分情報蓄積部203にはクライアント500から受信した全てのクエリを保存・転送していた。これにより、同期化処理を実施している間に正常稼働中のサーバ100で処理されたクエリを、新規のサーバ100においても忠実に再現することができるので、完全な同期化を図ることができる。
ところで、仲介装置から新規のサーバに転送する差分情報は専ら同期処理用にのみ用いられるので、該同期化において不要なクエリは転送する必要がない。具体的には、参照系クエリのSQL(SELECT)は不要である。なお、ここでは、SELECT FOR UPDATE文は、SELECT文の一種であるが更新処理に影響を与えるので、ここでは参照系クエリではなく更新系クエリとして取り扱うものとする。
そこで、本実施の形態では、第1の実施の形態と異なり、クライアント500から受信したクエリのうち、参照系クエリを除いたものを差分情報として新規のサーバ100に転送する。例えば、クライアント500から図22(a)に示すようなSQL文を受信したとすると、新規のサーバ100には図22(b)に示すようなSQL文を転送してやればよい。
このような処理を行うため、本実施の形態に係るサーバ制御部210は、第1の実施の形態と同様にクライアント500からクエリを受信した全てのクエリを差分情報蓄積部203に記憶する。そして、差分情報を新規サーバ100に転送するにあたって、まず該クエリが参照系クエリであるかを判別し、参照系クエリ以外を新規サーバ100に転送する。他の処理については第1の実施の形態と同様である。
本実施の形態によれば、第1の実施の形態と比較すると、新規サーバ100は同期化処理時において参照系クエリを処理する必要がないので同期化処理の短縮化を図ることができる。これは、複雑な参照系SQLや集合関数を含む参照系SQLなど処理負荷が大きい参照系SQLをクライアント500が発行している場合には特に有効である。他の効果については第1の実施の形態と同様である。
本実施の形態の変形例としては、サーバ制御部210が、同期化処理中にクライアント500からクエリを受信し、このクエリを差分情報として差分情報蓄積部203に蓄積するにあたって、まず該クエリが参照系クエリであるかを判別し、参照系クエリ以外を差分情報蓄積部203に記憶する。そして、差分情報の転送は差分情報蓄積部203に記憶されている全てのクエリを対象に行う方法が挙げられる。この変形例は、差分情報蓄積部203の記憶容量をさらに節約できるという効果を有する。
(第3の実施の形態)
本発明の第3の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第1の実施の形態と異なる点は、データベース同期化動作中における差分情報の蓄積処理にある。他の構成・動作等については第1の実施の形態と同様なので、ここでは相違点のみを説明する。
本発明の第3の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第1の実施の形態と異なる点は、データベース同期化動作中における差分情報の蓄積処理にある。他の構成・動作等については第1の実施の形態と同様なので、ここでは相違点のみを説明する。
第1の実施の形態では、サーバ制御部210は、クライアント500から受信した全てのパケットを差分情報蓄積部203に保存していた。すなわち、トランザクション制御SQL、参照系SQL及び更新系SQLの全てのSQLについて差分情報蓄積部203に保存し、サーバ100には差分情報蓄積部203に記憶されている全てのデータを古いものから順に送信していた。
一方、本実施の形態では、サーバ制御部210は、データベース同期化動作中にクライアント500から受信したパケットのうち、トランザクションの開始SQL(BEGIN)や確定SQL(COMMIT)や取消SQL(ROLLBACK)等のトランザクション制御SQL、及び、SELECTなど参照系のSQLについては保存せず、UPDATEやINSERTなどの更新系のSQLのうち正常稼働中のサーバ100でCOMMITされたもののみを差分情報蓄積部203に保存する。
ここで注意すべき点は、差分情報蓄積部203には、クライアント500から受信した順番ではなく、正常稼働中のサーバ100で処理された順番に更新クエリを蓄積することである。これは、更新対象が重複する更新クエリについては、その処理順序によってデータベース101の内容が異なってしまう可能性があるためである。
このような処理を実現するために、本実施の形態では、図23に示すような差分情報一時蓄積部205を新たに設けた。この差分情報一時蓄積部205のデータ構造は、差分情報蓄積部203と同様に、クライアントから受信したクエリと該クエリが属するトランザクションのIDとからなる。
サーバ制御部210は、同期化処理中にクライアント500からクエリを受信すると、更新系のもののみを順次、差分情報一時蓄積部205に蓄積するとともに、正常稼働中のサーバ100に転送する。一方、更新係以外のものについては、差分情報一時蓄積部205に蓄積することなく正常稼働中のサーバ100に転送する。
ここで、サーバ制御部210は、正常稼働中のサーバ100から更新クエリの実行が失敗したことを示す応答パケットを受信すると、当該更新クエリを差分情報一時蓄積部205から削除する。また、正常稼働中のサーバ100からトランザクションのROLLBACKが正常に完了したことを示す応答パケットを受信すると、サーバ制御部210は、当該トランザクションに属する全ての更新クエリを差分情報一時蓄積部205から削除する。一方、正常稼働中のサーバ100からトランザクションのCOMMITが正常に終了した応答パケットを受信すると、サーバ制御部210は、当該トランザクションに属する更新クエリについて差分情報一時蓄積部205から差分情報蓄積部203に順次移動させる。
以上のような処理により差分情報蓄積部203には、正常稼働中のサーバ100でCOMMITされた更新クエリのみが、その処理された順番で蓄積される。したがって、後に新規サーバ100から差分情報転送要求があったら、差分情報蓄積部203に記憶されている差分情報を蓄積されている順番で新規のサーバ100に転送すればよい。なお、新規のサーバ100のデータベース101は、仲介装置200からの更新クエリを順次処理するのみなので、この更新クエリはオートコミットモードで処理する。
このように、本実施の形態によれば、同期化処理には不要の参照系クエリ、BEGINやROLLBACKなどのトランザクション制御SQLを差分情報蓄積部203に蓄積することがないので、第1の実施形態と比較すると、差分情報の転送時間及びサーバでの処理時間を短縮化できる。他の効果については第1の実施の形態と同様である。
なお、本実施形態では、クライアント500から受信したクエリは、当該クエリの属するトランザクションが正常稼働中のサーバ100でCOMMITされた時点で、差分情報一時記憶部205から差分情報記憶部203へ移動されていたが、その変形例として、当該クエリが正常稼働中のサーバ100で正常処理された時点で移動するようにしてもよい。この場合には、トランザクションがROLLBACKしたらら該トランザクションに属する更新クエリを差分情報記憶部203から削除すればよい。このような処理は、例えばPostgreSQLのように、更新順序によって行の順番が変わるDBMSのデータベースを完全一致させるために有効である。
(第4の実施の形態)
本発明の第4の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第1の実施の形態と異なる点は、差分情報蓄積部の構造にある。他の構成・動作等については第1の実施の形態と同様なので、ここでは相違点のみを説明する。
本発明の第4の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第1の実施の形態と異なる点は、差分情報蓄積部の構造にある。他の構成・動作等については第1の実施の形態と同様なので、ここでは相違点のみを説明する。
本実施の形態に係る仲介装置200は、図25に示すように、第1の実施の形態とは異なり差分情報蓄積部203は設けず、送信キュー206に第1の実施形態における差分情報蓄積部203と送信キュー204の機能を統合させている。
本実施の形態に係る送信キュー206のデータ構造について図25を参照して説明する。送信キュー206は、クライアント500から受信したクエリの内容と、そのクエリの属するトランザクションIDと、各サーバ100への送信状態とを記憶する。トランザクションIDは、第1の実施の形態と同様に、トランザクション管理表202から取得される。各サーバ100への送信状態は、システムに属する各サーバ100毎に記憶される。
送信キュー206の各サーバ100への送信状態は、「未送信」,「送信完了」,「保留」の3つの値を取りうる。「未送信」は、クライアント500から受信したクエリが未だ当該サーバ100に送信されていない状態である。「送信完了」は、当該サーバ100への送信が完了した状態である。「保留」は、新規サーバ100のシステムへの組み込み処理中に、当該サーバ100への転送されることなく保留されている状態である。全てのサーバ100についての送信状態が「送信完了」になると、当該エントリは送信キュー206から削除される。
次に、サーバ制御部210の動作について説明する。サーバ制御部210は、クライアント500からクエリを受信すると、当該クエリがトランザクション開始SQL(BEGIN)の場合は当該トランザクションに対して新たなトランザクションIDを振り出してトランザクション管理表202に登録する。そして、当該クエリ内容,新規トランザクションID,各サーバ100の送信状態を「未送信」で送信キュー206に登録する。また、クライアント500から受信したクエリがトランザクション開始SQL(BEGIN)以外の場合は、当該クエリの属するトランザクションIDをトランザクション管理表202から取得し、当該クエリ内容,トランザクションID,各サーバ100の送信状態を「未送信」で送信キュー206に登録する。
サーバ制御部210は、送信キュー206に記録されているクエリを、その送信状態が「未送信」となっているサーバ100に対して送信し、当該サーバ100についての送信状態を「送信完了」に変更する。全てのサーバ100について送信状態が「送信完了」になったクエリについては送信キュー206から削除する。
仲介装置200からクエリを受信した各サーバ100は、当該クエリの処理を行い、応答パケットを仲介装置200に返す。仲介装置200のサーバ制御部210は、各サーバ100から受信した応答パケットを対比して障害発生の有無を確認し、正常な応答パケットの1つをクライアント500に返す。
一方、サーバ100から正当でない応答が仲介装置200に返ってきたり、応答そのものが返ってこない場合には、当該サーバ100に障害が発生したものとしてシステムから切り離す。具体的には、サーバ管理表201における当該サーバの稼働情報を「down」に変更するとともに、送信キュー206の送信状態の欄について当該サーバに関する項目を削除する。図26は、送信キュー206が図25に示すような状態でサーバ100bがシステムから切り離された場合の送信キュー206の一例である。
次に、新規サーバ100からシステムへの組み込み要求を受信した場合の動作について説明する。サーバ制御部210は、第1の実施の形態と同様に、組み込み要求受信時に実行中のトランザクションが終了するまで、新規トランザクションの開始は保留する。具体的には、クライアント500から受信したクエリが新規トランザクションに係るものの場合には、送信状態を「保留」として送信キュー206に保存する。一方、クライアント500から受信したクエリが組み込み要求時に実行中のトランザクションに係るものの場合には、送信状態を「未送信」として送信キュー206に保存する。図27は、送信キュー206が図26に示すような状態でクライアント500から新たにクエリを受信した場合の送信キュー206の一例である。図27の例では、三行目のトランザクションID=3のBEGINを除いて上のクエリから順に(古いクエリから順に)、トランザクションID=2のSELECT,トランザクションID=1のCOMMIT,トランザクションID=2のCOMMITの順に正常稼働中のサーバ100aへ転送され、その送信状態が「未送信」から「送信完了」に変更される。トランザクションID=3のBEGINは、新規のサーバ100bからスナップショット作成完了通知を受けた後に転送されることになる。
そして、組み込み要求受信時に実行中のトランザクションに係るクエリを全て正常稼働中のサーバ100に送信し終えると、サーバ制御部210は、送信キュー206に組み込み対象である新規のサーバ100の項目を追加する。ここで、送信キュー206には送信状態が「保留」となっているクエリが記憶されている場合がある。この場合、サーバ制御部210は、送信キュー206に記憶されているクエリーに対して、新規サーバ100についての送信状態を「保留」とする。図28は、図27の送信キュー206に対して新規サーバ100bの登録をした場合を示している。また、サーバ制御部210は、組み込み要求受信時に実行中のトランザクションに係るクエリを全て正常稼働中のサーバ100に送信し終えると、第1の実施の形態と同様に、正常稼働中のサーバ100に対してスナップショットの作成指示を送出する。
サーバ制御部210は、正常稼働中のサーバ100からスナップショット作成完了通知を受信すると、正常稼働中のサーバ100へのクエリの送信を再開する。具体的には、まず送信キュー206に記憶されている全てのクエリ(この時点では全てのクエリの送信状態は全てのサーバ100について「保留」になっている)について、正常稼働中のサーバ100の送信状態を「未送信」に変更する。そして、サーバ制御部210は、送信状態が「未送信」のクエリを当該サーバ100に順次送信し、送信が完了したら送信状態を「送信完了」に修正する。また、新たにクライアント500から受信したクエリは、正常稼働中のサーバ100についての送信状態は「未送信」、新規のサーバ100についての送信状態は「保留」にして送信キュー206に記憶する。図29は、図28の送信キュー206に対してスナップショット完了通知受信後に新たなクエリを受信した場合を示している。また、図30のように、正常稼働中のサーバ100aに対しては「送信完了」となっても新規のサーバ100bに対しては「送信完了」になっていない(「保留」になっている)ので、送信キュー206から当該クエリは削除しない。
新規のサーバ100が正常稼働中のサーバ100から受信したスナップショットを用いてデータベース101の復元が完了すると、サーバ制御部210は新規のサーバ100から差分情報転送要求を受信する。サーバ制御部210は、送信キュー206に記憶されているクエリであって、送信状態が「保留」となっているものを当該「保留」となっていたサーバ100、すなわち新規のサーバ100に古いものから順次送信する。送信したクエリについては、送信キュー206における当該サーバ100の送信状態を「送信完了」にし、全てのサーバ100についての送信状態が「送信完了」になったら当該エントリは削除する。
サーバ制御部210は、送信状態が「保留」となっているクエリが送信キュー206に存在しなくなると、サーバ管理表201に新規のサーバ100を「active」として追加することで、当該サーバ100をシステムに組み込む。以降の動作は各サーバ100が正常動作している場合のものと同様になる。
以上のように本実施の形態に係る仲介装置200では、第1の実施の形態における差分情報蓄積部203と送信キュー204の機能を、1つの送信キュー206に統合しているので、メモリの利用効率や処理効率が向上する。また、送信キュー206の各クエリに対して、各サーバ100への送信状態を記憶するようにしているので、新規サーバ100を組み込む際には当該サーバ100の送信状態を追加すればよい。これにより、一度に複数台のサーバ100をシステムに組み込むことができる。他の作用効果については第1の実施の形態と同様である。
なお、本実施の形態は、第1の実施の形態の変形例として説明したが、上記第2〜第3の実施の形態において同様の変形を適用できることは言うまでもない。
(第5の実施の形態)
本発明の第5の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第4の実施の形態と異なる点は、差分情報の蓄積方法にある。他の構成・動作等については第4の実施の形態と同様なので、ここでは相違点のみを説明する。
本発明の第5の実施の形態に係る多重化データベースシステムについて説明する。本実施の形態に係る多重化データベースシステムが第4の実施の形態と異なる点は、差分情報の蓄積方法にある。他の構成・動作等については第4の実施の形態と同様なので、ここでは相違点のみを説明する。
上述の第1の〜第4の実施の形態では、仲介装置200が正常稼働中のサーバ100にスナップショットの作成指示を送信するタイミングは、正常稼働中のサーバ100において実行中のトランザクションが無くなったときである。具体的には、新規サーバ100からの組込要求を受信した時点で実行中のトランザクションについて正常稼働中のサーバ100で処理を行うのと並行して、組込要求受信時以降にクライアント500から受信した新規トランザクションの開始要求を保留していた。そして、組込要求を受信した時に実行中のトランザクションが無くなった時点で、スナップショットの作成指示を送信している。これは、DBMSによっては、スナップショット作成時にトランザクションが実行中だと、そのトランザクションに属する更新クエリによるデータ更新がスナップショットに反映されるか否かが不確定となる場合を考慮したためである。
一方、本実施の形態では、サーバ100として、スナップショット作成時に実行中のトランザクションに属する更新クエリ及びスナップショット作成処理中に受信した更新クエリについては、当該スナップショットには反映しないという動作を行うものを用いる。これにより、本実施の形態に係る仲介装置200のサーバ制御部210は、組込要求受信時に実行中のトランザクションの終了を待つことなく、スナップショット作成指示の送信及び新規トランザクションの開始を行うことができる。なお、仲介装置200がスナップショット作成完了を待つ必要がないので、サーバ100のデータベース制御部102は、スナップショット作成が完了しても仲介装置200には完了通知を送信する必要はない。
このような処理を行うため、本実施の形態に係る仲介装置200のサーバ制御部210は、送信キュー206に記憶されている各クエリについて、全てのサーバ100について送信状態が「送信完了」となり、且つ、当該クエリに属するトランザクションが終了した場合に、当該クエリの登録を削除する。
以下、新規サーバ100をシステムに組み込む際の動作について図31〜図35を参照して説明する。いま、システムにはサーバ100aのみが組み込まれており、これから新たにサーバ100bを組み込むものとする。
サーバ制御部210は、新規サーバ100bから組込要求を受信すると、正常稼働中のサーバ100aに対して同期化指示(スナップショット作成指示)を送信する。新規サーバ100bが仲介装置200に対して組込要求を送信した際の送信キュー206の一例を図31に示す。前述したように、送信キュー206に記憶されたクエリは、当該クエリが送信完了しても該クエリの属するトランザクションが完了していないものは削除されずに残っている。同期化指示を受信したサーバ100aは、スナップショットの作成を開始する。ここで作成されるスナップショットは、送信キュー206に記憶されているクエリは反映されていないものである。また、サーバ制御部210は、新規サーバ100bから組込要求を受信すると、送信キュー206に記憶されている全てのクエリについて、当該新規サーバ100bの送信状態を「保留」にして追加する。この時の、送信キュー206の一例を図32に示す。
サーバ制御部210は、組込要求受信時以降にクライアント500からクエリを受信すると、正常稼働中のサーバ100aについては送信状態を「未送信」、新規サーバ100bについては送信状態を「保留」にして送信キュー206に順次追加する。そして、送信状態が「未送信」となっているクエリについては当該「未送信」のサーバ100aに対して順次転送し、送信状態を「送信完了」に変更していく。このとき、図33に示すように、送信キュー206に記憶されているクエリは、正常稼働中のサーバ100aについてはトランザクション単位で送信状態が「送信完了」となっているが、新規サーバ100bについては「保留」となっているので、ここではクエリの削除は行わない。
一方、仲介装置200からスナップショットの作成指示を受信したサーバ100aは、作成したスナップショットを新規のサーバ100bに送信する。新規のサーバ100bのデータベース制御部102bは、受信したスナップショットからデータベース101bを復元し、仲介装置200に差分情報転送要求を送信する。
差分情報転送要求を受信したサーバ制御部210は、送信キュー206に記憶されている送信状態が「保留」となっているクエリを差分情報として順次新規サーバ100bに送信し、図34に示すように、送信状態を「送信完了」に変更する。そして、前述したように、全てのサーバについて送信状態が「送信完了」となり、且つ、当該クエリのトランザクションが完了したら、そのクエリを削除する。以降、送信状態が「保留」のクエリの中の送信中にクライアント500からクエリを受信すると、図35に示すように、正常稼働中のサーバ100a及び新規サーバ100bの双方の送信状態を「未送信」で送信キュー206へ記憶する。そして、送信状態が「保留」のクエリが無くなった時点でデータベース100aとデータベース100bの同期が完了したことになる。
本実施形態によれば、システムで用いるサーバ100の機能的要件が限定されるためサーバ選択の幅が狭くなるものの、仲介装置200での処理が簡略化されるので処理効率の高いものとなる。
なお、本実施の形態では、サーバ100として、(1)トランザクション実行中でもスナップショットの作成開始ができ、(2)スナップショット作成中にクエリを処理可能であり且つ当該クエリがスナップショットに反映されないものを用いたが、(1’)トランザクション実行中でもスナップショットの作成開始ができるが、(2’)スナップショット作成中にはクエリを処理できない又はスナップショット作成中にクエリを処理すると当該処理がスナップショットに反映される場合があるようなサーバ100を用いることもできる。
ただし、この場合には、新規サーバ100から組込要求を受信すると直ちに正常稼働中のサーバ100に対してスナップショット作成指示を送信してよいが、スナップショット作成完了までは正常稼働中のサーバ100に対するクエリの送信を保留する必要がある。この保留処理の具体的な方法は上記第1の実施の形態と同様であるのでここでは説明は省略する。また、仲介装置200がスナップショットの作成完了を認識するために、スナップショットの作成が完了したサーバ100は、スナップショット作成完了を仲介装置200に通知する必要がある。これにより、本実施の形態よりもサーバ選択の幅が広いものとなる。
以上、本発明の実施形態について詳述したが、上記実施の形態は例示的なものであり、本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲に示されており、この特許請求の範囲の意味に入る全ての変形例は本発明に含まれるものである。
例えば、各サーバは要求に応じて同じ応答をするならば同じ実装である必要はない。すなわち、バージョン、仕様、プログラム言語、コンパイラの種類、コンパイラオプション、ハードウェアかソフトウェアか、などが異なっていてもよい。サーバには、PostgreSQLなどのフリーソフトウェアやOracleなどの市販のソフトウェア、独自開発のソフトウェア、いずれを使ってもよい。また、それらが混在していてもよい。例えば、サーバ100aはPostgreSQLでサーバ100bはOracleでも良い。
DBMSとしては、市中品(例えば、OracleやPostgreSQL)を使う場合は、データベース制御部102は、データベース管理部とデータベースサーバ管理部に機能を分けることによって、市中品を無改造で使うことができる。データベース管理部は、データベース101を直接操作するもので、例えばPostgreSQLの場合はpostmasterやpostgresに相当する。データベースサーバ管理部は、仲介装置200とデータベース管理部の間に介在し、クエリの送受信を中継したりするほかに、他のサーバを同期化する際のデータベース101のスナップショットを作成したり、そのスナップショットを他のサーバへ転送したりする処理を行う。
スナップショットの作成方法は、例えばDBMSがPostgreSQLならばpg_dumpなどのダンプツールやバックアップツールを使って実現する。なお、pg_dumpはPostgreSQLサーバ同士を同期化する場合には有用だが、異種のDBMS同士(例えばPostgreSQLとOracle)を同期化する場合には、DBMS固有のツールは使わずに、正常稼働中のDBMSサーバからSELECTクエリで全てのデータを取りだしINSERTクエリでデータを入れる汎用のツールを使えばよい。
また、上記実施の形態では、システムへの組み込み要求(新規サーバのデータベース同期化要求)は当該新規サーバ100のデータベース制御部102が仲介装置200へ送信しているが、保守端末などの他の装置から送信してもよいし、オペレータが仲介装置200に直接指示しても良い。
さらに、上記実施の形態では、サーバはパソコン上のソフトウェアで実現しているが、ハードウェアで実装しても良い。
また、上記実施の形態では、仮想サーバ800を構成する仲介装置200は1台のみであったが、複数台設けて冗長性を持たせることにより、より可用性の高い構成とすることも可能である。仲介装置を多重化させる技術については、例えば本願出願人による特開2003−345679号公報に記載されたものなどを用いればよい。
100…サーバ、101…データベース、102…データベース制御部、200…仲介装置、201…サーバ管理表、202…トランザクション管理表、203…差分情報蓄積部、204,206…送信キュー、205…差分情報一時蓄積部、210…サーバ制御部、300,400…ネットワーク、500…クライアント。
Claims (13)
- 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正常な応答の1つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおいて、新規の又はこのシステムから切り離されたデータベースサーバ(以後「新規データベースサーバ」と言う)をシステムに組み込む際に各データベースサーバのデータを同期化する方法であって、
仲介装置は、
クライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部を備え、
新規データベースサーバの組み込み要求があると、
(1a)正常稼働中のデータベースサーバに対してスナップショットの作成を指示し、
(1b)組み込み要求受信時以降にクライアントコンピュータから受信する処理要求を差分情報として差分情報記憶部に順次記憶し、
(1c)新規データベースサーバから差分情報転送要求を受信すると差分情報記憶部に記憶されている処理要求を新規データベースサーバに順次送出し、
(1d)差分情報記憶部に記憶されている処理要求の送出が終了すると差分情報の記憶処理を終了するとともに新規データベースサーバをシステムに組み込み、
正常稼働中のデータベースサーバは、
(2a)仲介装置からスナップショット作成指示を受信するとその時点でのデータベースのスナップショットの作成を開始し、
(2b)作成したスナップショットを新規データベースサーバに転送し、
新規データベースサーバは、
(3a)正常稼働中のデータベースサーバからスナップショットを受信すると該スナップショットを用いてデータベースを復元し、
(3b)スナップショットに基づきデータベースの復元が完了すると仲介装置に差分情報要求を送出し、
(3c)仲介装置から順次受信した処理要求に応じた処理を行う
ことを特徴とする多重化データベースシステムにおけるデータ同期化方法。 - 仲介装置は、
前記ステップ(1a)において、(1a1)組み込み要求受信時以降にクライアントコンピュータから受信する新規トランザクションに係る処理要求の処理開始を、正常稼働中のデータベースサーバからスナップショット作成完了通知を受信するまで保留し、(1a2)組み込み要求受信時点で処理中のトランザクションが全て終了したら正常稼働中のデータベースサーバに対してスナップショットの作成を指示し、
前記ステップ(1b)においては、正常稼働中のデータベースサーバからスナップショット作成完了通知があると組み込み要求受信時以降にクライアントコンピュータから受信する新規トランザクションに係る処理要求の処理を再開するとともに、該処理要求を差分情報として差分情報記憶部に順次記憶し、
正常稼働中のデータベースサーバは、
前記ステップ(2a)において、スナップショットの作成が完了すると仲介装置にスナップショット作成完了を通知する
ことを特徴とする請求項1記載の多重化データベースシステムにおけるデータ同期化方法。 - 仲介装置は、前記ステップ(1b)において、組み込み要求処理受信時に実行中のトランザクションに係る処理要求も差分情報として差分情報蓄積部に記憶する
ことを特徴とする請求項1記載の多重化データベースシステムにおけるデータ同期化方法。 - 仲介装置は、前記ステップ(1b)において、クライアントコンピュータから受信した全ての処理要求を差分情報蓄積部に記憶するとともに、前記ステップ(1c)において、差分情報記憶部に記憶されている全ての処理要求を新規データベースに送出する
ことを特徴とする請求項1乃至3何れか1項記載の多重化データベースシステムにおけるデータ同期化方法。 - 仲介装置は、前記ステップ(1b)において、クライアントコンピュータから受信した処理要求のうち参照系要求を除いたものを差分情報蓄積部に記憶するとともに、前記ステップ(1c)において、差分情報記憶部に記憶されている全ての処理要求を新規データベースに送出する
ことを特徴とする請求項1乃至3何れか1項記載の多重化データベースシステムにおけるデータ同期化方法。 - 仲介装置は、前記ステップ(1b)において、クライアントコンピュータから受信した全ての処理要求を差分情報蓄積部に記憶するとともに、前記ステップ(1c)において、差分情報記憶部に記憶されている処理要求のうち参照系要求を除いたものを新規データベースに送出する
ことを特徴とする請求項1乃至3何れか1項記載の多重化データベースシステムにおけるデータ同期化方法。 - 仲介装置は、前記ステップ(1b)において、クライアントコンピュータから受信した全ての処理要求を差分情報蓄積部に記憶するとともに、前記ステップ(1c)において、差分情報記憶部に記憶されている処理要求のうち正常稼働中のデータベースにおいて正常処理された処理要求のみを新規データベースサーバに送出する
ことを特徴とする請求項1乃至3何れか1項記載の多重化データベースシステムにおけるデータ同期化方法。 - 仲介装置は、前記ステップ(1c)において、差分情報記憶部に記憶されている処理要求のうち、トランザクション制御に係る処理要求及び参照系の処理要求を含まずに更新系の処理要求のみを新規データベースサーバに送出する
ことを特徴とする請求項7記載の多重化データベースシステムにおけるデータ同期化方法。 - 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正常な応答の1つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおいて、
仲介装置は、
クライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部と、
新規の又はこのシステムから切り離されたデータベースサーバ(以後「新規データベースサーバ」と言う)の該システムへの組み込み要求があると、正常稼働中のデータベースサーバに対してスナップショットの作成を指示し、組み込み要求受信時以降にクライアントコンピュータから受信する処理要求を差分情報として差分情報記憶部に順次記憶し、新規データベースサーバから差分情報転送要求を受信すると差分情報記憶部に記憶されている処理要求を新規データベースサーバに順次送出し、差分情報記憶部に記憶されている処理要求の送出が終了すると差分情報の記憶処理を終了するとともに新規データベースサーバをシステムに組み込む制御部とを備え、
データベースサーバは、
正常稼働中には、仲介装置からスナップショット作成指示を受信するとその時点でのデータベースのスナップショットの作成を開始し、作成したスナップショットを新規データベースサーバに転送するとともに、
システムへの組み込みを行う際には、正常稼働中のデータベースサーバからスナップショットを受信すると該スナップショットを用いてデータベースを復元し、スナップショットに基づきデータベースの復元が完了すると仲介装置に差分情報要求を送出し、仲介装置から順次受信した処理要求に応じた処理を行う制御部を備えた
ことを特徴とする多重化データベースシステム。 - 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正常な応答の1つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおける仲介装置であって、
クライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部と、
新規の又はこのシステムから切り離されたデータベースサーバ(以後「新規データベースサーバ」と言う)の該システムへの組み込み要求があると、正常稼働中のデータベースサーバに対してスナップショットの作成を指示し、組み込み要求受信時以降にクライアントコンピュータから受信する処理要求を差分情報として差分情報記憶部に順次記憶し、新規データベースサーバから差分情報転送要求を受信すると差分情報記憶部に記憶されている処理要求を新規データベースサーバに順次送出し、差分情報記憶部に記憶されている処理要求の送出が終了すると差分情報の記憶処理を終了するとともに新規データベースサーバをシステムに組み込む制御部とを備えた
ことを特徴とする仲介装置。 - 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正常な応答の1つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおける仲介装置を実現するプログラムであって、
コンピュータを、
クライアントコンピュータからの処理要求を差分情報として記憶する差分情報記憶部と、
新規の又はこのシステムから切り離されたデータベースサーバ(以後「新規データベースサーバ」と言う)の該システムへの組み込み要求があると、正常稼働中のデータベースサーバに対してスナップショットの作成を指示し、組み込み要求受信時以降にクライアントコンピュータから受信する処理要求を差分情報として差分情報記憶部に順次記憶し、新規データベースサーバから差分情報転送要求を受信すると差分情報記憶部に記憶されている処理要求を新規データベースサーバに順次送出し、差分情報記憶部に記憶されている処理要求の送出が終了すると差分情報の記憶処理を終了するとともに新規データベースサーバをシステムに組み込む制御部として機能させる
ことを特徴とする仲介プログラム。 - 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正常な応答の1つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおけるデータベースサーバであって、
正常稼働中には、仲介装置からスナップショット作成指示を受信するとその時点でのデータベースのスナップショットの作成を開始し、作成したスナップショットを、新規の又はこのシステムから切り離されたデータベースサーバ(以後「新規データベースサーバ」と言う)に転送するとともに、
システムへの組み込みを行う際には、正常稼働中のデータベースサーバからスナップショットを受信すると該スナップショットを用いてデータベースを復元し、スナップショットに基づきデータベースの復元が完了すると仲介装置に差分情報要求を送出し、仲介装置から順次受信した処理要求に応じた処理を行う制御部を備えた
ことを特徴とするデータベースサーバ。 - 複数のデータベースサーバと、クライアントコンピュータからの処理要求を各データベースサーバに中継するとともに各データベースサーバからの正常な応答の1つをクライアントコンピュータに処理結果として返す仲介装置とを備えた多重化データベースシステムにおけるデータベースサーバを実現するプログラムであって、
コンピュータを、
正常稼働中には、仲介装置からスナップショット作成指示を受信するとその時点でのデータベースのスナップショットの作成を開始し、作成したスナップショットを、新規の又はこのシステムから切り離されたデータベースサーバ(以後「新規データベースサーバ」と言う)に転送するとともに、
システムへの組み込みを行う際には、正常稼働中のデータベースサーバからスナップショットを受信すると該スナップショットを用いてデータベースを復元し、スナップショットに基づきデータベースの復元が完了すると仲介装置に差分情報要求を送出し、仲介装置から順次受信した処理要求に応じた処理を行う制御部として機能させる
ことを特徴とするデータベースサーバプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004109106A JP2007241322A (ja) | 2004-04-01 | 2004-04-01 | 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム |
PCT/JP2005/006483 WO2005096155A1 (ja) | 2004-04-01 | 2005-04-01 | 多重化データベースシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004109106A JP2007241322A (ja) | 2004-04-01 | 2004-04-01 | 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007241322A true JP2007241322A (ja) | 2007-09-20 |
Family
ID=38586850
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004109106A Pending JP2007241322A (ja) | 2004-04-01 | 2004-04-01 | 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007241322A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021096559A (ja) * | 2019-12-16 | 2021-06-24 | ヤフー株式会社 | データベース管理システム、データベース管理方法、およびプログラム |
-
2004
- 2004-04-01 JP JP2004109106A patent/JP2007241322A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2021096559A (ja) * | 2019-12-16 | 2021-06-24 | ヤフー株式会社 | データベース管理システム、データベース管理方法、およびプログラム |
JP7120985B2 (ja) | 2019-12-16 | 2022-08-17 | ヤフー株式会社 | データベース管理システム、データベース管理方法、およびプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2521037B1 (en) | Geographically distributed clusters | |
US7882286B1 (en) | Synchronizing volumes for replication | |
US5802062A (en) | Preventing conflicts in distributed systems | |
JP4668763B2 (ja) | ストレージ装置のリストア方法及びストレージ装置 | |
EP1704480B1 (en) | Cluster database with remote data mirroring | |
EP0974895A2 (en) | System for user control of version synchronization in mobile computing | |
US20050049945A1 (en) | Database log capture program that publishes transactions to multiple targets to handle unavailable targets by separating the publishing of subscriptions and subsequently recombining the publishing | |
US20070061379A1 (en) | Method and apparatus for sequencing transactions globally in a distributed database cluster | |
WO2010106991A1 (ja) | データの複製管理方法及びシステム | |
JP2001518663A (ja) | 高度に利用可能なクラスタ構成データベース | |
CN115098229A (zh) | 事务处理方法、装置、节点设备及存储介质 | |
WO2022170979A1 (zh) | 日志执行方法、装置、计算机设备及存储介质 | |
JP4136615B2 (ja) | データベースシステム及びデータベースのアクセス方法 | |
Rodrigues et al. | The GlobData fault-tolerant replicated distributed object database | |
JP2006338145A (ja) | 多重化データベースシステム及びその同期化方法、仲介装置、仲介プログラム | |
JP4998010B2 (ja) | データベースシステム管理、データベースシステム、プログラム及び処理装置 | |
JP2007241323A (ja) | 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム | |
JP2007241322A (ja) | 多重化データベースシステム及びそのデータ同期化方法、仲介装置、仲介プログラム、データベースサーバ、データベースサーバプログラム | |
WO2007028249A1 (en) | Method and apparatus for sequencing transactions globally in a distributed database cluster with collision monitoring | |
CN102508891B (zh) | 一种基于丢弃的多元数据服务器元数据日志一致性的方法 | |
KR100503899B1 (ko) | 데이터베이스 복제시스템 및 그 복제방법 | |
AU2011265370B2 (en) | Metadata management for fixed content distributed data storage | |
JP4138329B2 (ja) | データ処理システム及びデータ処理方法 | |
JP2850756B2 (ja) | 分散処理システムにおけるファイルの障害復旧方式 | |
Mehrotra et al. | Dealing with partial failures in multiple processor primary-backup systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080507 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20081014 |