JP3524290B2 - データの復旧方法およびその処理装置 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、分散処理システム
において処理装置の保持するデータの一致化と復旧方法
に関し、特にある処理装置の保持するデータを、他の複
数の処理装置へ一致化したり、非同期に復旧する場合に
好適に適用しうるデータの復旧及び一致化方法に関する
ものである。

【０００２】

【従来の技術】従来、分散処理システムにおいて複数の
処理装置へデータを一致化させる装置またはプログラム
としてはオペレーティングシステムのファイル複製機能
や、データベースソフトウェア（DB）のレプリケーショ
ン技法があり、例えば日経BP社「PCデータベースエンジ
ン・PCデータベースサーバ徹底活用法」, PP.109-198に
記載されている。これは、DB中のデータが更新された場
合に更新されたデータを指定された処理装置上のDBへ送
信することで、データ格納テーブルまたはある条件で一
部のデータを抽出したビューを指定された処理装置へ一
致化するものである。この方法によると、更新されたデ
ータをどの処理装置に送るか、すなわちどの処理装置に
レプリケートするかは、データを更新した処理装置によ
って一括管理されている。このため、多くの処理装置で
該データを共有する場合は、共有する処理装置の数だけ
データ送信と格納処理が発生するため、更新元の処理装
置の負荷が高くなり、システム全体の性能を下げてしま
う。また、ビューを共有する場合も、指定された条件に
基づくデータの抽出や、データ更新に伴ってビューが更
新されるか否かの判定も更新元の処理装置が集中管理し
ており、更新元の負荷を更に高めてしまう。

【０００３】更に、データテーブルのバックアップや復
旧のように一括してデータを取得する場合には、従来は
ディレイドコピー方式のように一度全データを取得し、
その後更新されたデータを順次反映させていく。この方
法では、全データ取得中の他のオンライン処理が止まっ
てしまうため、システムの応答性を下げてしまう。ま
た、多数の処理装置がこれを行うと、処理装置間で復旧
終了のずれが大きいことに加え、更新元の負荷やネット
ワークの負荷も高くなってしまう。

【０００４】

【発明が解決しようとする課題】分散処理システムにお
いては、各処理装置は必要なデータを自処理装置に保存
しておくことで高速にアクセス可能となり、運用性能を
向上できる。処理装置はシステムの拡張とともに増加
し、結果として多数のデータ複製が発生する。また、デ
ータを多重化して信頼性を向上させたり、重要なデータ
をバックアップする場合も、データの複製を持つことと
なる。更に、WWWを利用するシステムのように、オンラ
インで多数のデータを、多数の処理装置が利用すること
が多い。従来技術によると、分散処理システムにおいて
データを一致化又は復旧する場合は、データの更新元や
復旧元（以下ソースと呼ぶ）が相手先処理装置（デステ
ィネーションと呼ぶ）やそれぞれに対して送信するデー
タを管理し、逐次的にデスティネーションのデータを更
新する必要があった。この方式を適用すると、処理装置
の増加とともにソースの負荷が上昇し、システム全体の
レスポンスが低下していく。さらに、ソースとデスティ
ネーションの接続が複雑になり、あるデスティネーショ
ンのダウンが原因でソースの処理が滞り、これが連鎖し
てシステム全体の不全を招いてしまう。

【０００５】本発明は、ソースのデータ更新と復旧を並
行して行い、ソースにとって不特定多数のデスティネー
ションが並列してデータ更新や復旧を行うことを可能と
し、あるデスティネーションが復旧中または復旧中、ダ
ウン中に関わらずシステム全体の性能を保つことを可能
とすることを目的とする。

【０００６】

【課題を解決するための手段】本発明のデータ一致化方
法及び復旧方法は、ソースの持つデータを多数のデステ
ィネーションに一致化させる、または多数のデスティネ
ーションから並行して復旧することを可能とするもの
で、ソースが復旧または更新対象となるデータを論理的
な単位に分割し、該分割単位ごとに更新や復旧用データ
の識別子を付加して並行して送信を行う手段と、デステ
ィネーションごとでなく全体での復旧の状態を管理する
手段とを有し、各デスティネーションが自分の必要なデ
ータを判断する手段と、自分が該データの更新中か復旧
中かを判断してデータの分割単位ごとに自律的に受け取
る手段と、自分の必要なデータ分割単位の条件を判断し
て自律的に受け取る手段と、分割単位すべてを受信した
ことで復旧を完了したと判断する手段とを具えているこ
とを特徴とする。

【０００７】ソースは各デスティネーションを意識せ
ず、更新データや復旧用データを送信する。このデータ
の送信の仕方は、送信すべきメッセージに受信側がその
メッセージの受信可否を判断する内容コード付加して共
通伝送媒体（ネットワーク）に送信する。各デスティネ
ーションは、自分の状態に基づき、更新状態の場合は復
旧用データを無視し、また条件設定されている場合は、
各データが条件を満たすか判断して取得するか無視する
か決める。この方法により、ソースを過負荷とすること
なく多数のデスティネーションに対してデータの更新や
復旧を並行して行うことができる。更に、データの複製
を持とうとするデスティネーションを、システム全体の
性能を下げずに、オンライン中に増減させることが可能
である。

【０００８】

【発明の実施の形態】以下に、本発明の実施の形態を詳
細に説明する。

【０００９】図１は、本発明を適用したシステムの構成
例である。共通伝送媒体101を介して互いにデータの授
受を行なう処理装置111〜113と、ディスプレイやキーボ
ードを有する端末121〜123から構成されている。処理装
置111〜113には、端末121〜123が接続されている。ここ
で、端末とは、ディスプレイやキーボード等のマンマシ
ンインタフェ−スを持ち、このインタフェ−スを介し
て、処理装置上で実行されるプログラムの制御を行なっ
たり、プログラムの出力を参照したりする機能を有して
いる。また、処理装置はメモリのようなデータ記憶媒体
を持ち、処理装置に接続されている外部記憶装置131〜1
33はフロッピーディスクやハードディスク等のデータ記
憶媒体を保持している。本発明において一致化または復
旧されるデータ（ソースデータ）は、これらのデータ記
憶媒体に格納されている。

【００１０】図２は、ソースデータの論理分割例を示し
ている。（a）図は、テーブル形式のソースデータ分割
例である。ソースデータ201は、複数のレコード211〜21
6から構成されている。各レコードは共通の構造を持っ
ており、フィールド221〜225から構成される。このフィ
ールドはレコードを識別するための条件となり、例えば
「フィールド221が"18"に等しいもの」といった条件を
指定し、特定のレコードを選択できる。本例のテーブル
形式のソースデータでは、例えばレコードを１論理分割
単位とし、各レコードには重複しない論理番号をつけ
る。実際のレコード順序を考えてレコード221が分割単
位1、レコード2が分割単位2等と設定したり、あるいは
フィールド221の値をそのまま論理分割番号としてもよ
い。論理分割単位番号は連続でなくともよく、存在しな
い分割単位番号は空のデータとみなす。（b）図は、複
合ファイル形式のソースデータ分割例である。ソースデ
ータ251は、本体となるファイル261と、画面表示におい
て261に埋め込まれるファイル271〜272から構成されて
いる。本例では、例えば１ファイル261, 271〜272を１
論理分割単位とすることができる。

【００１１】図３は、第１図の伝送路上で送受信される
メッセージのフォーマットを示している。各メッセージ
には、制御コード（CtlC）301と、メッセージデータの
内容を示す内容コード（CC）302と、送信元アドレス（S
A）303がデータ304に付加され、伝送路上に送信され
る。各処理装置は、これらの情報をもとにして各メッセ
ージが自内のプログラムに必要なデータかを判断する。
データの更新・復旧処理においては、CCは、同一のメッ
セージに乗せて更新・復旧データを送られるソースデー
タグループを示す識別コードとなる。デスティネーショ
ンは、取得したいデータのソース識別コードを指定し
て、必要なソースデータのデータを受け取ることができ
る。

