JPH08263351A

JPH08263351A - リカバリ処理方式及び方法

Info

Publication number: JPH08263351A
Application number: JP7091614A
Authority: JP
Inventors: Hiroaki Takahashi; 宏明高橋; Toshiyuki Inoue; 利行井上; Tadao Odanaka; 忠雄小田中
Original assignee: N T T DATA TSUSHIN KK; NTT Data Communications Systems Corp
Current assignee: N T T DATA TSUSHIN KK; NTT Data Corp
Priority date: 1995-03-24
Filing date: 1995-03-24
Publication date: 1996-10-11

Abstract

(57)【要約】【目的】複数のサーバがトランザクションを分散処理
するシステムにおいて、データベースやファイルなどの
資源に対する障害リカバリ処理を１つのサーバに負担を
集中させずに高速に行えるようにする。【構成】複数のサーバ１１Ａ〜１１Ｅがネットワーク
１３を介して接続されている。従サーバ１１Ｄ、１１Ｅ
は、資源としてのファイル１７Ｄ、１７Ｅを管理してい
る。主サーバ１１Ａ〜１１Ｃは、各々のトランザクショ
ン処理において、従サーバ１１Ｄ、１１Ｅに対し資源の
更新命令を発行すると共に、発行した更新命令に基づく
資源の更新履歴（更新後イメージ）をジャーナル１８Ａ
〜１８Ｃに取得する。或る従サーバ１１Ｄで障害が生じ
た場合、障害復旧後に従サーバ１１Ｄは、自己のファイ
ル１７Ｄに対する最新の更新履歴を主サーバ１１Ａ〜１
１Ｃに要求し、主サーバ１１Ａ〜１１Ｃから送られた最
新の更新履歴に基づいてファイル１７Ｄのリカバリを行
う。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、相互接続された複数の
処理装置（以下、サーバという）がトランザクションを
分散処理する分散型のトランザクション処理システムに
おいて、データベース、メモリテーブル、ファイル等の
資源に対する障害リカバリ処理の改良に関する。

【０００２】

【従来の技術】図１は従来例に係る分散型トランザクシ
ョン処理システムにおけるリカバリ処理方式の概念図で
ある。

【０００３】図１に示すように、サーバ１Ａ、サーバ１
Ｂ、サーバ１Ｃには、それぞれ複数の端末４Ａ、５Ａ、
４Ｂ、５Ｂ、…が接続されている。各端末４Ａ、５Ａ、
４Ｂ、５Ｂ、…は、例えばワークステーションやパーソ
ナルコンピュータを用いたもので、対応するサーバ１
Ａ、１Ｂ、１Ｃとの間でトランザクションに関するメッ
セージの送受信を行う。

【０００４】サーバ１Ｄ及びサーバ１Ｅはそれぞれ資源
（この例ではファイル）７Ｄ、７Ｅおよび更新履歴ジャ
ーナル８Ｄ、８Ｅを有している。

【０００５】このような構成において、サーバ１Ａ、１
Ｂ、１Ｃはそれぞれの端末からトランザクション要求メ
ッセージを受け付けて、それぞれのトランザクションの
内容に応じサーバ１Ｄ又は１Ｅにファイル７Ｄ、７Ｅの
更新命令を出す。すると、サーバ１Ｄ、１Ｅは、それぞ
れのファイル７Ｄ、７Ｅの更新を行うと共に、ジャーナ
ル８Ｄ、８Ｅにそれぞれの更新内容を記録する。

【０００６】ここで、サーバ１Ｄのファイル７Ｄに障害
が発生した場合、障害復旧後にサーバ１Ｄは、自装置内
のジャーナル８Ｄに記録されている更新履歴を参照しな
がらシーケンシャルにリカバリを行う。通常、サーバ１
Ｄ内ではファイル７Ｄのバックアップが定期的に行われ
ているため、リカバリの処理は、障害発生前の最後のバ
ックアップデータをファイル７Ｄにコピーした上で、そ
のバックアップ取得時点以後の全ての更新履歴を時間的
順序に従ってシーケンシャルに実行することにより行
う。

【０００７】

【発明が解決しようとする課題】このように従来技術に
おいては、資源を管理する個々のサーバが、ジャーナル
内の更新履歴をシーケンシャルに実行することによりリ
カバリ処理を行う。そのため、リカバリを実行するサー
バに負荷が集中しリカバリに時間がかかるという問題が
ある。

【０００８】従って本発明の目的は、分散型トランザク
ション処理システムにおいて、データベース、メモリテ
ーブル、ファイル等の資源を管理するサーバで障害が発
生した場合、当該サーバに負担を集中させずに速やかに
リカバリが行えるようにすることにある。

【０００９】

