JP2016071526A - 分散データベースシステムおよびレプリケーション方法 - Google Patents

分散データベースシステムおよびレプリケーション方法 Download PDF

Info

Publication number
JP2016071526A
JP2016071526A JP2014198805A JP2014198805A JP2016071526A JP 2016071526 A JP2016071526 A JP 2016071526A JP 2014198805 A JP2014198805 A JP 2014198805A JP 2014198805 A JP2014198805 A JP 2014198805A JP 2016071526 A JP2016071526 A JP 2016071526A
Authority
JP
Japan
Prior art keywords
transaction
prepare
slave
commit
request
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.)
Pending
Application number
JP2014198805A
Other languages
English (en)
Inventor
基樹 関根
Motoki Sekine
基樹 関根
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 Solution Innovators Ltd
Original Assignee
NEC Solution Innovators 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 NEC Solution Innovators Ltd filed Critical NEC Solution Innovators Ltd
Priority to JP2014198805A priority Critical patent/JP2016071526A/ja
Publication of JP2016071526A publication Critical patent/JP2016071526A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

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

Abstract

【課題】各データベース間の整合性を保ちつつ、レプリケーションに要する処理時間を短くすることができる分散データベースシステムを提供する。
【解決手段】マスタDB80のプリペア要求手段81は、トランザクションのコミット指示がなされたときに、そのトランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDB90に対して、プリペア処理を指示するプリペア要求を行う。コミット手段82は、同一のトランザクションについてのプリペア要求に対して全てのスレーブDB90から送信される処理結果が全て成功の場合、その全てのスレーブDB90に対してトランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについてそのトランザクションのコミット処理を行う。
【選択図】図14

Description

本発明は、分散データベースシステム、マスタDB、レプリケーション方法、更新情報反映方法およびマスタDBプログラムに関する。
分散データベースシステムでは、トランザクションの整合性を保つため、一般的に2相(2フェーズ)コミットと呼ばれる分散アルゴリズムが用いられる。2相コミットでは、調整者と呼ばれるデータベース(以下、単にDBと記す。)が、参加者と呼ばれるDB全てを調整する。
2相コミットは、調整者が全ての参加者の調整を行うプリペア要求相と、調整者の決定により全ての参加者のトランザクションを完了させるコミット要求相により実現される。ここでプリペアとは、トランザクションをコミットまたはロールバックできる状態まで処理を進めることを意味する。具体的には、調整者が、参加者に更新ログ情報を送信することで、参加者の調整を行う。
図16は、2相コミットを用いた一般的な分散データベースシステムを示す説明図である。まず、クライアント50は、分散データベースシステム60に対して、コミット要求を行う(ステップS81)。分散データベースシステム60では、調整者61が各参加者62に対してプリペア要求を行う(ステップS82)。そして、調整者61は、参加者62からの応答を待って参加者にコミット要求を行う(ステップS83)。処理が完了すると、分散データベースシステム60は、クライアント50に対してコミット結果を応答する(ステップS84)。
図17は、2相コミットの一般的な処理を示すシーケンス図である。プリペア要求相において、調整者61は、各参加者62に対してプリペア要求を行う(ステップS91)。各参加者62は、要求に応じてプリペア処理を行い(ステップS92)、処理結果を調整者61に応答する(ステップS93)。
次に、コミット要求相において、調整者61は、各参加者に対してトランザクションのコミットまたはロールバック要求を行う(ステップS94)。参加者62は、要求に応じてコミットまたはロールバック処理を行い(ステップS95)、処理結果を調整者61に応答する(ステップS96)。
なお、特許文献1には、コミット処理の同期制御を効率的に行うことができるデータベース同期制御方式が記載されている。特許文献1に記載された方式では、更新サーバ数の数に応じて2フェーズ処理を行うかどうかが判断される。
特開平4−84238号公報
図17の破線枠で示すように、2相コミットにおいて、調整者は、全ての参加者からプリペア処理の応答メッセージを受信した後、参加者にコミットまたはロールバック要求メッセージを再度送信し、応答を受信するまで待ち合わせる。すなわち、2相コミットでは、調整者と参加者との間で、プリペア要求とコミット要求の2回の要求について送受信が行われるため、処理時間が長くなってしまうという問題がある。
また、特許文献1に記載された方式でも、更新サーバ数が2以上の場合には、全てのサーバに対してプリペア要求およびコミット要求が行われる。そのため、更新サーバ数が2以上の場合であっても、処理を効率化してレプリケーションに要する処理時間を短くできることが好ましい。
そこで、本発明は、各データベース間の整合性を保ちつつ、レプリケーションに要する処理時間を短くすることができる分散データベースシステム、マスタDB、レプリケーション方法、更新情報反映方法およびマスタDBプログラムを提供することを目的とする。
本発明による分散データベースシステムは、複数のスレーブDBと、更新情報を複数のスレーブDBに反映させるマスタDBとを備え、マスタDBが、トランザクションのコミット指示がなされたときに、そのトランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、プリペア処理を指示するプリペア要求を行うプリペア要求手段と、同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、その全てのスレーブDBに対してトランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについてそのトランザクションのコミット処理を行うコミット手段とを含み、スレーブDBが、マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合にそのトランザクションのコミット処理を行うとともに、自身のDBに対してプリペア処理を行い、そのプリペア処理の処理結果をマスタDBに送信するプリペア手段を含むことを特徴とする。
本発明によるマスタDBは、更新情報を複数のスレーブDBに反映させるマスタDBであって、トランザクションのコミット指示がなされたときに、そのトランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、プリペア処理を指示するプリペア要求を行うプリペア要求手段と、同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、その全てのスレーブDBに対してトランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについてそのトランザクションのコミット処理を行うコミット手段とを備え、プリペア要求手段が、マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合にそのトランザクションのコミット処理を行うとともに自身のDBに対してプリペア処理を行い、そのプリペア処理の処理結果をマスタDBに送信するスレーブDBに対して、プリペア要求を行うことを特徴とする。
本発明によるレプリケーション方法は、1つのマスタDBと複数のスレーブDBを含む分散データベースシステムにおいて、マスタDBで更新した更新情報を複数のスレーブDBに反映させるレプリケーション方法であって、マスタDBは、トランザクションのコミット指示がなされたときに、そのトランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行い、マスタDBが、全てのスレーブDBに対して、プリペア処理を指示するプリペア要求を行い、スレーブDBが、プリペア要求に応じて、自身のDBに対してプリペア処理を行い、そのプリペア処理の処理結果をマスタDBに送信し、マスタDBは、同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、その全てのスレーブDBに対してトランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについてそのトランザクションのコミット処理を行い、スレーブDBは、プリペア要求を受信したときにプリペア状態のトランザクションが存在した場合、そのトランザクションのコミット処理を行うことを特徴とする。
本発明による更新情報反映方法は、更新情報を複数のスレーブDBに反映させるマスタDBの更新情報反映方法であって、トランザクションのコミット指示がなされたときに、そのトランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、プリペア処理を指示するプリペア要求を行い、同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、その全てのスレーブDBに対してトランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについてそのトランザクションのコミット処理を行い、プリペア要求では、プリペア要求を、マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合にそのトランザクションのコミット処理を行うとともに自身のDBに対してプリペア処理を行い、そのプリペア処理の処理結果をマスタDBに送信するスレーブDBに対して行うことを特徴とする。
本発明によるマスタDBプログラムは、更新情報を複数のスレーブDBに反映させるマスタDBを含むコンピュータに適用されるマスタDBプログラムであって、コンピュータに、トランザクションのコミット指示がなされたときに、そのトランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、プリペア処理を指示するプリペア要求を行うプリペア要求処理、および、同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、その全てのスレーブDBに対してトランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについてそのトランザクションのコミット処理を行うコミット処理を実行させ、プリペア要求処理で、マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合にそのトランザクションのコミット処理を行うとともに自身のDBに対してプリペア処理を行い、そのプリペア処理の処理結果をマスタDBに送信するスレーブDBに対して、プリペア要求を行わせることを特徴とする。
本発明によれば、各データベース間の整合性を保ちつつ、レプリケーションに要する処理時間を短くすることができる。
本発明による分散データベースシステムの第1の実施形態の構成例を示すブロック図である。 第1の実施形態の分散データベースシステムの動作例を示すシーケンス図である。 スレーブDBでプリペア処理が失敗したときの動作例を示すシーケンス図である。 スレーブDBでプリペア処理が失敗したときの他の動作例を示すシーケンス図である。 プリペア処理が成功した場合の動作例を示す説明図である。 マスタDBでプリペア処理が失敗した時の動作例を示す説明図である。 スレーブDBでプリペア処理が失敗したときの動作例を示す説明図である。 スレーブDBでプリペア処理が失敗したときの他の動作例を示す説明図である。 第2の実施形態の分散データベースシステムの動作例を示すシーケンス図である。 マスタDBに障害が発生した場合の動作例を示す説明図である。 マスタDBに障害が発生した場合の他の動作例を示す説明図である。 マスタDBに障害が発生した場合の更に他の動作例を示す説明図である。 マスタDBに障害が発生した場合の更に他の動作例を示す説明図である。 本発明による分散データベースシステムの概要を示すブロック図である。 本発明によるマスタDBの概要を示すブロック図である。 2相コミットを用いた一般的な分散データベースシステムを示す説明図である。 2相コミットの一般的な処理を示す説明図である。
以下、本発明の実施形態を図面を参照して説明する。
本実施形態では、1つのマスタデータベース(以下、マスタDBと記す。)と複数のスレーブデータベース(以下、スレーブDBと記す。)を含む分散データベースシステムを想定する。本実施形態の分散データベースシステムでは、マスタDBで更新した更新情報(ログ)を他の全スレーブDBに反映させるレプリケーションを行う。
また、本実施形態で用いられるDBは、メモリデータベースを想定する。トランザクションをコミットまたはロールバックできる状態(以下、プリペア状態と記す。)にする処理(すなわち、プリペア処理)では、共有メモリのリソースが確保される。共有メモリのリソース確保が成功すれば、コミット処理で新たなリソースを追加することがない。また、コミット処理でディスクにログを出力することもないため、コミット処理が失敗することがない。したがって、本実施形態の分散データベースシステムは、プリペア処理が成功したならば、コミット処理が成功するとみなせるものである。
本実施形態の分散データベースシステムは、複数のデータベースを含む。複数のデータベースのうち、マスタとして動作するマスタDBが1つ決定され、残りのDBはスレーブDBとして動作する。以下の説明では、便宜上マスタDBとスレーブDBとを分けて説明するが、マスタDBとスレーブDBの構成は同一であってもよく、異なっていてもよい。
実施形態1.
図1は、本発明による分散データベースシステムの第1の実施形態の構成例を示すブロック図である。図1に例示する分散データベースシステム100は、マスタDB10と、2台のスレーブDB20(具体的には、スレーブDB20aおよびスレーブDB20b)とを備えている。
分散データベースシステム100は、クライアント30に接続され、クライアント30からのトランザクションを受け付ける。そして、クライアントからトランザクションのコミット指示がなされると、マスタDB10からスレーブDB20へのレプリケーションが行われる。
以下の説明では、スレーブDBに共通する機能を説明する場合、その主体をスレーブDB20と記し、各スレーブDBを区別して説明する場合、その主体をそれぞれスレーブDB20a、スレーブDB20bと記す。また、図1では、分散データベースシステムがスレーブDB20を2つ備えている場合を例示しているが、スレーブDB20の数は2台に限定されず、3台以上であってもよい。
マスタDB10は、各種制御を行うトランザクション制御部11と、記憶部12とを含む。また、各スレーブDB20も、各種制御を行うトランザクション制御部21と、記憶部22とを含む。
なお、以下の説明では、マスタDB10に含まれる記憶部12のことをマスタDBと記すこともある。また、スレーブDB20aおよびスレーブDB20bに含まれる記憶部22のことを、それぞれスレーブDB1およびスレーブDB2と記すこともある。
マスタDB10のトランザクション制御部11は、クライアント30からトランザクションのコミット指示がなされると、自身のDBに対してプリペア処理を行うとともに、全てのスレーブDB20に対して、プリペア処理の要求(以下、プリペア要求と記す。)を行う。
また、トランザクション制御部11は、同一のトランザクションについてのプリペア要求に対する処理結果を、全てのスレーブDB20から受信する。処理結果が全て成功の場合、トランザクション制御部11は、自身のDBについて上記トランザクションのコミット処理を行う。ただし、トランザクション制御部11は、スレーブDB20に対して、上記トランザクションのコミット処理の要求(以下、コミット要求と記す。)は行わない。
したがって、この処理により、マスタDBは、トランザクションのコミットが行われている一方、スレーブDB1およびスレーブDB2は、トランザクションのコミットまたはロールバックが可能な状態(すなわち、プリペア状態)になっている。
一方、同一のトランザクションについてのプリペア要求に対してスレーブDB20から送信される処理結果の少なくとも一部が失敗である場合、トランザクション制御部11は、全てのスレーブDB20に対してトランザクションのロールバック処理の要求(以下、ロールバック要求と記す。)を行う。さらに、トランザクション制御部11は、自身のDBのロールバック処理を行う。
スレーブDB20のトランザクション制御部21は、マスタDB10からのプリペア要求に応じて、自身のDBに対してプリペア処理を行う。そして、トランザクション制御部21は、そのプリペア処理の処理結果(具体的には、プリペア処理が成功したか失敗したか)をマスタDB10に送信する。
さらに、トランザクション制御部21は、プリペア要求を受信したときにプリペア状態のトランザクションが存在した場合には、そのトランザクションのコミット処理を行う。すなわち、トランザクション制御部21は、プリペア状態のトランザクションに対するコミット要求ではなく、他のトランザクションについてのプリペア要求を受信したときに、プリペア状態のトランザクションのコミット処理を行う。
本実施形態の分散データベースシステム100は、プリペア処理が成功すればコミット処理が失敗する可能性がないことを前提としている。そこで、マスタDB10は、スレーブDB20のプリペア処理が成功した段階でコミットされたものと扱い、コミット要求をスレーブDB20に送信しない。
このようにすることで、マスタDB10がスレーブDB20に行うコミット要求に要する処理時間およびスレーブDB20の応答を待つ時間を削減でき、コミット処理に要する処理時間を短縮できるため、レプリケーションに要する処理時間を短くすることができる。言い換えると、本実施形態の分散データベースシステムは、マスタDB10がスレーブDB20に対して明示的なコミット要求を行っていないため、実質的に1相コミットを実現していると言える。
トランザクション制御部11は、プログラム(マスタDBプログラム)に従って動作するコンピュータのCPUによって実現される。例えば、プログラムは、マスタDB10が備える記憶部12に記憶され、CPUは、そのプログラムを読み込み、プログラムに従って、トランザクション制御部11として動作してもよい。記憶部12は、例えば、磁気ディスク等により実現される。
また、本実施形態では、トランザクション制御部11と記憶部12の両方が、マスタDB10に含まれている場合を例示しているが、それぞれが専用のハードウェアで実現されていてもよい。
同様に、トランザクション制御部21は、プログラム(スレーブDBプログラム)に従って動作するコンピュータのCPUによって実現される。例えば、プログラムは、スレーブDB20が備える記憶部22に記憶され、CPUは、そのプログラムを読み込み、プログラムに従って、トランザクション制御部21として動作してもよい。記憶部22は、例えば、磁気ディスク等により実現される。
また、本実施形態では、トランザクション制御部21と記憶部22の両方が、スレーブDB20に含まれている場合を例示しているが、それぞれが専用のハードウェアで実現されていてもよい。
次に、本実施形態の分散データベースシステムの動作を説明する。図2は、本実施形態の分散データベースシステムの動作例を示すシーケンス図である。本動作例では、クライアントから、2種類のトランザクション(トランザクションAおよびトランザクションB)のコミット指示が同期的に行われるものとする。
まず、クライアント30からマスタDB10に対してトランザクションAのコミット指示がなされると、マスタDB10のトランザクション制御部11は、自身のDBに対してトランザクションAのプリペア処理を行う(ステップS11)。さらに、トランザクション制御部11は、全てのスレーブDB20に対してトランザクションAのプリペア要求を行う(ステップS12)。
スレーブDB20がマスタDB10からプリペア要求を受信すると、スレーブDB20のトランザクション制御部21は、プリペア状態のトランザクションが存在するか否か判断する(ステップS13)。プリペア状態のトランザクションが存在する場合(ステップS13におけるYes)、トランザクション制御部21は、トランザクションのコミット処理を行う(ステップS14)。
一方、プリペア状態のトランザクションが存在しない場合(ステップS13におけるNo)、トランザクション制御部21は、以降のプリペア処理を行う。なお、本動作例では、プリペア状態のトランザクションはまだ存在しないため、コミット処理は行われない。
次に、トランザクション制御部21は、マスタDB10からのプリペア要求に応じて、自身のDBに対してトランザクションAのプリペア処理を行う(ステップS15)。そして、トランザクション制御部21は、そのプリペア処理の処理結果をマスタDB10に送信する(ステップS16)。
マスタDB10は、全てのスレーブDB20からトランザクションAのプリペア処理の処理結果を受信するまで待機する。なお、一定時間経過しても処理結果が送信されない場合、マスタDB10は、処理結果が送信されないスレーブDB20を分散データベースシステム内における無効なスレーブとして切り離してもよい。
トランザクション制御部11は、トランザクションAについてのプリペア要求に対する処理結果が全て成功か否か判断する(ステップS17)。処理結果が全て成功の場合(ステップS17におけるYes)、トランザクション制御部11は、自身のDBについてトランザクションAのコミット処理を行う(ステップS18)。
一方、処理結果の少なくとも一部が失敗である場合(ステップS17におけるNo)、トランザクション制御部11は、全てのスレーブDB20に対してトランザクションAのロールバック要求を行う(ステップS19)。また、トランザクション制御部11は、自身のDBのロールバック処理を行う(ステップS20)。なお、本動作例では、全ての処理結果が成功であるものとする。
ここまでで、トランザクションAについての処理は終了する。すなわち、トランザクション制御部11は、スレーブDB20に対して、トランザクションAのコミット要求を行わない。
次に、クライアント30からマスタDB10に対してトランザクションBのコミット指示がなされると、マスタDB10のトランザクション制御部11は、自身のDBに対してトランザクションBのプリペア処理を行う(ステップS21)。さらに、トランザクション制御部11は、全てのスレーブDB20に対してトランザクションBのプリペア要求を行う(ステップS22)。
スレーブDB20がマスタDB10からプリペア要求を受信すると、スレーブDB20のトランザクション制御部21は、プリペア状態のトランザクションが存在するか否か判断する(ステップS23)。プリペア状態のトランザクションが存在する場合(ステップS23におけるYes)、トランザクション制御部21は、トランザクションのコミット処理を行う(ステップS24)。
本動作例では、プリペア状態のトランザクションAが存在する。そのため、トランザクション制御部21は、トランザクションAのコミット処理を行う。一方、プリペア状態のトランザクションが存在しない場合(ステップS23におけるNo)、トランザクション制御部21は、以降のプリペア処理を行う。
次に、トランザクション制御部21は、マスタDB10からのプリペア要求に応じて、自身のDBに対してトランザクションBのプリペア処理を行う(ステップS25)。そして、トランザクション制御部21は、そのプリペア処理の処理結果をマスタDB10に送信する(ステップS26)。マスタDB10は、全てのスレーブDB20からトランザクションBのプリペア処理の処理結果を受信するまで待機する。
トランザクション制御部21は、トランザクションBについてのプリペア要求に対する処理結果が全て成功か否か判断する(ステップS27)。処理結果が全て成功の場合(ステップS27におけるYes)、トランザクション制御部11は、自身のDBについてトランザクションBのコミット処理を行う(ステップS28)。
一方、処理結果の少なくとも一部が失敗である場合(ステップS27におけるNo)、トランザクション制御部11は、全てのスレーブDB20に対してトランザクションBのロールバック要求を行う(ステップS29)。また、トランザクション制御部11は、自身のDBのロールバック処理を行う(ステップS30)。なお、本動作例では、全ての処理結果が成功であるものとする。
ここまでで、トランザクションBについての処理は終了する。トランザクションAの場合と同様に、トランザクション制御部11は、スレーブDB20に対して、トランザクションBのコミット要求を行わない。
次に、スレーブDB20でプリペア処理が失敗した時の動作を説明する。初めに、初回のトランザクションAについてのプリペア要求に対してスレーブDB20の一部でプリペア処理が失敗した時の動作を説明する。図3は、スレーブDB20でプリペア処理が失敗したときの動作例を示すシーケンス図である。
クライアント30からマスタDB10に対してトランザクションAのコミット指示がなされてから、マスタDB10がスレーブDB20にプリペア要求を行い、各スレーブDB20がプリペア状態のトランザクションが存在するか否か判断するまでの処理は、図2に例示するステップS11からステップS14までの処理と同様である。
トランザクション制御部21は、マスタDB10からのプリペア要求に応じて、自身のDBに対してトランザクションAのプリペア処理を行う(ステップS33)。ここで、プリペア処理が失敗した場合、トランザクション制御部21は、プリペア処理が失敗したことを示す処理結果をマスタDB10に送信する(ステップS34)。
トランザクション制御部11は、トランザクションAについてのプリペア要求に対する処理結果が全て成功か否か判断する(ステップS17)。本動作例では、処理結果の少なくとも一部が失敗であるため(ステップS17におけるNo)、トランザクション制御部11は、全てのスレーブDB20に対してトランザクションAのロールバック要求を行う(ステップS19)。
スレーブDB20がロールバック要求を受信すると、トランザクション制御部21は、トランザクションAのロールバック処理を行い(ステップS35)、処理結果をマスタDB10に応答する(ステップS36)。また、トランザクション制御部11は、自身のDBのロールバック処理を行う(ステップS20)。
次に、2回目以降のトランザクションBについてのプリペア要求に対してスレーブDB20の一部でプリペア処理が失敗した時の動作を説明する。図4は、スレーブDB20でプリペア処理が失敗したときの他の動作例を示すシーケンス図である。
クライアント30からマスタDB10に対して初回のトランザクションAのコミット指示がなされてから、マスタDB10でトランザクションAのコミット処理が行われるまでの処理は、図2に例示するステップS11からステップS20までの処理と同様である。
また、クライアント30からマスタDB10に対してトランザクションBのコミット指示がなされてから、スレーブDB20がプリペア状態のトランザクションが存在するか否か判断するまでの処理は、図3に例示するステップS21からステップS23までの処理と同様である。
本動作例ではプリペア状態のトランザクションAが存在するため(ステップS23におけるYes)、トランザクション制御部21は、トランザクションAのコミット処理を行う(ステップS24)。
次に、トランザクション制御部21は、マスタDB10からのプリペア要求に応じて、自身のDBに対してトランザクションBのプリペア処理を行う(ステップS37)。ここで、プリペア処理が失敗した場合、トランザクション制御部21は、プリペア処理が失敗したことを示す処理結果をマスタDB10に送信する(ステップS38)。
トランザクション制御部11は、トランザクションBについてのプリペア要求に対する処理結果が全て成功か否か判断する(ステップS27)。本動作例では、処理結果の少なくとも一部が失敗であるため(ステップS27におけるNo)、トランザクション制御部11は、全てのスレーブDB20に対してトランザクションBのロールバック要求を行う(ステップS29)。
スレーブDB20がロールバック要求を受信すると、トランザクション制御部21は、トランザクションBのロールバック処理を行い(ステップS39)、処理結果をマスタDB10に応答する(ステップS40)。また、トランザクション制御部11は、自身のDBのロールバック処理を行う(ステップS30)。
本動作例のように、スレーブDB20でトランザクションBのプリペア処理が失敗したとしても、トランザクションAのコミット処理は実施される。そのため、本動作例では、結果として、トランザクションAは全てのDBでコミットされ、トランザクションBは全てのDBでロールバックされることになる。したがって、分散データベースシステム全体でデータの整合性を保つことができる。
以下、具体的な動作例を説明する。図5は、分散データベースシステムの具体的な動作例を示す説明図である。図5に示す例は、マスタDBおよびスレーブDBでプリペア処理が成功した場合の例を示す。図5に例示する動作例は、図2に例示する動作例に対応する。
クライアントからマスタDBに対して初回のトランザクションAのコミット指示がなされると、マスタDBは、トランザクションAのプリペア処理を行い、スレーブDB1およびスレーブDB2にトランザクションAのプリペア要求を行う。プリペア要求を受信した各スレーブDBは、トランザクションAのプリペア処理を行い、プリペア処理が成功したことを示す処理結果をマスタDBに送信する。処理結果が全て成功だった場合、マスタDBは、自身のDBについてコミット処理を行い、クライアントに処理結果を通知する。
次に、クライアントからマスタDBに対してトランザクションBのコミット指示がなされると、マスタDBは、トランザクションBのプリペア処理を行い、スレーブDB1およびスレーブDB2にトランザクションBのプリペア要求を行う。プリペア要求を受信した各スレーブDBは、まず、プリペア状態にあるトランザクションAのコミット処理を行う。そして、各スレーブDBは、トランザクションBのプリペア処理を行い、プリペア処理が成功したことを示す処理結果をマスタDBに送信する。処理結果が全て成功だった場合、マスタDBは、自身のDBについてコミット処理を行い、クライアントに処理結果を通知する。
次に、プリペア処理が失敗した時の動作例を説明する。図6は、マスタDBのメモリ枯渇等によりプリペア処理が失敗した時の動作例を示す説明図である。クライアントからマスタDBに対してトランザクションNのコミット指示がなされると、マスタDBは、トランザクションNのプリペア処理を行う。ここで、プリペア処理が失敗した場合、マスタDBは、トランザクションNのロールバック処理を行い、クライアントに処理結果を通知する。
次に、プリペア処理が失敗した時の他の動作例を説明する。図7は、プリペア状態のトランザクションが存在しない状態でスレーブDBのプリペア処理が失敗したときの動作例を示す説明図である。図7に例示する動作例は、図3に例示する動作例に対応する。
クライアントからマスタDBに対して初回のトランザクションAのコミット指示がなされると、マスタDBは、トランザクションAのプリペア処理を行い、スレーブDB1およびスレーブDB2にトランザクションAのプリペア要求を行う。プリペア要求を受信した各スレーブDBは、トランザクションAのプリペア処理を行う。
ここで、例えば、スレーブDB2でメモリ枯渇等によりプリペア処理が失敗したとする。この場合、スレーブDB1はプリペア処理が成功したことを示す処理結果をマスタDBに送信し、スレーブDB2はプリペア処理が失敗したことを示す処理結果をマスタDBに送信する。
この場合、マスタDBは、スレーブDB1およびスレーブDB2にトランザクションAのロールバック要求を行う。各スレーブDBは、トランザクションAのロールバック処理を行い、処理結果をマスタDBに送信する。そして、マスタDBも、トランザクションAのロールバック処理を行う。
次に、プリペア処理が失敗した時のさらに他の動作例を説明する。図8は、プリペア状態のトランザクションが存在する状態でスレーブDBのプリペア処理が失敗したときの動作例を示す説明図である。ここでは、スレーブDB1およびスレーブDB2は、プリペア状態のトランザクションAが存在するものとする。なお、図8に例示する動作例は、図4に例示する動作例に対応する。
この状態で、クライアントからマスタDBに対してトランザクションBのコミット指示がなされると、マスタDBは、トランザクションBのプリペア処理を行い、スレーブDB1およびスレーブDB2にトランザクションBのプリペア要求を行う。プリペア要求を受信した各スレーブDBは、まず、プリペア状態にあるトランザクションAのコミット処理を行う。そして、各スレーブDBは、トランザクションBのプリペア処理を行う。
ここで、例えば、スレーブDB2でメモリ枯渇等によりプリペア処理が失敗したとする。この場合、スレーブDB1はプリペア処理が成功したことを示す処理結果をマスタDBに送信し、スレーブDB2はプリペア処理が失敗したことを示す処理結果をマスタDBに送信する。
この場合、マスタDBは、スレーブDB1およびスレーブDB2にトランザクションBのロールバック要求を行う。各スレーブDBは、トランザクションBのロールバック処理を行い、処理結果をマスタDBに送信する。そして、マスタDBも、トランザクションBのロールバック処理を行う。
このように、いずれの具体例においても、データの整合性を保つことができる。
以上のように、本実施形態では、マスタDB10のトランザクション制御部11が、クライアント30からトランザクションのコミット指示がなされたときに、そのトランザクションのプリペア処理を自身のDBに対して行うとともに、全てのスレーブDB20に対してプリペア要求を行う。スレーブDB20のトランザクション制御部21は、プリペア要求に応じて、自身のDBに対してプリペア処理を行い、そのプリペア処理の処理結果をマスタDB10に送信する。マスタDB10のトランザクション制御部11は、同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、その全てのスレーブDBに対してトランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについてそのトランザクションのコミット処理を行う。一方、スレーブDB20のトランザクション制御部21は、プリペア要求を受信したときにプリペア状態のトランザクションが存在した場合、そのトランザクションのコミット処理を行う。
よって、各データベース間の整合性を保ちつつ、レプリケーションに要する処理時間を短くすることができる。具体的には、スレーブDB20でプリペア処理が失敗した場合でも、システム全体としてコミットまたはロールバックが行われるため、各データベース間の整合性を維持できる。
実施形態2.
次に、本発明による分散データベースシステムの第2の実施形態を説明する。本実施形態では、スレーブDBがマスタDBへの変更指示を受けた場合のトランザクションリカバリ機能を説明する。スレーブDBがマスタDBへの変更指示を受ける場合として、例えば、マスタDBに障害が発生した場合が挙げられる。ただし、変更指示が行われるタイミングは、マスタDBの障害発生時に限定されず、例えば、マスタDBのメンテナンス時などであってもよい。
本実施形態の分散データベースシステムの構成は、第1の実施形態と同様である。マスタDB10に障害が発生した場合に、スレーブDB20がマスタDBへの変更指示を受けると、変更指示を受けたスレーブDB20のトランザクション制御部21は、他のスレーブDBのトランザクションの進行状況を確認する。トランザクションの進行状況とは、各トランザクションがコミット処理まで行われているかプリペア状態にあるか等を示すものである。
トランザクションの進行状況の確認方法は任意である。例えば、各スレーブDB20が進行状況を各DB共通のカウンタ値で管理している場合、トランザクション制御部21は、そのカウンタ値を比較して進行状況を確認してもよい。
トランザクション制御部21は、他のスレーブDBのトランザクションの進行状況に基づいて、他のスレーブDB20に対してトランザクションのロールバック要求またはコミット要求を行う。具体的には、他のスレーブDB20間のトランザクションの進行状況が異なる場合、変更指示を受けたスレーブDB20のトランザクション制御部21は、以下のように動作する。
まず、第一の状況として、いずれかのスレーブDB20でコミット処理が行われているトランザクションが存在するとする。この場合、トランザクション制御部21は、他のスレーブDB20に対してそのトランザクションのコミット要求を行う。また、第二の状況として、コミット処理が行われていないプリペア状態のトランザクションが一部のスレーブDB20にのみ存在するとする。この場合、トランザクション制御部21は、そのプリペア状態のトランザクションを有するスレーブDBに対して、そのトランザクションのロールバック指示を行う。
このように、マスタDBの変更時に、トランザクション制御部21が他のスレーブDBのトランザクションの進行状況に基づいて、他のスレーブDBに対してトランザクションのロールバック要求またはコミット要求を行う。そのため、マスタDBが変更されるような場合であっても、各データベース間の整合性を保つことが可能になる。
次に、本実施形態の分散データベースシステムの動作を説明する。図9は、本実施形態の分散データベースシステムの動作例を示すシーケンス図である。ここでは、変更指示を受けたスレーブDBをスレーブDB20aと記し、その他のスレーブDBをスレーブDBbと記す。
外部コマンド等によりマスタ化要求が行われると、スレーブDB20aのトランザクション制御部21は、残りのスレーブDB20bに対して、トランザクションの進行状況を問い合わせる(ステップS41)。問い合わせを受けた各スレーブDB20bのトランザクション制御部21は、トランザクションの進行状況をスレーブDB20aに送信する(ステップS42)。
スレーブDB20aのトランザクション制御部21は、各スレーブDB20bのトランザクションの進行状況に応じて、各スレーブDB20bに対してコミット要求またはロールバック要求を行う(ステップS43)。
各スレーブDB20bのトランザクション制御部21は、スレーブDB20aからの要求に応じて、プリペア状態のトランザクションのコミット処理またはロールバック処理を行う(ステップS44)。また、スレーブDB20aのトランザクション制御部21も、同様にコミット処理またはロールバック処理を行う(ステップS45)。そして、スレーブDB20aは、マスタDBになるための各処理を行う(ステップS46)。
以下、具体的な動作例を説明する。以下の説明では、スレーブDB1がマスタ化するDBであり、スレーブDB2がその他のスレーブDBであるものとする。
図10は、トランザクションが存在しない状態で障害が発生した場合の動作例を示す説明図である。トランザクションが存在しない状態でマスタDBに障害が発生し、スレーブDB1に対して外部コマンド等によりマスタ化要求が行われたとする。このとき、スレーブDB1は、スレーブDB2にトランザクションの状況を取得するための要求を行い、スレーブDB2は、その要求に対して、トランザクションの状況を返信する。
図10に示す例では、トランザクションが存在せず、何もする必要がないことが分かるため、スレーブDB1は、自身のマスタ化処理を行う。
図11は、マスタDBがコミット処理を行った直後に障害が発生した場合の動作例を示す説明図である。この場合、全てのスレーブDBにはトランザクションBのプリペア要求が行われた状態であるため、全てのスレーブDBで、プリペア状態のトランザクションAのコミット処理と、新たなプリペア要求に対するプリペア処理が行われている。
この状態で、スレーブDB1に対して外部コマンド等によりマスタ化要求が行われたとする。このとき、スレーブDB1は、スレーブDB2にトランザクションの状況を取得するための要求を行い、スレーブDB2は、その要求に対して、トランザクションの状況を返信する
この場合、スレーブDB間でプリペア状態にあるトランザクションの内容が異なっていないことが分かるため、スレーブDB1は、プリペア状態にあるトランザクションBのコミット処理を行い、自身のマスタ化処理を行う。このとき、一度データの整合性を確保するため、スレーブDB1は、スレーブDB2に対してコミット要求を行ってもよい。
図12は、一部のスレーブDBに対してプリペア要求が行われている状態で障害が発生した場合の動作例を示す説明図である。本動作例では、マスタDBが初回のトランザクションAのプリペア処理を行うとともに一部のスレーブDBに対してのみプリペア要求を行った状態で障害が発生したとする。この場合、プリペア要求が行われたスレーブDB1では、トランザクションAのプリペア処理が行われ、プリペア要求が行われていないスレーブDB2では、トランザクションAのプリペア処理は行われていない。
この状態で、スレーブDB1に対して外部コマンド等によりマスタ化要求が行われたとする。このとき、スレーブDB1は、スレーブDB2にトランザクションの状況を取得するための要求を行い、スレーブDB2は、その要求に対して、トランザクションの状況を返信する
この場合、スレーブDB1は、スレーブDB間でプリペア状態にあるトランザクションの内容が異なっていることが分かる。この状況は、上述する第二の状況に相当する。そのため、スレーブDB1は、プリペア状態にあるトランザクションAのロールバック処理を行う。そして、スレーブDB1は、自身のマスタ化処理を行う。
なお、この状態の前提として、クライアントはトランザクションAのコミット指示を行っている。この障害は、分散データベースシステムのコミット処理実行中に起こった障害であるため、クライアントは、トランザクションAがコミットされたかロールバックされたか不明である。そこで、分散データベースシステムではロールバック処理を行うことで、データベースの不整合を防止している。
図13は、一部のスレーブDBに対してプリペア要求が行われている状態で障害が発生した場合の他の動作例を示す説明図である。本動作例では、すでにトランザクションAのプリペア要求が各スレーブDBに対して行われているものとする。また、マスタDBがトランザクションBのプリペア処理を行うとともに一部のスレーブDBに対してのみプリペア要求を行った状態で障害が発生したとする。この場合、プリペア要求が行われたスレーブDB1では、トランザクションAのコミット処理およびトランザクションBのプリペア処理が行われ、プリペア要求が行われていないスレーブDB2では、トランザクションAのコミット処理およびトランザクションBのプリペア処理のいずれも行われていない。
この状態で、スレーブDB1に対して外部コマンド等によりマスタ化要求が行われたとする。このとき、スレーブDB1は、スレーブDB2にトランザクションの状況を取得するための要求を行い、スレーブDB2は、その要求に対して、トランザクションの状況を返信する
この場合、スレーブDB1は、スレーブDB間でコミットされたトランザクションおよびプリペア状態にあるトランザクションの内容が異なっていることが分かる。具体的には、スレーブDB1は、一部のスレーブDBでトランザクションAのコミット処理が行われていることがわかる。この状況は、上述する第一の状況に相当する。そこで、スレーブDB1は、スレーブDB2に対してトランザクションAのコミット要求を行う。
一方、スレーブDB2はトランザクションBのプリペア要求が行われていない。そのため、スレーブDB1でのみトランザクションBのプリペア処理が行われている。この状況は、上述する第二の状況に相当する。そこで、スレーブDB1は、プリペア状態にあるトランザクションBのロールバック処理を行う。そして、スレーブDB1は、自身のマスタ化処理を行う。
なお、この状態の前提として、クライアントはトランザクションAのコミット処理をすでに完了し、トランザクションBのコミット指示を行っている。この障害は、分散データベースシステムのコミット処理実行中に起こった障害であるため、クライアントは、トランザクションBがコミットされたかロールバックされたか不明である。一方、クライアントは、トランザクションAのコミット処理は完了していると判断している。そこで、分散データベースシステムでは、トランザクションAについてはコミット処理を行い、トランザクションBについてはロールバック処理を行うことで、データベースの不整合を防止している。
以上のように、本実施形態では、第1の実施形態の構成に加え、スレーブDB20のトランザクション制御部21が、マスタDBへの変更指示を受けたときに、他のスレーブDBのトランザクションの進行状況に基づいて、他のスレーブDBに対してトランザクションのロールバック要求またはコミット要求を行う。よって、第1の実施形態の効果に加え、各データベース間の整合性をより保つことが可能になる。
次に、本発明の概要を説明する。図14は、本発明による分散データベースシステムの概要を示すブロック図である。本発明による分散データベースシステムは、複数のスレーブDB90(例えば、スレーブDB20)と、更新情報を複数のスレーブDB90に反映させるマスタDB80(例えば、マスタDB10)とを備えている。
マスタDB80は、トランザクションのコミット指示がなされたときに、そのトランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDB90に対して、プリペア処理を指示するプリペア要求を行うプリペア要求手段81(例えば、トランザクション制御部11)と、同一のトランザクションについてのプリペア要求に対して全てのスレーブDB90から送信される処理結果が全て成功の場合、その全てのスレーブDB90に対してトランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについてそのトランザクションのコミット処理を行うコミット手段82(例えば、トランザクション制御部11)とを含む。
スレーブDB90は、マスタDB80からのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合に、そのトランザクションのコミット処理を行うとともに、自身のDBに対してプリペア処理を行い、そのプリペア処理の処理結果をマスタDBに送信するプリペア手段91(例えば、トランザクション制御部21)を含む。
そのような構成により、各データベース間の整合性を保ちつつ、レプリケーションに要する処理時間を短くすることができる。
また、マスタDB80のコミット手段82は、同一のトランザクションについてのプリペア要求に対してスレーブDB90から送信される処理結果の少なくとも一部が失敗である場合、全てのスレーブDB90に対してトランザクションのロールバック処理を指示するロールバック要求を行うとともに自身のDBのロールバック処理を行ってもよい。
また、スレーブDB90のプリペア手段91は、トランザクションのロールバック要求を受信した場合、プリペア状態のトランザクションのロールバック処理を行ってもよい。
また、スレーブDB90のプリペア手段91は、マスタDB80への変更指示を受けたときに、他のスレーブDB90のトランザクションの進行状況に基づいて、その他のスレーブDB90に対してトランザクションのロールバック要求またはコミット要求を行ってもよい。
また、変更指示を受けたスレーブDB90(例えば、スレーブDB20a)のプリペア手段91は、他のスレーブDB間のトランザクションの進行状況が異なる場合、いずれかのスレーブDB90でコミット処理が行われているトランザクションが存在する場合、他のスレーブDB90に対してそのトランザクションのコミット要求を行い、コミット処理が行われていないプリペア状態のトランザクションが一部のスレーブDB90にのみ存在する場合、そのプリペア状態のトランザクションを有するスレーブDB90に対して、そのトランザクションのロールバック指示を行ってもよい。
図15は、本発明によるマスタDBの概要を示すブロック図である。本発明によるマスタDBは、プリペア要求手段81と、コミット手段82とを備えている。なお、マスタDBの内容は、図15に例示するマスタDB80の内容と同様である。
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
(付記1)1つのマスタDBと複数のスレーブDBを含む分散データベースシステムにおいて、前記マスタDBで更新した更新情報を前記複数のスレーブDBに反映させるレプリケーション方法であって、前記マスタDBが、トランザクションのコミット指示がなされたときに、当該トランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行い、前記マスタDBが、全てのスレーブDBに対して、前記プリペア処理を指示するプリペア要求を行い、前記スレーブDBが、前記プリペア要求に応じて、自身のDBに対してプリペア処理を行い、当該プリペア処理の処理結果を前記マスタDBに送信し、前記マスタDBは、同一のトランザクションについてのプリペア要求に対して前記全てのスレーブDBから送信される処理結果が全て成功の場合、当該全てのスレーブDBに対して前記トランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについて当該トランザクションのコミット処理を行い、前記スレーブDBが、前記プリペア要求を受信したときにプリペア状態のトランザクションが存在した場合、当該トランザクションのコミット処理を行うことを特徴とするレプリケーション方法。
(付記2)マスタDBが、同一のトランザクションについてのプリペア要求に対してスレーブDBから送信される処理結果の少なくとも一部が失敗である場合、全てのスレーブDBに対して前記トランザクションのロールバック処理を指示するロールバック要求を行うとともに自身のDBのロールバック処理を行う付記1記載のレプリケーション方法。
(付記3)スレーブDBが、トランザクションのロールバック要求を受信した場合、プリペア状態のトランザクションのロールバック処理を行う付記2記載のレプリケーション方法。
(付記4)スレーブDBが、マスタDBへの変更指示を受けたときに、他のスレーブDBのトランザクションの進行状況に基づいて、当該他のスレーブDBに対してトランザクションのロールバック要求またはコミット要求を行う付記1から付記3のうちのいずれか1項に記載のレプリケーション方法。
(付記5)変更指示を受けたスレーブDBが、他のスレーブDB間のトランザクションの進行状況が異なる場合、いずれかのスレーブDBでコミット処理が行われているトランザクションが存在する場合、他のスレーブDBに対して当該トランザクションのコミット要求を行い、コミット処理が行われていないプリペア状態のトランザクションが一部のスレーブDBにのみ存在する場合、当該プリペア状態のトランザクションを有するスレーブDBに対して、当該トランザクションのロールバック指示を行う付記4記載のレプリケーション方法。
(付記6)更新情報を複数のスレーブDBに反映させるマスタDBの更新情報反映方法であって、トランザクションのコミット指示がなされたときに、当該トランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、前記プリペア処理を指示するプリペア要求を行い、同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、当該全てのスレーブDBに対して前記トランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについて当該トランザクションのコミット処理を行い、前記プリペア要求では、プリペア要求を、マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合に当該トランザクションのコミット処理を行うとともに自身のDBに対してプリペア処理を行い、当該プリペア処理の処理結果をマスタDBに送信するスレーブDBに対して行うことを特徴とする更新情報反映方法。
(付記7)同一のトランザクションについてのプリペア要求に対してスレーブDBから送信される処理結果の少なくとも一部が失敗である場合、全てのスレーブDBに対して前記トランザクションのロールバック処理を指示するロールバック要求を行うとともに自身のDBのロールバック処理を行う付記6記載の更新情報反映方法。
(付記8)更新情報を複数のスレーブDBに反映させるマスタDBを含むコンピュータに適用されるマスタDBプログラムであって、前記コンピュータに、トランザクションのコミット指示がなされたときに、当該トランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、前記プリペア処理を指示するプリペア要求を行うプリペア要求処理、および、同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、当該全てのスレーブDBに対して前記トランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについて当該トランザクションのコミット処理を行うコミット処理を実行させ、前記プリペア要求処理で、マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合に当該トランザクションのコミット処理を行うとともに自身のDBに対してプリペア処理を行い、当該プリペア処理の処理結果をマスタDBに送信するスレーブDBに対して、プリペア要求を行わせるためのマスタDBプログラム。
(付記9)コンピュータに、コミット処理で、同一のトランザクションについてのプリペア要求に対してスレーブDBから送信される処理結果の少なくとも一部が失敗である場合、全てのスレーブDBに対して前記トランザクションのロールバック処理を指示するロールバック要求を行わせるとともに自身のDBのロールバック処理を行わせる付記8記載のマスタDBプログラム。
10 マスタDB
11,21 トランザクション制御部
12,22 記憶部
20,20a,20b スレーブDB
30,50 クライアント
60,100 分散データベースシステム

