JP2013206072A - データ整合システム、データ整合方法およびデータ整合プログラム - Google Patents

データ整合システム、データ整合方法およびデータ整合プログラム Download PDF

Info

Publication number
JP2013206072A
JP2013206072A JP2012073667A JP2012073667A JP2013206072A JP 2013206072 A JP2013206072 A JP 2013206072A JP 2012073667 A JP2012073667 A JP 2012073667A JP 2012073667 A JP2012073667 A JP 2012073667A JP 2013206072 A JP2013206072 A JP 2013206072A
Authority
JP
Japan
Prior art keywords
server
data
servers
network
slave
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
JP2012073667A
Other languages
English (en)
Other versions
JP5900094B2 (ja
Inventor
Hiroko Nagashima
寛子 永島
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.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to JP2012073667A priority Critical patent/JP5900094B2/ja
Publication of JP2013206072A publication Critical patent/JP2013206072A/ja
Application granted granted Critical
Publication of JP5900094B2 publication Critical patent/JP5900094B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】 マスターサーバおよびスレーブサーバから構成されるシステムにおけるサーバ間のデータの整合性を保障することを目的とする。
【解決手段】本発明によるデータベースシステムのマスターサーバ201は、マスターサーバ201と複数のスレーブサーバ202のデータ同期をとり、マスターサーバ201およびスレーブサーバ202の過半数のサーバが、最新データを持つように制御する。
【選択図】 図1

Description

本発明は、データ整合システム、データ整合方法およびデータ整合プログラムに関し、特に、マスタースレーブレプリケションを行うデータベースシステムにおけるデータ整合システム、データ整合方法およびデータ整合プログラムに関する。
マスターサーバのデータをスレーブサーバにコピーして、データの同期をとるデータベースレプリケーションにおいて、マスターサーバと複数のスレーブサーバとを繋ぐネットワークに障害が発生すると、スレーブサーバへのコピーに失敗し、データの同期がとれなくなる。
このような障害が発生した場合に、スレーブサーバの一つを新マスターサーバとして昇格させる方法があるが、その場合に、何の根拠もなく昇格させるスレーブサーバを選んでしまうと、最新データを持っていないスレーブサーバを新しいマスターサーバとして選択してしまう可能性がある。
特許文献1に、ネットワーク障害前にシステムを構成していたサーバ(マスターサーバとスレーブサーバ)のうち過半数のサーバがネットワーク障害後にも繋がっている場合に、繋がっているサーバの中で最新のデータを持っているサーバを新しいマスターサーバとして決定するデータ管理システムが記載されている。
特許文献1について、図11を参照して、マスターサーバMと4台のスレーブサーバS1、S2、S3およびS4との計5台のサーバが、ネットワーク障害の発生により、サーバMおよびS1と、サーバS2、S3およびS4との2つのグループに分断されてしまった場合を考える(以下、すべての図において、データ番号は、データの更新世代を示し、データ番号の数が大きいほど新しいデータであるとする)。図11では、最新データ番号は3である。
しかし、右側のサーバグループ(S2、S3およびS4)を新たな運用グループとして選択した場合、サーバS2、S3およびS4の中での最新データ番号は2となる。
これら3台のサーバを使用してネットワークを再構築して、これら3台のサーバのうちで最新データであるデータ番号が2のデータを持つサーバS3をマスターサーバに昇格させて運用を継続すると、本来の最新データであるデータ番号3(障害発生前のマスターサーバが記憶していた最新データ番号)のデータが抜け落ち、あるクライアントがすでに処理成功と判断済みのデータ番号3のデータが再構築後のシステムに反映されないため、クライアント間でのデータの整合性に矛盾が生じて正常な処理を継続することができない。
すなわち、ネットワーク障害後に運用継続グループとして使用することに決定したサーバ群の中で、最も新しいデータを持っているサーバを新たなマスターサーバとして選んだとしても、そのマスターサーバが障害発生前のシステム全体の最新データを持っていなければ正常な処理を続行できないのである。
このような事態を防ぐためには、システムの運用を一旦停止させ、システム管理者がシステム全体のデータの更新状況等を確認するといったような作業が必要となるが、それではシステムが一旦停止してから運用再開するまでに時間がかかってしまう。
そこで、ネットワーク障害が発生したとしても、運用停止時間を可能な限り短く、また、残存サーバで最新データを用いた運用を継続する方法が望まれている。
また、特許文献2には、スプリットブレイン状況発生時の継続使用するサーバ群の決定方法について、障害前のサーバ台数の過半数が繋がっていること、および、サーバごとの履歴情報によりサーバグループを選択することが記載されている。ここで、サーバごとの履歴情報とは、サーバグループに合流した日時の情報、そのグループは使用サーバのグループか否かの情報およびサーバがマスターかスレーブかの情報を含む。
特許文献3には、マスターサーバとスレーブサーバとのデータベースを等価にするシステムが記載されている。
特開2010−277467号公報 特開2010−186472号公報 特開2008−276553号公報
特許文献1に記載のデータ管理システムでは、上述したように、新しいマスターサーバが障害発生前のシステム全体での最新データを持っていることを保障できないという問題点がある。
特許文献2では、スレーブサーバにマスターサーバのデータがコピーされている前提で記述されており、スレーブサーバのデータが最新でない場合について考慮されていない。
また、特許文献3記載のシステムでは、マスターサーバのデータ更新をスレーブサーバへ反映する処理が非同期に行われており、スレーブサーバへの更新データの反映前にネットワーク障害が発生した場合にはデータ不整合が発生するという問題点がある。
本発明の目的は、上述した問題点を解決するデータ整合システム、データ整合方法およびデータ整合プログラムを提供することにある。
本発明のデータ整合システムは、ネットワークに接続された複数のサーバを含むシステムにおいて、前記複数のサーバのそれぞれは、データを格納するデータ格納手段と、前記ネットワークに障害が発生し該ネットワークが少なくとも2つのサーバグループに分断された場合に、自サーバが前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属しているときには、自サーバが属している前記サーバグループ内の全サーバ内の前記データ格納手段に格納されたデータのうちで最も新しいデータを自サーバのデータとして保持する復旧手段とを備え、前記ネットワーク障害発生後は、前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループによりシステムの運用を継続する。
本発明のデータ整合方法は、ネットワークに接続された複数のサーバを含むシステムにおいて、
前記複数のサーバのそれぞれが、前記ネットワークに障害が発生し該ネットワークが少なくとも2つのサーバグループに分断された場合に、自サーバが前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属しているときには、自サーバが属している前記サーバグループ内の全サーバ内のデータのうちで最も新しいデータを自サーバのデータとして保持する復旧ステップを含み、前記ネットワーク障害発生後は、前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループによりシステムの運用を継続する。
本発明のデータ整合プログラムは、ネットワークに接続された複数のサーバを含むシステムにおいて、前記複数のサーバのそれぞれに、前記ネットワークに障害が発生し該ネットワークが少なくとも2つのサーバグループに分断された場合に、自サーバが前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属しているときには、自サーバが属している前記サーバグループ内の全サーバ内のデータのうちで最も新しいデータを自サーバのデータとして保持する復旧処理を実行させ、前記ネットワーク障害発生後は、前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループによりシステムの運用を継続させる。
以上、本発明には、マスターサーバおよびスレーブサーバから構成されるシステムにおけるサーバ間のデータの整合性を保障できるという効果がある。
本発明の第1の実施形態のブロック図である。 本発明の第1の実施形態におけるクライアントを示すブロック図である。 本発明の第1の実施形態におけるマスターサーバおよびスレーブサーバを示すブロック図である。 本発明の第1の実施形態における更新処理の正常時のフローを示す図である。 本発明の第1の実施形態における更新処理の異常時のパターン1のフローを示す図である。 本発明の第1の実施形態における更新処理の異常時のパターン2のフローを示す図である。 本発明の第1の実施形態における障害時の動作説明をするためのブロック図である。 本発明の第2の実施形態のブロック図である。 本発明の第2の実施形態におけるマスターサーバおよびスレーブサーバを示すブロック図である。 本発明の第2の実施形態における更新処理の正常時のフローを示す図である。 特許文献1に記載の発明を説明するためのブロック図である。
次に、本発明の実施の形態について図面を参照して詳細に説明する。
図1は本発明の第1の実施形態を示すブロック図である。
図1において、本実施形態は、1つのマスターサーバ201と、複数のスレーブサーバ202と、複数のクライアント100とから構成され、これらの構成要素によりデータベースシステムが構成されている。
マスターサーバ201とスレーブサーバ202とは、ネットワークで繋がっている。また、クライアント100は、マスターサーバ201とスレーブサーバ202とが繋がっているネットワークとは別のネットワークで、マスターサーバ201およびスレーブサーバ202に繋がっている。
クライアント100は、マスターサーバ201またはスレーブサーバ202にアクセス要求を行う。
クライアント100は、図2に示すように、サーバ201または202に要求する処理の種類(更新または参照)および要求処理の宛先サーバ情報を格納する要求処理情報格納部101と、マスターサーバ201からエラー応答を受けたときに別サーバにリトライするためのタイマーを格納する再送時間情報格納部102を持つ。
マスターサーバ201は、クライアント100からのデータの更新または参照要求を受け、更新要求を受けた場合には更新処理したデータを保持する。
スレーブサーバ202は、クライアント100から参照要求のみ受け付け、マスターサーバ201の保持するデータのコピーを保持する。
クライアント100は、アクセスするサーバ(マスターサーバ201またはスレーブサーバ202)を決定して、アクセスする。アクセスするサーバを決定する方法は、例えば、あらかじめ決めた順番に使用する、あるいは、ランダムに使用する等がある。
マスターサーバ201およびすべてのスレーブサーバ202は、図3に示すように、クライアント100からの要求を処理する要求処理部210と、最新データを持つサーバ台数を計算する台数演算部220と、ネットワーク障害を検知する障害検知部230と、ネットワーク障害発生時に運用継続グループを探し、新しいマスターサーバ201を選択し、運用継続グループの他のサーバに最新データをコピーする障害復旧部240と、最新データを持つサーバ台数情報、自サーバと繋がっているサーバ台数情報および自サーバと繋がっているサーバの過半数台数情報を格納する台数情報格納部250と、データコピー送信先のスレーブサーバ情報を格納するスレーブ情報格納部260と、マスターサーバ201からスレーブサーバ202への再送間隔および再送回数を格納する再送制御情報格納部270と、クライアント100が更新または参照するデータおよびデータ番号を格納するデータ格納部280とを持つ。
図1に示す第1の実施形態は、マスターサーバ201が1台とスレーブサーバ202が3台の合計4台で構成されている。
すべてのサーバ(マスターサーバ201およびすべてのスレーブサーバ202)は、運用開始時に自分と繋がっているサーバの台数(自分も含めた台数)を自サーバと繋がっているサーバ台数情報として台数情報格納部250に格納する。さらに、すべてのサーバは、「(自分と繋がっているサーバの台数)/2+1」(小数点以下は切り捨て)で過半数(以下「border」とする)を計算し、自サーバと繋がっているサーバの過半数台数情報として台数情報格納部250に格納する。
マスターサーバ201はクライアント100からのデータの更新要求を要求処理部210で処理し、各スレーブサーバ202に更新したデータの差分情報をコピーする。ここで、更新したデータの差分情報とは、該当する更新要求で処理したデータの更新後の値および更新世代を示すデータ番号である。
マスターサーバ201は、データの差分情報を元に、各スレーブサーバ202へのコピーを実行し、その結果、最新データを持つ(すなわち、上記コピーが成功した)サーバ台数が、自サーバと繋がっているサーバの過半数以上であればコピー成功応答をクライアント100に返却する。逆に、過半数より少なければ、マスターサーバ201はコピー失敗応答をクライアント100に返却する。
次に、図4を参照してマスターサーバMの動作を詳細に説明する。
マスターサーバMは、クライアントClからデータの更新処理要求を受けて、初めに、最新データを持っているサーバ台数(以下、「S_count」)を初期化(0に設定)する。次に、マスターサーバMは、マスターサーバMのデータ格納部280内の、クライアントからの上記更新要求のあったデータを更新し、S_countに1加算する。
次に、マスターサーバMは、すべてのスレーブサーバS1〜S3に更新したデータの差分情報を送信する。
マスターサーバMからデータ差分情報を受け取った各スレーブサーバS1〜S3は、データ差分情報をデータ格納部280のデータに反映し、コピー完了後、コピー成功応答(「コピー成功通知」とも言う。)をマスターサーバMに返却する。
マスターサーバMは、複数のスレーブサーバS1〜S3のそれぞれからコピー成功応答を受け取る度にS_countに1を加算していく。マスターサーバMは、スレーブサーバS1〜S3からコピー成功応答を受け取ることで、マスターサーバMとスレーブサーバS1〜S3との有するデータを同期するとともに、スレーブサーバS1〜S3に障害が発生していないことを監視している。
マスターサーバMは、すべてのスレーブサーバS1〜S3から応答を受け取った後、S_countの値とborderの値との大小関係を調べ、S_countの値がborderの値以上(すなわち、データベースシステム構成台数の過半数以上のサーバにデータがコピーされた)ならば、クライアントClにコピー成功応答を返却する。
図4では、すべてのスレーブサーバS1〜S3からコピー成功応答を受け取っているため、S_count=4、border=3となる。この結果、S_count≧borderとなり、データベースシステム構成台数の過半数以上のサーバが最新データを持つことを確認できるため、マスターサーバMはクライアントClにコピー成功応答を返す。
次に、コピー通信中のデータ消失、ディスク破壊等で、スレーブサーバへのデータコピーが失敗した場合について、図5を参照して説明する。
マスターサーバMは、クライアントClからデータの更新処理要求を受けて、初めに、最新データを持っているサーバ台数(以下、「S_count」)を初期化(0に設定)する。次に、マスターサーバMは、マスターサーバMのデータ格納部280内の、クライアントからの上記更新要求のあったデータを更新し、S_countに1加算する。
次に、マスターサーバMは、すべてのスレーブサーバS1〜S3に更新したデータの差分情報を送信する。
マスターサーバMは、スレーブサーバS1およびS2からはコピー成功応答を受け取っている。しかし、スレーブサーバS3からのコピー成功応答が一定時間(再送制御情報格納部270に格納した再送間隔)を超えても返ってこないため、マスターサーバMは、スレーブサーバS3へデータ差分情報の再送を行う。
図5では、その1回目の再送の応答として、スレーブサーバS3からマスターサーバMにコピー失敗応答(「コピー失敗通知」とも言う。)が返ってきている。マスターサーバMは、コピー失敗応答を受け取ると、スレーブサーバS3にデータ差分情報を再度送信する。
図5では、その2回目の再送に対する応答もコピー失敗応答が返ってきている。再送制御情報格納部270に再送回数を2回と設定していた場合、マスターサーバMは、3回目の再送処理を行わず、スレーブサーバS3をデータベースシステムから論理的に切り離す。マスターサーバMは、データ破壊が起きている可能性があるスレーブサーバS3を切り離した後、S_countの値とborderの値との大小関係を比較する。
本例では、S_count=3、border=3となる。この場合、S_count≧borderの条件を満たすため、マスターサーバMは、クライアントClにコピー成功応答を返す。スレーブサーバS3を切り離した事でシステムの構成台数が1台減ったため、マスターサーバMは、borderの値を再計算し、border=2に再設定する。
最後に、図6を参照して、マスターサーバMがクライアントClにコピー失敗応答を返すときの動きを説明する。今回の例では、再送回数は2回と設定している。
マスターサーバMは、クライアントClからデータの更新処理要求を受けて、初めに、最新データを持っているサーバ台数(以下、「S_count」)を初期化(0に設定)する。次に、マスターサーバMは、マスターサーバMのデータ格納部280内の、クライアントからの上記更新要求のあったデータを更新し、S_countに1加算する。
次に、マスターサーバMは、すべてのスレーブサーバS1〜S3に更新したデータの差分情報を送信する。
その結果、マスターサーバMは、スレーブサーバS1からのコピー成功応答を受け取っているが、スレーブサーバS2およびS3のいずれからもコピー成功応答は受け取っていない。
具体的に、まず、スレーブサーバS2の動作について説明する。マスターサーバMは、スレーブサーバS2から何も応答が返らず、あらかじめ設定しておいた再送間隔を過ぎると、データ差分情報をスレーブサーバS2に再送する。それでも応答が返ってこないため、マスターサーバMは、もう一度再送しているが、スレーブサーバS2からは何も応答が返ってこない。再送回数は2回と設定されているため、マスターサーバMは、3回目の再送を行わずに、スレーブサーバS2をデータベースシステムから論理的に切り離す。
次に、スレーブサーバS3の動作について具体的に説明する。スレーブサーバS3からはコピー失敗応答がマスターサーバMに返ってきている。マスターサーバMは、コピー失敗応答を受け取ると、データ差分情報を再送する。
図6では、この再送に対してもコピー失敗応答がマスターサーバMに返ってきている。再送回数は2回と設定されているため、マスターサーバMは、2回目の再送に対する応答にもコピー成功応答が返ってこない場合には、3回目の再送を行わずにスレーブサーバS3をデータベースシステムから論理的に切り離す。
この結果、図6では、S_count=2、border=3となる。この結果、S_count<borderとなり、S_count≧borderの条件を満たさないため、すなわち、データベースシステム構成台数の過半数以上のサーバに最新データがコピーされていないため、最終的に、マスターサーバMはクライアントClにコピー失敗応答を返す。スレーブサーバS2およびS3を切り離した事で、システムの構成台数が2台減ったため、マスターサーバMは、borderの値を再計算し、border=2に再設定する。
図6の例では、再送回数を2回と設定したが、再送回数は任意である。また、再送を行わないことも可能である。
マスターサーバMは、クライアントClに返す応答を決めた後に、borderの値の再計算をする。borderの値の再計算により、図6のようにスレーブサーバの切り離しを行った後のデータベースシステム構成台数に基づいた過半数台数がborderに設定される。この処理により、クライアントClから次の更新要求が行われた際にも、図4、5および6を参照して説明した処理を有効に行うことが可能になる。
以上の動作により、クライアント100がコピー成功応答を受け取っているのであれば、過半数以上のサーバに最新かつ正しいデータがコピーされていることが保証される。したがって、ネットワーク障害によりサーバ群が分断された場合や、マスターサーバ201に障害が発生した場合でも、障害後に半数と繋がっているサーバが存在するならば、その半数と繋がっているサーバを含むサーバ群の中に、少なくとも1台は、最新かつ正しいデータを持つサーバが含まれることが言える。
以上のように、過半数のサーバに最新のデータが保有されていることが保障されたデータベースシステムにおいて、ネットワーク障害が発生した場合について、以下に説明する。
例えば、図7に示すように、サーバが4台の構成で運用しているデータベースシステムでネットワーク障害が発生したとする。
図7は、クライアントからマスターサーバへの更新要求の処理中にネットワーク障害が発生し、そのネットワーク障害により、マスターサーバMおよびスレーブサーバS1からなるグループと、スレーブサーバS2およびS3からなるグループとに分断された様子を示している。
ここで、データ番号は更新世代を示し、その値が大きいほど新しいデータであることを示している。
図7では、マスターサーバMと、スレーブサーバS2およびS3とが最新のデータ番号3のデータを保有し、スレーブサーバS1は最新データのコピー前に発生したネットワーク障害により、最新のデータ番号3のデータより古いデータ番号2のデータまでしか保有していないとする。この状態では、3台のサーバが最新のデータを保有しており、データベースシステムを構成する全サーバ台数(4台)のうちの過半数の台数のサーバが最新のデータを保有している。
ネットワーク障害は、各サーバ(マスターサーバおよびスレーブサーバ)が検出する。各サーバは
ネットワーク障害検出後、自分とつながっているサーバ台数を確認し、自分が障害前の全サーバ台数の半数以上の台数のサーバとつながっていることが分かった場合、自分が運用継続グループに属することになることを知る。
運用継続グループに属することを知った各サーバは、そのグループ内の他の全てのサーバに当該他の全てサーバが持つデータ番号を問い合わせ、自分の持つデータ番号と当該他の全てサーバが持つデータ番号とを比較し、自分の持つデータ番号が他の全てのサーバのそれよりも新しい場合には、何もせず、一方、自分の持つデータ番号より新しいデータ番号を持つ他のサーバのうちで最も新しいデータ番号を持つ他のサーバからそのデータ番号のデータを取得する。この結果、運用継続グループに属する全てのサーバが最新のデータ番号のデータを持つことになる。
その後、運用継続グループの中でマスターサーバとなるサーバを選択することになるが、どのサーバを選択するかは、様々な方法が考えられ、例えば、最初に障害を検出したサーバを選択したりする方法や、予め全てのサーバに優先順位を設定しておき、運用継続グループ内のサーバの中で一番優先順位の高いサーバを選択する方法などが考えられる。
また、図7のようにちょうど半数の2台ずつの2グループに分かれている場合に、どちらのグループを運用継続グループとして選ぶかは様々な方法が考えられるが、ここでは、障害前のマスターサーバMがいる方を優先する方法で運用継続グループを選択している。
すると、運用継続グループとして、マスターサーバMおよびスレーブサーバS1からなるグループが選ばれることになる。マスターサーバMとスレーブサーバS1は、保持データのデータ番号を比較し、マスターサーバMが保有する最新のデータのデータ番号は3であり、スレーブサーバS1のそれは2であるため、データ番号3のデータが本運用継続グループの最新データとして選択される。
その後、最新データであるデータ番号3を保有するマスターサーバMから、スレーブサーバS1はデータ番号3のデータを取得してコピーし、サーバMおよびS1によりデータベースシステムの運用が継続される。
データ番号は、わかりやすく説明するため、ここでは単に数字を使用したが、データの更新世代を一意に示すことができれば、データ更新時間やトランザクション番号等でも問題ない。
上記の例において、もし、最新データを持っているサーバが、例えば、サーバMではなく、サーバS1であったとすると、最新データをマスターサーバMにコピーした後、サーバS1が新マスターサーバに昇格し、運用を継続するようにしても良い。すなわち、新しいマスターサーバの選択方法は、障害前のマスターサーバを優先して使用する方法や、最新データを持っているスレーブサーバの中から予め定めた規則に従って選択する方法など、特に限定はない。
以上、説明したように、本実施形態には、ネットワーク障害発生時において、マスターサーバおよび複数のスレーブサーバから構成されるシステムにおけるサーバ間のデータの整合性を保障できるという効果がある。
図8は本発明の第2の実施形態を示すブロック図である。
本実施形態は、1台のマスターサーバMと2台のスレーブサーバS1およびS2との合計3台のサーバで構成されている。
本実施形態のサーバ(マスターサーバMおよびスレーブサーバS1およびS2)について、図9を参照して説明する。
本実施形態は、図9に示すように、第1の実施形態のサーバの構成に、送信制御情報格納部290を追加したものであり、クライアント100の動作は第1の実施形態と同様であり説明は省略する。送信制御情報格納部290には、送信したデータのデータ番号、スレーブサーバごとのコピー完了通知受け取り済みフラグおよび同じデータを一度に送る送信回数を格納する。
本実施形態は、データの冗長性をより高めるために、マスターサーバはスレーブサーバからの応答を待たずに一度に同じコピーを常に送る。図8では、マスターサーバ1台、スレーブサーバ2台の3台構成だが、サーバの台数は任意の数だけ存在してよい。また、アクセスするクライアントも任意の数だけ存在して良い。
図10を参照して図8のマスターサーバMの動作を詳細に説明する。
マスターサーバMは、クライアントClから更新処理要求を受けて、最新データを持っているサーバ台数(以下「S_count」)およびスレーブサーバごとのコピー完了通知受け取り済みフラグ(以下「S1フラグ」、「S2フラグ」)を初期化する。マスターサーバMは、マスターサーバMのデータ格納部280のデータを更新し、S_countに1を加算する。
次に、マスターサーバMは、すべてのスレーブサーバS1およびS2に、送信制御情報格納部290内に格納された、同じデータを一度に送る送信回数(ここでは2回)ずつ、更新したデータの更新差分情報であるデータ差分情報を送信する。
マスターサーバMからデータ差分情報を受け取ったスレーブサーバS1およびS2は、データ差分情報をデータ格納部280にコピーして反映し、コピー完了後、コピー成功応答をマスターサーバMに返却する。
より具体的に説明すると、スレーブサーバS1は、マスターサーバMから最初に送付された1回目のデータ差分情報によりコピーを実施し、マスターサーバMに1回目のコピー成功応答を返す。なお、サーバS1が、2回目のデータ差分情報(1回目と同じデータ差分情報)を受け取った際は、すでにコピー完了済みでコピーは不要のため、コピーを実施しないでマスターサーバMに2回目のコピー完了応答を返す。
マスターサーバMは、送信したデータ差分情報に対応するスレーブサーバS1からの1回目のコピー成功応答を受け取ったとき、既にコピー成功応答を受け取っているか否かを示すS1フラグを確認する。
このときは、まだ、S1フラグが立っていないため、マスターサーバMは、S1フラグを立てるとともに、S_countの値に1を加算する。
マスターサーバMは、送信した2回目のデータ差分情報(1回目と同じデータ差分情報)に対応するスレーブサーバS1からの2回目のコピー成功応答を受け取ったとき、S1フラグを再度確認する。このときには、既にS1フラグがたっているため、マスターサーバMはS_countの値の更新を行わない。
同様のやりとりがマスターサーバMとスレーブサーバS2との間でも行われる。
その後、マスターサーバMからクライアントClにコピー成功応答が返される。
第2の実施形態により、マスターサーバは、スレーブサーバに一度に複数回データを送ることが可能となり、冗長性が高められる。例えば、マスターサーバが常に2回スレーブサーバに同じデータを送る事で、仮に一つが何らかの障害でスレーブサーバに届かなかった場合でも、もう片方がスレーブサーバに届き、障害の影響を受けずに運用が継続可能である。
以上、説明したように、本実施形態には、第1の実施形態のマスターサーバおよびスレーブサーバから構成されるシステムにおけるサーバ間のデータの整合性を保障できるという効果に加え、第1の実施形態よりも耐障害性を向上できるという効果もある。
また、本発明は1組のマスタースレーブ関係に閉じた内容であり、データベースシステム上にマスターとスレーブのグループが複数存在しても、それぞれのマスタースレーブに適用可能である。
なお、第1および第2の実施形態において、クライアント、マスターサーバおよびスレーブサーバは専用のハードウェアで実現しても良いし、一般のコンピュータで実現してもよい。
さらに、クライアントはマスターサーバ201およびスレーブサーバ202と同じハードウェア上で実現しても良い。
100 クライアント
101 要求処理情報格納部
102 再送時間情報格納部
200 サーバ
201 マスターサーバ
202 スレーブサーバ
210 要求処理部
220 台数演算部
230 障害検知部
240 障害復旧部
250 台数情報格納部
260 スレーブ情報格納部
270 再送制御情報格納部
280 データ格納部
290 送信制御情報格納部

Claims (10)

  1. ネットワークに接続された複数のサーバを含むシステムにおいて、
    前記複数のサーバのそれぞれは、
    データを格納するデータ格納手段と、
    前記ネットワークに障害が発生し該ネットワークが少なくとも2つのサーバグループに分断された場合に、自サーバが前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属しているときには、自サーバが属している前記サーバグループ内の全サーバ内の前記データ格納手段に格納されたデータのうちで最も新しいデータを自サーバのデータとして保持する復旧手段と
    を備え、
    前記ネットワーク障害発生後は、前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループによりシステムの運用を継続することを特徴とするデータ整合システム。
  2. 少なくとも一つのマスターサーバと複数のスレーブサーバとがネットワークを介して接続されたシステムにおいて、
    前記マスターサーバは、
    第1のデータ格納手段と、
    クライアントからのデータ更新要求に応答して前記第1のデータ格納手段に格納されたデータの更新を行うとともに更新されたデータを送信する送信手段と、
    前記複数のサーバのうちの過半数の台数のサーバからコピー成功応答が返って来たことを確認したとき、前記クライアントにコピー成功応答を返す応答手段と
    を備え、
    前記スレーブサーバのそれぞれは、
    第2のデータ格納手段と、
    前記マスターサーバから送信される前記更新されたデータにより前記第2のデータ格納手段のデータを更新し、更新が成功した場合には前記コピー成功応答を前記マスターサーバに返す更新手段と、
    前記ネットワークに障害が発生し該ネットワークが少なくとも2つのサーバグループに分断された場合に、自サーバが前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属しているときには、自サーバが属している前記サーバグループ内の全サーバ内の前記データ格納手段に格納されたデータのうちで最も新しいデータを自サーバのデータとして保持する復旧手段と
    を備えることを特徴とするデータ整合システム。
  3. 前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属する前記サーバのうちの少なくとも1つを予め定めた規則に従って選択し、選択されたサーバを新たなマスターサーバとすることを特徴とする請求項2に記載のデータ整合システム。
  4. 前記マスターサーバの前記送信手段は、同じ前記更新されたデータを複数回連続して前記サーバに送信することを特徴とする請求項2または3に記載のデータ整合システム。
  5. ネットワークに接続された複数のサーバを含むシステムにおいて、
    前記複数のサーバのそれぞれが、前記ネットワークに障害が発生し該ネットワークが少なくとも2つのサーバグループに分断された場合に、自サーバが前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属しているときには、自サーバが属している前記サーバグループ内の全サーバ内のデータのうちで最も新しいデータを自サーバのデータとして保持する復旧ステップを含み、
    前記ネットワーク障害発生後は、前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループによりシステムの運用を継続することを特徴とするデータ整合方法。
  6. 少なくとも一つのマスターサーバと複数のスレーブサーバとがネットワークを介して接続されたシステムにおいて、
    前記マスターサーバが、クライアントからのデータ更新要求に応答して第1のデータ格納手段に格納されたデータの更新を行うとともに更新されたデータを送信する送信ステップと、
    前記マスターサーバが、前記複数のサーバのうちの過半数の台数のサーバからコピー成功応答が返って来たことを確認したとき、前記クライアントにコピー成功応答を返す応答ステップと、
    前記スレーブサーバのそれぞれが、前記マスターサーバから送信される前記更新されたデータにより第2のデータ格納手段のデータを更新し、更新が成功した場合には前記コピー成功応答を前記マスターサーバに返す更新ステップと、
    前記スレーブサーバのそれぞれが、前記ネットワークに障害が発生し該ネットワークが少なくとも2つのサーバグループに分断された場合に、自サーバが前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属しているときには、自サーバが属している前記サーバグループ内の全サーバ内の前記データ格納手段に格納されたデータのうちで最も新しいデータを自サーバのデータとして保持する復旧ステップと
    を含むことを特徴とするデータ整合方法。
  7. 前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属する前記サーバのうちの少なくとも1つを予め定めた規則に従って選択し、選択されたサーバを新たなマスターサーバとすることを特徴とする請求項6に記載のデータ整合方法。
  8. ネットワークに接続された複数のサーバを含むシステムにおいて、
    前記複数のサーバのそれぞれに、
    前記ネットワークに障害が発生し該ネットワークが少なくとも2つのサーバグループに分断された場合に、自サーバが前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属しているときには、自サーバが属している前記サーバグループ内の全サーバ内のデータのうちで最も新しいデータを自サーバのデータとして保持する復旧処理を実行させ、
    前記ネットワーク障害発生後は、前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループによりシステムの運用を継続させることを特徴とするデータ整合プログラム。
  9. 少なくとも一つのマスターサーバと複数のスレーブサーバとがネットワークを介して接続されたシステムにおいて、
    前記マスターサーバに、
    クライアントからのデータ更新要求に応答して第1のデータ格納手段に格納されたデータの更新を行うとともに更新されたデータを送信する送信処理と、
    前記複数のサーバのうちの過半数の台数のサーバからコピー成功応答が返って来たことを確認したとき、前記クライアントにコピー成功応答を返す応答処理と
    を実行させ、
    前記スレーブサーバのそれぞれに、
    前記マスターサーバから送信される前記更新されたデータにより前記第2のデータ格納手段のデータを更新し、更新が成功した場合には前記コピー成功応答を前記マスターサーバに返す更新処理と、
    前記ネットワークに障害が発生し該ネットワークが少なくとも2つのサーバグループに分断された場合に、自サーバが前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属しているときには、自サーバが属している前記サーバグループ内の全サーバ内の前記データ格納手段に格納されたデータのうちで最も新しいデータを自サーバのデータとして保持する復旧処理と
    を実行させることを特徴とするデータ整合プログラム。
  10. 前記ネットワーク障害発生前の全サーバ台数の半数以上の台数のサーバからなる前記サーバグループに属する前記サーバのうちの少なくとも1つを予め定めた規則に従って選択し、選択されたサーバを新たなマスターサーバとすることを特徴とする請求項9に記載のデータ整合プログラム。
JP2012073667A 2012-03-28 2012-03-28 データ整合システム、データ整合方法およびデータ整合プログラム Expired - Fee Related JP5900094B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012073667A JP5900094B2 (ja) 2012-03-28 2012-03-28 データ整合システム、データ整合方法およびデータ整合プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012073667A JP5900094B2 (ja) 2012-03-28 2012-03-28 データ整合システム、データ整合方法およびデータ整合プログラム

Publications (2)

Publication Number Publication Date
JP2013206072A true JP2013206072A (ja) 2013-10-07
JP5900094B2 JP5900094B2 (ja) 2016-04-06

Family

ID=49525099

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012073667A Expired - Fee Related JP5900094B2 (ja) 2012-03-28 2012-03-28 データ整合システム、データ整合方法およびデータ整合プログラム

Country Status (1)

Country Link
JP (1) JP5900094B2 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016151795A (ja) * 2015-02-16 2016-08-22 日本電信電話株式会社 データベースシステム及びそのマスター/スレーブ決定方法
JP2016177714A (ja) * 2015-03-23 2016-10-06 日本電気株式会社 ストレージ制御システムおよびストレージ制御方法
KR101750601B1 (ko) 2014-08-28 2017-06-27 네이버 주식회사 장애 내구성을 지닌 클러스터의 상태 감시 및 클러스터의 형상 변경을 위한 클러스터 관리 방법 및 데이터 저장 시스템
US9921927B2 (en) 2014-06-20 2018-03-20 Fujitsu Limited Redundant system, redundancy method, and computer-readable recording medium
CN111858744A (zh) * 2019-04-29 2020-10-30 北京嘀嘀无限科技发展有限公司 数据库数据同步方法、服务器及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002055964A (ja) * 2000-05-31 2002-02-20 Internatl Business Mach Corp <Ibm> 分散コンピューティング環境の処理グループを管理する方法、システム、およびプログラム製品
JP2008299481A (ja) * 2007-05-30 2008-12-11 Hitachi Ltd ストレージシステム及び複数拠点間でのデータコピー方法
JP2010277467A (ja) * 2009-05-29 2010-12-09 Nippon Telegr & Teleph Corp <Ntt> 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム
JP2011002970A (ja) * 2009-06-17 2011-01-06 Nippon Telegr & Teleph Corp <Ntt> 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002055964A (ja) * 2000-05-31 2002-02-20 Internatl Business Mach Corp <Ibm> 分散コンピューティング環境の処理グループを管理する方法、システム、およびプログラム製品
JP2008299481A (ja) * 2007-05-30 2008-12-11 Hitachi Ltd ストレージシステム及び複数拠点間でのデータコピー方法
JP2010277467A (ja) * 2009-05-29 2010-12-09 Nippon Telegr & Teleph Corp <Ntt> 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム
JP2011002970A (ja) * 2009-06-17 2011-01-06 Nippon Telegr & Teleph Corp <Ntt> 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6015047907; 中村 健二 外3名: '"ドメインリーダに基づく複製管理方式の評価と改良"' 情報処理学会論文誌 第39巻,第3号, 19980315, pp.716-724, 社団法人情報処理学会 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9921927B2 (en) 2014-06-20 2018-03-20 Fujitsu Limited Redundant system, redundancy method, and computer-readable recording medium
KR101750601B1 (ko) 2014-08-28 2017-06-27 네이버 주식회사 장애 내구성을 지닌 클러스터의 상태 감시 및 클러스터의 형상 변경을 위한 클러스터 관리 방법 및 데이터 저장 시스템
JP2016151795A (ja) * 2015-02-16 2016-08-22 日本電信電話株式会社 データベースシステム及びそのマスター/スレーブ決定方法
JP2016177714A (ja) * 2015-03-23 2016-10-06 日本電気株式会社 ストレージ制御システムおよびストレージ制御方法
CN111858744A (zh) * 2019-04-29 2020-10-30 北京嘀嘀无限科技发展有限公司 数据库数据同步方法、服务器及系统

Also Published As

Publication number Publication date
JP5900094B2 (ja) 2016-04-06

Similar Documents

Publication Publication Date Title
AU2019236685B2 (en) Distributed file system using consensus nodes
US9984140B1 (en) Lease based leader election system
EP2434729A2 (en) Method for providing access to data items from a distributed storage system
JP4896438B2 (ja) 分散障害許容型コンピューティングシステムにおける効率のよいレプリカセットの変更
CA2659395C (en) Match server for a financial exchange having fault tolerant operation
JP6084624B2 (ja) 高可用性クラスタにおけるスプリット・ブレイン耐性フェイルオーバ
CA2657882C (en) Fault tolerance and failover using active copy-cat
WO2016070375A1 (zh) 一种分布式存储复制系统和方法
US20120271795A1 (en) Scalable row-store with consensus-based replication
JP5548829B2 (ja) 計算機システム、データ管理方法及びデータ管理プログラム
JP5900094B2 (ja) データ整合システム、データ整合方法およびデータ整合プログラム
JP2007518195A (ja) リモートデータミラーリングを用いたクラスタデータベース
CN105493474A (zh) 用于支持用于同步分布式数据网格中的数据的分区级别日志的系统及方法
JP5292351B2 (ja) メッセージキュー管理システム及びロックサーバ及びメッセージキュー管理方法及びメッセージキュー管理プログラム
EP3039568B1 (en) Distributed disaster recovery file sync server system
US9396076B2 (en) Centralized version control system having high availability
JP6511739B2 (ja) 冗長システムおよび冗長化方法
WO2015196692A1 (zh) 一种云计算系统以及云计算系统的处理方法和装置
US11860828B2 (en) Methods, devices and systems for writer pre-selection in distributed data systems
EP2980707B1 (en) Method for creating a database clone of a distributed database, system for creating a database clone of a distributed database, program and computer program product
JP5956940B2 (ja) 冗長化システムおよび現用機決定方法
JP5480046B2 (ja) 分散トランザクション処理システム、装置、方法およびプログラム
JP2022503583A (ja) 分散コンピューティング環境で分散調整エンジンを非破壊的にアップグレードする方法、装置およびシステム
EP4180967A1 (en) Method and system for providing backup for a database
CN115633046A (zh) Kafka高可用方案优化方法、装置、设备及存储介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150216

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20151110

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151201

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160119

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: 20160209

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160222

R150 Certificate of patent or registration of utility model

Ref document number: 5900094

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees