次に、本発明の実施形態について図面を参照して説明する。
(第1の実施形態)
図1は、本発明の第1の実施形態である分散トランザクション処理システムの主要な構成を示すブロック図である。
図1を参照すると、本実施形態の分散トランザクション処理システムは、それぞれがトランザクション要求に応じた処理を実行する複数のデータサーバ111〜11nと、これらデータサーバ111〜11nに対するトランザクション要求を調停するトランザクション管理サーバ10と、を有する。データサーバ111〜11nおよびトランザクション管理サーバ10のそれぞれは、ネットワーク12に接続されており、相互通信が可能である。
トランザクション要求は、不図示のアプリケーションサーバからトランザクション管理サーバ10を介してデータサーバ111〜11nに供給される。トランザクション管理サーバ10は、コーディネータであって、アプリケーションサーバからのトランザクション要求を、トランザクションに関わるデータを保有するデータサーバ111〜11nに配信する。
データサーバ111〜11nのそれぞれが、トランザクション要求の実行状態を表すトランザクション状態情報を管理し、外部からの収集要求に応じて該トランザクション状態情報をその収集要求元に供給する。
収集要求元は、トランザクション管理サーバ10や、データサーバ111〜11nのうち、障害が発生し、その障害が復旧したデータサーバ等である。ここでの復旧とは、障害前のメモリ状態以外のディスクなどに記録された、不揮発性の情報は、障害発生前の状態になることである。
トランザクション管理サーバ10が収集要求元になるシチュエーションとしては、次の2つがある。第1は、トランザクション管理サーバ10において、障害が発生し、その障害が復旧した場合に、復旧したトランザクション管理サーバ10が、上記の収集要求元となるケースである。第2は、ネットワーク12に接続された不図示の別のトランザクション管理サーバに障害が発生した場合で、この別のトランザクション管理サーバに障害が発生し、その代替えとしてトランザクション管理サーバ10が用いられる場合に、トランザクション管理サーバ10が上記の収集要求元となるケースである。
第1のケースにおいて、復旧したトランザクション管理サーバ10は、障害発生時に自身が調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、データサーバ111〜11nから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、データサーバ111〜11nのそれぞれについて、仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。具体的には、最終状態に従ったトランザクション処理要求を、仕掛中のトランザクションに関わるデータサーバに送信することで、データの整合性をとる。
ここで、トランザクション状態情報の収集動作を具体的に説明する。トランザクション管理サーバ10は、トランザクションに係わるデータを自サーバ内のメモリ上に保持しているため、ダウン後は、トランザクション状態が分からない。データサーバ111〜11nのそれぞれは、トランザクション要求に応じた処理を実行し、その実行状態を示すトランザクション状態情報を、トランザクション要求元のトランザクション管理サーバ10の識別情報(ID)と対応付けて管理する。復旧したトランザクション管理サーバ10は、自身のIDを保持しており、そのIDを引数として用いた収集要求をデータサーバ111〜11nに配信する。データサーバ111〜11nは、収集要求に応じて、引数としてのIDに基づいて該当するトランザクション状態情報をトランザクション管理サーバ10に返信する。
第2のケースにおいて、トランザクション管理サーバ10は、別のトランザクション管理サーバにて障害が発生したことを検知する。障害発生を検知すると、トランザクション管理サーバ10は、その障害が発生したトランザクション管理サーバの識別情報(ID)を引数として用いた収集要求を、そのトランザクション管理サーバが調停していた仕掛中のトランザクションに関わるデータサーバに送信する。データサーバは、その収集要求に応じて、引数としてのIDに基づいて該当するトランザクション状態情報をトランザクション管理サーバ10に返信する。こうして、トランザクション管理サーバ10は、障害が発生した別のトランザクション管理サーバが調停していた仕掛中のトランザクションに係わるトランザクション状態情報を、そのトランザクションに関わるデータサーバから収集する。そして、トランザクション管理サーバ10は、収集したトランザクション状態情報に基づいて、仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクションに関わるデータサーバについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。この整合性をとるための処理も、上記の第1のケースと同様、最終状態に従ったトランザクション処理要求を、仕掛中のトランザクションに関わるデータサーバに送信することで実行される。
データサーバ111〜11nのそれぞれは、自データサーバにて障害が発生した場合に、その障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションに係わるトランザクション状態情報を他のデータサーバから収集し、該収集した情報に基づいて、該仕掛中のトランザクションの最終状態を決定し、該決定した最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。
本実施形態の分散トランザクション処理システムによれば、データサーバ111〜11nのトランザクション状態を共有ディスクで管理するのではなく、データサーバ111〜11nのそれぞれで個別に管理する。すなわち、データサーバ111〜11nのそれぞれがトランザクション状態を永続化する。また、データサーバ111〜11nのそれぞれは、収集要求に応じて、自データサーバで管理しているトランザクション状態情報をその収集要求元に供給する。
トランザクション管理サーバ10は、自サーバに障害が発生し、その障害から復旧した場合に、仕掛中のトランザクションに係わるトランザクション状態情報をデータサーバ111〜11nから収集することで、ディスクI/Oの実行なしで、自サーバの最終の状態(障害発生時点または発生直前の状態)を決定することができる。この結果、ディスクI/Oによる高負荷を回避でき、代替えのトランザクション管理サーバに負荷をかけずに、BASE特性を実現できる。
別のトランザクション管理サーバに障害が発生した場合は、トランザクション管理サーバ10が、その代替えのサーバとして動作する。この場合、トランザクション管理サーバ10は、別のトランザクション管理サーバにて実行されていた仕掛中のトランザクションに係わるトランザクション状態情報を、そのトランザクションに関わるデータサーバから収集することで、ディスクI/Oの実行なしで、別のトランザクション管理サーバの最終の状態(障害発生時点の状態)を決定することができる。この場合も、ディスクI/Oによる高負荷を回避でき、代替えのトランザクション管理サーバに負荷をかけずに、BASE特性を実現できる。
また、データサーバ111〜11nのいずれかに障害が発生し、その障害が発生したデータサーバが復旧した場合、復旧したデータサーバは、トランザクション管理サーバ10にアクセスすることなく、他のデータサーバからそれぞれのトランザクション状態情報を収集して自データサーバに関するトランザクションの最終状態を決定することができる。この結果、コーディネータに負荷をかけずに、BASE特性を実現できる。
加えて、トランザクション状態を共有ディスクで永続化する必要がなく、トランザクション管理サーバ10と別のトランザクション管理サーバとの間で、メモリやディスクで永続化したトランザクション状態の同期をとる必要もない。よって、データサーバ等に障害が発生していない通常動作時において、トランザクション管理サーバにおけるネットワークI/OおよびディスクI/Oの発生を抑制することができる。
トランザクション管理サーバまたはデータサーバにて障害が発生した場合で、その障害の復旧後に、トランザクション管理サーバ側ではトランザクションは完結したにも関わらず、データサーバ側では、それがデータに反映されていないことによる、データの不整合が生じる。第1のケースでは、トランザクション管理サーバ10が、復旧後に、仕掛中のトランザクションの最終状態に基づいて、データサーバ111〜11nのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。これにより、それぞれのデータサーバに対するトランザクションの一貫性を保つことができる。この結果、全データサーバ間でのトランザクション状態が同じ(完結)(commit/rollback)になる。
第2のケースでは、トランザクション管理サーバ10が、障害が発生した別のトランザクション管理サーバの仕掛中のトランザクションの最終状態に基づいて、データサーバ111〜11nのそれぞれについて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。この場合も、各データサーバに対するトランザクションの一貫性を保つことができる。
データサーバ111〜11nのそれぞれは、障害の復旧後に、自データサーバで実行していた仕掛中のトランザクションの最終状態に基づいて、該仕掛中のトランザクション前後におけるデータの整合性をとるための処理を行う。これによっても、各データサーバに対するトランザクションの一貫性を保つことができる。
図2は、図1に示した構成を適用した分散トランザクション処理の動作の一例を説明するための模式図である。
図2に示す分散トランザクション処理システムは、アプリケーションサーバ(APS)20、コーディネータ21、22およびデータサーバ23〜25からなる。コーディネータ22は、コーディネータ21の代替えとなるサーバであって、図1に示したトランザクション管理サーバ10に対応する。コーディネータ21は、前述した第2のケースにおける別のトランザクション管理サーバに対応する。データサーバ23〜25は、図1に示したデータサーバ111〜11nに対応する。
コーディネータ21は、メモリ21aを有し、トランザクション状態を更新サーバリスト21bとしてメモリ21aに保持する。アプリケーションサーバ20からコミット要求を受けると、コーディネータ21は、データサーバ23〜25に対してプリペア要求を送信する。このとき、コーディネータ21は、メモリ21aで保持しているトランザクション状態情報(更新サーバリスト21b)も一緒にデータサーバ23〜25に送信する。
データサーバ23は、ディスク装置または半導体メモリよりなる記憶部23aを有し、プリペア要求に応じた処理を実行した後は、自身のトランザクション状態を記憶部23a上で永続化する。データサーバ24、25も、データサーバ23と同様の構成であり、それぞれが記憶部24a、24aを有し、プリペア実行後に、自身のトランザクション状態を永続化する。
なお、プリペア要求の前に、コーディネータ21がダウンした場合は、アプリケーションサーバ20は、コーディネータ21のダウンを検知し、そのトランザクションがロールバックされたとみなし、トランザクションは復旧されない。
プリペア要求の送信後、コーディネータ21は、データサーバ23〜25に対してコミット要求を送信する。データサーバ23は、コミット要求に応じた処理を実行した後は、記憶部23a上で永続化しているトランザクション状態(更新サーバリスト23b)を更新する。同様に、データサーバ24、25も、コミット実行後に、永続化しているトランザクション状態(更新サーバリスト24b、25b)を更新する。
データサーバ23〜25によるコミット要求に応じた処理が正常に終了した場合、コーディネータ21は、データサーバ23〜25の全てからコミット/ロールバックの実行完了応答を受信する。この実行完了応答の受信後、コーディネータ21は、メモリ21a上で管理しているコミット/ロールバックの処理がなされたトランザクションに関する情報(更新サーバリスト21bなど)を全て削除する。
データサーバ23〜25のいずれかで、コミット要求に応じた処理が異常終了した場合、コーディネータ21は、障害の発生したデータサーバに対して、コミット/ロールバック要求を再度送信する。図2では、データサーバ25が異常終了している状態が示されている。
再度のコミット/ロールバック要求の送信を行っても、正常終了せずに、タイムアウトした場合、コーディネータ21は、該当トランザクション情報を全て削除する。その後、データサーバが復旧した際には、その復旧したデータサーバは、コーディネータ21を介さずに、他のデータサーバからトランザクション状態情報を収集して自身のトランザクションの最終状態(障害発生時点のトランザクションの状態)を決定し、トランザクション処理を完了させる。この動作は、図1に示したシステムにおける障害から復旧したデータサーバにて行われる動作に対応する。
プリペア要求の送信後にコーディネータ21がダウンした場合には、その代替えであるコーディネータ22が、データサーバ23〜25に対して、それぞれが保持しているトランザクション状態を更新サーバリストとして返却するように一斉に問い合わせを行う。データサーバ23〜25から返却されたトランザクション状態のうち、少なくとも1つがコミット実行完了状態であり、且つ、あるデータサーバから受信したトランザクション状態がプリペア実行完了状態である場合は、コーディネータ22は、そのデータサーバに対して、コミット要求を送信する。これにより、トランザクションに関わる全データサーバの更新処理の状態がコミット実行完了状態となるため、トランザクション処理を完遂させることができる。この動作は、図1に示したシステムにおけるトランザクション管理サーバ10が代替えのサーバとして動作した場合の動作(第2のケースの動作)に対応する。
上記のような動作によれば、コーディネータによるトランザクション状態の管理をメモリ上で行うので、コーディネータのディスクI/Oを減らすことができる。
また、データサーバへのプリペア要求の送信時にトランザクション状態も一緒に送信され、データサーバのそれぞれでトランザクション状態の永続化および更新を個別に行う。この場合、図16に示したシステムにおける共有ディスクへのアクセスや、特許文献1に記載されたような方法における同期をとるために必要とされるネットワークI/Oは不要である。よって、ディスクI/OやネットワークI/Oの発生を抑制することができる。
さらに、コーディネータ異常時に、データサーバからトランザクション状態を収集することで、仕掛り中のトランザクションを復旧し、BASE特性を実現することができる。
一方、データサーバ障害時には、コーディネータを介さず、トランザクションに関わったデータサーバのみで、トランザクション処理を完了させることができる。
例えば、障害が発生し、その障害が復旧したデータサーバは、再起動時に、自身が永続化している更新サーバリストに載っているデータサーバから、更新サーバリストを収集する。そして、得られた更新サーバリストの内容に基づいて、自身の仕掛中トランザクションの最終状態を決定し、トランザクション処理を完遂させる。
このように、各データサーバが個別にトランザクション状態を永続化することで、データサーバ障害時に、コーディネータを介させずに、トランザクション処理を完遂させることができるので、コーディネータのディスクI/OやネットワークI/Oを軽減させることができる。
なお、図2に示した構成において、コーディネータ22は、自身に障害が発生し、その障害が復旧した場合に、自身が調停していた仕掛中のトランザクションについて、それぞれが保持しているトランザクション状態を更新サーバリストとして返却するように一斉に問い合わせてもよい。この場合も、例えばデータサーバ23〜25から返却されたトランザクション状態のうち、少なくとも1つがコミット実行完了状態であり、且つ、あるデータサーバから受信したトランザクション状態がプリペア実行完了状態である場合は、コーディネータ22は、そのデータサーバに対して、コミット要求を送信する。これにより、トランザクションに関わる全データサーバの更新処理の状態がコミット実行完了状態となるため、トランザクション処理を完遂させることができる。この動作は、図1に示したシステムにおけるトランザクション管理サーバ10の障害復旧時の動作(第1のケースの動作)に対応する。
(第2の実施形態)
図3は、本発明の第2の実施形態である分散トランザクション処理システムの構成を示すブロック図である。
本実施形態の分散トランザクション処理システムは、アプリケーションサーバ(APS)30、コーディネータ31、死活監視サーバ32および複数のデータサーバ33からなる。アプリケーションサーバ30および死活監視サーバ32は、既存のシステムに用いられているもので実現可能である。
コーディネータ31は、アプリケーションサーバ30からのトランザクション要求を、そのトランザクションに関わるデータを保有する複数のデータサーバ33に配信する。
図4Aは、コーディネータが調停するトランザクションの状態遷移を説明するための図である。
図4Aを参照すると、トランザクションの状態は5つに分類され、それぞれ「begin」の状態S11、「更新済」の状態S12、「prepare実行完了」の状態S13、「commit実行完了」の状態S14、「rollback実行完了」の状態S15とされている。
アプリケーションサーバからトランザクション開始要求を受信すると、コーディネータの状態は「begin」の状態S11に遷移し、それをトランザクションの開始とみなす。トランザクションの開始後、アプリケーションサーバからデータ更新要求を受信すると、コーディネータの状態は「更新済」の状態S12に遷移する。
「prepare実行完了」の状態S13は、commitもしくはrollbackの準備ができたことを表す状態である。「prepare実行完了」の状態S13と「commit実行完了」の状態S14または「rollback実行完了」の状態S15との間に発生した更新要求は無視する。
「commit実行完了」の状態S14は、「begin」の状態S11から「prepare実行完了」の状態S13までのデータ更新を全てデータベースに反映した状態である。「rollback実行完了」の状態S15は、「begin」の状態S11から「prepare実行完了」の状態S13までのデータ更新を全て中止した状態である。
したがって、「begin」の状態S11がトランザクションの開始状態であり、「commit実行完了」の状態S14と「rollback実行完了」の状態S15は、トランザクションの最終状態である。また、トランザクションの途中状態には、「更新済」の状態S12と「prepare実行完了」の状態S13がある。
図4Aにおいて、状態遷移の入力は、「入力元サーバ:入力データ」の組で表記する。
図4Bは、データサーバが調停するトランザクションの状態遷移を説明するための図である。
図4Bを参照すると、トランザクションの状態は4つに分類され、それぞれ「更新済」の状態S21、「prepare実行完了」の状態S22、「commit実行完了」の状態S23、「rollback実行完了」の状態S24とされている。
コーディネータからデータ更新要求を受信すると、データサーバの状態は「更新済」の状態S21に遷移する。
「prepare実行完了」の状態S22は、commitもしくはrollbackの準備ができたことを表す状態である。「prepare実行完了」の状態S22と「commit実行完了」の状態S23または「rollback実行完了」の状態S24との間に発生した更新要求は無視する。
「commit実行完了」の状態S23は、「更新済」の状態S21から「prepare実行完了」の状態S22までのデータ更新を全てデータベースに反映した状態である。「rollback実行完了」の状態S24は、「更新済」の状態S21から「prepare実行完了」の状態S22までのデータ更新を全て中止した状態である。これら「commit実行完了」の状態S22と「rollback実行完了」の状態S23は、データサーバにおけるトランザクションの最終状態である。
図4Aおよび図4Bに示したトランザクション状態の遷移の契機は、コーディネータがトランザクション要求を受信し、その要求がデータサーバで実行され、正常に実行が完了し、その旨を通知できた場合のみである。
詳細に説明すると、トランザクション要求の発信元サーバがアプリケーションサーバである場合、発信先はコーディネータである。トランザクション要求の発信元サーバがコーディネータである場合、発信先はデータサーバである。一方、トランザクション要求の完了応答の発信元サーバがデータサーバである場合、発信先はコーディネータである。
入力トランザクション要求は、begin要求、データ更新要求、prepare要求、commit要求、rollback要求の5種類に分類される。
図4Aおよび図4Bにおいて、遷移先のない入力については状態遷移が発生せず、異常状態とする。ここでは、異常状態については説明しない。ただし、異常状態以外について、「begin」の状態からprepare要求、rollback要求、commit要求を受信することもあるが、それら要求は無視して処理せず、状態についても、初期化される。
次に、図3に示したアプリケーションサーバ30、コーディネータ31、死活監視サーバ32およびデータサーバ33のそれぞれの構成や役割について説明する。
図5に、コーディネータ31、死活監視サーバ32およびデータサーバ33のそれぞれの機能モジュールを示す。
アプリケーションサーバ30は、アプリケーションプログラムから構成され、コーディネータ31へトランザクション要求(begin、データ更新、prepare、commit、rollback)を送信する。なお、アプリケーションサーバ30は、本発明の特徴部を構成するものではないので、ここでは、その詳細な説明を省略する。
コーディネータ31は、CPUとメモリとディスクを保持する計算機より構成されるものであって、アプリケーションサーバ30から受信したトランザクション要求を解析し、操作対象のデータを保持する複数のデータサーバにデータ操作要求を送信する。
具体的には、図5に示すように、コーディネータ31は、トランザクション受信部310、トランザクション解析部311、データ操作送受信部312およびリカバリ部313を有する。
コーディネータ31では、アプリケーションサーバ30からのトランザクション要求は、トランザクション受信部310で受信される。トランザクション受信部310にて、アプリケーションサーバからトランザクションを受け付けると、トランザクション解析部311が、該当するトランザクションを解析する。
図6に、トランザクション解析部311にて行われるトランザクション解析処理の一手順を示す。
まず、アプリケーションサーバから取得したトランザクションの要求として受信したトランザクション要求を、トランザクションリストの「受信トランザクション要求」に退避する(ステップS30)。
次に、トランザクション要求がbeginであるか否かを判定する(ステップS31)。トランザクション要求がbeginである場合は、トランザクションリストに、新規トランザクションを登録して(ステップS32)、処理を終了する。この場合、コーディネータ31は、begin要求をデータサーバ33に通知しない。これにより、データサーバ33とのネットワーク通信が発生しないため、オーバヘッドを削減できる。
ここで、トランザクションリストとは、コーディネータが調停している仕掛中トランザクションをリストとして保持するものである。図7に示すように、トランザクションリスト34は、トランザクション要求の内容および識別子(ID)からなる。
トランザクションリストへの新規トランザクションの登録は、コーディネータ31がアプリケーションサーバ30からのトランザクション開始のbegin要求を受信した際に、トランザクションを一意に識別するためのID(以下、TxID)を生成し、新規トランザクションとしてトランザクションリスト34に登録する。
トランザクションとして、begin要求を受信したとき、そのトランザクションのIDと、それに関するワークスペースは存在しない。したがって、トランザクションを生成した場合は、ワークスペース36も同時に生成される。なお、初回の生成時には、ワークスペース内に受信したトランザクション要求を記憶する。また、更新時やcommit/rollbackの要求を受信した際も、ワークスペース内に受信したトランザクション要求を更新する。ワークスペース36には、トランザクションが受信したトランザクション要求と、更新操作に関連するデータサーバおよびトランザクション状態のリストを示す更新サーバリスト35とが、更新が発生するごとに追加される。
受信トランザクション要求の利用目的は、主にアプリケーションサーバ30からcommit/rollback要求を受信した際に、データサーバ33に送信すべき要求を記憶することである。なぜなら、2相コミットの形態では、データサーバが管理するトランザクションには、prepare実行完了状態がある。このため、受信トランザクション要求と更新サーバリスト内のデータサーバが管理するトランザクション状態が異なる場合がある。
例えば、図7に示した例では、TxID=1の受信トランザクション要求はrollbackであり、更新サーバリスト35に記載のデータサーバB、データサーバCのトランザクション状態はprepareである(データサーバのトランザクション状態は、コーディネータにprepare実行完了応答が通知されてから更新される)。
再び、図6を参照する。ステップS31で、トランザクション要求がbeginでないと判定された場合は、続いて、トランザクション要求がデータ更新であるか否かの判定を行う(ステップS33)。トランザクション要求がデータ更新である場合は、そのトランザクション要求が登録されていないかを判定する(ステップS34)。
ステップS34で、トランザクション要求が登録されていないと判定された場合は、TxIDで示されるトランザクションにおいて更新されたデータを保有するデータサーバを更新サーバリストに登録する(ステップS35)。なお、データサーバが更新サーバリストにすでに登録されている場合は、そのデータサーバの追加登録は行わない。
ここで、トランザクションのデータ構造について説明する。トランザクションは、1つ以上のステートメント(SQL文などの命令文)から構成され、ステートメントには、操作対象データを識別できる識別情報が含まれている。トランザクション解析部111は、SQL文から操作対象のデータを識別する手段として、SQL文の構文解析・意味解析などの既存技術を用いて、データ更新要求受信時に、どのkeyが操作対象なのかを識別することができ、データサーバ対応表を用いて、そのkeyを含むデータIDと、そのkeyを保有するデータサーバを決定することができる。
データサーバ対応表は、図8に示すように、データID、キーレンジおよびデータサーバIDの3つの項目からなる。データサーバ対応表は、トランザクション要求が来るたびに、更新データを保有するデータサーバを決定するために利用される。
データサーバを決定すると、データサーバリストにあるデータサーバごとに、トランザクションにおけるデータ更新後の値を(データID、key、value)の形式で、トランザクションごとにリスト化する(ステップS36)。
図9に、データサーバごとに管理されるトランザクションごとの更新対象データリストの一例を示す。更新対象データリスト37は、データサーバリスト36にあるデータサーバごとに生成される。
ここで、トランザクションが扱うデータ型はリレーショナル・データモデルでも適用可能であるが、簡単のため、key-valueストアモデルとする。データIDは、テーブルを構成するレコードの集合を表す一意の識別子である。レコード内の1レコードを表すためにkeyというテーブル内で一意の識別子を利用し、keyに紐づけられたvalueに対して操作を行う。
ステップS33で、トランザクション要求がデータ更新でないと判定された場合は、続いて、トランザクション要求がcommitまたはrollbackであるか否かを判定する(ステップS37)。
ステップS37で、トランザクション要求がcommitまたはrollbackであると判定された場合は、更新サーバリストに記載のデータサーバに対してprepareを送信し、commit/rollbackの準備ができた段階で、commit/rollbackを送信する必要がある。したがって、ステップS38で、トランザクション要求をprepareとする。
トランザクション解析部311によって、関連するデータサーバへのデータ操作要求を配信する準備が完了した後、データ操作要求送受信部312が、データサーバリスト内の各データサーバに対して、リスト化されているトランザクションごとの更新対象データリストを送信する。
アプリケーションサーバ30からのトランザクション要求が、commit/rollbackである場合は、2相コミットのため、コーディネータ31は、ワークスペース内の更新サーバリストに記載されたデータサーバにprepareを送信する。その後、prepareに対する実行完了応答がデータサーバからコーディネータ31に返却されると、コーディネータ31は、データサーバごとのトランザクション状態をprepareに変更する。そして、更新サーバリスト内の全データサーバの実行完了応答が返ってきた時点で、コーディネータ31は、受信トランザクション要求(commit/rollback)を、更新サーバリスト内の全データサーバに送信する。
本実施形態によれば、BASE特性を実現しているため、1つのデータサーバからcommit/rollback実行完了応答が返却された時点で、コーディネータ31は、アプリケーションサーバ30に実行完了応答を返却する。この手段によれば、アプリケーションサーバ30へのレスポンスタイムを短縮できる。
また、コーディネータ31は、図7〜図9に示した情報を全てメモリ上で管理する。また、リカバリログについては、コーディネータ31側では記録せず、各データサーバ33側で、自身が管理するデータの更新に対するリカバリログをとる。この手段によれば、コーディネータ31のディスクアクセスを回避できる。
再び、図5を参照すると、データサーバ33は、CPUとメモリとディスクを保持する計算機よりなり、コーディネータ31からのデータ操作要求を、自身が保有するデータに反映させる。具体的には、データサーバ33は、データ操作要求受信部330、データ操作要求実行部331、ログ管理部332、リカバリ部333およびデータベース334を有する。
データサーバ33では、データ操作要求受信部330が、コーディネータ31からデータ操作要求を受信し、その後、データ操作要求実行部331が、解釈された要求を実行する。解釈された要求がデータ更新要求である場合、データ操作要求実行部331は、対象データにロックをかけ、更新後にロックを解除する。これにより、トランザクション間の排他制御を実現する。その後、ログ管理部333が、データ操作要求について、メモリ上にリカバリログを作成する。リカバリログに書き込む内容については、後述する。
図10を参照して、データサーバ33の管理情報について説明する。図10に示す例は、データサーバAの管理情報である。
図10を参照すると、データサーバ33は、メモリ33aおよびディスク33bを有する。ディスク33bは、図5に示したデータベース334を構成するものである。
コーディネータ31からのデータ操作要求を受信すると、データ操作要求実行部331がデータ操作要求を実行した後、ログ管理部333が、メモリ33a上に、リカバリログ333aを追加書き込みする(リカバリログは時系列で書き込まれる)。1回の更新操作に対して、(コーディネータID、データID、更新対象のキー、更新後の値)の組の情報が書き込まれる。
コーディネータ31からprepare 要求を受信するまでは、データサーバ33において、メモリ33a上でリカバリログ333aを管理する。コーディネータ31から、あるトランザクションのprepare要求を受信すると、データサーバ33において、ログ管理部333は、2つのファイル334a、334bを生成する。
ファイル334aは、図10に示すprepare対象トランザクションの更新後情報を含むファイルである。更新後情報は、対象のトランザクションのリカバリログだけをメモリ33a上から抽出したものである。ファイル334aは、ディスク33bに格納される。
ファイル334bは、コーディネータ31からのprepare要求の引数として受信した、prepare要求対象のトランザクションに対するワークスペース情報であり、コーディネータ31が保持しているワークスペース情報を、更新サーバリスト内の自身のトランザクション状態のみをprepare実行完了状態に変更した上で、ファイルに書き出すことで生成される。
これらファイル334a、334bは、ディスク33b上で永続化される。その際、更新サーバリスト内の自身が管理するトランザクション状態のみprepare実行完了状態となる。
その後、データサーバ33は、コーディネータ31にprepare実行完了応答を行う。コーディネータ31は、prepare実行完了応答を該当する全データサーバから受信した後に、該当する全データサーバに一斉にcommit/rollback要求を配信する。commit/rollback要求を受信したデータサーバは、更新後情報を実際に、データベース334に反映させ、ワークスペース内の自身が管理するトランザクション状態をcommitに更新する。
再び、図5を参照すると、死活監視サーバ32は、サーバ死活監視部320と代替サーバ通知部321から構成される。死活監視部320は、コーディネータ31が正常に動作しているかダウンしているかを監視する。代替サーバ通知部321は、ダウンしたコーディネータの替わりとなる待機中のコーディネータに、コーディネータがダウンしたことを通知する。この通知において、ダウンしたコーディネータIDが一緒に通知される。通常、代替コーディネータと死活監視サーバは異なるハードウェアで実現される。
以下に、死活監視サーバ32の管理情報について説明する。
死活監視サーバ32は、どのコーディネータが起動、もしくはダウンしているかを(コーディネータID、状態:起動/ダウン)の形式で示される情報で管理する。常に複数の代替コーディネータが待機しており、サーバ死活監視部320が、コーディネータのダウンを検知すると、代替コーディネータにダウンしたコーディネータIDを通知する。通知を受けた代替コーディネータは、以降のトランザクションを調停する。
本実施形態によるコーディネータ異常時のトランザクション回復保証の範囲は、データサーバでprepare要求の実行完了後、commit要求の実行完了となるまでである。
次に、コーディネータ31に障害が発生した場合の処理について説明する。
コーディネータ31に障害が発生した場合、代替コーディネータ、データサーバ、死活監視サーバの3つの間で情報をやり取りすることで、コーディネータ31が仕掛中のトランザクション処理を完了させる。
図11を参照して、コーディネータのトランザクションのリカバリの流れについて説明する。
コーディネータ31に障害が発生すると、死活監視サーバ32において、サーバ死活監視部320がコーディネータ31の障害発生を検知する。そして、代替サーバ通知部321が、待機中の代替コーディネータ31−1を選択し、その代替コーディネータ31−1に対して、障害が発生したコーディネータ31のIDを引数として障害通知を行う。
代替コーディネータ31−1は、リカバリ部313およびデータ操作送受信部312を有する。リカバリ部313は、障害通知受信部313a、情報収集部313bおよびトランザクション状態決定部313cを有する。
代替コーディネータ31−1において、障害通知受信部313aが、死活監視サーバ32からの障害通知を受信すると、情報収集部313bが、全データサーバ33に対して、障害発生コーディネータIDを引数として渡し、その引数で指定されたコーディネータが障害前に調停していたトランザクションに対するワークスペースを返信するよう要求する。
各データサーバ33では、リカバリ部333のトランザクション状態通知部333aが代替コーディネータ31−1からの返信要求を受信する。トランザクション状態通知部333aは、その返信要求に含まれているコーディネータIDに基づいて、図10に示したディスク33b上で永続化しているワークスペースから、障害の発生したコーディネータが調停していた、仕掛中のトランザクションに対するワークスペースを抽出し、その抽出したワークスペースを代替コーディネータ31−1に返信する。
代替コーディネータ31−1では、情報収集部313bが各データサーバ33から収集したワークスペースに基づいて、トランザクション状態決定部313cが、各データサーバ33が管理するトランザクション状態を確認し、障害の発生したコーディネータ31が調停していたトランザクションの最終状態を決定する。
収集した各データサーバ33のワークスペースに記載されたトランザクション状態から、更新サーバリストを復元する場合、各データサーバ33の保持するトランザクション状態が異なる場合がある。なぜなら、コーディネータ31がcommit/rollback要求を送信する際に、障害が発生する場合があるためである。通常は、データサーバ33は、prepare要求を受信した後は、コーディネータ31から受信したワークスペースをディスク33bに書き込んで、コーディネータ31にprepare実行完了応答を返信する。したがって、トランザクション状態決定部313cにてトランザクションの最終状態を決定する。
図12は、代替コーディネータ31−1が、各データサーバ33からワークスペースを収集し、その収集したワークスペースからトランザクション状態を復元する手順を説明するための模式図である。
図12に示すように、各データサーバ33から収集したワークスペース40は、データサーバ中心の管理構造になっている。このため、データサーバ中心の管理構造のワークスペース40を、トランザクション中心の管理構造のワークスペース41に変更する必要がある。
図13に、データサーバ中心の管理構造のワークスペースを、トランザクション中心の管理構造のワークスペースに変更する手順を示す。以下、図12および図13を参照して、データサーバA、B、Cから収集したワークスペースから、トランザクションリストを復元する過程について説明する。
代替コーディネータ31−1が死活監視サーバ32からの通知を受信した場合は、トランザクションリストは空である。トランザクション状態決定部313cは、まず、収集したワークスペースのうち1つを取り出し(ステップS40)、その取り出したワークスペースがトランザクションに登録されていないトランザクションXかを判定する(ステップS41)。ステップS41において、最初はトランザクションリストは空なので、トランザクションXのための新規ワークスペースは必ず作成される。したがって、トランザクションリストに登録されないまま、ステップS41で「No」という判定になることはない。つまり、ステップS41で「No」に遷移する場合は、トランザクションリストに必ず、トランザクションXが登録されている。
ステップS41で、取り出したワークスペースがトランザクションに登録されていないトランザクションXであると判定した場合は、トランザクション状態決定部313cは、トランザクションXに対する新規ワークスペースを作成する(ステップS42)。そして、トランザクション状態決定部313cは、トランザクションXをトランザクションリストに追加し、受信トランザクション要求として、取り出したワークスペース内の要求をコピーする(ステップS43)。
ステップS41で、取り出したワークスペースがトランザクションに登録されていないトランザクションXではないと判定した場合、または、ステップS43の処理を実行した場合は、トランザクション状態決定部313cは、更新サーバリスト内のデータサーバ自身のトランザクション状態が「更新済」であるか否かを判定する(ステップS44)。更新済みと判定したものは、ワークスペース内の形成には必要ないため、無視する。
ステップS44で、「更新済」でないと判定した場合は、トランザクション状態決定部313cは、更新サーバリストから、データサーバ自身のトランザクション状態を、トランザクションXの新規ワークスペースの更新サーバリストに追加する(ステップS45)。
ステップS45を実行後、トランザクション状態決定部313cは、収集したワークスペースを全て取り出したか否かを判定する(ステップS46)。
ステップS44で、「更新済」でないと判定した場合、または、ステップS46で、ワークスペースを全て取り出したと判定した場合は、ステップS40からの処理を繰りかえる。
例えば、図12に示した収集ワークスペース40からデータサーバAから収集したワークスペースを取り出した場合、その取り出したワークスペースでは、TxID=1とされ、受信トランザクション要求がcommitとされているので、トランザクションリスト作成時にその情報を反映する。その後、更新サーバリスト内に記載されたデータサーバのうち、受信したワークスペースを保有するデータサーバのみのトランザクション状態を、トランザクションリスト内の更新サーバリストに、データサーバIDとともに追加する。データサーバAから収集したワークスペースの場合、データサーバAに関するトランザクション状態がprepareなので、TxID=1におけるワークスペース内の更新サーバリストに「データサーバA:prepare」を追加する。
上記の処理を、データサーバAから受信したワークスペースだけでなく、収集ワークスペース40の全てに対して行い、トランザクションリストとそれに付随するワークスペースを、コーディネータの障害発生前の状態に復元する。
以上のようにして、データサーバ中心の管理構造のワークスペースがトランザクション中心の管理構造のワークスペースに変更される。トランザクション状態決定部313cは、その管理構造が変更されたワークスペースに基づいて、各データサーバ33が管理するトランザクション状態を確認し、障害が発生したコーディネータ31が調停していたトランザクションの最終状態を決定する。
図14に、トランザクション状態の決定手順を示す。この決定手順において、基本的な決定方針として、あるトランザクションにかかる、更新サーバリスト内のあるデータサーバで管理しているトランザクション状態の少なくとも1つがcommitもしくはrollbackであれば、最終状態は、その状態と同じ(commitもしくはrollback)となる。
つまり、トランザクションの最終状態を決定する場合の優先順位は、
commit/rollback > prepare
となる。
図14を参照すると、トランザクション状態決定部313cは、まず、トランザクションリストからトランザクションを1つ取り出し(ステップS50)、そのトランザクションにかかるワークスペース内の更新サーバリストからトランザクション状態を1つ取り出す(ステップS51)。
次に、トランザクション状態決定部313cは、取り出したトランザクション状態がcommitまたはrollbackであるか否かを判定する(ステップS52)。
ステップS52で、トランザクション状態がcommitまたはrollbackであると判定した場合は、トランザクション状態決定部313cは、トランザクションの最終状態をcommitまたはrollbackに決定する(ステップS53)。
ステップS52で、トランザクション状態がcommitおよびrollbackのいずれでもないと判定した場合は、トランザクション状態決定部313cは、更新サーバリスト内のトランザクション状態を全て取り出したか否かを判定する(ステップS54)。
ステップS54で、トランザクション状態を全て取り出したと判定した場合は、トランザクション状態決定部313cは、トランザクションの最終状態を決定する(ステップS55)。ここで、トランザクションの最終状態は、commitかrollbackのいずれかに決定される。具体的には、prepare状態に対して、事前のシステム設定がcommitであればprepare状態をcommitにすることで最終状態を決定し、事前のシステム設定がrollbackであればprepare状態をrollbackにすることで最終状態を決定する。
トランザクションの最終状態を決定した後で、このトランザクションの最終状態にするためのトランザクション要求をこのトランザクションに関係するデータサーバに送信し、受信したデータサーバはそのトランザクション要求に対する処理をすることで、システム内のデータサーバの整合性をとることができる。
ステップS54で、未だ取り出されていないトランザクション状態があると判定した場合は、ステップS51からの処理が再び実行される。
ステップS53またはステップS55の処理が実行された後、トランザクション状態決定部313cは、更新サーバリスト内のトランザクション状態がprepareであるデータサーバに、決定されたトランザクションの最終状態にするための要求をデータサーバリストに追加する(ステップS56)。
次に、トランザクション状態決定部313cは、トランザクションリスト内のトランザクションを全て取り出したか否かを判定する(ステップS57)。トランザクションを全て取り出したと判定した場合は、トランザクション状態決定部313cによる決定処理を終了する。未だ取り出されていないトランザクションがあると判定した場合は、ステップS50からの処理が再び実行される。
以上のようにして調停すべきトランザクションの最終状態を決定すると、その後は、代替コーディネータ31−1は、通常のトランザクション処理と同様に、prepare実行完了状態であるデータサーバのみに対してcommit/rollback要求を送信して、データサーバにトランザクション処理を実行させる。そして、代替コーディネータ31−1は、データサーバからcommit/rollback実行完了応答を受信し、トランザクション処理を完了させる。
上記のトランザクションの最終状態を決定する手法によれば、コーディネータ31の障害発生時に、全データサーバからワークスペースを収集することにより、収集時に複数のデータサーバに障害が発生した場合でも、どれか1つのデータサーバが正常であり、かつトランザクションが最終状態である(commit/rollback)場合、代替コーディネータ31−1は、処理完了すべきトランザクションにどのデータサーバが関わっているかを特定でき、自身の最終状態を、他のデータサーバに反映させるトランザクション要求を配信することで、仕掛中トランザクション処理を完了できる。
次に、データサーバ33に障害が発生した場合の動作について説明する。
データサーバ33に障害が発生した場合、図5に示したリカバリ部333が、最終状態にないトランザクションの処理を完了させる。
図15に、各データサーバのトランザクションのリカバリの流れを模式的に示す。データサーバA〜Cは、図5に示したデータサーバ33と同じ構成である。データサーバA〜Cのリカバリ部333は、図11に示したトランザクション状態通知部333aに加えて情報収集部333b、トランザクション状態決定部33cおよびデータ操作送受信部33dを有する。なお、図15においては、便宜上、リカバリの流れを説明するために必要な部分のみが示されている。
図15には、コーディネータ31からcommit要求が発信され、そのcommit要求が、データサーバCに到着する前に、データサーバCに障害が発生した場合の、リカバリの流れが示されている。
コーディネータ31は、BASE特性より、データサーバCからのレスポンスを無視して、アプリケーションサーバ30にcommit実行完了通知を返信する。したがって、その時点では、データサーバCにおけるトランザクションはcommitされていないため、データと整合性がとれていない状態が発生する。
しかし、データサーバCが復旧し、再起動すると、データサーバCでは、リカバリ部333の情報収集部333bが、障害前に永続化していたワークスペースに存在するprepare実行完了状態のトランザクションを探し、ワークスペース内の更新サーバリスト内に記載されたデータサーバが管理するトランザクションIDを引数として、他のデータサーバA、Bに対してトランザクションの最終状態を問い合わる。
なお、再起動は一例であり、データサーバCの代替のデータサーバに切り替えて、代替のデータサーバが、上記を実施してもよい。
データサーバA、Bでは、リカバリ部333のトランザクション状態通知部333aが、データサーバCからの問い合わせを受けて、該当するトランザクションIDに関して永続化していたワークスペースをデータサーバCに返信する。このワークスペースは、前述したコーディネータの障害時のリカバリで説明したフォーマットと同じである。
コーディネータの障害時のリカバリでは、代替コーディネータが、コーディネータIDを引数として、関連する全データサーバから、ワークスペースを収集していた。これに対して、データサーバの障害時のリカバリでは、トランザクションIDを引数として、関連する全データサーバから、ワークスペースを収集するようになっており、この点が、コーディネータ障害時と異なる。
また、コーディネータ障害時のリカバリでは、更新後情報に記載のコーディネータIDと引数のトランザクションIDとの比較で一致した場合、該当のトランザクションのワークスペースを選択する。一方、データサーバ障害時のリカバリでは、更新後情報は利用せず、トランザクションIDとワークスペース内のトランザクションIDとの比較で一致した場合、該当のトランザクションのワークスペースを選択する。
データサーバCでは、リカバリ部333のトランザクション状態決定部333cが、更新サーバリスト内のデータサーバから収集したトランザクション状態から、図12に示した収集ワークスペース41のようなトランザクションリストを形成する。その後、トランザクション状態決定部333cが、図14に示した手順でトランザクションの最終状態を決定する。
なお、データサーバの場合、図14において、ステップS56は、「決定された最終状態のための要求をデータ操作要求受信部に送信」する処理となる。この処理では、データ操作送受信部333dが、トランザクション状態決定部333cで決定したトランザクションの最終状態にするための要求をデータ操作要求受信部330に送信する。
データ操作要求受信部330は、データ操作送受信部333dからの要求をデータ操作要求実行部331に供給する。データ操作要求実行部331は、データ操作送受信部333dからの要求に応じた処理を実行する。これにより、トランザクション状態決定部333cで決定したトランザクションの最終状態の情報がデータベース334に反映させる。
以上の処理により、データサーバCの障害前に永続化していたトランザクションを処理することができ、最新のデータ状態にすることができ、整合性を保つことができる。
なお、上記のデータサーバの障害時のリカバリにおいては、データサーバCが復旧するまで、データの整合性が保てないとしたが、データサーバ間でのディスク共有や、レプリケーションなどの手法を用いることで、データサーバの障害時でも、即時に復旧することができ、トランザクションを停止させることなく、処理することができる。
また、上記のデータサーバの障害時のリカバリによれば、データサーバに障害が発生した場合、BASE特性によって、アプリケーションサーバへのレスポンスを優先しながら、コーディネータを介すことなく、データサーバ間の通信のみで整合性を保つことができる。
以上説明した各実施形態は、本発明の一例であり、その構成および動作は、発明の趣旨を逸脱しない範囲で当業者が採用し得る変更を適用することができる。
例えば、図10に示したデータサーバ33において、リカバリログ333aをディスク33bに格納してもよく、また、ファイル334a、334bをメモリ33aに格納してもよい。
各実施形態において、データサーバおよびトランザクション管理サーバ(コーディネータ)のそれぞれは、プログラムに従って動作するコンピュータ装置よりなり、それぞれのサーバの機能は、コンピュータがプログラムを実行することにより提供することができる。プログラムは、コンピュータ装置内の記憶部に予め格納されてもよく、また、CD−ROMやDVDなどに代表される記録媒体を介してコンピュータ装置に提供されてもよい。さらに、プログラムは、インターネットに代表されるネットワークを介してコンピュータ装置に提供されてもよい。