Claims (10)

  1. 複数のスレーブDBと、
    更新情報を前記複数のスレーブDBに反映させるマスタDBとを備え、
    前記マスタDBは、
    トランザクションのコミット指示がなされたときに、当該トランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、前記プリペア処理を指示するプリペア要求を行うプリペア要求手段と、
    同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、当該全てのスレーブDBに対して前記トランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについて当該トランザクションのコミット処理を行うコミット手段とを含み、
    前記スレーブDBは、
    前記マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合に当該トランザクションのコミット処理を行うとともに、自身のDBに対してプリペア処理を行い、当該プリペア処理の処理結果を前記マスタDBに送信するプリペア手段を含む
    ことを特徴とする分散データベースシステム。
  2. マスタDBのコミット手段は、同一のトランザクションについてのプリペア要求に対してスレーブDBから送信される処理結果の少なくとも一部が失敗である場合、全てのスレーブDBに対して前記トランザクションのロールバック処理を指示するロールバック要求を行うとともに自身のDBのロールバック処理を行う
    請求項1記載の分散データベースシステム。
  3. スレーブDBのプリペア手段は、トランザクションのロールバック要求を受信した場合、プリペア状態のトランザクションのロールバック処理を行う
    請求項2記載の分散データベースシステム。
  4. スレーブDBのプリペア手段は、マスタDBへの変更指示を受けたときに、他のスレーブDBのトランザクションの進行状況に基づいて、当該他のスレーブDBに対してトランザクションのロールバック要求またはコミット要求を行う
    請求項1から請求項3のうちのいずれか1項に記載の分散データベースシステム。
  5. 変更指示を受けたスレーブDBのプリペア手段は、他のスレーブDB間のトランザクションの進行状況が異なる場合、いずれかのスレーブDBでコミット処理が行われているトランザクションが存在する場合、他のスレーブDBに対して当該トランザクションのコミット要求を行い、コミット処理が行われていないプリペア状態のトランザクションが一部のスレーブDBにのみ存在する場合、当該プリペア状態のトランザクションを有するスレーブDBに対して、当該トランザクションのロールバック指示を行う
    請求項4記載の分散データベースシステム。
  6. 更新情報を複数のスレーブDBに反映させるマスタDBであって、
    トランザクションのコミット指示がなされたときに、当該トランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、前記プリペア処理を指示するプリペア要求を行うプリペア要求手段と、
    同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、当該全てのスレーブDBに対して前記トランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについて当該トランザクションのコミット処理を行うコミット手段とを備え、
    前記プリペア要求手段は、マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合に当該トランザクションのコミット処理を行うとともに自身のDBに対してプリペア処理を行い、当該プリペア処理の処理結果をマスタDBに送信するスレーブDBに対して、プリペア要求を行う
    ことを特徴とするマスタDB。
  7. コミット手段は、同一のトランザクションについてのプリペア要求に対してスレーブDBから送信される処理結果の少なくとも一部が失敗である場合、全てのスレーブDBに対して前記トランザクションのロールバック処理を指示するロールバック要求を行うとともに自身のDBのロールバック処理を行う
    請求項6記載のマスタDB。
  8. 1つのマスタDBと複数のスレーブDBを含む分散データベースシステムにおいて、前記マスタDBで更新した更新情報を前記複数のスレーブDBに反映させるレプリケーション方法であって、
    前記マスタDBが、トランザクションのコミット指示がなされたときに、当該トランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行い、
    前記マスタDBが、全てのスレーブDBに対して、前記プリペア処理を指示するプリペア要求を行い、
    前記スレーブDBが、前記プリペア要求に応じて、自身のDBに対してプリペア処理を行い、当該プリペア処理の処理結果を前記マスタDBに送信し、
    前記マスタDBは、同一のトランザクションについてのプリペア要求に対して前記全てのスレーブDBから送信される処理結果が全て成功の場合、当該全てのスレーブDBに対して前記トランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについて当該トランザクションのコミット処理を行い、
    前記スレーブDBが、前記プリペア要求を受信したときにプリペア状態のトランザクションが存在した場合、当該トランザクションのコミット処理を行う
    ことを特徴とするレプリケーション方法。
  9. 更新情報を複数のスレーブDBに反映させるマスタDBの更新情報反映方法であって、
    トランザクションのコミット指示がなされたときに、当該トランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、前記プリペア処理を指示するプリペア要求を行い、
    同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、当該全てのスレーブDBに対して前記トランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについて当該トランザクションのコミット処理を行い、
    前記プリペア要求では、プリペア要求を、マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合に当該トランザクションのコミット処理を行うとともに自身のDBに対してプリペア処理を行い、当該プリペア処理の処理結果をマスタDBに送信するスレーブDBに対して行う
    ことを特徴とする更新情報反映方法。
  10. 更新情報を複数のスレーブDBに反映させるマスタDBを含むコンピュータに適用されるマスタDBプログラムであって、
    前記コンピュータに、
    トランザクションのコミット指示がなされたときに、当該トランザクションをコミットまたはロールバックできるプリペア状態にするプリペア処理を自身のDBに対して行うとともに、全てのスレーブDBに対して、前記プリペア処理を指示するプリペア要求を行うプリペア要求処理、および、
    同一のトランザクションについてのプリペア要求に対して全てのスレーブDBから送信される処理結果が全て成功の場合、当該全てのスレーブDBに対して前記トランザクションのコミット処理を指示するコミット要求を行うことなく自身のDBについて当該トランザクションのコミット処理を行うコミット処理を実行させ、
    前記プリペア要求処理で、マスタDBからのプリペア要求を受信したときに、プリペア状態のトランザクションが存在した場合に当該トランザクションのコミット処理を行うとともに自身のDBに対してプリペア処理を行い、当該プリペア処理の処理結果をマスタDBに送信するスレーブDBに対して、プリペア要求を行わせる
    ためのマスタDBプログラム。
JP2014198805A 2014-09-29 2014-09-29 分散データベースシステムおよびレプリケーション方法 Pending JP2016071526A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014198805A JP2016071526A (ja) 2014-09-29 2014-09-29 分散データベースシステムおよびレプリケーション方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014198805A JP2016071526A (ja) 2014-09-29 2014-09-29 分散データベースシステムおよびレプリケーション方法

Publications (1)

Publication Number Publication Date
JP2016071526A true JP2016071526A (ja) 2016-05-09

Family

ID=55866990

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014198805A Pending JP2016071526A (ja) 2014-09-29 2014-09-29 分散データベースシステムおよびレプリケーション方法

Country Status (1)

Country Link
JP (1) JP2016071526A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7377305B2 (ja) 2022-03-30 2023-11-09 株式会社日立製作所 分散トランザクション制御システム及び分散トランザクション制御方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7377305B2 (ja) 2022-03-30 2023-11-09 株式会社日立製作所 分散トランザクション制御システム及び分散トランザクション制御方法

Similar Documents

Publication Publication Date Title
US9311199B2 (en) Replaying jobs at a secondary location of a service
CN109951331B (zh) 用于发送信息的方法、装置和计算集群
JP5088734B2 (ja) 耐障害性トランザクション処理システム及び処理方法
EP2754284B1 (en) Idempotence for database transactions
US8326800B2 (en) Seamless upgrades in a distributed database system
US8868514B2 (en) Transaction support for distributed data
US20190129976A1 (en) Apparatus for controlling synchronization of metadata on network and method for the same
US8880486B2 (en) Distributed database system utilizing an extended two-phase-commit process
US20120254342A1 (en) Method for Providing Access to Data Items from a Distributed Storage System
US7490115B2 (en) Commitment chains for conflict resolution between disconnected data sharing applications
JP6220851B2 (ja) 2フェーズコミットコールの厳密な順序付けに基づいたトランザクションリカバリをサポートするためのシステムおよび方法
US20160147813A1 (en) Distributed transaction commit protocol
US10242027B2 (en) Three phase commit for a distributed file system
US6823355B1 (en) Synchronous replication of transactions in a distributed system
WO2018068661A1 (zh) 一种基于Paxos协议的分布式一致性系统的在线扩容、在线缩容的方法和装置
US9582314B2 (en) Managing data consistency between loosely coupled components in a distributed computing system
US6823356B1 (en) Method, system and program products for serializing replicated transactions of a distributed computing environment
US20100030826A1 (en) Production-alternate system including production system for processing transactions and alternate system as a backup system of the production system
US20190258646A1 (en) Distributed transactions across multiple consensus groups
US9760529B1 (en) Distributed state manager bootstrapping
US20210034605A1 (en) Transaction processing for a database distributed across availability zones
US6873987B1 (en) Method, system and program products for recovering from failures within a shared nothing distributed computing environment
US6247038B1 (en) Optimized synchronization procedure
US7325046B1 (en) Method, system and program products for managing processing groups of a distributed computing environment
JP2016071526A (ja) 分散データベースシステムおよびレプリケーション方法