【００１２】図４は、各処理装置におけるデータの登録
テーブルである。(a)はソースデータの登録テーブル例
である。ソースデータに関する情報が、レコード421〜4
25にそれぞれ格納される。レコードの構成は、データの
内容を一意に識別するDF(411)及びDID(412)、各データ
を復旧する際、次にどの論理分割単位から復旧するかを
示す復旧レコード番号(413)、どのレコードまで送れば
全デスティネーションの復旧が完了するかを示す復旧終
了レコード番号(414)、論理分割単位の最大数total（41
5）、復旧シーケンス番号seq_number（416）、更新バー
ジョンupdate_ver（417）等から構成される。(b)は、デ
スティネーションデータの登録テーブル例である。ソー
スデータ同様に、各データの情報がレコード461〜465に
格納される。レコードの構成は、データの内容を一意に
識別するDF(471)及びDID(472)、各デスティネーション
データが現在復旧中か、復旧を終えて更新中かを示す現
在状態フィールド473、復旧中に全論理分割単位が取得
されたか否かを管理するための復旧終了判定マップ47
4、データを取得した際に、媒体やデータに対応してデ
ータを書き込むプロセスの情報451である。

【００１３】図５は、本例において用いられるメッセー
ジのデータ部のフォーマットを示す。(a)図は、ソース
からデスティネーションへ一致化・復旧データを送信す
る場合に用いるデータフォーマットである。ソースの状
態一般を示すstatus511、このメッセージに載せてデー
タを送るソースデータの数を示すnum_recover512、各ソ
ースデータの復旧及び更新状態を示すrecovery513〜51
5、データの入るitem部516〜518から構成される。recov
ery部は各ソースデータの数だけ存在し、ソースデータ
を識別するDF521及びDID522、論理分割単位構成数を示
すtotal523、復旧シーケンスを表すseq_number524、こ
のメッセージ中のデータも含めて次に送られる復旧用論
理分割単位の番号525、ソースデータが更新される度に
更新されるupdate_ver526から構成される。このうちtot
alは、実際の論理分割単位の数に一致している必要はな
く、取りうる最大の論理分割単位数を表す。このため、
実際の論理分割単位に付けられた番号は連続していなく
ともよい。seq_numberは、ソース側で復旧処理が開始し
たときに決定する番号であり、例えばタイムスタンプ等
を用いる。デスティネーション側はこの番号をチェック
して、復旧処理中にソース側がダウンしたり、復旧処理
が異常終了したりしたことを判断できる。fromには、復
旧用の論理分割単位の番号が設定される。このメッセー
ジ中に復旧用の分割単位データが含まれる場合はその先
頭の番号が、含まれない場合は次回以降のメッセージで
送られる最初の復旧用分割単位番号、言い換えると、前
回の復旧処理で送った復旧用論理分割単位の次にあたる
番号が設定される。item部は、各データの内容を指定す
るDF531及びDID533、このデータが復旧用か、更新用
か、実在しない論理分割単位を示す空データかを示すct
l532、論理分割単位番号を示すl_no534、データのサイ
ズsize535、及び実データ部536から成る。各itemに復旧
用データか、更新用データかの識別フラグctlが付けら
れているため、更新データと復旧データが同時に送られ
てもデスティネーションは自分で判断して不要なデータ
を廃棄できる。(b)図は、デスティネーションからソー
スへ復旧開始を通知する際に用いるデータフォーマット
である。デスティネーションは、あるデータについて復
旧処理を行ないたい場合に、１度ソースからの図(a)形
式のメッセージを受け取り、図(b)に示すフォーマット
で復旧開始通知をソースへ送る。551〜554は、通知を送
る前に受け取ったメッセージのstatus及びrecovery部で
ある。また、復旧したい条件を記述するcondition556と
そのサイズcondition_size555を付加する。デスティネ
ーションは、fromで示される分割単位から復旧を開始す
ることになり、(i)totalと合わせていつ復旧が終了した
かを自ら判断可能であり、(ii)ソース側は復旧開始通知
を受け取ると、from以前の分割単位までを送ればよいこ
とがわかる。これにより、各デスティネーションを意識
しなくともデータの復旧を完了させることができる。