【課題を解決するための手段】本発明は、相互通信可能
な複数の処理装置がトランザクションを分散処理するシ
ステムにおける、１つの処理装置の管理する資源に対し
てリカバリ処理を行うための方式において、少なくとも
２つの処理装置が、複数の処理装置が発した資源に対す
る更新命令に基づく、更新履歴を蓄積したジャーナルを
分散して管理し、資源を管理する処理装置が、資源のリ
カバリ処理に必要な更新履歴をジャーナルを管理する処
理装置へ要求する更新履歴要求手段と、ジャーナルを管
理する処理装置から送られた更新履歴に基づいて、資源
の更新を実行するリカバリ手段とを備え、ジャーナルを
管理する処理装置の各々が、更新履歴要求手段からの要
求に応じて、リカバリ処理に必要な更新履歴をジャーナ
ルより抽出して資源を管理する処理装置へ送信する更新
履歴送信手段を備えることを特徴とする。

【００１０】本発明の方式は、望ましくは、ジャーナル
内の個々の更新履歴が、資源の更新後イメージを表した
ものであり、リカバリ手段が、資源に対する最後の更新
履歴のみに基づいて資源を更新するように構成される。

【００１１】本発明はまた、上記方式によって行われる
リカバリ処理方法も提供する。

【００１２】

【作用】本発明のリカバリ処理方式によれば、資源更新
のジャーナルが２つ以上の処理装置に分散して管理され
ているため、リカバリ処理においては、それら２つ以上
の処理装置の並行処理により、必要な更新履歴が抽出さ
れる。そして、その抽出された更新履歴に基づいて資源
のリカバリが行われる。必要な更新履歴の収集処理を複
数の処理装置で並行処理するため、１つの処理装置の負
荷が減り、リカバリ処理の時間が短縮する。

【００１３】ここで、「資源」とは、データベース、フ
ァイル、テーブル、レコード等といったトランザクショ
ンで更新の対象となる個々の情報又はそのような情報の
集合体を意味する。

【００１４】通常、リカバリの対象となる資源は多数の
更新可能単位（例えば、レコード）に分れているため、
リカバリ処理はそれら多数の更新可能単位の１つ１つに
対して行う必要がある。この場合、それら多数の更新可
能単位のリカバリをマルチ・プロセスによって多重に実
行することが、処理時間を短縮する上で望ましい。

【００１５】更新履歴を資源の更新後イメージを表す形
式でジャーナルに蓄積してある場合は、障害発生時点の
最新の更新履歴のみに基づいて資源の更新をやり直すこ
とでリカバリが可能である。従って、従来のようにバッ
クアップ取得時点からシーケンシャルに更新を繰り返す
必要がなくなり、リカバリ処理時間が一層短縮される。

【００１６】好適な実施例では、資源に対する更新命令
を発した処理装置が各自の発した更新命令に関するジャ
ーナルを管理している。そのため、ジャーナルがトラン
ザクション処理時の通信障害や他の処理装置の障害の影
響を受けるおそれがなく、ジャーナルの信頼性が高い。

【００１７】好適な実施例では、リカバリ処理に必要な
更新履歴を特定するために、資源のロックログを利用し
ている。ロックログは、資源更新の排他制御を管理する
ために標準的に必要なものである。よって、ロックログ
を利用することにより、リカバリ処理用の更新履歴の特
定のために特別のログを設ける必要がない。

【００１８】

【実施例】図２は本発明に係る分散型トランザクション
処理システムの障害リカバリ方式を示すブロック図であ
る。

【００１９】複数台のサーバ１１Ａ、１１Ｂ、…１１Ｅ
がネットワーク１３を介して通信可能に接続されてい
る。

【００２０】サーバ１１Ａ、１１Ｂ、１１Ｃには、それ
ぞれ複数の端末１４Ａ、１５Ａ、１４Ｂ、１５Ｂ、…が
接続されている。各端末１４Ａ、１５Ａ、１４Ｂ、１５
Ｂ、…は、例えばワークステーションやパーソナルコン
ピュータを用いたもので、対応するサーバ１１Ａ、１１
Ｂ、１１Ｃとの間でトランザクションに関するメッセー
ジの送受信を行う。

【００２１】サーバ１１Ｄ及びサーバ１１Ｅは資源（こ
の例ではファイル）１７Ｄ、１７Ｅをそれぞれ有してい
る。

【００２２】サーバ１１Ａ、１１Ｂ、１１Ｃは、それぞ
れが発行した更新命令に基づく更新履歴を時系列的に蓄
積した更新履歴ジャーナル１８Ａ、１８Ｂ、１８Ｃを有
している。尚、ジャーナル１８Ａ、１８Ｂ、１８Ｃ内の
更新履歴は、資源の更新後イメージを表した形式となっ
ている。

