JP2015191514A - データ復旧システム及びデータ復旧方法 - Google Patents

データ復旧システム及びデータ復旧方法 Download PDF

Info

Publication number
JP2015191514A
JP2015191514A JP2014069225A JP2014069225A JP2015191514A JP 2015191514 A JP2015191514 A JP 2015191514A JP 2014069225 A JP2014069225 A JP 2014069225A JP 2014069225 A JP2014069225 A JP 2014069225A JP 2015191514 A JP2015191514 A JP 2015191514A
Authority
JP
Japan
Prior art keywords
client
server
data
side database
priority
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.)
Granted
Application number
JP2014069225A
Other languages
English (en)
Other versions
JP6262055B2 (ja
Inventor
尊仁 天津
Takahito Amatsu
尊仁 天津
義文 折茂
Yoshifumi Orimo
義文 折茂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Metawater Co Ltd
Original Assignee
Metawater Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Metawater Co Ltd filed Critical Metawater Co Ltd
Priority to JP2014069225A priority Critical patent/JP6262055B2/ja
Publication of JP2015191514A publication Critical patent/JP2015191514A/ja
Application granted granted Critical
Publication of JP6262055B2 publication Critical patent/JP6262055B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】サーバが停止した場合であってもタイムラグ無くデータの閲覧をすることができるデータ復旧システム及びデータ復旧方法を提供する。
【解決手段】通信状態にあるサーバ2とクライアント3とを備え、サーバ2が外部からのデータを常時受信して該データを格納するサーバ側データベース22を有し、クライアント3が外部からのデータを常時受信して該データを格納するクライアント側データベース32を有するデータ復旧システムであって、クライアント3は、サーバ2と通信不能であることを検知した場合に縮退モードに移行することを特徴とする。
【選択図】図1

Description

本発明は、サーバコンピュータ及びクライアントコンピュータを備えるデータ復旧システム及びデータ復旧方法に関するものである。
従来から、サーバコンピュータ(以下、サーバという。)とクライアントコンピュータ(以下、クライアントという。)を備えるシステムにおいて、サーバが異常等により停止した場合のシステムの復旧方法が提案されている(例えば特許文献1)。具体的には特許文献1には、サーバが異常等により稼働状態でないことをクライアントが検知した場合、クライアントがサーバプログラムを実行することによりサーバとして機能し、システムの復旧を迅速に行う技術が開示されている。
特開2005−107819号公報
従来の技術は、サーバが稼働状態でないことが検知された場合に、クライアントがサーバプログラムを起動する構成を採用している。そのため、例えばサーバがデータを常時受信し蓄積するシステムにおいては、サーバの停止からクライアントにおけるサーバプログラムの起動までの間のデータを受信することができず、データ当該期間においてデータを閲覧することができなかった。
従って、上記のような問題点に鑑みてなされた本発明の目的は、サーバが停止した場合であってもタイムラグ無くデータの閲覧をすることができるデータ復旧システム及びデータ復旧方法を提供することにある。
上記課題を解決するために本発明に係るデータ復旧システムは、
通信状態にあるサーバとクライアントとを備え、前記サーバが外部からのデータを常時受信して該データを格納するサーバ側データベースを有し、前記クライアントが前記外部からの前記データを常時受信して該データを格納するクライアント側データベースを有するデータ復旧システムであって、
前記クライアントは、前記サーバと通信不能であることを検知した場合に縮退モードに移行することを特徴とする。
また本発明に係るデータ復旧システムは、前記サーバが、自装置が稼働停止後に再起動した場合、前記サーバ側データベースのデータに欠損が発生しているか否かを判定し、欠損が発生している場合、前記クライアント側データベースに基づき前記サーバ側データベースのデータを補完することを特徴とする。
また本発明に係るデータ復旧システムは、前記クライアントが、自装置が稼働停止後に再起動した場合、前記クライアント側データベースのデータに欠損が発生しているか否かを判定し、欠損が発生している場合、前記サーバ側データベースに基づき前記クライアント側データベースのデータを補完することを特徴とする
また本発明に係るデータ復旧システムは、
前記データ復旧システムは前記クライアントを複数備え、
前記複数のクライアントは自己の優先度を記憶しており、
前記サーバは、自装置が稼働停止後に再起動した場合、前記サーバ側データベースのデータの欠損が発生した期間を判定し、前記優先度が最高のクライアントの前記クライアント側データベースに基づき、前記サーバ側データベースの前記期間におけるデータを補完することを特徴とする。
また本発明に係るデータ復旧システムは、
前記優先度が、前記クライアントの直近の起動時刻が早い程、高く設定されることを特徴とする。
また本発明に係るデータ復旧システムは、
前記クライアントが、自装置が稼働停止後に再起動した場合、前記クライアント側データベースのデータに欠損が発生しているか否かを判定し、前記欠損が発生している場合、前記サーバが補完をした後の前記サーバ側データベース又は前記優先度が最高のクライアントの前記クライアント側データベースに基づき前記クライアント側データベースのデータを補完することを特徴とする。
また、本発明に係るデータ復旧方法は、
通信状態にあるサーバとクライアントとを備え、前記サーバが外部からのデータを常時受信して該データを格納するサーバ側データベースを有し、前記クライアントが前記外部からの前記データを常時受信して該データを格納するクライアント側データベースを有するシステムにおけるデータ復旧方法であって、
前記クライアントが、前記サーバとの通信状態を監視し、前記サーバと通信不能であることを検知した場合に縮退モードに移行するステップ
を含むことを特徴とする。
本発明におけるデータ復旧システム及びデータ復旧方法によれば、サーバが停止した場合であってもタイムラグ無くデータの閲覧をすることができる。
実施の形態1のデータ復旧システムのブロック図である。 実施の形態1のデータ復旧システムのサーバの動作を示すフローチャートである。 実施の形態1のデータ復旧システムのクライアントの動作を示すフローチャートである。 実施の形態2のデータ復旧システムのブロック図である。 優先度決定処理を示すフローチャートである。 実施の形態2のデータ復旧システムのサーバの動作を示すフローチャートである。 実施の形態2のデータ復旧システムのクライアントの動作を示すフローチャートである。 優先度決定処理を他の例を示すフローチャートである。
以下、本発明の実施の形態について説明する。
(実施の形態1)
図1は本発明の実施の形態1に係るデータ復旧システムのブロック図である。実施の形態1に係るデータ復旧システムは、コントローラ1と、サーバ2と、クライアント3とを備える。コントローラ1とサーバ2間、及びコントローラ1とクライアント3間は制御LAN(Local Area Network)4により接続されている。またサーバ2と、クライアント3とは、情報LAN5により接続されている。概略として本システムにおいては、コントローラ1から監視に必要なデータをサーバ2及びクライアント3のデータベースに格納し、クライアント3により、サーバ2に格納したデータを表示可能なように構成されている。なおコントローラ1は本システムにおいて必須の構成ではなく、サーバ2及びクライアント3は、外部からデータを受信する構成であればよい。
コントローラ1は、プラントを監視する外部の装置である。コントローラ1は、制御LAN4によりサーバ2及びクライアント3に、プラントに係る瞬時値、等のデータを常時送信する。図1においてはコントローラ1が1台のみの例を示しているがこれに限られず、コントローラ1は2台以上であってもよい。
サーバ2は、通信部21と、サーバ側データベース(DB)22と、表示部23と、制御部24とを備える。
通信部21は、制御LAN4を介して外部であるコントローラ1と通信する。また通信部21は、情報LAN5を介して、クライアント3と通信、すなわちデータの送受信をする。通信部21は、サーバ2に割り当てられた制御LAN4用のIPアドレスと、情報LAN5のIPアドレスとを用いてこれらの通信を行う。
サーバ側データベース22には、制御LAN4を介してコントローラ1から通信部21が常時受信しているデータが格納(蓄積)される。
表示部23は、液晶ディスプレイ、有機ELディスプレイ等により構成され、サーバ側データベース22のデータを抽出して、ユーザの指定する形式で表示する。ユーザの指定する形式は、瞬時データ、トレンドデータ、履歴データ、帳票データ等を加工したトレンド画面、履歴画面、帳票画面等の表示画面である。すなわちユーザは表示部23により、コントローラ1からのデータを適宜閲覧することができる。
制御部24は、サーバ2に係る各種制御を行う。例えば制御部24は、制御LAN4を介して通信部21がコントローラ1から受信した瞬時値等のデータを、サーバ側データベース22に格納する。また制御部24は、クライアント3にサーバ側データベース22に格納されているデータを通信部21により送信する。
また制御部24は、自装置の状況を監視し、自装置が稼働停止状態から再起動したか否かを判定する。サーバ2の稼働停止は、通信部21に異常が生じた場合、又はサーバ2自体に異常が生じた場合に起きる。また制御部24は、クライアント3との通信を監視し、通信状態又は通信不能であるかを検知する。ここで通信状態とは、サーバ2又はクライアント3が、サーバ2とクライアント3とつながる情報LAN5を介して、それぞれが相手を検知できる状態である。また通信不能とは、サーバ2又はクライアント3が、サーバ2とクライアント3とつながる情報LAN5を介して、相手を検知できない状態である。通信不能の原因として考えられるのは、サーバ2がクライアント3を検知できなくなる場合(原因1)と、クライアント3がサーバ2を検知できなくなる場合(原因2)の2つがある。原因1の場合、さらにサーバ2とクライアント3とつながる情報LAN5に異常が生じたことに起因する場合(原因1−1)と、クライアント3が、クライアント3の各部設備に故障が生じたこと(例えば通信部31に異常が生じた)、クライアントの制御LAN4に異常が生じたこと(データを取れなくなる)、クライアント3の保守などによってクライアント3の稼動が停止したことに起因する場合(原因1−2)とがある。原因1−1の場合、データの欠損は生じない。一方、原因1−2の場合、クライアント側データベース32にデータ欠損が生じる。
また原因2の場合、さらにサーバ2とクライアント3とつながる情報LAN5に異常が生じたことに起因する場合(原因2−1)と、サーバ2が、サーバ2の各部設備に故障(例えば通信部21に異常が生じた)生じたこと、サーバ2の制御LAN4に異常が生じたこと(データを取れなくなる)、サーバ2の保守などによってサーバ2の稼動が停止したことに起因する場合(原因2−2)とがある。原因2−1の場合、データの欠損は生じない。原因2−2の場合、サーバ側データベース22にデータ欠損が生じる。
制御部24は、自装置が稼働停止から再起動した場合、サーバ側データベース22にデータの欠損があるか否かを判定する。制御部24は、データの欠損がある場合、後述するクライアント3のクライアント側データベース32に基づき、サーバ側データベース22のデータを補完する。この場合、制御部24は、サーバ側データベース22において欠損の生じている期間を特定し、当該期間におけるデータをクライアント側データベース32から取得して、当該期間のデータの補完をする。データの欠損は、例えばサーバ2の通信部21において異常が生じコントローラ1との通信ができていなかった場合に生じる。あるいは、サーバ2が異常停止していた場合にも、生じる。このような場合において、制御部24は、稼働停止から再起動した場合、サーバ側データベース22にデータの欠損があることを検知し、クライアント側データベース32に基づき、サーバ側データベース22のデータを補完する。
クライアント3は、通信部31と、クライアント側データベース(DB)32と、表示部33と、制御部34とを備える。
通信部31は、制御LAN4を介して外部であるコントローラ1と通信する。また通信部31は、情報LAN5を介して、サーバ2と通信、すなわちサーバ2とデータの送受信をする。通信部31は、クライアント3に割り当てられた制御LAN4用のIPアドレスと、情報LAN5のIPアドレスとを用いてこれらの通信を行う。
クライアント側データベース32には、制御LAN4を介してコントローラ1から通信部31が常時受信しているデータが格納(蓄積)される。なおクライアント側データベース32に格納されるデータは、所定期間内(以下、データ保持期間という。)におけるデータであり、当該期間よりも前のデータは削除される。したがってクライアント側データベース32に格納されているデータは、サーバ側データベース22に格納されるデータよりもデータ量が少ない。
表示部33は、液晶ディスプレイ、有機ELディスプレイ等により構成される。表示部33には、サーバ2から受信するサーバ側データベース22のデータを抽出して、ユーザの指定する形式で表示する。ユーザの指定する形式は、瞬時データ、トレンドデータ、履歴データ、帳票データ等を加工したトレンド画面、履歴画面、帳票画面等の表示画面である。すなわちユーザは表示部33により、コントローラ1からのデータを適宜閲覧することができる。
制御部34は、クライアント3に係る各種制御を行う。例えば制御部34は、制御LAN4を介して通信部31がコントローラ1から受信した瞬時値等のデータを、クライアント側データベース32に格納する。また制御部34は、通信部31により、サーバ2からサーバ側データベース22に格納されているデータを受信する。また制御部34は、当該データを表示部33に表示させる。
さらに制御部34は、サーバ2との情報LAN5による通信の状況を監視し、通信状態であるか、通信不能であるかを判定する。
制御部34は、サーバ2との通信状況に応じて、クライアント3を縮退モードに移行させる。ここで縮退モードとは、サーバ2が通信不能であるとクライアント3の制御部34が判定した場合に、クライアント3が移行する動作モードである。縮退モードにおいては、クライアント3がユーザ指示に基づきコントローラからのデータを参照する際、サーバ側データベース22の代わりに、自己のクライアント側データベース32を参照する。このようにサーバ2と通信不能である場合、クライアント3は縮退モードに移行するため、ユーザはサーバ2と通信ができない状況であっても、コントローラ1からクライアント3が受信している瞬時値等のデータを参照することができる。なお通常の動作モード(以下、通常モードという。)においては、上述したようにクライアント3がユーザ指示に基づきコントローラからのデータを参照する際、サーバ側データベース22を参照する。
なおクライアント3がサーバ2と通信不能になる場合は、例えばサーバ2の稼働が停止している場合、サーバ2とクライアント3との間の情報LAN5に係る通信経路に異常がある場合が考えられる。
また制御部34は、サーバ2と通信可能に復帰した場合、縮退モードから通常モードに移行する。
また制御部34は、自装置の状況を監視し、自装置が稼働停止状態から再起動したか否かを判定する。クライアント3の稼働停止は、通信部31に異常が生じた場合、又はクライアント3自体に異常が生じた場合に起きる。制御部34は、自装置が稼働停止から再起動した場合、データ保持期間内のクライアント側データベース32のデータに欠損があるか否かを判定する。制御部34は、データの欠損がある場合、サーバ2のサーバ側データベース22に基づき、クライアント側データベース32のデータを補完する。例えば制御部34は、クライアント側データベース32において欠損の生じている期間を特定し、当該期間におけるデータを、サーバ側データベース22から取得して、当該期間のデータの補完をする。データの欠損は、例えばクライアント3の通信部31において異常が生じコントローラ1との通信ができていなかった場合に生じる。あるいは、クライアント3が異常停止していた場合にも、生じる。このような場合において、制御部34は、サーバ2と通信不能から通信状態に復帰した場合、クライアント側データベース32にデータの欠損があることを検知し、サーバ側データベース22に基づき、クライアント側データベース32のデータを補完する。
次に、実施の形態1に係るデータ復旧システムについて、図2及び図3に示すフローチャートによりサーバ2及びクライアント3の各動作を説明する。
図2は、サーバ2の動作を示すフローチャートである。まずサーバ2の通信部21は、制御LAN4を介してコントローラ1からのデータを受信する(ステップS110)。なお通信部21はコントローラ1からのデータを常時受信している。制御部24は、制御LAN4を介して通信部21がコントローラ1から受信した瞬時値等のデータを、サーバ側データベース22に格納する。
続いてサーバ2が稼働停止し(ステップS120)、その後再起動した場合(ステップS130)、制御部24は、サーバ側データベース22にデータの欠損があるか否かを判定する(ステップS140)。制御部24は、データの欠損がある場合(ステップS140:はい)、クライアント3のクライアント側データベース32に基づき、サーバ側データベース22のデータを補完する(ステップS150)。例えば制御部24は、サーバ側データベース22において欠損の生じている期間を特定し、当該期間におけるデータを、クライアント側データベース32から取得して、データの補完をする。一方、データの欠損が無い場合(ステップS140:いいえ)、処理を完了する。
図3は、クライアント3の動作を示すフローチャートである。はじめにクライアント3の通信部31は、制御LAN4を介してコントローラ1からのデータを受信する(ステップS210)。なお通信部31はコントローラ1からのデータを常時受信している。制御部34は、制御LAN4を介して通信部31がコントローラ1から受信した瞬時値等のデータを、クライアント側データベース32に格納する。
続いてクライアント3がサーバ2と通信不能になった場合(ステップS220)、制御部34は、クライアント3を通常モードから縮退モードに移行させる(ステップS230)。その後、クライアント3がサーバ2と通信可能になった場合、制御部34は、クライアント3を縮退モードから通常モードに移行させる(ステップS240)。
続いて制御部34は、クライアント3が稼働停止し(ステップS250)、再起動した場合(ステップS260)、クライアント側データベース32にデータ保持期間内におけるデータの欠損があるか否かを判定する(ステップS270)。制御部34は、データの欠損がある場合、サーバ2のサーバ側データベース22に基づき、クライアント側データベース32のデータを補完する(ステップS280)。例えば制御部34は、クライアント側データベース32において欠損の生じている期間を特定し、当該期間におけるデータを、サーバ側データベース22から取得して、データの補完をする。一方、データの欠損が無い場合(ステップS270:いいえ)、処理を完了する。
図1に戻り、実施の形態1のデータ復旧システムにおけるデータ補完の概念を示す。図1において、矢印6は、クライアント3からサーバ2へデータの補完をしていることを示している。例えばサーバ2が異常等により停止して通信不能になり、その後サーバ2が起動して通信状態になった場合、矢印6に示すようにクライアント3のクライアント側データベース32から、サーバ2にデータを送信し、サーバ側データベース22のデータを補完する。
このように本発明によれば、サーバ2及びクライアント3が常時コントローラ1からのデータを常時受信し、それぞれサーバ側データベース22及びクライアント側データベース32に格納している。そしてクライアント3がサーバ2と通信できない場合、クライアントが縮退モードに移行することで、ユーザはサーバ2と通信ができない状況であっても、コントローラ1からクライアント3が受信している瞬時値等のデータを参照することができる。さらにサーバ2及びクライアント3が、異常停止、通信障害等により通信不能な状態から通信可能な状態に復帰した場合に、各データベースの欠損の有無を判定し、欠損がある場合に別のデータベースに基づきデータを補完するようにしている。このため、データを常時受信し蓄積するようなシステムにおいても、データの完全性及び信頼性の低下を防止することができる。
(実施の形態2)
以下に、本発明の実施の形態2について説明をする。図4は本発明の実施の形態2のデータ復旧システムの構成を示すブロック図である。実施の形態1と同一の構成については同一の符号を付し、説明は省略する。実施の形態2に係るデータ復旧システムは、実施の形態1にかかる構成と比較して、クライアントが複数存在する点が相違する。本実施の形態では、クライアント3a、3bの2台のクライアントを備える例を説明するがこれに限られず、クライアント端末は3台以上であってもよい。クライアント3aとクライアント3bとの構成は同一であるため、以下クライアント3aについてその構成を説明し、クライアント3bの構成については説明を省略する。
クライアント3aは、通信部31aと、クライアント側データベース32aと、表示部33aと、制御部34aと、優先度記憶部35aとを備える。通信部31a、クライアント側データベース32a、表示部33aは、それぞれ実施の形態1の通信部31、クライアント側データベース32、表示部33と同一の構成である。
制御部34aは、実施の形態1の制御部34に対応する。制御部34aは、実施の形態1の制御部34と同様の制御に加えて、以下に示す制御を行う。
制御部34aは、自己の端末の優先度(優先順位)を設定する処理(以下、優先度設定処理という)を行う。優先度とは、サーバ2、又はクライアント(3a又は3b)が自己のデータベースの補完を行う場合に、補完元となるデータベースの順位を示す値である。サーバ2、は、優先度が最高のクライアント(3aまたは3b)のクライアント側データベースに基づき、自己のデータベースを補完する。また、優先度が最高でないクライアント(3a又は3b)は、優先度が最高のクライアント(3aまたは3b)のクライアント側データベースに基づき自己のデータベースを補完する。本実施の形態の場合、クライアントが2台であるため、優先度は1または2である。この場合優先度「1」が最高であり、優先度「2」は、優先度「1」より低い。なおクライアントがN台存在する場合には、優先度は1からNまでとなる。ここでNは2以上の整数である。当該優先度は、優先度記憶部35aに格納される。
制御部34aは優先度設定処理を、クライアントの端末起動時に行う。以下、制御部34aが行う優先度設定処理について説明する。図5は、優先度設定処理を示すフローチャートである。まず制御部34は、自己の直近の起動時刻を取得する(ステップS310)。次に制御部34aは、他の全てのクライアント(本実施の形態では、クライアント3b)の直近の起動時刻を通信部31aにより、情報LAN5を介して取得する(ステップS320)。続いて制御部34aは、自己の起動時刻と、他の全てのクライアントの起動時刻とを比較し、起動時刻順に優先度を設定する(ステップS330)。すなわち制御部34aは、直近の起動時刻が早い程、優先度を高く設定する。例えば制御部34aは、クライアント3aの直近の起動時刻が、2014年3月1日11時00分であり、クライアント3bの直近の起動時刻が2014年3月1日10時00分である場合、クライアント3aの優先度を2と設定する。またクライアント3bの優先度を1と設定する。制御部34aは、設定した優先度を、優先度記憶部35aに記憶する(ステップS340)。
制御部34aは、上述の優先度設定処理を、制御LAN4、情報LAN5等に異常が生じる等、状況が変化した場合に行う。具体的には制御部34aは、サーバ2と通信不能から通信可能に復帰した場合や、他のクライアント(クライアント3b)と通信不能から通信可能に復帰した場合(或いは通信可能から通信不能に変化した場合)に、優先度設定処理を行う。このような場合は、サーバ2又は他のクライアントが稼働停止や再起動等している可能性があり、直近の起動時刻が変わるため、制御部34aは、優先度設定処理をそれに応じて行う。
そして実施の形態2に係るサーバ2の制御部24は、サーバ側データベース22の補完の際に、クライアントの優先度を用いる。すなわち制御部24は、クライアント3と通信不能から通信状態に復帰した場合、サーバ側データベース22にデータの欠損があるか否かを判定する。制御部24は、データの欠損がある場合、優先度が最高のクライアント(例えばクライアント3b)のクライアント側データベース32bに基づき、サーバ側データベース22のデータを補完する。サーバ2は、クライアント3a、3bの優先度を、各クライアントから自動的に通知を受けて把握してもよい。或いはサーバ2がデータを補完する際に、各クライアント(3a、3b)に優先度の送信を要求して、各クライアントの優先度を把握してもよい。
同様にクライアント3aの制御部34aは、クライアント側データベース32aのデータに欠損があるか否かを判定する。制御部34aは、データの欠損がある場合、サーバ2のサーバ側データベース22に基づき、クライアント側データベース32aのデータを補完する。或いは制御部34aは、データの欠損がある場合、優先度が最高のクライアント(例えばクライアント3b)のクライアント側データベース32bに基づき、クライアント側データベース32aのデータを補完するようにしてもよい。
次に、実施の形態2に係るデータ復旧システムについて、図6、7に示すフローチャートによりサーバ2及びクライアント3aの各動作を説明する。実施の形態1と同一の動作については同一の符号を付し、説明は省略する。また、以下の動作ではクライアント3bの優先度が最高(優先度が1)であるものとして説明をする。
図6は、サーバ2の動作を示すフローチャートである。ステップS110からステップS140までは実施の形態1と同一である。サーバ2の制御部24は、データの欠損がある場合(ステップS140:はい)、優先度が最高のクライアント3bのクライアント側データベース32bに基づき、サーバ側データベース22のデータを補完する(ステップS151)。
図7は、クライアント3aの動作を示すフローチャートである。ステップS210からステップS240までは実施の形態1と同一である。クライアント3aの制御部34aは、ステップS240に続いて、優先度設定処理を行う(ステップS241)。その後、制御部34aは、クライアント側データベース32aにデータの欠損がある場合、サーバ2のサーバ側データベース22に基づき、データの補完をする。あるいは制御部34aは、クライアント3bのクライアント側データベース32bに基づき、クライアント側データベース32のデータを補完する(ステップS281)。
図4に戻り、実施の形態2のデータ復旧システムにおけるデータ補完の概念を示す。図4において、矢印7は、クライアント3bからサーバ2へデータの補完をしていることを示している。例えばサーバ2が異常等により停止して通信不能になり、その後サーバ2が起動して通信状態になった場合、矢印7に示すようにクライアント3のクライアント側データベース32から、サーバ2にデータを送信し、サーバ側データベース22のデータを補完する。また図4において、矢印8は、クライアント3bからクライアント3aへデータを送信して補完をしていることを示している。例えばクライアント3aが異常等により停止して通信不能になり、その後クライアント3aが起動して通信状態になった場合、矢印8に示すようにクライアント3bのクライアント側データベース32bから、クライアント3aにデータを送信し、クライアント側データベース32aのデータを補完する。
このように実施の形態2にかかるデータ復旧システムによれば、サーバ2及びクライアント3a、3bが常時コントローラ1からのデータを常時受信し、それぞれサーバ側データベース22及びクライアント側データベース32a、32bに格納している。そしてサーバ2及びクライアント3a、3bが、異常停止、通信障害等により通信不能な状態から、通常の通信可能な状態に復帰した場合に、各データベースの欠損の有無を判定し、欠損がある場合に優先度に応じて別のデータベースに基づきデータを補完するようにしている。このため、データを常時受信し蓄積するようなシステムにおいても、データの完全性及び信頼性の低下を防止することができる。また優先度は、起動時刻に応じて定めており、起動時刻が最も早いクライアントの優先度を高く設定しているため、最も完全性の高いデータを保持している可能性の高いデータベースからデータの補完ができ、データの完全性及び信頼性の低下を防止することができる。
ここで、サーバ、クライアントとして機能させるために、コンピュータを好適に用いることができ、そのようなコンピュータは、サーバ、クライアントの各機能を実現する処理内容を記述したプログラムを、当該コンピュータの記憶部に格納しておき、当該コンピュータの中央演算処理装置(CPU)によってこのプログラムを読み出して実行させることで実現することができる。
本発明を諸図面や実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形や修正を行うことが容易であることに注意されたい。従って、これらの変形や修正は本発明の範囲に含まれることに留意されたい。例えば、各手段、各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の手段やステップ等を1つに組み合わせたり、或いは分割したりすることが可能である。
例えば実施の形態1及び2において、コントローラ1とサーバ2と、クライアント3間は制御LAN4により通信し、サーバ2とクライアント3間は、情報LAN5により通信するものとしたがこれに限られない。例えば制御LAN4及び情報LAN5とを1つのLANにより構成するようにしてもよい。この場合、サーバ2及びクライアント3は、ネットワーク用のアドレス(IPアドレス)を1つのみ割り当てればよい。
また実施の形態2における優先度設定処理は上述したものに限られない。図8は優先度設定処理の他の例を示すフローチャートである。図8に示す優先度設定処理では、クライアント3aの制御部34aは、他の全てのクライアントの通信状態に係る情報(通信状態情報)を取得する(ステップS321)。そして制御部34aは、起動時刻に加えて、当該通信状態情報に応じて優先度を決定する(ステップS331)。通信状態情報は、制御LAN4及び情報LAN5に係る通信の状態を表す情報(各通信経路に係る通信可能か通信不能かを示す情報)を含む。例えばあるクライアントにおいて制御LAN4が通信不能である場合、当該クライアントはコントローラ1からのデータを受信できない。このような場合、当該クライアントの優先度を、起動時刻にかかわらず下げるようにしてもよい。このような優先度設定処理を行うことにより、コントローラ1からのデータに欠損が生じている可能性の高いクライアントの優先を下げ、データに欠損が生じていない可能性の高いクライアントの優先度を上げることになるため、よりデータの完全性及び信頼性の低下を防止することができる。
なお図7において、クライアント3aは優先度設定処理をステップS240の後のみに行っているがこれに限られず、ステップS220の後にも行ってもよい。またクライアント3aは、優先度設定処理を所定時間間隔毎に定期的に行ってもよい。
以下、各クライアントの起動時刻及び通信状態情報に応じて優先度を設定(変更)する例について説明する。まずクライアントA〜Cにそれぞれ起動順に優先度1〜3が設定されているとする。クライアントAが異常停止した場合、クライアントB及びクライアントCは、クライアントAと通信できないため、自己の直近の起動時刻がクライアントの起動時刻より早いと判断し、自己の優先度をそれぞれ1及び2に上げるように変更する。一方クライアントAは、再起動されたとき、自己の起動時刻が一番遅いと判断し、自己の優先度を3に下げる。
次に優先度が最高のクライアントの制御LAN4に異常が生じた場合の優先度の設定について説明する。まずクライアントA〜Cにそれぞれ起動順に優先度1〜3が設定されているとする。クライアントAの制御LAN4に異常が生じた場合、クライアントAは稼動停止される。クライアントB及びクライアントCは、クライアントAと通信できないため、自己の直近の起動時刻がクライアントの起動時刻より早いと判断し、自己の優先度をそれぞれ1及び2にあげるように変更する。一方クライアントAは、再起動されたとき、自己の起動時刻が一番遅いと判断し、自己の優先度を3に下げる。
次にあるクライアントの情報LAN5に異常が生じた場合の優先度の設定について説明する。まずクライアントA〜Cにそれぞれ起動順に優先度1〜3が設定されているとする。クライアントCの情報LAN5に異常が生じた場合、クライアントCは、クライアントA及びクライアントBと通信不能となるため、自己の直近の起動時刻が最も早いと判定し、優先度を1に上げ、かつ縮退モードに移行する。クライアントCの情報LANが正常に復帰した場合において、自己の直近起動時刻を、クライアントA及びBの直近の起動時刻と比較し、自己の優先度を変更する。このように構成しているため優先度が最高のクライアントが複数存在することを防ぐことができる。
次に、全てのクライアントの情報LAN5に異常が生じた場合の優先度の設定について説明する。当該異常は、例えばクライアントA〜Cを接続するスイッチングハブ等に異常が生じた場合に発生する。まずクライアントA〜Cにそれぞれ起動順に優先度1〜3が設定されているとする。クライアントA〜Cの情報LAN5に異常が生じた場合、クライアントA〜Cは、それぞれ他のクライアントと通信不能となるため、それぞれ自己の直近の起動時刻が最も早いと判定し、それぞれ自己の優先度を1に上げ、縮退モードに移行する。その後クライアントA〜Cの情報LANが正常に復帰した場合において、それぞれ自分の直近起動時刻を、他のクライアントの直近の起動時刻と比較し、自己の優先度を変更する。このように構成しているため優先度が最高のクライアントが複数存在することを防ぐことができる。
なお実施の形態1及び2のシステムにおいてサーバ2は表示部23を備えるとしたがこれに限られず、サーバ2には表示部23を設けなくてもよい。この場合、コントローラ1からのデータは、クライアント3(3a、3b)のみで閲覧することができる。
なお実施の形態1及び2のシステムにおいて、クライアント3(3a、3b)の制御部34は、サーバ2との通信状況に応じてクライアント3(3a、3b)を縮退モードに移行するとしたが、当該縮退モードへの移行を行わなくてもよい。すなわち制御部34は、図3及び図7におけるステップS230及びステップS240の縮退モードへの移行及び通常モードへの復帰を行わなくてもよい。この場合、クライアント3は、ステップS230及びステップS240以外の処理は行う。すなわちサーバ2及びクライアント3はそれぞれ、自装置が稼働停止から再起動した場合において、サーバ側データベース22及びクライアント側データベース32の補完の処理を行う。従来は、サーバがデータを常時受信し蓄積するシステムにおいては、サーバの停止からクライアントにおけるサーバプログラムの起動までの間のデータを受信することができず、データの欠損が生じてしまっていた。一方で本願発明の実施の形態1及び2では、当該データの欠損が生じないことを目的として、サーバ2及びクライアント3(3a、3b)がそれぞれ、自装置が稼働停止から再起動した場合において、サーバ側データベース22及びクライアント側データベース32の補完の処理を行う。そのため、サーバの停止からクライアントにおけるサーバプログラムの起動までの間のデータも受信及び記憶でき、データの完全性及び信頼性の低下を防止することができる。
1 コントローラ
2 サーバ
3、3a、3b クライアント
4 制御LAN
5 情報LAN
21 通信部
22 サーバ側データベース
23 表示部
24 制御部
31、31a、31b 通信部
32、32a、32b クライアント側データベース
33、33a、33b 表示部
34、34a、34b 制御部

Claims (7)

  1. 通信状態にあるサーバとクライアントとを備え、前記サーバが外部からのデータを常時受信して該データを格納するサーバ側データベースを有し、前記クライアントが前記外部からの前記データを常時受信して該データを格納するクライアント側データベースを有するデータ復旧システムであって、
    前記クライアントは、前記サーバと通信不能であることを検知した場合に縮退モードに移行することを特徴とする、データ復旧システム。
  2. 前記サーバは、自装置が稼働停止後に再起動した場合、前記サーバ側データベースのデータに欠損が発生しているか否かを判定し、欠損が発生している場合、前記クライアント側データベースに基づき前記サーバ側データベースのデータを補完することを特徴とする、請求項1に記載のデータ復旧システム。
  3. 前記クライアントは、自装置が稼働停止後に再起動した場合、前記クライアント側データベースのデータに欠損が発生しているか否かを判定し、欠損が発生している場合、前記サーバ側データベースに基づき前記クライアント側データベースのデータを補完することを特徴とする、請求項1又は2に記載のデータ復旧システム。
  4. 前記データ復旧システムは前記クライアントを複数備え、
    前記複数のクライアントは自己の優先度を記憶しており、
    前記サーバは、自装置が稼働停止後に再起動した場合、前記サーバ側データベースのデータの欠損が発生した期間を判定し、前記優先度が最高のクライアントの前記クライアント側データベースに基づき、前記サーバ側データベースの前記期間におけるデータを補完することを特徴とする、請求項1に記載のデータ復旧システム。
  5. 前記優先度は、前記クライアントの直近の起動時刻が早い程、高く設定されることを特徴とする、請求項4に記載のデータ復旧システム。
  6. 前記クライアントは、自装置が稼働停止後に再起動した場合、前記クライアント側データベースのデータに欠損が発生しているか否かを判定し、前記欠損が発生している場合、前記サーバが補完をした後の前記サーバ側データベース又は前記優先度が最高のクライアントの前記クライアント側データベースに基づき前記クライアント側データベースのデータを補完することを特徴とする、請求項4又は5に記載のデータ復旧システム。
  7. 通信状態にあるサーバとクライアントとを備え、前記サーバが外部からのデータを常時受信して該データを格納するサーバ側データベースを有し、前記クライアントが前記外部からの前記データを常時受信して該データを格納するクライアント側データベースを有するシステムにおけるデータ復旧方法であって、
    前記クライアントが、前記サーバとの通信状態を監視し、前記サーバと通信不能であることを検知した場合に縮退モードに移行するステップ
    を含むことを特徴とするデータ復旧方法。
JP2014069225A 2014-03-28 2014-03-28 データ復旧システム及びデータ復旧方法 Active JP6262055B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014069225A JP6262055B2 (ja) 2014-03-28 2014-03-28 データ復旧システム及びデータ復旧方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014069225A JP6262055B2 (ja) 2014-03-28 2014-03-28 データ復旧システム及びデータ復旧方法

Publications (2)

Publication Number Publication Date
JP2015191514A true JP2015191514A (ja) 2015-11-02
JP6262055B2 JP6262055B2 (ja) 2018-01-17

Family

ID=54425936

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014069225A Active JP6262055B2 (ja) 2014-03-28 2014-03-28 データ復旧システム及びデータ復旧方法

Country Status (1)

Country Link
JP (1) JP6262055B2 (ja)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0954719A (ja) * 1995-08-14 1997-02-25 Meidensha Corp クライアント・サーバ型データベース
JPH0981431A (ja) * 1995-09-19 1997-03-28 Fuji Facom Corp データベース処理システム及びデータベースの更新方法
JP2000122982A (ja) * 1998-10-14 2000-04-28 Mitsubishi Electric Corp 多階層クライアントサーバシステム
JP2000181770A (ja) * 1998-12-21 2000-06-30 Mitsubishi Electric Corp データベース保守管理システム
JP2000214919A (ja) * 1999-01-22 2000-08-04 Toshiba Corp 分散型プラント監視システム及びそのシステムの処理プログラムを記録する記録媒体
JP2005107819A (ja) * 2003-09-30 2005-04-21 Daifuku Logistic Technology:Kk コンピュータネットワークシステムのフェイルセーフ方法
JP2011248567A (ja) * 2010-05-26 2011-12-08 Toshiba Corp プラント監視システムおよびプラント監視方法

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0954719A (ja) * 1995-08-14 1997-02-25 Meidensha Corp クライアント・サーバ型データベース
JPH0981431A (ja) * 1995-09-19 1997-03-28 Fuji Facom Corp データベース処理システム及びデータベースの更新方法
JP2000122982A (ja) * 1998-10-14 2000-04-28 Mitsubishi Electric Corp 多階層クライアントサーバシステム
JP2000181770A (ja) * 1998-12-21 2000-06-30 Mitsubishi Electric Corp データベース保守管理システム
JP2000214919A (ja) * 1999-01-22 2000-08-04 Toshiba Corp 分散型プラント監視システム及びそのシステムの処理プログラムを記録する記録媒体
JP2005107819A (ja) * 2003-09-30 2005-04-21 Daifuku Logistic Technology:Kk コンピュータネットワークシステムのフェイルセーフ方法
JP2011248567A (ja) * 2010-05-26 2011-12-08 Toshiba Corp プラント監視システムおよびプラント監視方法

Also Published As

Publication number Publication date
JP6262055B2 (ja) 2018-01-17

Similar Documents

Publication Publication Date Title
CN106330475B (zh) 一种通信系统中管理主备节点的方法和装置及高可用集群
EP3550436A1 (en) Method and apparatus for detecting and recovering fault of virtual machine
US10609133B2 (en) Method and device for establishing communication connection
JP5707355B2 (ja) ホットスタンバイ方式によるクライアントサーバシステム
CN114531373A (zh) 节点状态检测方法、节点状态检测装置、设备及介质
CN106776206A (zh) 监听进程状态的方法、装置及电子设备
JP6007988B2 (ja) 予備系装置、運用系装置、冗長構成システム、及び負荷分散方法
CN113965494A (zh) 用于冗余进程网络中的故障检测和角色选择的方法
CN107465756B (zh) 一种服务请求处理的方法和装置
JP6262055B2 (ja) データ復旧システム及びデータ復旧方法
JP5989288B1 (ja) 冗長化システム及び通信ユニット
CN114567536B (zh) 异常数据处理方法、装置、电子设备和存储介质
US20230095362A1 (en) Routing Packet Processing Method, Communication Device, Storage Medium, and System
US10234841B2 (en) Programmable logic controller, slave device, and duplex system
US20180183709A1 (en) Communication node, communication system, communication method, and program
US20190199591A1 (en) System for provisioning racks autonomously in data centers
US10491421B2 (en) Ring protection network module
CN107509108A (zh) 一种智能电视在异常情况重启后网络类型恢复的方法
CN114124644A (zh) 基于Linux内核态的以太网OAM告警方法及装置
WO2020083271A1 (zh) 一种聚合链路收敛方法、装置及存储介质
US11010269B2 (en) Distributed processing system and method for management of distributed processing system
CN109088921B (zh) 一种写操作处理方法、装置和计算机可读存储介质
JP6591828B2 (ja) 中継装置および中継システム
JP2021026559A (ja) アラーム管理システムおよびアラーム管理方法
CN115714713B (zh) 电力监控系统多群组服务实例切换方法和装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20161121

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170823

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170905

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171024

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20171128

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171213

R150 Certificate of patent or registration of utility model

Ref document number: 6262055

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250