【００１４】図６は、ソフトウェアモジュール構成例で
ある。処理装置601がソース、602がデスティネーション
である。ユーザプログラム611,612,651、データ更新管
理プロセス621、データ送信プロセス622、復旧管理プロ
セス623、データ受信プロセス624というプロセスで構成
する。ソースにおいてユーザプロセスからデータ更新管
理プロセスを介してデータを書き込むと（631）、該デ
ータは媒体へ格納され（632）、変化のあった論理分割
単位が送信プロセスへ送られる（633）。この分割単位
は送信プロセスによって伝送媒体へ流され、デスティネ
ーションが受信する（634）。デスティネーションでは
該メッセージよりデータを取りだし、対応するデスティ
ネーションデータの状態を判断してデータ更新管理プロ
セスへデータを渡し（635）、媒体へ格納する（636）。
または、ユーザプログラム651へデータを渡す。復旧を
開始する場合は伝送媒体へ通知メッセージを流し（63
7）、復旧管理プロセス623は媒体から論理分割単位ごと
にデータを取りだして送信する（638）。

【００１５】図７は、更新データ送信処理を示すフロー
チャートである。ユーザプロセスからソースデータが更
新されるか、後に示す復旧処理によって、復旧用又は更
新用の分割単位が本処理に渡される（ステップ701）。
この分割単位を取得し（ステップ702）、分割単位に適
合したアイテムヘッダが付けられる。ここでアイテムヘ
ッダとは図５のitem部514のうちdata部537以外の部分で
ある。DF及びDIDは更新または復旧されるソースデータ
のものが付けられる。l_no部は該分割単位の番号、size
部は渡された論理分割単位のサイズが設定される。ctl
部は該分割単位の属性を設定するものであって、例えば
ユーザプロセスからの更新の場合は"1"を、復旧処理か
ら渡されたデータで実論理分割単位を渡された場合は"
0"を、実分割単位がない空分割単位の場合は"3"を指定
する。アイテムヘッダが設定された後、該データはメッ
セージ送信用バッファに格納される（ステップ704）。

【００１６】メッセージの送信において、本例では相乗
り方式を用いる。バッファにデータが格納された後、送
信バッファが満配かどうか判定し（ステップ705）、満
配になっていない場合は次のデータ待ちに入る。満配に
なった場合は、ソースデータ管理テーブルを用いてメッ
セージヘッダを設定し（ステップ706）、該テーブルを
更新し（ステップ707）、メッセージを送信する（ステ
ップ708）。またはバッファが満配にならなくとも、タ
イムアウト割り込み（ステップ711）によってメッセー
ジは送信される。バッファにデータがたまっていない場
合は、メッセージヘッダのみの送信となる。ソースデー
タ管理テーブルにおいては、送信メッセージに更新用デ
ータが含まれている場合はupdate_verを更新し、復旧用
データが含まれている場合は復旧レコード番号を更新す
る。

【００１７】図８は復旧処理を示すフローチャートであ
る。デスティネーションからのメッセージを待ち（ステ
ップ751）、復旧開始通知を受信すると（ステップ75
2）、ソース管理テーブルを更新する（ステップ753）。
ソース管理テーブルの更新とは、該通知メッセージに指
定された復旧開始データ識別子DF及びDIDを見て該当ソ
ースデータを検索し、復旧開始した分割単位番号fromを
用いて復旧終了レコードを更新することである。分割単
位番号fromは、通知送信元のデスティネーションがfrom
以降の分割単位から復旧を開始したことを意味してお
り、ソース側はソースデータが一巡するように分割単位
を送ればよい。本例では分割単位を循環して送るものと
し、fromの１つ前にあたる分割単位番号を設定する。次
に該ソースデータに対する復旧が開始しているかをチェ
ックし（ステップ754）、開始している場合は復旧開始
通知メッセージ待ちに入る。開始していない場合は、復
旧シーケンス番号seq_verを更新し（ステップ755）、復
旧データ送信処理を開始する。復旧データ送信処理は、
このスレッドで実行しても、別スレッドで実行してもよ
い。本処理においては、ソースデータ管理テーブルの復
旧終了レコード番号を見て復旧データ送信が完了したか
どうかを判定し（ステップ761）、完了したすなわちこ
のスレッドで復旧終了レコードまで一巡して送った場合
は終了する。完了していない場合は、次に送信すべき分
割単位を取得する（ステップ762）。本例では循環方式
で送るが、更新が発生して更新データとして送った分割
単位分を差し引いて送ってもよい。次にこのデータを復
旧用データとして送信要求し（ステップ763）、どの分
割単位まで送ったかを記憶し、完了判定にもどる。