【００２３】このような構成において、サーバ１１Ａ、
１１Ｂ、１１Ｃはそれぞれの端末からトランザクション
要求メッセージを受け付けて、それぞれのトランザクシ
ョンの内容に応じサーバ１１Ｄ又は１１Ｅにファイル１
７Ｄ、１７Ｅの更新命令を発行する（図中の破線矢
印）。すると、サーバ１１Ｄ、１１Ｅは、それぞれのフ
ァイル１７Ｄ、１７Ｅの更新を行う。

【００２４】また、サーバ１１Ａ、１１Ｂ、１１Ｃは、
更新命令の発行に際して、自身が発行するその更新命令
を各々のジャーナル１８Ａ、１８Ｂ、１８Ｃに記録す
る。

【００２５】ここで、例えばサーバ１１Ｄのファイル１
７Ｄに障害が発生したとする。すると、障害復旧後にサ
ーバ１１Ｄは、サーバ１１Ａ、１１Ｂ、１１Ｃに依頼し
て、それらのジャーナル１８Ａ、１８Ｂ、１８Ｃ中から
ファイル１７Ｄの更新履歴を取寄せ（図中の太実線矢
印）、これに基づいてファイル１７Ｄのリカバリを行
う。

【００２６】図３はファイル１７Ｄのリカバリ処理をよ
り具体的に示した説明図である。

【００２７】例えば、サーバ１１Ｄに障害が生じた時点
において、サーバ１１Ｄのファイル１７Ｄ内のレコード
Ｒ１及びＲ２に対して、サーバ１１Ａより更新命令が発
行されており、またレコードＲ３に対して、サーバ１１
Ｂより更新命令が発行されていたとする。この場合、サ
ーバ１１Ｄはリカバリ処理において、レコードＲ１及び
Ｒ２に対する障害発生時の（つまり最新の）更新履歴Ｊ
１及びＪ２をサーバ１１Ａより取寄せ、かつ、レコード
Ｒ３に対する障害発生時の（つまり最新の）更新履歴Ｊ
３をサーバ１１Ｂより取寄せ、これら最新の更新履歴Ｊ
１、Ｊ２、Ｊ３に基づいてファイル１７Ｄ内のレコード
Ｒ１、Ｒ２、Ｒ３を更新する。

【００２８】このように、リカバリ処理では、従来のよ
うにシーケンシャルに更新履歴を実行するのでなく、障
害発生時点において各資源に対し最後に行われた（最新
の）更新履歴のみを抽出して更新を実行する。これによ
り、リカバリ処理の負荷が小さくなりリカバリ時間が短
縮される。

【００２９】図４は、図３に示したリカバリ処理の具体
例を更に詳細に示した説明図である。

【００３０】図４に示すように、サーバ１１Ｄ及び１１
Ｅは、それぞれのファイル１７Ｄ、１７Ｅ内の各レコー
ドに対するロック処理の履歴を時系列的に蓄積したロッ
クログ１９Ｄ、１９Ｅをそれぞれ備えている。ここで、
ロック処理とは、或るトランザクションで或るレコード
を更新している最中、他のトランザクションによる同一
レコードの更新を禁止（ロック）するアクセスの排他制
御をいう。

【００３１】ロックログ１９Ｄ、１９Ｅ内に蓄積された
個々のロックログ情報は、そのロック処理を依頼したト
ランザクションの識別子と、ファイル内のどのレコード
をロックしたかを示すロック情報とから構成される。例
えば、図中右下端に示すロックログ情報Ｌ３は、「サー
バＢ−３」という識別子（サーバ１１Ｂの第３番のトラ
ンザクションを意味する）と、「レコード３ロック」と
いうロック情報（レコードＲ３をロックしたことを意味
する）とから構成されている。

【００３２】また、サーバ１１Ａ、１１Ｂ、１１Ｃのジ
ャーナル１８Ａ、１８Ｂ、１８Ｃ内の個々のジャーナル
情報（つまり個々の更新履歴）は、その更新命令を発し
たトランザクション識別子と、その更新命令による更新
の内容とから構成されている。例えば図中左下端に示す
ジャーナル情報Ｊ３は、「サーバＢ−３」という識別子
（サーバ１１Ｂの第３番のトランザクションを意味す
る）と、「レコード３値を６に更新」という更新内容
（レコードＲ３の値を６に更新することを意味する）と
から構成されている。ここで、重要な点は、ジャーナル
情報内の更新内容は、更新対象資源の更新後のイメージ
（上記例では、更新後の値が６であること）を表したも
のであって、更新による変化量（例えば、値を加算す
る、減算する等）を表したのものではない点である。

【００３３】個々のロックログ情報と個々のジャーナル
情報とは、トランザクション識別子によって相互に対応
付けられている。例えば、上に例示したロックログ情報
Ｌ３は、上に例示したジャーナル情報Ｊ３に対応してい
る。

【００３４】サーバ１１Ｄで障害が発生した場合を例に
とり、障害復旧後のサーバ１１Ｄ内のファイル７Ｄに対
するリカバリ処理の手順を以下に示す。

