JP7152828B1 - ビザンチン故障を検知するデータ管理システム及び方法 - Google Patents

ビザンチン故障を検知するデータ管理システム及び方法 Download PDF

Info

Publication number
JP7152828B1
JP7152828B1 JP2022531632A JP2022531632A JP7152828B1 JP 7152828 B1 JP7152828 B1 JP 7152828B1 JP 2022531632 A JP2022531632 A JP 2022531632A JP 2022531632 A JP2022531632 A JP 2022531632A JP 7152828 B1 JP7152828 B1 JP 7152828B1
Authority
JP
Japan
Prior art keywords
server
client
transaction
lock
response
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.)
Active
Application number
JP2022531632A
Other languages
English (en)
Other versions
JPWO2022250047A1 (ja
Inventor
浩之 山田
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.)
Scalar Inc
Original Assignee
Scalar Inc
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 Scalar Inc filed Critical Scalar Inc
Priority claimed from PCT/JP2022/021235 external-priority patent/WO2022250047A1/ja
Priority to JP2022151926A priority Critical patent/JP2022180556A/ja
Application granted granted Critical
Publication of JP7152828B1 publication Critical patent/JP7152828B1/ja
Publication of JPWO2022250047A1 publication Critical patent/JPWO2022250047A1/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance

Abstract

第１及び第２の計算機システムから構成されるデータ管理システムが、クライアントと、同一のトランザクション要求について同じ決定的関数を実行する第１及び第２のサーバとを備える。第１のサーバが、第１の計算機システムに備えられ、第２のサーバが、第２の計算機システムに備えられる。トランザクション要求毎に、順序付けフェーズにおいて、第２のサーバが、クライアントからのトランザクション要求をstrict serializableな半順序に順序付けし、コミットフェーズにおいて、第１のサーバが、クライアントからのトランザクション要求に従うトランザクションを当該半順序で実行して第１の応答をクライアントに返し、検証フェーズにおいて、第２のサーバが、クライアントからのトランザクション要求に従うトランザクションを当該半順序で実行して第２の応答をクライアントに返し、クライアントが、第２の応答と第１の応答との比較の結果を基に、ビザンチン故障を検知する。

Description