【００１８】本処理において、データの送信及び復旧の
開始／完了状態の判定に、デスティネーション各々を意
識することはない。デスティネーションの数によらず、
全体でどこまで送ればよいかが管理されるのみである。
このため、デスティネーション数の増減による設定の変
更や性能の劣化を発生させずに、柔軟にシステムを拡張
／縮小することができる。

【００１９】図９は、デスティネーションの処理を示す
フローチャートである。ソースからのメッセージを待ち
（ステップ851）、ソースからのメッセージを取得する
（ステップ852）。該メッセージをデスティネーション
データ管理テーブルに登録されているデータごとに処理
する（ステップ853）。１つのデスティネーションデー
タを選択し（ステップ861）、該データの現在状態を管
理テーブルより取得し、復旧待ち状態である場合は（ス
テップ862）受信メッセージヘッダよりstatus及びrecov
ery部、該デスティネーションデータのDF及びDIDと指定
条件を設定して復旧開始通知を送信し（ステップ87
1）、現在状態を復旧中にする（ステップ872）。次にア
イテム部を検索してデスティネーションデータとDF及び
DIDが一致するものを選択し（ステップ863）、受信メッ
セージ中のアイテム部を順次処理する。本ステップにお
いて、デスティネーションデータの現在状態が更新中で
ある場合は復旧用のアイテムすなわちアイテムヘッダの
ctl部に0または3が指定されているものは無視する。ま
たデスティネーションデータに条件が指定されている場
合は、該条件を満たすもののみを選択する。選択された
アイテムデータは、管理テーブルに指定された書き込み
プロセスに渡して媒体へ格納する、またはユーザプロセ
スに渡す（ステップ864）。その後、デスティネーショ
ンデータの状態更新を行なう（ステップ865）。本状態
更新においては、デスティネーションデータが復旧中で
ある場合は、アイテムデータの論理分割単位番号を用い
て管理テーブルの復旧終了判定マップを更新して復旧が
完了したかを判定し、完了した場合は更新中に状態を更
新する。更新中である場合は何もしない。

【００２０】本処理により、デスティネーションは自ら
の状態を元に復旧データと更新データの判定を行ない、
また自ら復旧の完了を判定できる。これにより、複数の
デスティネーションの自律的な復旧と一致化が可能とな
る。

【００２１】以下、復旧及び一致化の種々の形態につい
て、説明する。図１０は、１ソースデータから１デステ
ィネーションデータへの複製の例である。処理装置901
がソース、処理装置902がデスティネーションである。
本例では、外部記憶装置911に格納されているソースデ
ータ921を、記憶装置912に格納されるデスティネーショ
ンデータ922へ複製する。921、922には、同一のDF及びD
IDが割り当てられている。デスティネーションデータ92
2には、条件が指定されておらず全データを複製する。