【００３５】（１）サーバ１１Ｄは、まず、自装置内で
定期的に取得しているファイル１７Ｄのバックアップデ
ータ（図示省略）をファイル１７Ｄにコピーし、次にロ
ックログ１９Ｄに対して、ファイル１７Ｄ内の全てのレ
コードＲ１、Ｒ２、Ｒ３に対する最後のロックログ情報
を要求する。図示の例では、レコードＲ１についてトラ
ンザクション識別子「サーバＡ−２」のロックログ情報
が、レコードＲ２についてトランザクション識別子「サ
ーバＡ−１」のロックログ情報が、レコードＲ３につい
ては識別子「サーバＢ−３」のロックログ情報が、それ
ぞれ最後のロックログ情報として抽出される。

【００３６】（２）次に、サーバ１１Ｄは、この最後の
ロックログ情報のトランザクション識別子から、そのト
ランザクション処理を担当したサーバを認識し、そのサ
ーバに対してそのトランザクションのジャーナル情報を
要求する。例えば、レコードＲ１、Ｒ２に関しては、最
後のロックログ情報のトランザクション識別子が「サー
バＡ−２」、「サーバＡ−１」であるから、サーバ１１
Ａに対して同じトランザクション識別子を持つジャーナ
ル情報を要求し、また、レコードＲ３に関しては、最後
のロックログ情報のトランザクション識別子が「サーバ
Ｂ−３」であるから、サーバ１１Ｂに対して同じトラン
ザクション識別子を持つジャーナル情報を要求する。

【００３７】（３）サーバ１１Ａは、サーバ１１Ｄから
要求されたトランザクション識別子「サーバＡ−２」、
「サーバＡ−１」を持つジャーナル情報をジャーナル１
８Ａから検索する。その結果、レコードＲ１及びレコー
ドＲ２に対する最新のジャーナル情報Ｊ１及びＪ２が抽
出される。

【００３８】（４）同様に、サーバ１１Ｂは、サーバ１
１Ｄから要求されたトランザクション識別子「サーバＢ
−３」を持つジャーナル情報をジャーナル１８Ｂから検
索する。その結果、レコードＲ３に対する最新のジャー
ナル情報Ｊ３が抽出される。

【００３９】（５）サーバ１１Ａは、抽出した最新のジ
ャーナル情報Ｊ１、Ｊ２をサーバ１１Ｄに送信する（太
実線矢印ａ）。同様に、サーバ１１Ｂも、抽出した最新
のジャーナル情報Ｊ３をサーバ１１Ｄに送信する（太実
線矢印ｂ）。

【００４０】（６）サーバ１１Ｄは、サーバ１１Ａ及び
１１Ｂから受信した最新のジャーナル情報Ｊ１、Ｊ２、
Ｊ３に基づいて各レコードＲ１、Ｒ２、Ｒ３に対する更
新をマルチ・プロセスにより多重に実行する。既に述べ
たようにジャーナル情報は更新後イメージを表した形式
であるから、最新のジャーナル情報Ｊ１、Ｊ２、Ｊ３に
基づいて更新を行うだけで、ファイル１７Ｂは障害が発
生せずに正常に更新が行われた状態に回復される。

【００４１】図５は、トランザクションを処理するサー
バ（以下、主サーバという）１１Ａのブロック構成図で
ある（他の主サーバ１１Ｂ及び１１Ｃも同様の構成であ
る）。

【００４２】主サーバ１１Ａの役割は、既に説明したよ
うに、端末１４Ａ又は１５Ａからのトランザクション要
求メッセージを受け付け、トランザクションの内容に応
じた更新命令を作成して、その更新命令に応じた更新履
歴（ジャーナル情報）をジャーナル１８Ａに取得すると
共に、その更新命令を更新対象のファイルを管理するサ
ーバ（以下、従サーバという）１１Ｄ又は１１Ｅに送信
し、その更新結果を端末１４Ａ又は１５Ａに返信するこ
とである。

【００４３】この役割を果たすため、主サーバ１１Ａ
は、メッセージ送受信装置２１と、トランザクション要
求処理部２２と、ロック・更新メッセージ処理部２３
と、ジャーナル処理部２４と、ロック・更新処理部２５
と、リカバリ処理部２６とを備えている。

【００４４】メッセージ送受信装置２１は、端末１４
Ａ、１５Ａとのメッセージの送受信及び従サーバ１１
Ｄ、１１Ｅとのメッセージの送受信を行うものである。

【００４５】トランザクション要求処理部２２は、端末
１４Ａ、１５Ａからトランザクション要求メッセージを
受け付けてこれを解析したり、端末１４Ａ、１５Ａにト
ランザクションの処理結果を返信したりするものであ
る。