本発明は、概して、データ管理に関し、特に、ビザンチン故障の検知に関する。
下記のデータ管理システムが知られている。
・複数の計算機システムを有する。複数の計算機システムが、それぞれ、オブジェクト群セットを格納する。複数の計算機システムにおけるオブジェクト群セットは同じ状態に保たれる。
・計算機システムにおけるオブジェクト群セットは、対象毎のオブジェクト群である。「オブジェクト群」は、一つ以上のオブジェクトである。「オブジェクト」は、対象の状態を表す。「対象」は、任意の有体物又は無体物である。例えば、「対象」として、口座を採用し、対象の「状態」として、口座における残高を採用することができる。
・計算機システムは、オブジェクトをリード及び／又はライトするトランザクションの要求に応答して、トランザクションを実行する。
・計算機システムは、一つ又は複数のノードでよく、ネットワークを含んでもよい。計算機システムは、当該計算機システムの管理者（例えば、一組織又は一個人）から操作され得るが、当該計算機システムの管理者以外の者（例えば、組織又は個人）からは操作され得ない。例えば、計算機システム１は管理者１から操作され得るが、計算機システム２は管理者１から操作され得ない。計算機システム２は管理者２のみから操作され得る。
データ管理システムにおけるビザンチン故障を検知する方法として、非特許文献１に開示の方法「PeerReview」がある。PeerReviewは、peer-to-peerで動作する。また、PeerReviewでは、計算機システムは、単一ノードである。PeerReviewについて、便宜上、最初にレコードを作成するノードを「プライマリノード」と呼び、プライマリノード以外のノードを「セカンダリノード」と呼ぶ。
PeerReviewは、全順序ハッシュチェーン型実行ログをプライマリノードで作成し、プライマリノードと同じ状態や結果を計算するために一以上のセカンダリノードの各々に当該ログをシーケンシャルに再生させる。
Andreas Haeberlen, Petr Kouznetsov, and Peter Druschel. 2007. PeerReview: Practical Accountability for Distributed Systems. In SOSP. 175-188.(https://people.mpi-sws.org/~druschel/publications/peerreview-sosp07.pdf)
上述したデータ管理システムにおけるビザンチン故障の検知を、strict serializabilityを保証し、且つ、トランザクションを並列に実行可能としつつ実現することが望ましい。しかし、PeerReviewでは、セカンダリノードは、プライマリノードが作成した全順序ハッシュチェーン型実行ログをシーケンシャルに再生する必要があり、そのため、トランザクション実行の全体的な並列性が制限される。
第１及び第２の計算機システムから構成されるデータ管理システムが、対象の状態を表すオブジェクトをリード及び／又はライトするトランザクションの要求であるトランザクション要求を送信するクライアントと、同一のトランザクション要求について同じ決定的関数を実行する第１及び第２のサーバとを備える。
第１の計算機システムが、第１のオブジェクト群セットを管理する。当該第１のオブジェクト群セットは、対象毎の第１のオブジェクト群である。第１のオブジェクト群は、一つ以上の第１のオブジェクトである。第１のオブジェクトは、対象の状態を表す。
第２の計算機システムが、第２のオブジェクト群セットを管理する。当該第２のオブジェクト群セットは、対象毎の第２のオブジェクト群である。第２のオブジェクト群は、一つ以上の第２のオブジェクトである。第２のオブジェクトは、対象の状態を表す。
第１のサーバが、第１の計算機システムに備えられる。第１のサーバによるトランザクションの実行では、第１のオブジェクトが第１のオブジェクト群セットからリードされる、及び／又は、第１のオブジェクトが第１のオブジェクト群セットにライトされる。
第２のサーバが、第２の計算機システムに備えられる。第２のサーバによるトランザクションの実行では、第２のオブジェクトが第２のオブジェクト群セットからリードされる、及び／又は、第２のオブジェクトが第２のオブジェクト群セットにライトされる。
順序付けフェーズ、コミットフェーズ及び検証フェーズがある。トランザクション要求毎に、順序付けフェーズにおいて、クライアントが、当該トランザクション要求を第２のサーバに送信し、第２のサーバが、クライアントからの当該トランザクション要求をstrict serializableな半順序に順序付けし、コミットフェーズにおいて、クライアントが、当該トランザクション要求を第１のサーバに送信し、第１のサーバが、クライアントからの当該トランザクション要求に従うトランザクションを、順序付けフェーズにおいて決定された半順序で実行し、当該トランザクション要求の第１の応答をクライアントに返し、検証フェーズにおいて、第２のサーバが、クライアントからのトランザクション要求に従うトランザクションを順序付けフェーズにおいて決定された半順序で実行し、当該トランザクション要求の第２の応答をクライアントに返し、クライアントが、第２の応答と第１の応答との比較の結果を基に、ビザンチン故障を検知する。
データ管理システムにおけるビザンチン故障の検知を、strict serializabilityを保証し、且つ、トランザクションを並列に実行可能としつつ実現することができる。
実施形態に係るデータベースシステムの構成の一例を示す。 ハードウェア構成の一例を示す。 ロックテーブルの構成の一例を示す。 プルーフの構成の一例を示す。 順序付けフェーズでの処理の流れの一例を示す。 コミットフェーズでの処理の流れの一例を示す。 検証フェーズでの処理の流れの一例を示す。 リカバリ処理の流れの一例を示す。 リカバリ試行処理の流れの一例を示す。 アボート試行処理の流れの一例を示す。 プルーフ取得処理の流れの一例を示す。 順序付け検証の流れの一例を示す。 新規状態導出処理の流れの一例を示す。
以下の説明では、「インターフェース装置」は、一つ以上のインターフェースを含む。一つ以上のインターフェースは、一つ以上の同種の通信インターフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。
また、以下の説明では、「記憶装置」は、一つ以上のメモリを含む。記憶装置に関して少なくとも一つのメモリは、揮発性メモリでよい。記憶装置は、主に、プロセッサによる処理の際に使用される。記憶装置は、メモリの他に、一つ以上の不揮発性の記憶デバイス（例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive））を含んでもよい。
また、以下の説明では、「プロセッサ」は、一つ以上のプロセッサを含む。少なくとも一つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。一つ以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部又は全部を行うハードウェア回路を含んでもよい。
また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサによって実行されることで、定められた処理を、適宜に記憶装置（例えばメモリ）及び／又はインターフェース装置（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。また、プロセッサは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又は計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。また、以下の説明において、二つ以上のプログラムが一つのプログラムとして実現されてもよいし、一つのプログラムが二つ以上のプログラムとして実現されてもよい。
また、以下の説明では、「ｙｙｙ部」の表現にて機能を説明することがあるが、機能は、一つ以上のコンピュータプログラムがプロセッサによって実行されることで実現されてもよいし、一つ以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよいし、それらの組合せによって実現されてもよい。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置及び／又はインターフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通符号を使用し、同種の要素を区別する場合は、参照符号を使用することがある。
また、以下の説明では、「レコード」とは、アプリケーションプログラムのようなプログラムから見た一つの論理的な電子データの塊であり、具体的には、対象の状態を表すオブジェクトの一例である。レコードとしてのデータは、例えば、キーバリューペア又はタプルがある。
また、以下の実施形態において、「ビザンチン故障」は、任意の故障でよく、改ざんのような悪意のある内部攻撃を含んでよい。
図１は、実施形態に係るデータベースシステムの構成の一例を示す。
二つの計算機システム１５０を有するデータベースシステム１３０がある。データベースシステム１３０は、データ管理システムの一例である。
二つの計算機システム１５０がそれぞれデータベース１５４を有する。二つの計算機システム１５０のデータベース１５４が同じ状態に保たれる。
二つの計算機システム１５０は、プライマリシステム１５０Ｐとセカンダリシステム１５０Ｓである。プライマリシステム１５０Ｐが、第１の計算機システムの一例である。セカンダリシステム１５０Ｓが、第２の計算機システムの一例である。プライマリシステム１５０Ｐが、最初にコミットを行う計算機システムである。セカンダリシステム１５０Ｓが、プライマリシステム１５０Ｐ以外の計算機システムである。
プライマリシステム１５０Ｐが、プライマリデータベース１５４Ｐと、プライマリサーバ１５５Ｐとを有する。プライマリサーバ１５５Ｐは、一つ又は複数のプライマリサーバ部１１Ｐ（例えば１１Ｐ１～１１Ｐ３）を有するデータベースサーバである。プライマリサーバ部１１Ｐが、プライマリデータベース１５４Ｐに対してデータの入出力を行う。プライマリデータベース１５４Ｐが、第１のオブジェクト群セットの一例であり、プライマリサーバ１５５Ｐが、第１のサーバの一例である。プライマリデータベース１５４Ｐは、複数レプリカから構成される分散データベースでもよい。プライマリシステム１５０Ｐが、プライマリのデータベースシステムであって、プライマリサーバ１５５Ｐが、プライマリシステム１５０Ｐの外に存在してもよい。
同様に、セカンダリシステム１５０Ｓが、セカンダリデータベース１５４Ｓと、セカンダリサーバ１５５Ｓとを有する。セカンダリサーバ１５５Ｓは、一つ又は複数のセカンダリサーバ部１２Ｐ（例えば１１Ｓ１～１１Ｓ３）を有する。セカンダリサーバ部１２Ｐが、セカンダリデータベース１５４Ｓに対してデータの入出力を行う。セカンダリデータベース１５４Ｓが、第２のオブジェクト群セットの一例であり、セカンダリサーバ１５５Ｓが、第２のサーバの一例である。セカンダリデータベース１５４Ｓも、複数レプリカから構成される分散データベースでもよい。セカンダリシステム１５０Ｓが、セカンダリのデータベースシステムであって、セカンダリサーバ１５５Ｓが、セカンダリシステム１５０Ｓの外に存在してもよい。
データベース１５４は、対象毎に、全てのバージョンのレコードを有してもよい。また、対象毎に、過去のバージョンのレコードは、データベース１５４とは別に管理されてもよく、過去のバージョンのレコードは、計算機システム１５０の中及び外のどちらに存在してもよい。
また、データベース１５４において、レコードは、当該レコードのライトを含んだトランザクションのＩＤ（例えばnonce）や、当該レコードの生成のためのインプット（当該レコードの生成のためにリードされた全てのレコードのＩＤ及びバージョンの集合）や、ＭＡＣを含んでもよいし、トランザクションＩＤ、インプット及びＭＡＣといったデータが、当該レコードに紐づけられてデータベース１５４とは別の場所に存在してもよい。ＭＡＣは、認証用データの一例である。認証用データは、ＭＡＣに代えて、authentication（受信者が、受信したデータがそのデータの送信者から送信されたと確信できること）に使用される他種のデータ、例えば電子署名でもよい。
セカンダリサーバ１５５Ｓが、ロックテーブル１２を管理する。ロックテーブル１２は、複数のセカンダリサーバ部１１Ｓに共通でもよいし、各セカンダリサーバ部１１Ｓが、ロックテーブル１２を保持し、一のセカンダリサーバ部１１Ｓがロックテーブル１２を更新した場合にその更新が他のセカンダリサーバ部１１Ｓのロックテーブル１２に反映されてもよい。また、各セカンダリサーバ部１１Ｓがロックテーブル１２の一部分を有し（例えば、第１のセカンダリサーバ部１１Ｓ１がロックテーブル１２の第１の部分を有し、第２のセカンダリサーバ部１１Ｓ２がロックテーブル１２の第２の部分を有し）、複数のセカンダリサーバ部１１Ｓ全体が一つのロックテーブル１２を有してもよい。
データベースシステム１３０のクライアントシステム１１０が、一つ又は複数のクライアント計算機１０（例えば１０Ａ～１０Ｃ）を有する。クライアント計算機１０は、物理的又は仮想的な計算機である。クライアント計算機１０は、アプリケーション１０１と、データベースクライアント１０２とを有する。
本実施形態に係るデータベースシステム１３０は、データベースクライアント１０２とデータベースサーバ１５５とを含む。データベースサーバ１５５が、データベース１５４を含み、計算機システムとして構成されてもよい。
データベースシステム１３０は、競合しないトランザクションを並列に実行する。データベースシステム１３０は、計算機システム１５０におけるビザンチン故障を検知する。
データベースクライアント１０２は、アプリケーション１０１に対してデータベースシステム１３０の単一のビューを提供する。データベース１５４は、単一ノードデータベースでもよいしマルチノード分散データベースでもよい。
データベースサーバ１５５Ｐ（データベースサーバ部１１Ｐ１～１１Ｐ３）及び１５５Ｓ（データベースサーバ部１１Ｓ１～１１Ｓ３）は、同じ決定的関数のセットを有する。データベースクライアント１０２は、実行するべき関数への参照と、その関数についてのすべての必要とされるパラメータとを含むトランザクション要求を発行する。
データベースシステム１３０は、リードオペレーション及びライトオペレーションをサポートする。
両方のデータベース１５４がＡＣＩＤ（Atomicity、Consistency、Isolation及びDurability）且つIsolationにおいてはstrict serializabilityを必ずしも提供しなくてもよい。例えば、プライマリデータベース１５４Ｐが、ＡＣＩＤをread committed Isolationで提供してもよく、セカンダリデータベース１５４Ｓが、単一レコードに対する単一オペレーションにおいてDurabilityとLinearizabilityを提供してもよい。両方のデータベース１５４が、レコードのセットから構成され、レコードのセットにおいては、プライマリキーが各レコードを識別する。
本実施形態では、下記が採用されている。
・二つの計算機システム１５０が正常であり、二つの計算機システム１５０に同じ要求が入力された場合、二つの計算機システム１５０は同じ決定的関数のセットを有しているため、結果は同じである。
・一方の計算機システム１５０にビザンチン故障があり他方の計算機システム１５０が正常の場合、safetyは提供され、ビザンチン故障の検知が可能である。
・二つの計算機システム１５０の両方にビザンチン故障がある場合、各計算機システム１５０におけるビザンチン故障を検知できない可能性がある。
・二つの計算機システム１５０のいずれも特権的な能力を有しない。つまり、データベースシステム１３０は、非中央集権的なシステムである。また、二つの計算機システム１５０のデータベース１５４を同じ状態に保つために、二つの計算機システム１５０は合意を経てトランザクションやリカバリといった処理を行う。別の言い方をすれば、各計算機システム１５０は、もう１つの計算機システム１５０の合意無しにトランザクションやリカバリを進めることはできない。
・データベース１５４は、対象毎にレコード群を有してよい。各対象について、レコード群は、一つ以上のレコードでよい。一つの主キー（レコードＩＤ）が一つの対象に対応してよい。本実施形態では、一つの主キー（一つの対象）につき、全てのバージョンのレコードがデータベース１５４に存在するが、過去のバージョンのレコードは、データベース１５４の外で管理されてもよいし、一部のバージョンのレコードは管理対象外であってもよい。
・データベースシステム１３０は、ＭＡＣ（Message Authentication Code）のために２つのタイプの秘密データを管理する。一方の秘密データは、クライアント１０２とサーバ１５５との間で共有される秘密データ（以下、秘密ClientServer）である。他方の秘密データは、プライマリサーバ１５５Ｐとセカンダリサーバ１５５Ｓとの間で共有される秘密データ（以下、秘密PrimarySecondary）である。
データベースシステム１３０のベースとなる物理的な計算機システムは、図２に例示のシステムでよい。すなわち、物理的な計算機システムは、通信ネットワーク１９に接続された一つ又は複数の計算機２３０で構成されてよい。計算機２３０は、通信ネットワーク１９に接続されるインターフェース装置２３１、データベース１５４の一部又は全部やコンピュータプログラムを記憶する記憶装置２３２、及び、それらの装置２３１及び２３２に接続されたプロセッサ２３３を有してよい。プロセッサ２３３がサーバプログラムを実行することでデータベースサーバ部１１又はデータベースサーバ１５５が実現されてよい。一つ以上の計算機２３０がデータベース１５４を記憶しデータベースサーバ１５５を実現し、一つの計算機システム１５０がそのデータベース１５４及びデータベースサーバ１５５を含んでよい。
クライアントシステム１１０も、少なくとも一つの計算機を含んだ物理的な計算機システムに基づくシステムでよい。一つ又は複数の計算機がそれぞれクライアント計算機でよい。一つ又は複数のクライアント計算機のプロセッサがアプリケーションプログラムやクライアントプログラムを実行してよく、アプリケーションプログラムが実行されることでアプリケーション１０１が実現されてよく、また、クライアントプログラムが実行されることでデータベースクライアント１０２が実現されてよい。アプリケーション１０１とデータベースクライアント１０２は、同一のクライアント計算機に存在してもよいし別々のクライアント計算機に存在してもよい。
図３は、ロックテーブル１２の構成の一例を示す。
ロックテーブル１２は、セカンダリデータベース１５４Ｓの主キー毎にロックエントリ３００を有する。つまり、ロックエントリ３００は、一つの主キーにつき一つである。ロックエントリ３００は、レコードＩＤ３０１、バージョン３０２、ロックタイプ３０３、ロックカウント３０４、ロックホルダ３０５、インプット３０６及び最新更新時刻３０７といったデータを有する。一つのロックエントリ３００を例に取る。また、図３の説明において、そのロックエントリ３００のレコードＩＤ３０１及びバージョン３０２に対応するレコードを「対応レコード」と言う。
レコードＩＤ３０１は、セカンダリデータベース１５４Ｓのうちの対応レコードのＩＤを表す。バージョン３０２は、対応レコードのバージョンを表す。バージョンは、例えば番号であり、対応レコードがコミットされた場合にインクリメントされる。
ロックタイプ３０３は、ロックのタイプを表す。ロックタイプ３０３として、“リードロック”、“ライトロック”及び“ロック無し”がある。“リードロック”は、リードのために取得されたロックを意味する。“ライトロック”は、ライトのために取得されたロックを意味する。“ロック無し”は、ロックが取得されていないことを意味する。
ロックカウント３０４は、対応レコードのロックを取得しているトランザクションの数を表す。ライトロックについては、トランザクション数は１である。リードロックについては、トランザクション数は１以上である。ロックホルダ３０５は、ライトロック又はリードロックを取得しているトランザクションのトランザクションＩＤ（nonce）の集合である。
インプット３０６は、ライトロックが取得された場合に格納されるデータであり、当該ライトロックが取得されたレコードＩＤについて次バージョンのレコードを生成するためにリードされた全てのレコードのＩＤ及びバージョンの集合である。例えば、対応レコードの次バージョンのレコードの生成のためにレコード（レコードＩＤ“ｋ１”及びバージョン“２”）とレコード（レコードＩＤ“ｋ２”及びバージョン“３”）がリードされた場合、対応レコードのインプット３０６は、レコードＩＤ“ｋ１”及びバージョン“２”とレコードＩＤ“ｋ２”びバージョン“３”の集合である。
最新更新時刻３０７は、ロックエントリ３００が更新された最新の時刻（日時）を表す。
図４は、プルーフの構成の一例を示す。
後述するように、本実施形態では、ライト又はリードされるレコード毎に当該レコードのプルーフ（当該レコードのリード又はライトのプルーフ）が作成される。プルーフは、レコードＩＤ４０１、バージョン４０２、nonce（トランザクションＩＤ）４０３、インプット４０４及び署名４０５といったデータを有する。図４の説明において、図４に例示のプルーフに対応するレコードを「対応レコード」と言う。
レコードＩＤ４０１は、対応レコードのＩＤを表す。バージョン４０２は、対応レコードのバージョンを表す。
nonce（トランザクションＩＤ）４０３は、対応レコードをリード又はライトするトランザクションのnonce（ＩＤ）を表す。インプット４０４は、対応レコードを作成するためにリードされたレコードのＩＤ及びバージョンの集合である。
署名４０５は、秘密PrimarySecondaryを用いて作成されたＭＡＣであり、データ４０１～４０４についてのＭＡＣである。
データベースシステム１３０のビザンチン故障検知プロトコルの重要な点は、プライマリサーバ１５５Ｐとセカンダリサーバ１５５Ｓとが、非中央集権的且つ並列にトランザクションの半順序関係について合意を交わすことである。プロトコルは、３つのフェーズ、すなわち、順序付けフェーズ、コミットフェーズ、及び検証フェーズで構成される。まず、セカンダリサーバ１５５Ｓが、クライアント１０２から与えられたトランザクションを、競合に基づいて半順序に順序付けする（順序付けフェーズ）。次に、プライマリサーバ１５５Ｐが、セカンダリサーバ１５５Ｓによって順序付けされたトランザクションを実行及びコミットする（コミットフェーズ）。最後に、セカンダリサーバ１５５Ｓが、プライマリサーバ１５５Ｐから与えられた順序付け結果を検証し、トランザクションを実行する（検証フェーズ）。３フェーズプロトコルは、両方の計算機システム１５０が正常である限り、両方のデータベース１５４に同じ正しい（strict serializableな）状態及び結果を導出させる。どちらかの計算機システム１５０にビザンチン故障が発生した場合には、それらの状態又は結果は相異なるものとなる。クライアント１０２は、その相違を検知し、データベースシステム１３０におけるビザンチン故障を検知することができる。以下、各フェーズを詳細に説明する。なお、以下の説明において、「エラーを応答にセットする」とは、エラーを表すデータを応答にセットすることを意味する。「結果を応答にセットする」とは、トランザクション実行の結果を表すデータを応答にセットすることを意味する。例えば、結果を表すデータは、トランザクション実行の成否を表すデータと、決定的関数の実行により得られた状態（例えば、リードされたレコードが表す状態、又は、リードされた複数のレコードが表す複数の状態を用いて算出された状態）を表すデータとを含む。
図５は、順序付けフェーズでの処理の流れの一例を示す。
クライアント１０２が、アプリケーション１０１から、データベースシステム１３０に対する関数の実行のためのトランザクション要求を受信した場合に、順序付けフェーズが開始する。クライアント１０２は、アプリケーション１０１からのトランザクション要求に基づき内部的なトランザクション要求を作成する（Ｓ５０１）。トランザクション要求は、＜ｎ、ｆ、ａ、ｓ＞というパラメータを有している。パラメータは下記の通りである。
・ｎは、要求を識別する一意なトランザクションＩＤ（例えば、nonce（又はUUID））である。
・ｆは、関数への参照である。
・ａは、関数の引数である。
・ｓは、秘密ClientServerを用いて、ｎ、ｆ、及びａについて作成されるＭＡＣ（以下、ＭＡＣClient）である。
クライアント１０２は、作成されたトランザクション要求をセカンダリサーバ１５５Ｓに送信する（Ｓ５０２）。
セカンダリサーバ１５５Ｓは、トランザクション要求を受信し（Ｓ５０３）、秘密ClientServerを用いて、当該トランザクション要求のＭＡＣClientを検証する（Ｓ５０４）。Ｓ５０４においてエラーが検知された場合（Ｓ５０５：Ｎｏ）、セカンダリサーバ１５５Ｓは、ＭＡＣ検証エラーを応答にセットし（Ｓ５１６）、当該応答をクライアント１０２に返す（Ｓ５１７）。
なお、「ＭＡＣ検証エラー」は、ビザンチン故障があることを意味する。しかし、順序付けフェーズではトランザクションは実行されないため、ここでのＭＡＣ検証エラーは、ビザンチン故障があるがプライマリデータベース１５４Ｐとセカンダリデータベース１５４Ｓに相違が無いことを意味する。
Ｓ５０４においてエラーが検知されなかった場合（Ｓ５０５：Ｙｅｓ）、セカンダリサーバ１５５Ｓは、Ｓ５０３で受信したトランザクション要求を、トランザクション要求用のデータベースにライトする（Ｓ５０６）。トランザクション要求毎にnonce（トランザクションＩＤ）があり、そのデータベースには、nonceを主キーとしたレコードがあり、そのレコードに、トランザクション要求それ自体（又は、そのトランザクション要求が有するパラメータ）がライトされる。同一nonceを有するトランザクション要求が既にライトされている場合、セカンダリサーバ１５５Ｓは、Ｓ５０３で受信したトランザクション要求に従うトランザクションをアボートする。
Ｓ５０６の後、セカンダリサーバ１５５Ｓは、Ｓ５０３で受信したトランザクション要求で指定されている関数の実行をシミュレーションして、その関数によって、どのレコードがリードされどのレコードがライトされることになるのか、すなわち、リードセット（リードされる一つ以上のレコード）及びライトセット（ライトされる一つ以上のレコード）を識別する。シミュレーションでは、レコードをセカンダリデータベース１５４Ｓにライトすること無しに、関数が実行される。つまり、シミュレーションは、トランザクション要求の仮実行に相当する。
リードセット及びライトセットが識別された後に、セカンダリサーバ１５５Ｓは、リードセット内のレコード毎にリードロックを取得し、ライトセット内のレコード毎にライトロックを取得しようとする（Ｓ５０８）。具体的には、セカンダリサーバ１５５Ｓは、下記を試行する。
・リードセット内のレコード毎に、セカンダリサーバ１５５Ｓは、当該レコードの主キーからロックエントリ３００を識別する。識別されたロックエントリ３００におけるロックタイプ３０３が“ロック無し”又は“リードロック”であれば、リードロックの取得に成功する（ロックタイプ３０３が“ロック無し”であれば、セカンダリサーバ１５５Ｓは、ロックタイプ３０３を“リードロック”に更新する）。リードロックの取得が成功の場合、セカンダリサーバ１５５Ｓは、ロックカウント３０４の値を１インクリメントし、ロックホルダ３０５に当該トランザクションのＩＤ（Nonce）を追加し、最新更新時刻３０７を更新する。
・ライトセット内のレコード毎に、セカンダリサーバ１５５Ｓは、当該レコードの主キーからロックエントリ３００を識別する。識別されたロックエントリ３００におけるロックタイプ３０３が“ロック無し”であれば、ライトロックの取得に成功する。ライトロックの取得が成功の場合、セカンダリサーバ１５５Ｓは、ロックタイプ３０３を“ライトロック”に更新し、ロックカウント３０４を“１”とし、ロックホルダ３０５に当該トランザクションのＩＤ（Nonce）を登録し、インプット３０６に、当該レコードの作成のためにリードされた全てのレコード（リードセット内の一つ以上のレコード）の各々のレコードのＩＤ及びバージョンを登録し、最新更新時刻３０７を更新する。
リードセット及びライトセットの全てのレコードについてロックが取得された場合（Ｓ５０９：Ｙｅｓ）、セカンダリサーバ１５５Ｓは、秘密PrimarySecondaryを用いて、トランザクションＩＤについてＭＡＣ（以下、ＭＡＣSecondary）を作成し（Ｓ５１０）、当該作成されたＭＡＣSecondaryを応答にセットし（Ｓ５１１）、当該応答をクライアント１０２に返す（Ｓ５１５）。
少なくとも一つのレコードについてロックが取得されなかった場合（Ｓ５０９：Ｎｏ）、リカバリ処理（図８～図１３参照）が行われる（Ｓ５１２）。その後、セカンダリサーバ１５５Ｓは、Ｓ５０３で受信したトランザクション要求についてＳ５０８で取得したロックを全て解放する（Ｓ５１３）。そして、セカンダリサーバ１５５Ｓは、エラーを応答にセットし（Ｓ５１４）、当該応答をクライアント１０２に返す（Ｓ５１５）。なお、リカバリ処理において、順序付け検証（図１２）が行われた場合、下記の通りでよい。
・順序付け検証（図１２）において、後述のＳ１２０６、Ｓ１２０９又はＳ１２１１が行われた場合、Ｓ５１４はスキップされ、Ｓ５１５が行われる。つまり、クライアント１０２に返る応答は、順序付け検証においてエラーがセットされた応答でよい。
・順序付け検証（図１２）において、後述のＳ１２１２が行われた場合、Ｓ５１４は行われる。すなわち、順序付け検証において応答にセットされたＯＫはエラーに差し替えられる。
Ｓ５１１、Ｓ５１４及びＳ５１６において、応答には、Ｓ５０３で受信したトランザクション要求が有するトランザクションＩＤがセットされてもよい。
クライアント１０２は、Ｓ５１５又はＳ５１７で送信された応答を受信する（Ｓ５１９）。クライアント１０２は、当該応答にエラーがセットされている場合（Ｓ５２０：Ｎｏ）、エラーを識別し、エラーをアプリケーション１０１に返す（Ｓ５２１）。当該応答にエラーがセットされていない場合（Ｓ５２０：Ｙｅｓ）、Ｓ５０１で作成されたトランザクション要求について、順序付けフェーズが終了し、コミットフェーズが開始される。
以上の順序付けフェーズの重要な点は、トランザクション要求の競合の有無を判定しその判定結果に基づいてトランザクション要求を事前に半順序に順序付けすることである。この順序付けフェーズが無いと、競合するトランザクション要求が、非決定的な結果を引き起こすことがある。結果として、プライマリデータベース１５４Ｐの状態とセカンダリデータベース１５４Ｓの状態とがビザンチン故障が発生せずとも相違することになる。
トランザクション要求の競合の有無の判定には、リードセット及びライトセットにおける各レコードについて２フェーズロッキング（２ＰＬ）ベースのロック手法が利用される。トランザクション順序付けのための２ＰＬベースのロック手法を使用して、データベースシステム１３０におけるstrict serializabilityが保証される。
順序付けフェーズにおけるいずれの処理も並列に実行される。順序付けフェーズにおいてリードセット及びライトセットの全てのレコードについてロックが取得されたならば、トランザクションは競合しないということである。そのトランザクションは、コミットフェーズにおいてプライマリサーバ１５５Ｐにより並列に実行され、その後の検証フェーズにおいてセカンダリサーバ１５５Ｓにより並列に実行される。
一方、リードセット及びライトセットにおける少なくとも一つのレコードについてロックが取得できなければ、トランザクションは競合するということである。この場合、セカンダリサーバ１５５Ｓは、トランザクションをアボートし、そのトランザクション要求について取得されたロックを全て解放する。ロックが解放されるのを待つ代わりにトランザクションをアボートする理由は、セカンダリサーバ１５５Ｓがシミュレーション（Ｓ５０７）を再実行して、レコードの最新のバージョンを得て、strict serializableにトランザクションを順序付けする必要があるからである。
図６は、コミットフェーズでの処理の流れの一例を示す。
クライアント１０２がセカンダリサーバ１５５Ｓから肯定応答（エラーがセットされておらずＭＡＣSecondaryがセットされている応答）を受信した場合に、コミットフェーズが開始する。クライアント１０２は、まず、セカンダリサーバ１５５Ｓからの肯定応答に対応したトランザクション要求（Ｓ５０１で作成したトランザクション要求）に、セカンダリサーバ１５５Ｓからの肯定応答にセットされているＭＡＣSecondaryを追加する（Ｓ６０１）。クライアント１０２は、当該トランザクション要求をプライマリサーバ１５５Ｐへ送信する（Ｓ６０２）。
プライマリサーバ１５５Ｐは、当該トランザクション要求を受信する（Ｓ６０３）。プライマリサーバ１５５Ｐは、そのトランザクション要求におけるＭＡＣClientを、秘密ClientServerを用いて検証し、当該トランザクション要求におけるＭＡＣSecondaryを、秘密PrimarySecondaryを用いて検証する（Ｓ６０４）。少なくとも一つのＭＡＣの検証においてエラーが検知された場合（Ｓ６０５：Ｎｏ）、プライマリサーバ１５５Ｐは、ＭＡＣ検証エラーを応答にセットし（Ｓ６１２）、当該応答をクライアント１０２に返す（Ｓ６１３）。なお、ここでのＭＡＣ検証エラーは、ビザンチン故障があるがプライマリデータベース１５４Ｐとセカンダリデータベース１５４Ｓに相違が無いことを意味する。プライマリサーバ１５５Ｐにおいてトランザクションは実行されていない（Ｓ６０６が行われていない）ためである。
いずれのＭＡＣの検証においてもエラーが検知されなかった場合（Ｓ６０５：Ｙｅｓ）、プライマリサーバ１５５Ｐは、Ｓ６０３で受信したトランザクション要求に従うトランザクションを実行する（Ｓ６０６）。具体的には、プライマリサーバ１５５Ｐは、当該トランザクション要求で指定されている関数を参照し、アトミックに、プライマリデータベース１５４Ｐからレコードをリード、及び／又は、プライマリデータベース１５４Ｐへレコードをライトすること、Ｓ６０３で受信したトランザクション要求をトランザクション要求用のデータベースへライトすることとを行う。ライトされるレコードのバージョンは、そのレコードと同一主キーのライト前のレコードのバージョンの次のバージョンとされる。ライトされるトランザクション要求のトランザクションステータスは、“Committed”又は“Aborted”である。
Ｓ６０６の実行が失敗の場合（Ｓ６０７：Ｎｏ）、プライマリサーバ１５５Ｐは、トランザクションをアボートし（Ｓ６０８）、エラーを応答にセットし（Ｓ６０９）、当該応答をクライアント１０２に返す（Ｓ６１３）。
Ｓ６０６の実行が成功の場合（Ｓ６０７：Ｙｅｓ）、プライマリサーバ１５５Ｐは、ライトされたレコード毎に、及び、リードされたレコード毎に、プルーフ（図４参照）を作成する（Ｓ６１０）。以下、プライマリサーバ１５５Ｐが作成したプルーフを、便宜上、「プライマリプルーフ」と呼ぶ。プライマリプルーフが、第１のプルーフの一例であり、プライマリプルーフにおけるインプット４０４が、第１のインプットの一例である。プライマリプルーフが有する署名４０５は、プライマリサーバ１５５Ｐが秘密PrimarySecondaryを用いて作成したＭＡＣ（以下、ＭＡＣPrimary）である。プライマリサーバ１５５Ｐは、当該プライマリプルーフと、トランザクションの実行の結果とを応答にセットし（Ｓ６１１）、当該応答をクライアント１０２に返す（Ｓ６１３）。プライマリサーバ１５５Ｐが応答にセットした結果を、便宜上、「プライマリ結果」と呼ぶ。プライマリ結果が、第１の結果の一例である。
Ｓ６０９、Ｓ６１１及びＳ６１２において、応答には、Ｓ６０３で受信したトランザクション要求が有するトランザクションＩＤがセットされてもよい。
クライアント１０２は、プライマリサーバ１５５Ｐから応答（第１の応答の一例）を受信する（Ｓ６１４）。クライアント１０２は、当該応答にエラーがセットされている場合（Ｓ６１５：Ｎｏ）、エラーを識別し、エラーをアプリケーション１０１に返す（Ｓ６１６）。当該応答にエラーがセットされていない場合（Ｓ６１５：Ｙｅｓ）、Ｓ５０１で作成されたトランザクション要求について、コミットフェーズが終了し、検証フェーズが開始される。
コミットフェーズでは、プライマリサーバ１５５Ｐは、トランザクション要求を、受信したら直ちに実行してもよいし任意の順序で実行してもよい。具体的には、プライマリサーバ１５５Ｐは、受信したトランザクション要求について競合の有無を判定すること無しに（リード又はライトされるレコードについてロックの取得無しに）、受信したトランザクション要求を任意のタイミングで実行してよい。なぜならば、受信したトランザクション要求は、セカンダリサーバ１５５Ｓによってstrict serializableを保証して既に半順序に順序付けされているからである。結果として、プライマリサーバ１５５Ｐにおいて、競合の無いトランザクション要求の並列実行が可能である。
図７は、検証フェーズでの処理の流れの一例を示す。
クライアント１０２がプライマリサーバ１５５Ｐから肯定応答（エラーがセットされていない応答）を受信した場合に、検証フェーズが開始する。
クライアント１０２は、アプリケーション１０１に応答を返す前に、受信した肯定応答内の全プライマリプルーフを、セカンダリサーバ１５５Ｓに送信する（Ｓ７０１）。
セカンダリサーバ１５５Ｓは、クライアント１０２からプライマリプルーフを受信する（Ｓ７０２）。セカンダリサーバ１５５Ｓは、各プライマリプルーフについて、当該プライマリプルーフがプライマリサーバ１５５Ｐにより作成されたかどうかを確かめるために、当該プライマリサーバ１５５Ｐ内の署名４０５（ＭＡＣ）を、秘密PrimarySecondaryを用いて検証する（Ｓ７０３）。いずれかのプライマリプルーフの署名４０５（ＭＡＣ）の検証においてエラーが検知された場合（Ｓ７０４：Ｎｏ）、セカンダリサーバ１５５Ｓは、ＭＡＣ検証エラーを応答にセットし（Ｓ７１１）、当該応答をクライアント１０２に返す（Ｓ７１２）。ここでのＭＡＣ検証エラーは、ビザンチン故障があり、プライマリデータベース１５４Ｐとセカンダリデータベース１５４Ｓに相違があり得ることを意味する。プライマリサーバ１５５Ｐにおいてトランザクションがコミットしている（レコードがプライマリデータベース１５４Ｐにライトされている可能性がある）ためである。
いずれのプライマリプルーフの署名４０５（ＭＡＣ）の検証においてもエラーが検知されなかった場合（Ｓ７０４：Ｙｅｓ）、セカンダリサーバ１５５Ｓは、順序付け検証を行う（Ｓ７０５）。
順序付け検証では、図１２に示すように、プライマリシステム１５０Ｐとセカンダリシステム１５０Ｓでの順序付けが同じことを確認するために、プライマリプルーフと、プライマリプルーフから識別されるロックエントリ３００とが比較される。すなわち、セカンダリサーバ１５５Ｓは、プライマリプルーフ毎に、当該プライマリプルーフと、当該プライマリプルーフと同一主キーのロックエントリ３００との間で、バージョン及びインプットを比較して、それらが一致するかどうかをチェックする。Ｓ５１３で実施されるリカバリ処理に起因して、ロックエントリの欠落又はバージョンの不一致といったエラーが生じ得るが、順序付け検証では、そのようなエラーが検知され得る。順序付け検証は、事前検証であり、最終的な検証は、クライアント１０２により実行される。なぜなら、セカンダリシステム１５０Ｓに悪意がある場合、順序付け検証をスキップすることがあり得るからである。
プライマリプルーフとロックエントリ３００（当該プライマリプルーフが有する主キーから特定されるロックエントリ３００）との比較を各プライマリプルーフについて行うことは、セカンダリシステム１５０Ｓにおける順序付けとプライマリシステム１５０Ｐにおける順序付けとの比較に相当する。理由は、下記の通りである。
・プライマリプルーフは、当該プルーフに対応のレコードの作成に使用された全てのレコードのＩＤ及びバージョンの集合であるインプット４０４を有する。同様に、ロックエントリ３００も、当該ロックエントリ３００に対応のレコードの作成に使用された全てのレコードのＩＤ及びバージョンの集合であるインプット３０６を有する。
・従って、プライマリプルーフもロックエントリ３００も、トランザクションにおけるレコードの依存関係を表している。つまり、両方ともトランザクション間の依存関係を表している。
・トランザクション間の依存関係が同じである、ということは、トランザクションは同じ半順序で並んでいることを意味する。
・以上の通りであるため、プライマリプルーフとロックエントリ３００との比較を各プライマリプルーフについて行うことは、セカンダリシステム１５０Ｓにおける順序付けとプライマリシステム１５０Ｐにおける順序付けとの比較に相当する。プライマリシステム１５０Ｐとセカンダリシステム１５０Ｓ間でトランザクションの半順序が同じため、同じ結果が導出される。
順序付け検証において検証エラー又はビザンチン故障エラーが応答にセットされた場合（Ｓ７０６：Ｎｏ）、セカンダリサーバ１５５Ｓは、当該応答をクライアント１０２に返す（Ｓ７１２）。
順序付け検証においてＯＫ（検証成功を意味するデータ）が応答にセットされた場合（Ｓ７０６：Ｙｅｓ）、セカンダリサーバ１５５Ｓは、Ｓ５０３で受信したトランザクション要求（Ｓ７０２で受信したトランザクションＩＤをキーにトランザクション要求用のデータベースから特定されたトランザクション要求）に従うトランザクションを実行する（Ｓ７０７）。
Ｓ７０７のトランザクション実行に成功すると、セカンダリサーバ１５５Ｓは、Ｓ７０７でリード及び／又はライトされたレコード毎に、プルーフを作成する（Ｓ７０８）。以下、セカンダリサーバ１５５Ｓが作成したプルーフを、便宜上、「セカンダリプルーフ」と呼ぶ。セカンダリプルーフが、第２のプルーフの一例であり、セカンダリプルーフにおけるインプット４０４が、第２のインプットの一例である。セカンダリプルーフが有する署名４０５は、セカンダリサーバ１５５Ｓが秘密PrimarySecondaryを用いて作成したＭＡＣ（ＭＡＣSecondary）である。
セカンダリサーバ１５５Ｓは、Ｓ７０７でリード又はライトされたレコード毎に、ロックを解放する（Ｓ７０９）。これにより、順序付けフェーズのＳ５０８で取得されたロックが解放される。なお、Ｓ７０７でライトされたレコードがあれば、ライトされたレコード毎に、ロックエントリ３００のバージョン３０２がインクリメントされる。また、Ｓ７０９では、更新されたロックエントリ３００毎に、最新更新時刻３０７が更新される。また、Ｓ７０９では、バージョン３０２のインクリメントと、最新更新時刻３０７の更新と、ロックの解放は、アトミックに行われる。また、ロックの解放では、リードロックについては、ロックカウント３０４のデクリメントと、ロックホルダ３０５からのトランザクションＩＤの削除が行われ、バージョン３０２のインクリメントは行われない。
Ｓ７０９の後、セカンダリサーバ１５５Ｓは、セカンダリプルーフ及び結果（Ｓ７０７の結果）を応答にセットし（Ｓ７１０）、当該応答をクライアント１０２に返す（Ｓ７１２）。セカンダリサーバ１５５Ｓが応答にセットした結果を、便宜上、「セカンダリ結果」と呼ぶ。セカンダリ結果が、第２の結果の一例である。
クライアント１０２は、セカンダリサーバ１５５Ｓから応答（第２の応答の一例）を受信する（Ｓ７１３）。クライアント１０２は、当該応答にエラーがセットされていない場合（Ｓ７１４：Ｎｏ）、エラーを識別し、エラーをアプリケーション１０１に返す（Ｓ７１８）。
当該応答にエラーがセットされていない場合（Ｓ７１４：Ｙｅｓ）、クライアント１０２は、プライマリ結果とセカンダリ結果を比較し、且つ、全プライマリプルーフと全セカンダリプルーフとを比較する（Ｓ７１５）。プライマリサーバ１５５Ｐとセカンダリサーバ１５５Ｓで同じトランザクションが実行された場合、全てのプライマリプルーフと全てのセカンダリプルーフは一致するはずである。なぜなら、プライマリサーバ１５５Ｐとセカンダリサーバ１５５Ｓにより同じ決定的関数が実行され、故に、同じレコードがリードされ同じレコードがライトされるはずだからである。
プライマリ結果とセカンダリ結果が一致し、且つ、全プライマリプルーフと全セカンダリプルーフが一致する場合（Ｓ７１５：Ｙｅｓ）、クライアント１０２は、ＯＫ（トランザクションのＩＤと当該トランザクションの成功とを表すデータ）をアプリケーション１０１に返す（Ｓ７１６）。
プライマリ結果とセカンダリ結果が一致しない、又は、少なくとも一つのプルーフについて一致するプルーフが無い場合（Ｓ７１５：Ｎｏ）クライアント１０２は、プライマリシステム１５０Ｐとセカンダリシステム１５０Ｓのいずれかにおいてビザンチン故障があることを表すデータをアプリケーション１０１に返す（Ｓ７１７）。
以上が、ビザンチン故障検知プロトコルの説明である。
ビザンチン故障検知プロトコルにおいて、２ＰＬベースの順序付けが採用されている。このため、データベースシステム１３０におけるstrict serializabilityを保証することができる。一比較例として、順序付けにＭＶＣＣ（MultiVersion Concurrency Control）を用いることが検討されるが、ＭＶＣＣでは、セカンダリシステム１５０Ｓとプライマリシステム１５０Ｐとの間で一貫した順序付けを保証することは困難である。具体的には、例えば、次の通りである。すなわち、競合するトランザクションＴ１とＴ２とがデータベースシステム１３０にほぼ同時に到来し、ＭＶＣＣを用いて共に順序付けされる、と仮定する。そして、両方のトランザクションが、直列化順序Ｔ１→Ｔ２で順序付けフェーズを通過する、と仮定する。しかし、その直列化順序Ｔ１→Ｔ２がプライマリシステム１５０Ｐにおいて保証されるものではない。なぜならば、セカンダリシステム１５０Ｓは、競合グラフなどの明示的な順序依存性をプライマリシステム１５０Ｐに渡さず、故に、プライマリシステム１５０Ｐは、セカンダリシステム１５０Ｓとは異なる直列化順序（例えば、Ｔ２→Ｔ１）でトランザクションを順序付けすることがあり得るからである。
ビザンチン故障検知プロトコルが上述の三つのフェーズ（順序付け→コミット→検証）で構成されているため、データベースシステム１３０は、strict serializabilityを保証しつつ、並列実行を達成することができる。
また、ビザンチン故障検知プロトコルによれば、セカンダリシステム１５０Ｓがプライマリシステム１５０Ｐよりも先に始動し、プライマリサーバ１５５Ｐがコミットフェーズの処理を行う。コミットフェーズの処理においてトランザクションの状態が確定するが、トランザクションの状態の確定は、セカンダリシステム１５０Ｓよりもプライマリシステム１５０Ｐが行うことが好ましい。しかし、変形例として、プライマリシステム１５０Ｐが先に始動してもよい。すなわち、順序付けフェーズの処理と検証フェーズの処理をプライマリサーバ１５５Ｐが行いコミットフェーズの処理をセカンダリサーバ１５５Ｓが行ってもよい。
ところで、ビザンチン故障検知プロトコルによれば、順序付けフェーズにおいて既にロックが取得されていた場合、取得されているロックが解放されるべきであれば当該ロックを解放するためのリカバリ処理が行われる（Ｓ５１２）。例えば、セカンダリシステム１５０Ｓにおいて、ノードクラッシュやネットワーク故障などのクラッシュ故障があると、ロックが取得されたまま（解放されないまま）になることがある。リカバリ処理では、そのようなロックを解放することができる。
図８は、リカバリ処理の流れの一例を示す。
セカンダリサーバ１５５Ｓは、チェックするロックがあれば（Ｓ８０１：Ｙｅｓ）、そのロックから一つのロックを抽出する（Ｓ８０２）。ここで言う「チェックするロック」は、リードセット及びライトセットのうちのロックが取得されなかったレコードについてのロックであって、未だＳ８０２で抽出されていないロックである。
セカンダリサーバ１５５Ｓは、抽出されたロックが失効しているか否かを判定する（Ｓ８０３）。この判定は、当該ロックのロックエントリ３００における最新更新時刻３０７から一定時間経過しているか否かを判定である。なお、ロックが失効していない場合（Ｓ８０４：Ｎｏ）、そのロックが取得されているレコードについては、ロックの解放無しにリカバリ処理が終了し、トランザクションはアボートされる。
ロックが失効している場合（Ｓ８０４：Ｙｅｓ）、そのロックのリカバリ試行処理が行われる（Ｓ８０５）。
図９は、リカバリ試行処理の流れの一例を示す。
セカンダリサーバ１５５Ｓは、そのロックのロックホルダ３０５（トランザクションＩＤの集合）を取得する（Ｓ９０１）。セカンダリサーバ１５５Ｓは、チェックするトランザクションＩＤがあれば（Ｓ９０２：Ｙｅｓ）、そのトランザクションＩＤから一つのトランザクションＩＤを抽出する（Ｓ９０３）。ここで言う「チェックするトランザクションＩＤ」は、Ｓ９０１で取得されたトランザクションＩＤのうち、未だＳ９０３で抽出されていないトランザクションＩＤである。
セカンダリサーバ１５５Ｓは、Ｓ９０３で抽出されたトランザクションＩＤのステータスを特定するアボート試行処理を開始する（Ｓ９０４）。すなわち、図１０に示すように、セカンダリサーバ１５５Ｓは、そのトランザクションＩＤを指定したアボート要求をプライマリサーバ１５５Ｐに送信する（Ｓ１００１）。プライマリサーバ１５５Ｐは、当該アボート要求を受信し、当該アボート要求で指定されているトランザクションＩＤのトランザクションをアボートすることを試行し（Ｓ１００２）、そのトランザクションのステータスをセカンダリサーバ１５５Ｓに返す（Ｓ１００３）。そのトランザクションが未だコミットされていなければ、プライマリサーバ１５５Ｐがそのトランザクションのアボートに成功し、アボート済を意味するステータス“Aborted”が返される。そのトランザクションが既にコミットされていれば、プライマリサーバ１５５Ｐがそのトランザクションのアボートに失敗し、コミット済を意味するステータス“Committed”が返される。そのトランザクションが未だコミットされていないがプライマリサーバ１５５Ｐがそのトランザクションのアボートに失敗した場合（例えばセカンダリサーバ１５５Ｓがビジー状態であることが理由でトランザクションのアボートに失敗した場合）、所定のステータス“Unknown”が返される。セカンダリサーバ１５５Ｓは、アボート要求で指定されたトランザクションＩＤのトランザクションのステータスを受信する（Ｓ１００４）。図１０に例示のセカンダリサーバ１５５Ｓとプライマリサーバ１５５Ｐ間の通信は、クライアント１０２（典型的には、当該トランザクションＩＤのトランザクションを要求したクライアント）経由で行われてもよいし当該クライアント１０２非経由で行われてもよい。また、セカンダリサーバ１５５Ｓは、アボート要求に代えて、トランザクションＩＤを指定したステータス取得要求をプライマリサーバ１５５Ｐに送信し、ステータス取得要求に対しプライマリサーバ１５５Ｐから応答されたステータスに応じて、アボート要求をプライマリサーバ１５５Ｐに送信してもよい。
セカンダリサーバ１５５Ｓは、プライマリサーバ１５５Ｐから応答されたステータスが“Unknown”の場合（Ｓ９０５：Ｎｏ）、Ｓ９０３で取得したＩＤについてのリカバリをスキップし、他のトランザクションＩＤをチェックする（Ｓ９０２）。このロック取得済のレコードが別のトランザクションのリードレコード又はライトレコードとなる場合に、そのレコードは再度リカバリ処理の対象になるので、リカバリをスキップすることは問題を引き起こさない。
セカンダリサーバ１５５Ｓは、プライマリサーバ１５５Ｐから応答されたステータスが“Committed”又は“Aborted”の場合（Ｓ９０５：Ｙｅｓ）、そのトランザクションについてのロックをリカバリする。
ロックタイプ３０３が“リードロック”の場合（Ｓ９０６：Ｙｅｓ）、セカンダリサーバ１５５Ｓは、トランザクションについてのロックを解放する（Ｓ９０８）。具体的には、セカンダリサーバ１５５Ｓは、ロックホルダ３０５からこのトランザクションのＩＤを除去し、ロックカウント３０４をデクリメントする。
ロックタイプ３０３が“ライトロック”であり（Ｓ９０６：Ｎｏ）、ステータスが“Aborted”の場合（Ｓ９０７：Ｙｅｓ）、セカンダリサーバ１５５Ｓは、ロックエントリ３００のバージョン３０２をインクリメントすること無しにロックを解放する（Ｓ９０８）。具体的には、セカンダリサーバ１５５Ｓは、ロックホルダ３０５からこのトランザクションＩＤを除去し（つまりロックホルダ３０５を空にし）、ロックカウント３０４をデクリメントする（つまり“０”とする）。
ロックタイプ３０３が“ライトロック”であり（Ｓ９０６：Ｎｏ）、ステータスが“Committed”の場合（Ｓ９０７：Ｎｏ）、セカンダリサーバ１５５Ｓは、プルーフ取得処理を開始する（Ｓ９０９）。すなわち、図１１に示すように、セカンダリサーバ１５５Ｓは、このロックに対応のレコードのプライマリプルーフを取得するべく、プルーフ要求をプライマリサーバ１５５Ｐに送信する（Ｓ１１０１）。そのプルーフ要求では、ロックエントリ３００のレコードＩＤ（主キー）と当該ロックエントリ３００のバージョン３０２の次のバージョンとが指定される。プライマリサーバ１５５Ｐは、当該プルーフ要求を受信し、当該プルーフ要求で指定されているレコードＩＤ及びバージョンのレコードについてプライマリプルーフを作成する（Ｓ１１０２）。具体的には、プライマリサーバ１５５Ｐは、プルーフ要求で指定されているレコードＩＤ及びバージョンに該当するレコードから、トランザクションＩＤ及びインプットを特定する。プライマリサーバ１５５Ｐは、プルーフ要求で指定されているレコードＩＤ及びバージョンと、特定されたトランザクションＩＤ及びインプットとを基に、ＭＡＣを生成する。プライマリサーバ１５５Ｐは、それらのレコードＩＤ、バージョン、トランザクションＩＤ、インプット及びＭＡＣを含んだプライマリプルーフを作成する。プライマリサーバ１５５Ｐは、当該プライマリプルーフをセカンダリサーバ１５５Ｓに返す（Ｓ１１０３）。セカンダリサーバ１５５Ｓは、Ｓ１１０１で送信したプルーフ要求の応答として、当該プライマリプルーフを受信する（Ｓ１１０４）。
セカンダリサーバ１５５Ｓは、受信したプライマリプルーフについて順序付け検証（図１２）を行う（Ｓ９１０）。この順序付け検証においてＯＫが応答にセットされた場合に（Ｓ９１１：Ｙｅｓ）、セカンダリサーバ１５５Ｓは、当該検証されたプライマリプルーフに対応するレコードの新しい状態を導出する新規状態導出処理（図１３参照）を行う（Ｓ９１２）。セカンダリサーバ１５５Ｓは、その状態を表すレコードをセカンダリデータベース１５４Ｓにライトし（Ｓ９１３）、ロックを解放する（Ｓ９１４）。新しい状態を表すレコードがライトされるので、セカンダリサーバ１５５Ｓは、ロックを解放する場合に、ロックエントリ３００のバージョン３０２をインクリメントする。順序付け検証においてエラーが検知された場合（Ｓ９１１：Ｎｏ）、このリカバリ試行処理が終了する。
各レコードについてのリカバリ処理は、再試行され得るように冪等である。セカンダリサーバ１５５Ｓの複数のプロセスが、リカバリ処理を同時に行ったとしても、一つのプロセスのみが、linearizableにロックを解放する。
また、セカンダリサーバ１５５Ｓは、プライマリサーバ１５５Ｐとの間での合意無しにロックを解放しない。具体的には、セカンダリサーバ１５５Ｓは、ライトロックされているレコードのプライマリプルーフをプライマリサーバ１５５Ｐから取得し、当該プライマリプルーフの順序付け検証がされた場合に、ロックを解放する。
図１２は、順序付け検証の流れの一例を示す。
セカンダリサーバ１５５Ｓは、検証するプライマリプルーフがあれば（Ｓ１２０１：Ｙｅｓ）、そのプライマリプルーフから一つのプライマリプルーフを抽出する（Ｓ１２０２）。ここで言う「検証するプライマリプルーフ」は、クライアント１０２又はプライマリサーバ１５５Ｐから受信したプライマリプルーフのうち、未だＳ１２０２で抽出されていないプライマリプルーフである。また、プライマリプルーフは、上述したように、レコード一つにつき一つである。例えば、二つのレコードＡ及びＢをリードし二つのレコードＣ及びＤをライトする場合、プライマリプルーフは四つである。二つのレコードＡ及びＢをリードし二つのレコードＡ及びＢをライトする場合、プライマリプルーフは二つである。
セカンダリサーバ１５５Ｓは、抽出されたプライマリプルーフに対応のロックエントリ３００を取得する（Ｓ１２０３）。具体的には、セカンダリサーバ１５５Ｓは、プライマリプルーフのレコードＩＤと同じレコードＩＤのロックエントリ３００を取得する。
セカンダリサーバ１５５Ｓは、ロックエントリ３００のロックタイプ３０３が“リードロック”である場合（Ｓ１２０４：Ｙｅｓ）、プライマリプルーフのバージョン４０２とロックエントリ３００のバージョン３０２が一致するか否かを判定する（Ｓ１２０５）。それらのバージョンが一致する場合（Ｓ１２０５：Ｙｅｓ）、処理がＳ１２０１に戻る。それらのバージョンが不一致の場合（Ｓ１２０５：Ｎｏ）、セカンダリサーバ１５５Ｓは、検証エラーを応答にセットする（Ｓ１２０６）。なお、「検証エラー」とは、「ＭＡＣ検証エラー」と異なるエラーであり、ビザンチン故障の可能性がある（しかし必ずしもビザンチン故障があるとは限らない）ことを意味するエラーである。なお、クライアント１０５は、検証エラーがセットされている応答を受けた場合には、ビザンチン故障によってレコードが改ざんされているかどうかを確認するために、改ざんの可能性があるレコードをリードすることが望ましい。
セカンダリサーバ１５５Ｓは、ロックエントリ３００のロックタイプ３０３が“リードロック”ではない場合（Ｓ１２０４：Ｎｏ）、当該ロックタイプ３０３が“ライトロック”であるか否かを判定する（Ｓ１２０７）。ロックタイプ３０３が“ライトロック”ではない場合（Ｓ１２０７：Ｎｏ）、例えば、ロックタイプ３０３が改ざんされた場合、セカンダリサーバ１５５Ｓは、検証エラーを応答にセットする（Ｓ１２０９）。
ロックタイプ３０３が“ライトロック”である場合（Ｓ１２０７：Ｙｅｓ）、セカンダリサーバ１５５Ｓは、ロックエントリ３００のバージョン３０２の１インクリメント後の値と、プライマリプルーフのバージョン４０２が一致するか否かを判定する（Ｓ１２０８）。それらのバージョンが不一致の場合（Ｓ１２０８：Ｎｏ）、セカンダリサーバ１５５Ｓは、検証エラーを応答にセットする（Ｓ１２０９）。
それらのバージョンが一致する場合（Ｓ１２０８：Ｙｅｓ）、セカンダリサーバ１５５Ｓは、ロックエントリ３００のインプット３０６と、プライマリプルーフのインプット４０４が一致するか否かを判定する（Ｓ１２１０）。それらのインプットが不一致の場合（Ｓ１２１０：Ｎｏ）、セカンダリサーバ１５５Ｓは、ビザンチン故障エラーを応答にセットする（Ｓ１２１１）。それらのインプットが一致する場合（Ｓ１２１０：Ｙｅｓ）、処理がＳ１２０１に戻る。
セカンダリサーバ１５５Ｓは、検証するプライマリプルーフが無い場合（Ｓ１２０１：Ｎｏ）、すなわち、全てのプライマリプルーフについてエラーが検知されない場合、ＯＫを応答にセットする（Ｓ１２１２）。
図１３は、新規状態導出処理の流れの一例を示す。
セカンダリサーバ１５５Ｓは、Statesとして空の値をセットする（Ｓ１３０１）。セカンダリサーバ１５５Ｓは、プライマリプルーフからインプット４０４、具体的には、一つ又は複数の入力値を取得する（Ｓ１３０２）。
セカンダリサーバ１５５Ｓは、チェックする入力値があれば（Ｓ１３０３：Ｙｅｓ）、その入力値から一つの入力値を抽出する（Ｓ１３０４）。ここで言う「チェックする入力値」は、Ｓ１３０２で取得された入力値のうち、未だＳ１３０４で抽出されていない入力値である。
セカンダリサーバ１５５Ｓは、抽出した入力値に対応のレコードをデータベース１５４Ｓからリードし（Ｓ１３０５）、リードしたレコードをStatesに追加する（Ｓ１３０６）。
チェックされる入力値がなければ（Ｓ１３０３：Ｎｏ）、セカンダリサーバ１５５Ｓは、Ｓ９０９で取得されたプライマリプルーフが有するトランザクションＩＤをキーに、トランザクション要求用のデータベースからトランザクション要求を取得する（Ｓ１３０７）。セカンダリサーバ１５５Ｓは、取得されたトランザクション要求で指定されている関数を取得する（Ｓ１３０８）。セカンダリサーバ１５５Ｓは、Statesを用いて、当該関数を実行する（Ｓ１３０９）。これにより新しい状態（States）が得られる。セカンダリサーバ１５５Ｓは、得られた新しい状態を返す（Ｓ１３１０）。
以上、一実施形態を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。
例えば、同一のトランザクション要求について同じ決定的関数をプライマリサーバ１５５Ｐ及びセカンダリサーバ１５５Ｓが実行することは、同じ決定的関数のセットがプライマリサーバ１５５Ｐ及びセカンダリサーバ１５５Ｓに予めインストールされている以外の方法により実現されてもよい。例えば、クライアント１０２が、トランザクション要求の送信の都度に、トランザクション要求と共に決定的関数をプライマリサーバ１５５Ｐ及びセカンダリサーバ１５５Ｓに送信し、プライマリサーバ１５５Ｐ及びセカンダリサーバ１５５Ｓは、それぞれ、トランザクション要求と共に受信した決定的関数を実行してよい。また、トランザクション要求は、ＳＱＬ文でもよい。
また、例えば、上述の２ＰＬベースのロック手法以外の手法を利用して、strict serializableに半順序に順序付けすることが実現されてもよい。
また、上述した実施形態によれば、トランザクション要求毎に、順序付けフェーズにおいて、セカンダリサーバ１５５Ｓが、クライアント１０２からの当該トランザクション要求をstrict serializableな半順序に順序付けする。具体的には、トランザクション要求毎に、セカンダリサーバ１５５Ｓが、クライアントからのトランザクション要求に従うトランザクションを仮実行することで当該トランザクションの競合の有無を判定し、競合が無いことが判定された場合に所定の応答をクライアントに返す。
１３０：データベースシステム

Claims (13)

  1. 第１及び第２の計算機システムから構成されるデータ管理システムであって、
    対象の状態を表すオブジェクトをリード及び／又はライトするトランザクションの要求であるトランザクション要求を送信するクライアントと、
    同一のトランザクション要求について同じ決定的関数を実行する第１及び第２のサーバと
    を備え、
    前記第１の計算機システムが、第１のオブジェクト群セットを管理し、当該第１のオブジェクト群セットは、対象毎の第１のオブジェクト群であり、第１のオブジェクト群は、一つ以上の第１のオブジェクトであり、第１のオブジェクトは、対象の状態を表し、
    前記第２の計算機システムが、第２のオブジェクト群セットを管理し、当該第２のオブジェクト群セットは、対象毎の第２のオブジェクト群であり、第２のオブジェクト群は、一つ以上の第２のオブジェクトであり、第２のオブジェクトは、対象の状態を表し、
    前記第１のサーバが、前記第１の計算機システムに備えられ、
    前記第２のサーバが、前記第２の計算機システムに備えられ、
    順序付けフェーズ、コミットフェーズ及び検証フェーズがあり、
    トランザクション要求毎に、
    前記順序付けフェーズにおいて、
    前記クライアントが、当該トランザクション要求を前記第２のサーバに送信し、
    前記第２のサーバが、前記クライアントからの当該トランザクション要求をstrict serializableな半順序に順序付けし、
    前記コミットフェーズにおいて、
    前記クライアントが、当該トランザクション要求を前記第１のサーバに送信し、
    前記第１のサーバが、前記クライアントからの当該トランザクション要求に従うトランザクションを、前記順序付けフェーズにおいて決定された半順序で実行し、当該トランザクション要求の第１の応答を前記クライアントに返し、
    前記検証フェーズにおいて、
    前記第２のサーバが、前記クライアントからのトランザクション要求に従うトランザクションを前記順序付けフェーズにおいて決定された半順序で実行し、当該トランザクション要求の第２の応答を前記クライアントに返し、
    前記クライアントが、前記第２の応答と前記第１の応答との比較の結果を基に、ビザンチン故障を検知する、
    データ管理システム。
  2. 前記順序付けフェーズにおいて、
    前記第２のサーバが、前記クライアントからのトランザクション要求に従うトランザクションを仮実行することで当該トランザクションの競合の有無を判定し、競合が無いことが判定された場合に所定の応答を前記クライアントに返し、
    前記コミットフェーズにおいて、
    前記所定の応答を受信したクライアントが、前記トランザクション要求を前記第１のサーバに送信し、
    前記第１のサーバが、前記クライアントからのトランザクション要求に従うトランザクションを実行し、当該トランザクションにおいてリード及び／又はライトされた一つ以上の第１のオブジェクトの各々について第１のプルーフを作成し、当該トランザクションの実行結果である第１の結果と、当該作成された一つ以上の第１のプルーフとを有する第１の応答を前記クライアントに返し、
    前記検証フェーズにおいて、
    前記第２のサーバが、当該トランザクション要求に従うトランザクションを実行し、当該トランザクションにおいてリード及び／又はライトされた一つ以上の第２のオブジェクトの各々について第２のプルーフを作成し、当該トランザクションの実行結果である第２の結果と、当該作成された一つ以上の第２のプルーフとを有する第２の応答を前記クライアントに返し、
    前記クライアントが、前記第１の応答が有する一つ以上の第１のプルーフと、前記第２の応答が有する一つ以上の第２のプルーフとが一致するか否かの判定と、前記第１の応答が有する第１の結果と、前記第２の応答が有する第２の結果とが一致するか否かの判定とを行い、いずれかの判定の結果が偽の場合にビザンチン故障を検知する、
    請求項１に記載のデータ管理システム。
  3. 前記順序付けフェーズにおいて、前記第２のサーバが、前記受信したトランザクション要求に従うトランザクションを仮実行することで、リード又はライトされる一つ以上の第２のオブジェクトを特定し、当該特定された一つ以上の第２のオブジェクトの各々についてロックを取得できた場合に、前記所定の応答を返し、
    前記検証フェーズにおいて、前記第２のサーバが、前記トランザクション要求に従うトランザクションを実行した場合に、当該トランザクション要求について前記順序付けフェーズにおいて取得した全てのロックを解放する、
    請求項２に記載のデータ管理システム。
  4. 第２のオブジェクトがロックされてから一定時間経過しても当該第２のオブジェクトがロックされたままの場合、
    前記第２のサーバが、当該ロックを取得しているトランザクションを特定し、特定されたトランザクションのＩＤを指定した所定の要求を前記第１のサーバに送信し、
    前記第１のサーバが、前記所定の要求を受信し、当該要求で指定されているＩＤに対応のトランザクションについてのステータスを表す応答を返し、
    前記第２のサーバが、当該応答を受信し、当該応答が表すステータスがアボート済の場合、当該第２のオブジェクトのロックを解放する、
    請求項３に記載のデータ管理システム。
  5. 前記受信した応答が表すステータスがコミット済であり、取得されているロックのタイプがリードロックの場合、前記第２のサーバが、当該第２のオブジェクトのロックを解放する、
    請求項４に記載のデータ管理システム。
  6. 前記受信した応答が表すステータスがコミット済であり、取得されているロックのタイプがライトロックの場合、
    前記第２のサーバが、当該第２のオブジェクトのオブジェクトＩＤと、当該ロックが取得されたときの当該第２のオブジェクトのバージョンとを特定し、当該特定されたオブジェクトＩＤと、当該特定されたバージョンの次のバージョンとを指定したプルーフ要求を、前記第１のサーバに送信し、
    前記第１のサーバが、当該プルーフ要求を受信し、当該プルーフ要求で指定されているオブジェクトＩＤ及びバージョンの第１のオブジェクトを特定し、当該特定された第１のオブジェクトの第１のプルーフを作成し、当該第１のプルーフを返し、
    当該第１のプルーフは、当該第１のオブジェクトのオブジェクトＩＤ及びバージョンと、当該第１のオブジェクトの作成に使用された全ての第１のオブジェクトのオブジェクトＩＤ及びバージョンの集合である第１のインプットとを含み、
    前記第２のサーバが、当該第１のプルーフを受信し、当該第１のプルーフを用いて、当該ロックが取得されたときの第２のオブジェクトの次バージョンの第２のオブジェクトを作成し、当該作成された次バージョンの第２のオブジェクトを前記第２のオブジェクト群セットにライトし、当該ロックを解放する、
    請求項４に記載のデータ管理システム。
  7. 前記第２のサーバが、
    前記受信した第１のプルーフが表すバージョンと、当該ロックが取得されたときの第２のオブジェクトのバージョンとの比較を含む検証である順序付け検証を行い、
    当該検証においてエラーが検知されない場合に、前記次バージョンの第２のオブジェクトを作成及びライトと、当該ロックの解放とを行う、
    請求項６に記載のデータ管理システム。
  8. 前記受信した応答が表すステータスがアボート済及びコミット済のいずれでもない場合、前記第２のサーバは、
    当該ロックを解放せず、
    当該ロックが取得されている第２のオブジェクトを別のトランザクションがリード又はライトする場合に、前記所定の要求を前記第１のサーバに送信する、
    請求項４に記載のデータ管理システム。
  9. 前記検証フェーズにおいて、前記第２のサーバが、前記クライアントから前記一つ以上の第１のプルーフを受信し、当該一つ以上の第１のプルーフについて順序付け検証を行い、
    第１のプルーフは、当該第１のプルーフに対応の第１のオブジェクトのオブジェクトＩＤ及びバージョンと、当該第１のオブジェクトの作成に使用された全ての第１のオブジェクトのオブジェクトＩＤ及びバージョンの集合である第１のインプットとを含み、
    前記順序付け検証において、第１のプルーフにおけるオブジェクトＩＤと同じオブジェクトＩＤの第２のオブジェクトについて取得されているロックのタイプがライトロックであり、且つ、当該ロックが取得されたときの第２のオブジェクトの次バージョンと、当該第１のプルーフが表すバージョンとが同じである場合、前記第２のサーバが、
    当該ロックが取得されたオブジェクトＩＤについて次バージョンのレコードを生成するためにリードされた全ての第２のオブジェクトのオブジェクトＩＤ及びバージョンの集合である第２のインプットと、前記受信した第１のプルーフにおける第１のインプットとが一致しているか否かを判定し、
    当該判定の結果が偽である場合、ビザンチン故障を意味するビザンチン故障エラーを前記クライアントに返す、
    請求項２に記載のデータ管理システム。
  10. 前記順序付け検証において、前記第２のサーバは、前記一つ以上の第１のプルーフのいずれについてもエラーが検知されなかった場合、前記トランザクション要求に従うトランザクションを実行する、
    請求項９に記載のデータ管理システム。
  11. 前記順序付け検証において下記のいずれかの場合に、前記第２のサーバは、ビザンチン故障の可能性があることを意味するエラーである検証エラーを前記クライアントに返す、
    ・第１のプルーフにおけるオブジェクトＩＤと同じオブジェクトＩＤの第２のオブジェクトについて取得されているロックのタイプがリードロックであり、且つ、当該ロックが取得されたときの第２のオブジェクトのバージョンと、当該第１のプルーフが表すバージョンとが異なっている、
    ・第１のプルーフにおけるオブジェクトＩＤと同じオブジェクトＩＤの第２のオブジェクトについて取得されているロックのタイプがライトロックであり、且つ、当該ロックが取得されたときの第２のオブジェクトの次バージョンと、当該第１のプルーフが表すバージョンとが異なっている、
    請求項９に記載のデータ管理システム。
  12. 前記順序付けフェーズにおいて、
    前記第２のサーバは、前記クライアントからのトランザクション要求にクライアントの正しい認証用データがあるかを検証し、
    前記第２のサーバは、前記第２のサーバの認証用データを前記クライアントに返し、
    前記コミットフェーズにおいて、
    前記第１のサーバは、前記クライアントからのトランザクション要求に、クライアント及び第２のサーバのそれぞれの正しい認証用データがあるかを検証し、
    前記第１のサーバは、前記一つ以上の第１のプルーフの各々に、前記第１のサーバの認証用データを含め、
    前記検証フェーズにおいて、
    前記第２のサーバは、前記クライアントからの一つ以上の第１のプルーフの各々に第１のサーバの正しい認証用データがあるかを検証し、
    前記第１及び第２のサーバのいずれも、認証用データの検証においてエラーが検知された場合、認証エラーを前記クライアントに返し、
    前記順序付けフェーズ又は前記コミットフェーズにおける認証エラーは、ビザンチン故障であるが第１及び第２のオブジェクト群セットには相違が生じないエラーであり、
    前記検証フェーズにおける認証エラーは、ビザンチン故障であり第１及び第２のオブジェクト群セットに相違が生じているエラーである、
    請求項２に記載のデータ管理システム。
  13. 第１及び第２の計算機システムから構成されるデータ管理システムにより行われる方法であって、
    対象の状態を表すオブジェクトをリード及び／又はライトするトランザクションの要求であるトランザクション要求毎に、
    順序付けフェーズにおいて、
    クライアントが、当該トランザクション要求を第２のサーバに送信し、
    前記第２のサーバが、前記クライアントからの当該トランザクション要求をstrict serializableな半順序に順序付けし、
    コミットフェーズにおいて、
    前記クライアントが、当該トランザクション要求を第１のサーバに送信し、
    前記第１のサーバが、前記クライアントからの当該トランザクション要求に従うトランザクションを、前記順序付けフェーズにおいて決定された半順序で実行し、当該トランザクション要求の第１の応答を前記クライアントに返し、
    検証フェーズにおいて、
    前記第２のサーバが、前記クライアントからのトランザクション要求に従うトランザクションを前記順序付けフェーズにおいて決定された半順序で実行し、当該トランザクション要求の第２の応答を前記クライアントに返し、
    前記クライアントが、前記第２の応答と前記第１の応答との比較の結果を基に、ビザンチン故障を検知し、
    前記第１のサーバが、前記第１の計算機システムに備えられており、
    前記第２のサーバが、前記第２の計算機システムに備えられており、
    前記第１及び第２のサーバは、同一のトランザクション要求について同じ決定的関数を実行するようになっており、
    前記第１の計算機システムが、第１のオブジェクト群セットを管理し、当該第１のオブジェクト群セットは、対象毎の第１のオブジェクト群であり、第１のオブジェクト群は、一つ以上の第１のオブジェクトであり、第１のオブジェクトは、対象の状態を表し、
    前記第２の計算機システムが、第２のオブジェクト群セットを管理し、当該第２のオブジェクト群セットは、対象毎の第２のオブジェクト群であり、第２のオブジェクト群は、一つ以上の第２のオブジェクトであり、第２のオブジェクトは、対象の状態を表す、
    データ管理方法。
JP2022531632A 2021-05-24 2022-05-24 ビザンチン故障を検知するデータ管理システム及び方法 Active JP7152828B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2022151926A JP2022180556A (ja) 2021-05-24 2022-09-22 ビザンチン故障を検知するデータ管理システム及び方法

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202163192211P 2021-05-24 2021-05-24
US63/192,211 2021-05-24
US202263327586P 2022-04-05 2022-04-05
US63/327,586 2022-04-05
PCT/JP2022/021235 WO2022250047A1 (ja) 2021-05-24 2022-05-24 ビザンチン故障を検知するデータ管理システム及び方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2022151926A Division JP2022180556A (ja) 2021-05-24 2022-09-22 ビザンチン故障を検知するデータ管理システム及び方法

Publications (2)

Publication Number Publication Date
JP7152828B1 true JP7152828B1 (ja) 2022-10-13
JPWO2022250047A1 JPWO2022250047A1 (ja) 2022-12-01

Family

ID=83598287

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2022531632A Active JP7152828B1 (ja) 2021-05-24 2022-05-24 ビザンチン故障を検知するデータ管理システム及び方法
JP2022151926A Pending JP2022180556A (ja) 2021-05-24 2022-09-22 ビザンチン故障を検知するデータ管理システム及び方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2022151926A Pending JP2022180556A (ja) 2021-05-24 2022-09-22 ビザンチン故障を検知するデータ管理システム及び方法

Country Status (2)

Country Link
EP (1) EP4350518A1 (ja)
JP (2) JP7152828B1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019233773A1 (en) * 2018-06-07 2019-12-12 International Business Machines Corporation Efficient validation for blockchain
JP2020522778A (ja) * 2019-03-18 2020-07-30 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ビュー変更プロトコルを終了するためのシステムおよび方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019233773A1 (en) * 2018-06-07 2019-12-12 International Business Machines Corporation Efficient validation for blockchain
JP2021525931A (ja) * 2018-06-07 2021-09-27 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ ブロックチェーンのための効率的な検証
JP2020522778A (ja) * 2019-03-18 2020-07-30 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ビュー変更プロトコルを終了するためのシステムおよび方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
YAMADA Hiroyuki, NEMOTO Jun，Scalar DL: Scalable and Practical Byzantine Fault Detection for Transactional Database Systems，Proceedings of the VLDB Endowment [online]，2022年05月30日，Vol.15, No.7，pp.1324-1336，[2022年7月13日検索], インターネット<URL : https://dl.acm.org/doi/abs/10.14778/3523210.3523212>
YAMADA HIROYUKI, NEMOTO JUN: "Scalar DL: Scalable and Practical Byzantine Fault Detection for Transactional Database Systems", PROCEEDINGS OF THE VLDB ENDOWMENT [ONLINE], vol. 15, no. 7, JPN7022003356, March 2022 (2022-03-01), pages 1324 - 1336, ISSN: 0004828445 *

Also Published As

Publication number Publication date
EP4350518A1 (en) 2024-04-10
JPWO2022250047A1 (ja) 2022-12-01
JP2022180556A (ja) 2022-12-06

Similar Documents

Publication Publication Date Title
Nathan et al. Blockchain meets database: Design and implementation of a blockchain relational database
US11860900B2 (en) Log-based distributed transaction management
US10185632B2 (en) Data synchronization with minimal table lock duration in asynchronous table replication
TWI507899B (zh) 資料庫管理系統及方法
Sovran et al. Transactional storage for geo-replicated systems
US10296371B2 (en) Passive two-phase commit system for high-performance distributed transaction execution
US10157108B2 (en) Multi-way, zero-copy, passive transaction log collection in distributed transaction systems
US11768885B2 (en) Systems and methods for managing transactional operation
JP2017532677A (ja) マルチテナントアプリケーションサーバ環境におけるトランザクション回復のためのシステムおよび方法
US10318475B2 (en) System and method for persistence of application data using replication over remote direct memory access
US11627122B2 (en) Inter-system linking method and node
JP2016517605A (ja) ビザンチン故障耐性データ複製を行う方法およびシステム
US20220123991A1 (en) System with tamper-evidence
CN113168371A (zh) 多主共享存储数据库的写-写冲突检测
JP6618138B1 (ja) 改ざん検知性を有するデータ管理システム
JP7152828B1 (ja) ビザンチン故障を検知するデータ管理システム及び方法
WO2022250047A1 (ja) ビザンチン故障を検知するデータ管理システム及び方法
CN117337431A (zh) 探测拜占庭故障的数据管理系统以及方法
CN114846458A (zh) 分布式可串行化并发控制方案
US20220121643A1 (en) System with tamper-evidence
US20230069165A1 (en) Byzantine fault tolerant pre-preprocessing for state machine replication
WO2020152893A1 (ja) 改ざん検知性を有するデータ管理システム
EP3916573A1 (en) System having tampering detection property

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220527

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20220527

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220719

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220922

R150 Certificate of patent or registration of utility model

Ref document number: 7152828

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150