【００２２】図１１は、図１０の例における、復旧及び
更新処理のイベントシーケンス例である。デスティネー
ション側の受信処理1001と、ソース側の更新通知及び送
信処理1002、復旧データ送信処理1003間のデータのやり
取りを示す。デスティネーション側処理1001は、復旧を
開始したいとき少なくとも１つのソースからのメッセー
ジを待つ。これを受信すると（1011）、該受信メッセー
ジヘッダ中のrecovery部のfromを含む前述のデータを設
定して復旧開始通知をソースに送る（1012）。ソース側
は該通知を受信して、復旧終了位置を保存し（1021）、
復旧用データの送信を開始する。本例では循環送信を行
なっており、分割単位番号2から順次復旧用として分割
単位データを送信依頼する（1031、1032）。復旧中にソ
ースデータが更新されても、復旧データの送信（1014）
と該更新データの送信（1013）は並行して行なわれ、全
ての分割単位のデータが受信されたときに復旧処理は終
了する。更新処理は、分割単位の削除や追加も含み、全
分割単位数は変わらない。本例では分割単位番号1のデ
ータ（1033）を含むメッセージを受信して復旧を完了し
ている（1015）。復旧が完了すると、メッセージ中の復
旧用データは廃棄し（1016）、更新用のデータのみ受け
取る（1017）。

【００２３】次に、１ソースデータから複数のデスティ
ネーションデータへの複製の例を図１２に示す。処理装
置1101がソース、処理装置1102、1103がデスティネーシ
ョンである。本例では、処理装置1101内部に格納されて
いるソースデータ1121を、外部記憶装置1111に格納され
るデスティネーションデータ1122、及び外部記憶装置11
12に格納されるデスティネーションデータ1123へ複製す
る。処理装置1102、1103は独立しており、それぞれ任意
のタイミングで復旧を開始したりする。1121〜1123に
は、同一のDF及びDIDが割り付けられている。

【００２４】図１３は、図１２の例における復旧及び更
新のイベントシーケンス例である。デスティネーション
側となる処理装置1111の受信処理1201と処理装置1112の
受信処理1202、ソース側の更新通知及び送信処理1203、
復旧データ送信処理1204間のデータのやり取りを示す。
1211〜1213の処理は、図１０及び図１１で説明した１ソ
ース１デスティネーションの場合と同様である。デステ
ィネーション1202が復旧を開始し、復旧終了レコード位
置の設定（1221）と、復旧用データの送信（1231、123
2）が行なわれている。ここで、デスティネーション120
1が復旧を開始する。1201はデスティネーション1202用
の復旧データを含むメッセージ1214を受け取り、該メッ
セージより分割単位番号10以降の復旧データを受信し始
めたことを知るとともに、ソースへ通知する（1215）。
ソースはこのメッセージをうけとり、新しいデスティネ
ーションが復旧を始めたこと、及び分割単位番号10から
復旧を始めたことを知り、復旧終了分割単位番号を9と
して更新する（1222）。その後ソースは更新データに含
めて復旧データを循環して分割単位9まで送る（1233、1
234）。分割単位1を受信してデスティネーション1202が
復旧を完了し（1216）、分割単位9を受信してデスティ
ネーション1201が復旧を完了する（1217）。

【００２５】本処理例において、ソースは２つのデステ
ィネーションに対してそれぞれ復旧を行なうのでない。
全体の復旧状態のみを管理し、分割単位を2から最後ま
で送った後1から9まで循環して送っている。復旧データ
送信は、全体での復旧完了番号まで送り終わったところ
で終了する。各デスティネーションは、他のデスティネ
ーションに対する復旧データも傍受しながら、自ら復旧
の完了を判断することができる。このため、他のデステ
ィネーションの状態に関わらずデータの更新を行なった
り、ソースに過負荷をかけたり他のデスティネーション
への更新や復旧を妨げることなく復旧を遂行することが
できる。

【００２６】図１４は、前述の例の組み合わせ例であ
る。処理装置1301がソースとなり、ソースデータ1321、
1322をそれぞれ処理装置1302のデスティネーションデー
タ1323、処理装置1303のデスティネーションデータ1324
へ一致化及び復旧させる。これらのデータの一致化及び
復旧は、同一のメッセージ1341への相乗りで行なう。処
理装置1302はまた、ソースとなりソースデータ1331を処
理装置1303へ複製させる。処理装置1303においては、全
データを外部記憶装置1312中のデスティネーションデー
タ1324へ保存し、さらに内部記憶装置中のデスティネー
ションデータ1333にその一部を保存する。データ1331〜
1333は、同一のDF及びDIDが割り当てられている。本例
においても、前述の処理と同様に復旧及び一致化が好適
に実行される。