【００４６】ロック・更新メッセージ処理部２３は、従
サーバ１１Ｄ、１１Ｅへロック処理依頼や更新命令のメ
ッセージを送信したり、従サーバ１１Ｄ、１１Ｅからロ
ック処理や更新の結果やリカバリ要求のメッセージを受
信するものである。

【００４７】ジャーナル処理部２４は、トランザクショ
ン要求処理部２２からトランザクション要求に応じた更
新内容を受け取って、これを更新履歴（ジャーナル情
報）としてジャーナル１８Ａに記録するものである。

【００４８】ロック・更新処理部２５は、トランザクシ
ョン要求処理部２２からトランザクション要求に応じた
更新内容を受け取って、更新対象のレコードに対するロ
ック依頼をそのレコードを管理する従サーバ１１Ｄ又は
１１Ｅへ、ロック・更新メッセージ処理部２３を通じて
送信したり、更新対象のレコードがロックされた後に、
そのレコードに対する更新命令を従サーバ１１Ｄ又は１
１Ｅに送信したりするものである。

【００４９】リカバリ処理部２６は、従サーバ１１Ｄ、
１１Ｅからのリカバリ要求をロック・更新メッセージ処
理部２３から受取り、そのリカバリ要求で要求された更
新履歴（ジャーナル情報）をジャーナル１８Ａから検索
し、ロック・更新メッセージ処理部２３を通じて従サー
バ１１Ｄ、１１Ｅに返信するものである。

【００５０】図６は、従サーバ１１Ｄのブロック構成図
である（従サーバ１１Ｅも同様の構成である）。

【００５１】従サーバ１１Ｄの役割は、既に説明したよ
うに、主サーバ１１Ａ、１１Ｂ、１１Ｃからのロック処
理依頼や更新命令を受け付け、対象レコードのロック処
理や更新を行い、その結果を主サーバ１１Ａ、１１Ｂ、
１１Ｃに返信したり、障害が発生した場合に、障害復旧
後に自装置の資源のリカバリ処理を行うことにある。

【００５２】この役割を果たすため、従サーバ１１Ｄ
は、メッセージ送受信装置３１と、ロック更新メッセー
ジ処理部３２と、ロック処理部３３と、ロックログ処理
部３４と、ファイル処理部３５と、リカバリ処理部３６
とを備えている。

【００５３】メッセージ送受信装置３１は、主サーバ１
１Ａ、１１Ｂ、１１Ｃとのメッセージの送受信を行うも
のである。

【００５４】ロック・更新メッセージ処理部３２は、主
サーバ１１Ａ、１１Ｂ、１１Ｃからロック処理依頼や更
新命令のメッセージを受信して解析したり、ロック処理
や更新の結果を主サーバ１１Ａ、１１Ｂ、１１Ｃへ返信
したりするものである。

【００５５】ロック処理部３３は、主サーバ１１Ａ、１
１Ｂ、１１Ｃからのロック処理依頼に従ってロック処理
を実行するものである。

【００５６】ロックログ処理部３４は、ロック処理部３
３が実行したロック処理の履歴をロックログ１９Ｄに書
き込むものである。

【００５７】ファイル処理部３５は、主サーバ１１Ａ、
１１Ｂ、１１Ｃからの更新命令に従ってファイル１７Ｄ
内の対象レコードの更新を行うものである。

【００５８】リカバリ処理部３６は、障害復旧後にリカ
バリ処理を行うために、ロックログ１９Ｄから最後のロ
ックログ情報を検索して、対応するジャーナル情報を要
求するリカバリ要求を主サーバ１１Ａ、１１Ｂ、１１Ｃ
へ送信したり、主サーバ１１Ａ、１１Ｂ、１１Ｃからの
ジャーナル情報に基づいてファイル１７Ｄのリカバリ処
理を行うものである。

【００５９】図７、図８は、本実施例における正常トラ
ンザクション処理の詳細な手順を示すフローチャートで
ある。

【００６０】ここでは主サーバ１１Ａが従サーバ１１Ｄ
のファイルを更新する場合を例にとり説明する。

【００６１】まず、或る端末１４Ａにおいて、ユーザか
らの入力情報から所定の前処理（Ｓ１）を経てトランザ
クション要求（特定のレコードの更新依頼）を作成し
（Ｓ２）、これを主サーバ１１Ａに送信する（Ｓ３）。

【００６２】主サーバ１１Ａでは、端末１４Ａからのト
ランザクション要求をトランザクション要求処理部２２
が受信し（Ｓ４）、次いでロック・更新処理部２５がト
ランザクション要求に応じて更新対象のレコードに対す
るロック処理依頼を生成し（Ｓ５）、そして、ロック・
更新メッセージ処理部２３がこのロック処理依頼を従サ
ーバ１１Ｄに向けて送信する（Ｓ６）。

【００６３】従サーバ１１Ｄでは、ロック・更新メッセ
ージ処理部３２が主サーバ１１Ａからのロック処理依頼
を受信し（Ｓ７）、次いでロック処理部３３が更新対象
のレコードが既にロック済みか否か判断する（Ｓ８）。
ロック済みでなければ、ロック処理部３３がロック処理
を実行し、そして、ロックログ処理部３３がそのロック
処理のログ情報を作成してロックログ１９Ｄに書き込む
（Ｓ９）。このロックログ情報には、トランザクション
識別子と、ロック対象のレコードが含まれるファイル名
及びそのレコードのレコード番号と、ロック情報とが含
まれている。

【００６４】ロック処理が完了すると、ロック・更新メ
ッセージ処理部３２がロック処理成功の旨の結果を主サ
ーバ１１Ａに向けて送信する（Ｓ１０）。

【００６５】なお、ロック処理依頼があったときに、ス
テップＳ８で更新対象レコードが既にロック済みであっ
た場合には、ロック処理は実行されず、ロック処理不成
功の旨の結果がロック・更新メッセージ処理部３２から
主サーバ１１Ａに向けて送信される（Ｓ１０）。

【００６６】主サーバ１１Ａでは、ロック・更新メッセ
ージ処理部２３がロック処理結果を受信し（Ｓ１１）、
ロック・更新処理部２５がロック処理が成功したか否か
判断する（Ｓ１２）。

【００６７】ロック処理不成功の場合（Ｓ１２でＮ）、
つまり、対象レコードが既にロック済みであった場合
は、端末が要求したトランザクションはロールバックさ
れる。図８に示すように、トランザクション要求処理部
２２が端末１４Ａに更新処理をロールバックする旨の結
果を送信する（Ｓ１３）。

【００６８】一方、ロック処理が成功した場合は（Ｓ１
２でＹ）、ジャーナル処理部２４が更新命令に基づくジ
ャーナル情報（更新履歴）をジャーナル１８Ａに書き込
む（Ｓ１５）。ジャーナル情報は、トランザクション識
別子と、対象レコードが含まれるファイル名及び対象レ
コードのレコード番号と、更新内容とを含んでいる。既
に述べたように、更新内容は更新後イメージを表した形
式である。

【００６９】次いで、ロック・更新メッセージ処理部１
２が従サーバ１１Ｄに向けて、更新命令を送信し（Ｓ１
６）、トランザクション要求処理部２２が端末１４Ａに
向けて更新処理がコミットされた旨の結果を送信する
（Ｓ１７）。

【００７０】端末１４Ａは、ロールバック又はコミット
の旨の結果を受信して（Ｓ１４）ユーザに提示し、その
処理を終了する。

【００７１】従サーバ１１Ｄでは、ロック・更新メッセ
ージ処理部３２が更新命令を受信し（Ｓ１８）、ファイ
ル処理部３５がその更新命令に基づいてファイル１７Ｄ
内の対象レコードの内容を更新する（Ｓ１９）。更新が
完了すると、ロックログ処理部５４が、対象レコードを
アンロックした旨のロックログ情報をロックログ１９Ｄ
へ書き込む（Ｓ２０）。

【００７２】以上のようにして正常なトランザクション
処理が完了する。トランザクション処理が完了した段階
で、主サーバ１１Ａのジャーナル１８Ａには、そのトラ
ンザクション処理で実行されたレコード更新の内容を示
すジャーナル情報が保存され、従サーバ１１Ｄのロック
ログ１９Ｄには、そのトランザクション処理で実行され
た更新対象レコードのロックとアンロックとを示すロッ
クログ情報のペアが保存されていることになる。

【００７３】図９、図１０は従サーバ１１Ｄで障害が発
生した場合に、障害復旧後のリカバリ処理の手順を詳細
に示したフローチャートである。

【００７４】従サーバ１１Ｄにおいて、例えばファイル
１７Ｄのボリューム障害が発生したとする。すると、フ
ァイル１７Ｄ用の記憶装置が正常なものに交換された後
に、以下の手順によりリカバリ処理が実行される。

【００７５】まず、従サーバ１１Ｄのリカバリ処理部３
６が、ファイル１７Ｄを閉塞状態に設定してロック処理
を始めとする外部からの一切の操作を禁止した上で（Ｓ
３１）、定期的に取得してあったバックアップデータ
（ファイル原本）をファイル１７Ｄに読み込む（Ｓ３
２）。