【００２７】

【発明の効果】ソースデータの更新や復旧を論理的に分
割された単位ごとに行ない、該分割単位の転送において
デスティネーションを指定せず、それぞれに復旧用／更
新用といった識別子を付けて転送し、デスティネーショ
ン側で受信の判断と復旧の完了を判断することにより、
ソースの設定を変えたりすることなくデスティネーショ
ンを増減させることが可能となり、システムの柔軟性が
向上する。また本方法により、ソースデータの更新と復
旧を並行して行なうことが可能となり、システム全体の
処理、特にオンライン処理を停滞させることなく復旧を
行なうことができる。また複数のデスティネーション側
が並行して復旧を行なうことができるため、ソースを過
負荷にすることなく、復旧処理の性能が向上する。

【図面の簡単な説明】

【図１】本発明の一実施例における分散処理システムの
構成を示すブロック図。

【図２】本発明におけるソースデータの論理分割例の説
明図。

【図３】共通伝送媒体を介して処理装置間で送受信され
るメッセージデータの構成図。

【図４】データの一致化と復旧方法を実現するソース側
及びデスティネーション側のテーブル例説明図。

【図５】データの一致化及び復旧に用いるメッセージの
フォーマット図。

【図６】本発明を実現する処理装置内のプログラム構成
例説明図。

【図７】更新されたソースデータ及び復旧データの送信
処理を管理する処理を示すフローチャート。

【図８】更新されたソースデータ及び復旧データの復旧
開始／完了管理する処理を示すフローチャート。

【図９】更新データ及び復旧データを受信する処理を示
すフローチャート。

【図１０】１ソース１デスティネーションの場合での構
成例図。

【図１１】図１０の処理のイベントシーケンス説明図。

【図１２】１ソース２デスティネーションの場合での構
成例図。

【図１３】図１２の処理のイベントシーケンス説明図。

【図１４】図１０及び図１２にて説明した例の複合形態
での実施例の説明図。

【符号の説明】

601：ソース処理装置、602：デスティネーション処理装
置、611〜612ユーザプログラム、621：データ更新管理
プロセス、622：データ送信プロセス、623：復旧管理プ
ロセス、624：データ受信プロセス。

フロントページの続き (72)発明者 河野 克己 神奈川県川崎市麻生区王禅寺1099番地 株式会社日立製作所 システム開発研究 所内 (72)発明者 綿谷 洋 茨城県日立市大みか町五丁目２番１号 株式会社日立製作所 大みか工場内 (72)発明者 松野 強 茨城県日立市大みか町５丁目２番１号 日立プロセスコンピュータエンジニアリ ング株式会社内 (56)参考文献 特開 平２−162430（ＪＰ，Ａ) 特開 平４−195444（ＪＰ，Ａ) 特開 平３−63845（ＪＰ，Ａ) 特開 平２−260055（ＪＰ，Ａ) 特開 平４−302040（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 12/00 G06F 15/00

Claims (6)