【００７６】次に、ロックログ１９Ｄを所定の方法でサ
ーチして（例えば、最後尾からシーケンシャルにサーチ
して）、個々のロックログ情報を順番に読み込む（Ｓ３
３）。そして、ロックログ情報を１つ読み込む都度、ま
ず、同じレコードのロックログ情報を既に読んでいるか
否かチェックする（Ｓ３４）。その結果、まだ同じレコ
ードのロックログ情報を読んでいなければ（Ｓ３４で
Ｎ）、それは当該レコードに関する最後のロックログ情
報である可能性があるから、そのロックログ情報をメモ
リに保持する（Ｓ３５）。一方、既に同じレコードのロ
ックログ情報を読んでいる場合は（Ｓ３４でＹ）、現在
読み込んだロックログが既に読んだものよりも新しいか
否か判断し（Ｓ３６）、新しい場合は（Ｓ６でＹ）既に
読んでいたロックログ情報を破棄して（Ｓ３７）、現在
読み込んだロックログ情報をメモリに保持する（Ｓ３
５）。一方、現在読み込んだロックログ情報が既に読ん
だロックログ情報よりも古い場合は（Ｓ６でＮ）、現在
読み込んだロックログ情報を破棄する（Ｓ３８）。

【００７７】以上のステップステップＳ３３からＳ３８
の処理を、図１０に示すようにロックログ１９Ｄの全て
のログ情報を読み込に終わるまで繰り返す（Ｓ３９）。
その結果、ファイル１７Ｄの各レコードに関して最後の
ロックログの情報がメモリ上に抽出される。

【００７８】こうして最後のロックログ情報が全てのレ
コードについて抽出されると、次に、ロック・更新メッ
セージ処理部３２が、それら最後のロックログ情報内の
トランザクション識別子に基づいて対応する更新履歴
（ジャーナル情報）を要求するメッセージを、そのトラ
ンザクション識別子により特定された主サーバに送信す
る（Ｓ４０）。例えば、図４に示した具体例では、最後
のロックログ情報のトランザクション識別子は「サーバ
Ａ−１」「サーバＡ−２」「サーバＢ−３」であるか
ら、トランザクション識別子「サーバＡ−１」及び「サ
ーバＡ−２」に対応する更新履歴の要求は主サーバ１１
Ａに、トランザクション識別子「サーバＢ−３」に対す
る更新履歴の要求は主サーバ１１Ｂにそれぞれ送信され
ることになる。

【００７９】主サーバ１１Ａでは、ロック・更新メッセ
ージ処理部２３が更新履歴要求を受信すると（Ｓ４
１）、リカバリ処理部２６が当該要求のトランザクショ
ン識別子を検索キーに用いてジャーナル１８Ａから要求
された更新履歴（最新のジャーナル情報）を検索してこ
れを読み込み（Ｓ４２）、ロック・更新メッセージ処理
部２３がこの更新履歴を従サーバ１１Ｄに返信する（Ｓ
４３）。

【００８０】他方の主サーバ１１Ｂでも、サーバ１１Ａ
の上記処理と並行して同様に、要求された最新の更新履
歴が読み込まれ、従サーバ１１Ｄに返信される。

【００８１】従サーバ１１Ｄでは、ロック・更新メッセ
ージ処理部３２が主サーバ１１Ａ、１１Ｂからの最新の
更新履歴を受信すると（Ｓ４４）、ファイル処理部３５
がこの更新履歴に基づいてファイル１７Ｄ内の各レコー
ドの内容を更新する（Ｓ４５）。このステップＳ４４、
４５のレコード更新処理は、複数プロセスにより複数レ
コードについて多重に実行される。この最新の更新履歴
に基づく更新により、ファイル１７Ｄの内容は障害が発
生しなかった場合と同様の正しい内容に改められる。

【００８２】この後、リカバリ処理部３６がファイル１
７Ｄの閉塞を解除して（Ｓ４６）、リカバリ処理を終了
する。

【００８３】以上、本発明の一実施例を説明したが、本
発明はこの実施例にのみ限定されるものではなく、他の
種々の態様でも実施することができる。例えば、上記実
施例では、従サーバにおいてリカバリに必要な最新の更
新履歴を特定するためにロックログを利用したが、必ず
しもロックログを利用する必要はなく、最新の更新履歴
の特定が可能でさえあれば、別の手段を用いても構わな
い。例えば、ロック処理依頼や更新命令に含まれている
トランザクション識別子をログ形式又はレコード別の上
書形式で記録しておき、レコード毎の最終のトランザク
ション識別子から最新の更新履歴を特定することも可能
である。或いは、ロック処理依頼又は更新命令を発行し
た主サーバの識別子を同様の形式で記録しておき、レコ
ード毎に最終の主サーバを特定してこれに更新履歴要求
を送信して、その主サーバにおいて最新の更新履歴を選
択して従サーバに返送することも可能である。或いは、
サーバの台数がそれ程多くなければ、従サーバより全て
の主サーバに対して各々のジャーナル内での各レコード
毎の最新の更新履歴を要求して、それを収集した従サー
バにおいて、各レコード毎の真に最新の更新履歴を選択
するようにしてもよい。

【００８４】