(57)【特許請求の範囲】
1. 【請求項１】伝送媒体に接続された複製元処理装置と、
   複数の複製先処理装置と、からなり、前記複製先処理装
   置の各々が、前記複製元処理装置の保持するデータの複
   製データを保持する処理システムにおいて、前記複製先
   処理装置の各々が、前記複製データを復旧するデータの
   復旧方法であって、 前記複製先処理装置の各々は、前記複製元処理装置が前
   記保持するデータを所定の単位に分割して送信する分割
   データと、当該分割データに付された各々を識別する識
   別子と、に基づく前記複製データの復旧開始通知を、前
   記複製元処理装置に通知し、 前記複製元処理装置は、 前記複製先処理装置の各々から通知された、前記復旧開
   始通知に基づき、 前記分割データの内、前記複数の複製先処理装置の何れ
   もが復旧を完了するのに十分な前記分割データを、更新
   用データであるか復旧用データであるかの識別子と、前
   記分割データ各々を識別する識別子とを付し、前記複製
   先処理装置を特定する宛先を付さずに、前記伝送媒体に
   出力し、 前記複製先処理装置の各々は、 前記伝送媒体上の前記分割データ各々を受信し、 自処理装置が前記複製データの復旧処理中であるか否か
   の処理状態を検出し、 自処理装置が復旧処理中であると検出した場合に、受信
   した前記分割データの中から、付された前記識別子によ
   り自処理装置の前記複製データの復旧に必要な前記分割
   データを識別し、 前記識別した前記分割データに基づいて前記複製データ
   の復旧処理を行うことを特徴とするデータの復旧方法。
2. 【請求項２】請求項１のデータの復旧方法において、 前記複製元処理装置は、 前記分割データ単位のそれぞれに、前記分割データ各々
   を識別する識別子として識別番号を付して、前記分割デ
   ータを管理し、 前記分割データを所定の順序で前記伝送媒体に出力し、 前記複製先処理装置の各々は、前記復旧開始通知を、自
   処理装置が復旧を開始する際に用いた前記分割データの
   識別番号を含めて、前記複製元処理装置へ通知し、 前記複製元処理装置は、 前記複数の複製先処理装置の各々から受信した前記復旧
   開始通知から、前記複数の複製先処理装置何れもが復旧
   を完了するのに十分な前記識別番号を特定し、 前記特定した識別番号に達するまで、前記分割データを
   所定の順序で伝送媒体に出力することを特徴とするデー
   タの復旧方法。
3. 【請求項３】請求項２のデータの復旧方法において、 前記複製先処理装置は、 前記受信した分割データの前記識別番号が、自処理装置
   が通知した前記復旧開始通知に含めた前記識別番号から
   特定できる、自処理装置が復旧を完了するのに十分な前
   記分割データの識別番号に達するまで、前記分割データ
   を用いて前記復旧処理を行うことを特徴とするデータの
   復旧方法。
4. 【請求項４】伝送媒体を介して複製元処理装置と接続
   し、該複製元処理装置の保持するデータの複製データを
   保持する処理装置において、 前記複製元処理装置により前記保持するデータが所定の
   単位に分割されて、更新用データであるか復旧用データ
   であるかの識別子と前記分割データ各々を識別する識別
   子とが付され、前記複製先処理装置を特定する宛先を付
   されずに、前記伝送媒体に送出される分割データを受信
   する手段と、 受信した前記分割データに基づく、前記複製データの復
   旧開始通知を、前記複製元処理装置に通知する手段と、 自処理装置が前記複製データの復旧処理中であるか否か
   の処理状態を検出する手段と、 自処理装置が復旧処理中であると検出した場合に、受信
   した前記分割データの中から、付された前記識別子によ
   り自処理装置の前記複製データの復旧に必要な前記分割
   データを識別する手段と、 前記識別した前記分割データに基づいて前記複製データ
   の復旧処理を行う手段と、を有することを特徴とする処
   理装置。
5. 【請求項５】請求項４の処理装置において、 前記分割データには、前記分割データ各々を識別する前
   記識別子として識別番号が付され、 前記複製元処理装置が復旧を完了するのに十分な分割デ
   ータを特定できるように、自処理装置が復旧を開始する
   際に用いた前記分割データに付された前記識別番号を、
   前記復旧開始通知に含める手段を有することを特徴とす
   る処理装置。
6. 【請求項６】請求項５の処理装置において、 前記復旧処理を行う手段は、 前記受信した分割データの前記識別番号が、自処理装置
   が通知した前記復旧開始通知に含めた前記識別番号から
   特定できる、自処理装置が復旧を完了するのに十分な前
   記分割データの識別番号に達するまで、前記分割データ
   を用いて前記復旧処理を行うことを特徴とする処理装
   置。