【発明の効果】以上説明したように、本発明によれば、
資源のリカバリ処理を複数の処理装置により並行処理で
き、また好適な構成では更に、最新の更新履歴に基づく
更新処理だけでリカバリができるため、１つの処理装置
におけるリカバリ処理の負担が軽減し、リカバリ時間を
短縮することができる。

【図面の簡単な説明】

【図１】従来例に係る分散型トランザクション処理シス
テムにおける障害リカバリ方式を示すブロック図。

【図２】本発明の一実施例に係る分散型トランザクショ
ン処理システムにおける障害リカバリ方式の全体構成を
示すブロック図。

【図３】図２の実施例の障害リカバリ処理をより具体的
に説明するための説明図。

【図４】図３に示した障害リカバリ処理を一層詳細に説
明するための説明図。

【図５】主サーバの構成を示すブロック図。

【図６】従サーバの構成を示すブロック図。

【図７】正常トランザクション処理の手順の前段部分を
示すフローチャート。

【図８】正常トランザクション処理の手順の後段部分を
示すフローチャート。

【図９】リカバリ処理の手順の前段部分を示すフローチ
ャート。

【図１０】リカバリ処理の手順の後段部分を示すフロー
チャート。

【符号の説明】

１１Ａ、１１Ｂ、１１Ｃサーバ（主サーバ）１４、１５端末１１Ｄ、１１Ｅサーバ（従サーバ）１７Ｄ、１７Ｅファイル１８Ａ、１８Ｂ、１８Ｃジャーナル１９Ｄ、１９Ｅロックログ２２トランザクション要求処理部２３、３２ロック・更新メッセージ処理部２４ジャーナル処理部２５ロック・更新処理部２６、３６リカバリ処理部３３ロック処理部３４ロックログ処理部３５ファイル処理部

Claims

【特許請求の範囲】

【請求項１】相互通信可能な複数の処理装置がトラン
ザクションを分散処理するシステムにおける、１つの処
理装置の管理する資源に対してリカバリ処理を行うため
の方式において、少なくとも２つの処理装置が、前記複数の処理装置が発
した前記資源に対する更新命令に基づく更新履歴を蓄積
したジャーナルを分散して管理し、前記資源を管理する処理装置が、前記資源のリカバリ処理に必要な更新履歴を前記ジャー
ナルを管理する処理装置へ要求する更新履歴要求手段
と、前記ジャーナルを管理する処理装置から送られた更新履
歴に基づいて、前記資源の更新を実行するリカバリ手段
とを備え、前記ジャーナルを管理する処理装置の各々が、前記更新
履歴要求手段からの前記要求に応じて、前記リカバリ処
理に必要な更新履歴を前記ジャーナルより抽出して前記
資源を管理する処理装置へ送信する更新履歴送信手段を
備えることを特徴とするリカバリ処理方式。
【請求項２】請求項１記載の方式において、前記ジャーナル内の個々の更新履歴が、前記資源の更新
後イメージを表したものであり、前記リカバリ手段が、前記資源に対する最後の更新履歴
のみに基づいて前記資源を更新することを特徴とするリ
カバリ処理方式。
【請求項３】請求項１記載の方式において、前記更新命令を発した複数の処理装置の各々が、各自の
発した更新命令に関するジャーナルを管理することを特
徴とするリカバリ処理方式。
【請求項４】請求項１記載の方式において、前記資源を管理する処理装置が、前記資源のロック処理
の履歴を蓄積したロックログを備え、前記更新履歴要求手段が、前記ロックログ内のロック処
理の履歴に基づいて、前記リカバリ処理に必要な更新履
歴を特定することを特徴とするリカバリ処理方式。
【請求項５】請求項２記載の方式において、前記資源を管理する処理装置が、前記資源のロック処理
の履歴を蓄積したロックログを備え、前記更新履歴要求手段が、前記ロックログ内のロック処
理の最後の履歴に基づき、前記資源に対する最新の更新
履歴を特定し、そして、この最新の更新履歴に対する要
求を発することを特徴とするリカバリ処理方式。
【請求項６】相互通信可能な複数の処理装置がトラン
ザクションを分散処理するシステムにおける、１つの処
理装置の管理する資源に対してリカバリ処理を行うため
の方法において、少なくとも２つの処理装置が、前記複数の処理装置が発
した前記資源に対する更新命令に基づく更新履歴を蓄積
したジャーナルを分散して管理する過程と、前記資源を管理する処理装置において、前記資源のリカバリ処理に必要な更新履歴を前記ジャー
ナルを管理する処理装置へ要求する過程と、前記ジャーナルを管理する処理装置から送られた更新履
歴に基づいて、前記資源の更新を実行する過程と、前記ジャーナルを管理する処理装置の各々が、前記資源
を管理する処理装置からの前記要求に応じて、前記リカ
バリ処理に必要な更新履歴を前記ジャーナルより抽出し
て前記資源を管理する処理装置へ送信する過程と、を備
えることを特徴とするリカバリ処理方法。