JP2014038564A - データベースに対する処理を行うシステム及び方法 - Google Patents
データベースに対する処理を行うシステム及び方法 Download PDFInfo
- Publication number
- JP2014038564A JP2014038564A JP2012181880A JP2012181880A JP2014038564A JP 2014038564 A JP2014038564 A JP 2014038564A JP 2012181880 A JP2012181880 A JP 2012181880A JP 2012181880 A JP2012181880 A JP 2012181880A JP 2014038564 A JP2014038564 A JP 2014038564A
- Authority
- JP
- Japan
- Prior art keywords
- server
- processing
- client
- database
- data
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- 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
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
-
- 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
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
-
- 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
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
-
- 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
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
-
- 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
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1443—Transmit or communication errors
-
- 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
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/80—Database-specific techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/82—Solving problems relating to consistency
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/825—Indexing scheme relating to error detection, to error correction, and to monitoring the problem or solution involving locking
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】クライアントの要求に応じて複数のサーバのうちのあるサーバでデータを処理するトランザクションがコミットされる前にそのサーバに障害が発生した場合であっても、データの整合性を損なうことなく、トランザクションの処理を継続する。
【解決手段】クライアント10では、トランザクションログ記憶部15が、サーバ20に発行したSQL文をトランザクションIDに対応付けて記憶しておく。サーバ20に障害が発生すると、そのトランザクションIDに対応するロック情報は保持された状態で、クライアント10では、SQL処理部14が、トランザクションログ記憶部15にそのトランザクションIDに対応付けて記憶されたSQL文を順に取り出し、同じトランザクションIDで再度SQL文を発行し、サーバ20では、SQL処理部24が、そのトランザクションIDで再度発行されたSQL文を処理する。
【選択図】図6
【解決手段】クライアント10では、トランザクションログ記憶部15が、サーバ20に発行したSQL文をトランザクションIDに対応付けて記憶しておく。サーバ20に障害が発生すると、そのトランザクションIDに対応するロック情報は保持された状態で、クライアント10では、SQL処理部14が、トランザクションログ記憶部15にそのトランザクションIDに対応付けて記憶されたSQL文を順に取り出し、同じトランザクションIDで再度SQL文を発行し、サーバ20では、SQL処理部24が、そのトランザクションIDで再度発行されたSQL文を処理する。
【選択図】図6
Description
本発明は、データベースに対する処理を行うシステム及び方法に関する。特に、本発明は、データベースに対する処理を要求するクライアントと、クライアントによる要求に応じてデータベースに対する処理を行う複数のサーバとを含み、データベースに対する処理を行うシステム、及び、そのようなシステムにおいてデータベースに対する処理を行う方法に関する。
クライアントから複数のサーバの何れかを使用してデータベースにアクセスするデータベースシステムが知られている。かかるデータベースシステムでは、あるサーバに障害が発生しても、他のサーバが稼働し続けるので、データベースの可用性が高まる。
ところが、複数のサーバの何れかにおいてトランザクションがコミットされる前に障害が発生すると、そのトランザクションはロールバックされてしまう。
ところが、複数のサーバの何れかにおいてトランザクションがコミットされる前に障害が発生すると、そのトランザクションはロールバックされてしまう。
このように、コミットし得なかったソフトウェア・リソースがある場合において、トランザクションを再処理依頼する技術が提案されている(例えば、特許文献1参照)。
特許文献1の技術では、トランザクションに関連した個々のソフトウェア・リソースが識別され、これらのリソースの処理が開始される。これらのリソースの処理が終了すると、それらの関連APIは、そのソフトウェア・リソースがコミットしたこと又はコミットし得なかったことを表すメッセージ及びソフトウェア・リソースがコミットし得なかった理由を返送する。この理由に基づいて、適正なエラー解決及び回復オペレーションが遂行され、コミットし得なかったソフトウェア・リソースに対してのみトランザクションが再処理依頼される。既にコミットしたソフトウェア・リソースはそれらの状態を維持される。
特許文献1の技術では、トランザクションに関連した個々のソフトウェア・リソースが識別され、これらのリソースの処理が開始される。これらのリソースの処理が終了すると、それらの関連APIは、そのソフトウェア・リソースがコミットしたこと又はコミットし得なかったことを表すメッセージ及びソフトウェア・リソースがコミットし得なかった理由を返送する。この理由に基づいて、適正なエラー解決及び回復オペレーションが遂行され、コミットし得なかったソフトウェア・リソースに対してのみトランザクションが再処理依頼される。既にコミットしたソフトウェア・リソースはそれらの状態を維持される。
また、クライアント・サーバ・システムにおけるデータ更新に関する技術は、公報記載の技術としても知られている(例えば、特許文献2参照)。
特許文献2は、クライアント・サーバ・システム内のオブジェクトの一貫性を保持しつつ、クライアントとサーバとの間で非同期にてキャッシュの更新動作を行い、クライアントで処理がブロックされる事態を回避し且つ通信回線の負荷を軽減し、さらにシステム全体のパフォーマンスを高める技術を開示する。この特許文献2の技術では、クライアントは自身のキャッシュ内のオブジェクトを更新した場合には、更新されたオブジェクトのIDとその内容をサーバに送る。クライアントは自身のオブジェクトのバージョンを0にし、他の処理を開始する。クライアントからの送信を受けて、サーバはそのIDのオブジェクトにサーバで更新ロックをかけ、サーバでのバージョンを最新のものにする。そして、サーバはこれには何等の応答を行わない。そして、トランザクションが承認されて終了する場合には、サーバは更新内容で自身のディスクを更新し、クライアントにサーバでのバージョンを送る。
特許文献2は、クライアント・サーバ・システム内のオブジェクトの一貫性を保持しつつ、クライアントとサーバとの間で非同期にてキャッシュの更新動作を行い、クライアントで処理がブロックされる事態を回避し且つ通信回線の負荷を軽減し、さらにシステム全体のパフォーマンスを高める技術を開示する。この特許文献2の技術では、クライアントは自身のキャッシュ内のオブジェクトを更新した場合には、更新されたオブジェクトのIDとその内容をサーバに送る。クライアントは自身のオブジェクトのバージョンを0にし、他の処理を開始する。クライアントからの送信を受けて、サーバはそのIDのオブジェクトにサーバで更新ロックをかけ、サーバでのバージョンを最新のものにする。そして、サーバはこれには何等の応答を行わない。そして、トランザクションが承認されて終了する場合には、サーバは更新内容で自身のディスクを更新し、クライアントにサーバでのバージョンを送る。
更に、データベースシステム等における障害発生時の処理に関する技術も、公報記載の技術として知られている(例えば、特許文献3〜5参照)。
特許文献3は、コミットメント処理中に障害が発生した場合そのコミットメント処理を代替手段で継続する分散トランザクションの障害復旧方法を開示する。この特許文献3の方法では、トランザクションのコミットメント処理中にサーバ処理手段がダウンした場合、生存管理手段がそれを検出する。トランザクション復旧手段は、トランザクション情報管理テーブルおよびリソース情報管理テーブルを参照して、サーバ処理手段で処理中だったトランザクションを引き継ぐ。2相コミットメントTX制御手段は、トランザクション情報の中にあるデータ更新状態から、データベースファイル上のデータを更新したことに対するコミットメント処理を継続する。コミットメント処理が完了すると、2相コミットメントTX制御手段に通知し、トランザクション情報管理テーブル上のデータ更新状態を書き換える。
特許文献3は、コミットメント処理中に障害が発生した場合そのコミットメント処理を代替手段で継続する分散トランザクションの障害復旧方法を開示する。この特許文献3の方法では、トランザクションのコミットメント処理中にサーバ処理手段がダウンした場合、生存管理手段がそれを検出する。トランザクション復旧手段は、トランザクション情報管理テーブルおよびリソース情報管理テーブルを参照して、サーバ処理手段で処理中だったトランザクションを引き継ぐ。2相コミットメントTX制御手段は、トランザクション情報の中にあるデータ更新状態から、データベースファイル上のデータを更新したことに対するコミットメント処理を継続する。コミットメント処理が完了すると、2相コミットメントTX制御手段に通知し、トランザクション情報管理テーブル上のデータ更新状態を書き換える。
特許文献4は、キュー管理(FIFO)を行っているファイル(キューデータファイル)の障害回復に際し、バックアップファイルなしで短時間でファイルの回復を実現できるキューファイルの回復制御装置を開示する。この特許文献4の装置では、トランザクション処理の制御を行うオンライン実行制御部と、キューデータの登録・読み出しおよび処理の履歴であるジャーナルデータの取得制御を行うキューデータ登録・読み出し制御部、キューファイルの回復制御を行うキュー回復制御部、前記キューファイルにキューデータを登録・読み出ししたとき、前記キューファイルの回復ポインタを更新して格納する更新情報テーブルとを備えたキューデータ制御部と、前記キューデータ登録・読み出し制御部が登録・読み出ししたキューデータおよび前記キューデータ登録・読み出し制御部が取得したジャーナルデータをそれぞれ格納するキューファイルおよびジャーナルファイルとを備え、前記キュー回復制御部は前記更新情報テーブルおよびジャーナルファイルを用いてキューを回復制御する。
特許文献5は、クラスタ構成のメッセージキューイングシステムにおいて、引継ぎノードが、業務プログラムやキュー管理プログラムを再開始することなく、障害ノードが持つキューに残された滞留メッセージを引継ぎ、引継ぎノードのキューのメッセージと同一視して処理を行なえるようにする技術を開示する。この特許文献5の技術では、クラスタ構成のメッセージキューイングシステムで、あるノードに障害が発生したとき、障害ノードのキューと同じ名称のキューを持つノードが障害ノードのメッセージ処理を引継ぎ、障害ノードのメッセージを引継ぎノードのメッセージとマージする。引継ぎノードのユーザアプリケーションからメッセージの取得要求があったときは、メッセージの属するノードに応じたディスク装置からメッセージを取得する。障害ノードが復旧したときは、他ノードによる引継ぎ処理が終了していた場合、ログ情報を初期化し、キューへのアクセスを可能にする。
上述したように、複数のサーバの何れかにおいてトランザクションがコミットされる前に障害が発生すると、そのトランザクションはロールバックされるので、ユーザは、ロールバックされたトランザクションで発行したSQL文と同じSQL文を再度発行しなければならない。
しかしながら、同じSQL文を再度発行する場合、SQL文が対象とするデータの整合性が損なわれることがある。トランザクションがデータを更新する際にはデータにロックが掛けられるが、ロールバックによりデータのロックが解除され、同じSQL文を再度発行する前に、他のトランザクションによりそのデータが更新される場合があるからである。例えば、座席予約が順調に進んでいたが、突然エラー通知を受け、再度同じ座席を予約しようとすると、既に他の人により予約済みとなっていた、といった場合である。
尚、特許文献1〜5の技術は何れも、このような課題を解決する手段を提供するものではない。
しかしながら、同じSQL文を再度発行する場合、SQL文が対象とするデータの整合性が損なわれることがある。トランザクションがデータを更新する際にはデータにロックが掛けられるが、ロールバックによりデータのロックが解除され、同じSQL文を再度発行する前に、他のトランザクションによりそのデータが更新される場合があるからである。例えば、座席予約が順調に進んでいたが、突然エラー通知を受け、再度同じ座席を予約しようとすると、既に他の人により予約済みとなっていた、といった場合である。
尚、特許文献1〜5の技術は何れも、このような課題を解決する手段を提供するものではない。
本発明の目的は、クライアントの要求に応じて複数のサーバのうちのあるサーバでデータを処理するトランザクションがコミットされる前にそのサーバに障害が発生した場合であっても、データの整合性を損なうことなく、トランザクションの処理を継続することにある。
かかる目的のもと、本発明は、データベースに対する処理を要求するクライアントと、クライアントによる要求に応じてデータベースに対する処理を行う複数のサーバとを含み、データベースに対する処理を行うシステムであって、クライアントは、自身で動作するアプリケーションからデータベースにおけるデータを処理するSQL文を受け付けると、SQL文を記憶する記憶部と、複数のサーバのうちの一のサーバに特定のトランザクションとしてSQL文による処理を要求する処理要求部と、一のサーバにおいて特定のトランザクションがコミットされる前に障害が発生すると、複数のサーバのうちの他のサーバに、特定のトランザクションとして、記憶部に記憶されたSQL文による再処理を要求する再処理要求部とを含み、複数のサーバのそれぞれは、処理要求部による要求に応じて、データに特定のトランザクションによるロックを掛けた状態でデータを処理する処理部と、データを処理したサーバにおいて特定のトランザクションがコミットされる前に障害が発生すると、データにロックを掛けたままの状態で、再処理要求部による要求に応じて、データを再処理する再処理部とを含む、システムを提供する。
ここで、クライアントは、複数のサーバの何れかにデータベースへの接続又はトランザクションのコミットを要求したときの応答に基づいて、特定のトランザクションを認識する認識部を更に含む、ものであってよい。
また、複数のサーバのそれぞれは、データを処理したサーバにおいて特定のトランザクションがコミットされる前に障害が発生すると、データに対するSQL文による更新内容を示す更新情報を自身が保持していれば、更新情報を特定のトランザクションが開始される前の状態に復旧する復旧部を更に含む、ものであってよい。
更に、このシステムは、データに特定のトランザクションによるロックが掛けられていることを示すロック情報を、複数のサーバにより共有される情報として管理する共有情報管理装置を更に含む、ものであってよい。
また、複数のサーバのそれぞれは、データを処理したサーバにおいて特定のトランザクションがコミットされる前に障害が発生すると、データに対するSQL文による更新内容を示す更新情報を自身が保持していれば、更新情報を特定のトランザクションが開始される前の状態に復旧する復旧部を更に含む、ものであってよい。
更に、このシステムは、データに特定のトランザクションによるロックが掛けられていることを示すロック情報を、複数のサーバにより共有される情報として管理する共有情報管理装置を更に含む、ものであってよい。
また、本発明は、データベースに対する処理を要求するクライアントと、クライアントによる要求に応じてデータベースに対する処理を行う複数のサーバとを含むシステムにおいて、データベースに対する処理を行う方法であって、クライアントが、自身で動作するアプリケーションからデータベースにおけるデータを処理するSQL文を受け付けると、SQL文を所定の記憶部に記憶するステップと、クライアントが、複数のサーバのうちの一のサーバに特定のトランザクションとしてSQL文による処理を要求するステップと、一のサーバが、クライアントによる処理の要求に応じて、データに特定のトランザクションによるロックを掛けた状態でデータを処理するステップと、クライアントが、一のサーバにおいて特定のトランザクションがコミットされる前に障害が発生すると、複数のサーバのうちの他のサーバに、特定のトランザクションとして、所定の記憶部に記憶されたSQL文による再処理を要求するステップと、他のサーバが、一のサーバにおいて特定のトランザクションがコミットされる前に障害が発生すると、データにロックを掛けたままの状態で、クライアントによる再処理の要求に応じて、データを処理するステップとを含む、方法も提供する。
更に、本発明は、データベースに対する処理を要求するクライアントと、クライアントによる要求に応じてデータベースに対する処理を行う複数のサーバとを含むシステムにおいて、データベースに対する処理を行う方法であって、クライアントが、複数のサーバのうちの一のサーバから次のトランザクションを識別する識別情報を受信するステップと、クライアントが、自身で動作するアプリケーションからデータベースにおけるデータを処理するSQL文を受け付けると、識別情報とSQL文とを対応付けて所定の記憶部に記憶するステップと、クライアントが、一のサーバに識別情報とSQL文による処理要求とを送信するステップと、一のサーバが、クライアントから識別情報と処理要求とを受信すると、データと識別情報とデータにロックが掛けられていることを示す情報とを対応付けたロック情報が複数のサーバで共有される記憶領域に記憶された状態で、データを処理するステップと、クライアントが、一のサーバにおいてデータの処理がコミットされる前に障害が発生すると、複数のサーバのうちの他のサーバに、識別情報と、所定の記憶部に識別情報に対応付けて記憶されたSQL文による再処理要求とを送信するステップと、他のサーバが、一のサーバにおいてデータの処理がコミットされる前に障害が発生すると、ロック情報が記憶領域に記憶されたままの状態で、クライアントから識別情報と再処理要求とを受信すると、データを処理するステップとを含む、方法も提供する。
ここで、識別情報を受信するステップでは、一のサーバに送信したデータベースへの接続要求に対する応答又は一のサーバに送信したトランザクションのコミット要求に対する応答に含まれる識別情報を受信する、ものであってよい。
また、本発明は、データベースに対する処理を要求するクライアントと、クライアントによる要求に応じてデータベースに対する処理を行う複数のサーバとを含むシステムにおいて、クライアントとして、コンピュータを機能させるプログラムであって、コンピュータを、自身で動作するアプリケーションからデータベースにおけるデータを処理するSQL文を受け付けると、SQL文を記憶する記憶部と、複数のサーバのうちの一のサーバに特定のトランザクションとしてSQL文による処理を要求することにより、一のサーバが、データに特定のトランザクションによるロックを掛けた状態でデータを処理するように制御する処理制御部と、一のサーバにおいて特定のトランザクションがコミットされる前に障害が発生すると、複数のサーバのうちの他のサーバに、特定のトランザクションとして、記憶部に記憶されたSQL文による再処理を要求することにより、他のサーバが、データにロックを掛けたままの状態で、データを再処理するように制御する再処理制御部として機能させる、プログラムも提供する。
更に、本発明は、データベースに対する処理を要求するクライアントと、クライアントによる要求に応じてデータベースに対する処理を行う複数のサーバとを含むシステムにおいて、サーバとして、コンピュータを機能させるプログラムであって、コンピュータを、クライアントから特定のトランザクションとしてなされた、データベースにおけるデータを処理するSQL文による処理の要求に応じて、データに特定のトランザクションによるロックを掛けた状態でデータを処理する処理部と、データを処理したサーバにおいて特定のトランザクションがコミットされる前に障害が発生すると、データにロックを掛けたままの状態で、クライアントから特定のトランザクションとしてなされた、SQL文による再処理の要求に応じて、データを再処理する再処理部として機能させる、プログラムも提供する。
本発明によれば、クライアントの要求に応じて複数のサーバのうちのあるサーバでデータを処理するトランザクションがコミットされる前にそのサーバに障害が発生した場合であっても、データの整合性を損なうことなく、トランザクションの処理を継続することができる。
以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
図1は、本実施の形態が適用されるデータベースシステムの構成例を示したブロック図である。
図示するように、データベースシステムは、クライアント10と、サーバ20a,20b,20c,20dと、共有情報管理装置30a,30bと、データベース40とを含む。そして、クライアント10と、サーバ20a,20b,20c,20dとは、ネットワーク81で接続され、サーバ20a,20b,20c,20dと、共有情報管理装置30a,30bとは、ネットワーク82で接続され、データベース40は、サーバ20a,20b,20c,20d及び共有情報管理装置30a,30bに、ネットワーク83で接続されている。
図1は、本実施の形態が適用されるデータベースシステムの構成例を示したブロック図である。
図示するように、データベースシステムは、クライアント10と、サーバ20a,20b,20c,20dと、共有情報管理装置30a,30bと、データベース40とを含む。そして、クライアント10と、サーバ20a,20b,20c,20dとは、ネットワーク81で接続され、サーバ20a,20b,20c,20dと、共有情報管理装置30a,30bとは、ネットワーク82で接続され、データベース40は、サーバ20a,20b,20c,20d及び共有情報管理装置30a,30bに、ネットワーク83で接続されている。
クライアント10は、サーバ20a,20b,20c,20dの何れかに接続し、データベース40を操作するSQL(Structured Query Language)文を接続先に発行するコンピュータである。また、クライアント10は、サーバ20a,20b,20c,20dから受け取る負荷情報に基づいて、負荷が分散するようにサーバ20a,20b,20c,20dのうちの接続先を決定する機能を有する。更に、サーバ20a,20b,20c,20dの何れかに障害が発生した場合の接続先を、負荷情報に基づいて決定する機能も有する。或いは、クライアント10は、明示的な指定に基づいて、サーバ20a,20b,20c,20dのうちの接続先を決定するようにしてもよい。ここで、クライアント10としては、デスクトップPC(Personal Computer)、ノートPC、タブレットPC、PDA(Personal Digital Assistants)、スマートフォン、携帯電話等を用いるとよい。
サーバ20a,20b,20c,20dは、データベース40を共有しており、それぞれが、クライアント10が発行したSQL文を用いてデータベース40にアクセスする機能を有するコンピュータである。サーバ20a,20b,20c,20dは、データベース40に対するアクセスの一貫性を提供するように連携している。尚、図では、サーバ20a,20b,20c,20dを示したが、これらを区別する必要がない場合は、サーバ20と称する。また、図には、4つのサーバ20を示したが、2つ、3つ、或いは、5つ以上のサーバ20を設けてもよい。
共有情報管理装置30a,30bは、サーバ20a,20b,20c,20dの間で共有する情報を管理する装置である。ここで、共有する情報とは、例えば、データベース40におけるデータのロックに関する情報(以下、「ロック情報」という)、データベースシステム内で一意であるトランザクションの識別情報(以下、「トランザクションID」という)の使用状況等である。尚、共有情報管理装置30a,30bは、同期二重化された装置であり、共有情報管理装置30aが、プライマリーの共有情報管理装置として、共有情報管理装置30bが、共有情報管理装置30aに障害が発生した場合にセカンダリーの共有情報管理装置として、それぞれ機能する。但し、以下では、共有情報管理装置30aに障害は発生せず、共有情報管理装置として共有情報管理装置30aのみを用いるものとして説明する。
データベース40は、サーバ20a,20b,20c,20dによって共有され、クライアント10がSQL文を発行することによって処理する対象のデータを格納する。
ネットワーク81は、クライアント10とサーバ20a,20b,20c,20dとの間の情報通信に用いられる通信手段であり、例えば、インターネットである。
ネットワーク82は、サーバ20a,20b,20c,20d、共有情報管理装置30a,30bの相互間で高速データ通信を行うための通信手段である。ここで、ネットワーク82としては、RDMA(Remote Direct Memory Access)機能を活用して各サーバ20及び各共有情報管理装置30のメモリに対する直接アクセスを可能としたInfiniband(商標)が例示される。
ネットワーク83は、サーバ20a,20b,20c,20d、共有情報管理装置30a,30bと、データベース40との間の情報通信に用いられる通信手段であり、例えば、SAN(Storage Area Network)である。
ネットワーク82は、サーバ20a,20b,20c,20d、共有情報管理装置30a,30bの相互間で高速データ通信を行うための通信手段である。ここで、ネットワーク82としては、RDMA(Remote Direct Memory Access)機能を活用して各サーバ20及び各共有情報管理装置30のメモリに対する直接アクセスを可能としたInfiniband(商標)が例示される。
ネットワーク83は、サーバ20a,20b,20c,20d、共有情報管理装置30a,30bと、データベース40との間の情報通信に用いられる通信手段であり、例えば、SAN(Storage Area Network)である。
まず、このようなデータベースシステムにおける一般的な動作を説明する。尚、ここでは、データベース40に格納されたデータのキャッシュに読み込む単位を「ページ」と呼ぶ。
図2は、ページを参照する際の一般的な動作を示した図である。但し、この図では、図1のサーバ20a,20b,20c,20dのうち、サーバ20a及びサーバ20bのみを示し、クライアント10は省略している。また、共有情報管理装置30aについては、内部の記憶領域も示している。最新データ領域31aは、サーバ20a,20bが共有する最新のデータを記憶するためのキャッシュ領域であり、複数のサーバで共有される記憶領域の一例である。ロック情報領域32aは、サーバ20a,20bが共有するロック情報を記憶する記憶領域であり、共有通信領域33aは、サーバ20a,20bが共有するメタ情報を記憶する記憶領域である。
さて、図では、サーバ20a及びサーバ20bを使用してページAを参照する場合を例にとっている。尚、ここでは、サーバ20a、サーバ20b、共有情報管理装置30aの何れも、ページAを持っていないものとする。
まず、サーバ20aにSQL文が発行され、Emp=Yという条件を満たすレコードが要求されている(1−1)。これにより、ページAの取得が必要になったとする。
サーバ20aは、ページAを持っていないので、共有情報管理装置30aの最新データ領域31aに対して、読出し登録要求を発行する(1−2)。すると、共有情報管理装置30aは、最新データ領域31a内の図示しないディレクトリエントリに、サーバ20aがページAを保持していることを登録する。
この場合、最新データ領域31aにはページAがキャッシュされていなかったので、サーバ20aは、データベース40からページAを取得する(1−3)。
まず、サーバ20aにSQL文が発行され、Emp=Yという条件を満たすレコードが要求されている(1−1)。これにより、ページAの取得が必要になったとする。
サーバ20aは、ページAを持っていないので、共有情報管理装置30aの最新データ領域31aに対して、読出し登録要求を発行する(1−2)。すると、共有情報管理装置30aは、最新データ領域31a内の図示しないディレクトリエントリに、サーバ20aがページAを保持していることを登録する。
この場合、最新データ領域31aにはページAがキャッシュされていなかったので、サーバ20aは、データベース40からページAを取得する(1−3)。
次に、サーバ20bにも同じSQL文が発行され(1−4)、ページAの取得が必要になったとする。
サーバ20bも、ページAを持っていないので、共有情報管理装置30aの最新データ領域31aに対して、読出し登録要求を発行する(1−5)。すると、共有情報管理装置30aは、最新データ領域31a内の図示しないディレクトリエントリに、サーバ20bがページAを保持していることを登録する。
この場合、最新データ領域31aにはページAがキャッシュされていなかったので、サーバ20bは、データベース40からページAを取得する(1−6)。
尚、その後、サーバ20bが再度ページAを参照する場合は、サーバ20bがキャッシュ上に保持するページAを参照すればよい(1−7)。
サーバ20bも、ページAを持っていないので、共有情報管理装置30aの最新データ領域31aに対して、読出し登録要求を発行する(1−5)。すると、共有情報管理装置30aは、最新データ領域31a内の図示しないディレクトリエントリに、サーバ20bがページAを保持していることを登録する。
この場合、最新データ領域31aにはページAがキャッシュされていなかったので、サーバ20bは、データベース40からページAを取得する(1−6)。
尚、その後、サーバ20bが再度ページAを参照する場合は、サーバ20bがキャッシュ上に保持するページAを参照すればよい(1−7)。
図3は、ページを更新する際の一般的な動作を示した図である。但し、この図でも、図1のサーバ20a,20b,20c,20dのうち、サーバ20a及びサーバ20bのみを示し、クライアント10は省略している。また、共有情報管理装置30aについては、図2と同様に内部の記憶領域も示している。
さて、図では、図2の動作が完了したときの状態から動作が開始するものとする。即ち、動作が開始する時点で、最新データ領域31aはページAを持っておらず、サーバ20a,20bはキャッシュ上にページAを保持しているものとする。
まず、サーバ20aにSQL文が発行され、サーバ20aが更新処理を実行する(2−1)。これにより、ページAが更新され、ページA’になったとする。
次に、サーバ20aにコミットが発行され、ページAの更新が確定したとする(2−2)。
サーバ20aは、共有情報管理装置30aの最新データ領域31aに対して、書込み登録要求を発行する(2−3)。すると、共有情報管理装置30aは、最新データ領域31aにページA’を書き込む。
これにより、共有情報管理装置30aは、サーバ20bが保持するページAの無効化(クロスインバリデーション)を行う(2−4)。また、このとき、共有情報管理装置30aは、最新データ領域31a内の図示しないディレクトリエントリからサーバ20bの登録を削除する。
そして、共有情報管理装置30aは、書込み登録要求の応答をサーバ20aに返す(2−5)。
これにより、サーバ20aは、クライアント10(図示せず)にコミット完了の応答を返す(2−6)。
まず、サーバ20aにSQL文が発行され、サーバ20aが更新処理を実行する(2−1)。これにより、ページAが更新され、ページA’になったとする。
次に、サーバ20aにコミットが発行され、ページAの更新が確定したとする(2−2)。
サーバ20aは、共有情報管理装置30aの最新データ領域31aに対して、書込み登録要求を発行する(2−3)。すると、共有情報管理装置30aは、最新データ領域31aにページA’を書き込む。
これにより、共有情報管理装置30aは、サーバ20bが保持するページAの無効化(クロスインバリデーション)を行う(2−4)。また、このとき、共有情報管理装置30aは、最新データ領域31a内の図示しないディレクトリエントリからサーバ20bの登録を削除する。
そして、共有情報管理装置30aは、書込み登録要求の応答をサーバ20aに返す(2−5)。
これにより、サーバ20aは、クライアント10(図示せず)にコミット完了の応答を返す(2−6)。
次に、サーバ20bが再度ページAを必要とした場合、サーバ20bは、共有情報管理装置30aの最新データ領域31aに対して、改めて読出し登録要求を発行する(2−7)。すると、共有情報管理装置30aは、サーバ20bにページA’を書き込む(2−8)。また同時に、最新データ領域31a内の図示しないディレクトリエントリに、サーバ20bがページA’を保持していることを登録する。
ところが、図3の更新動作において、サーバ20aでコミットが完了する前に障害が発生すると、ページAの更新がロールバックされてしまう。そうなると、再度同じ更新をサーバ20bから行おうとしても、その前に別のサーバ20からページAが更新されてしまう可能性がある。
そこで、本実施の形態では、データベースシステムにおけるあるサーバ20がダウンしても、そこで実行中のトランザクションのデータに対するロック情報は保持したままにし、クライアント10から別のサーバ20を利用して、実行中であったトランザクションと同じトランザクションスコープで、再度、同じSQL文を発行するようにする。
より詳細には、次のような動作を行う。
第一に、クライアント10が、発行したSQL文をログする。
第二に、各トランザクションを、トランザクションID等でクライアント10からも識別できるようにする。
第三に、データベースシステムにおけるあるサーバ20がダウンしても、そのサーバ20で実行中のトランザクションのロック情報は保持し、全てのサーバ20で共有できるようにする。
第四に、サーバ20で障害が発生した旨を受信し、又は、サーバ20での障害の発生を検出したクライアント10は、別のサーバ20を利用して、同じトランザクションIDで、SQL文を再実行する。
第五に、このSQL文を受信したサーバ20は、指定されたトランザクションIDで、SQL文を処理する。
そこで、本実施の形態では、データベースシステムにおけるあるサーバ20がダウンしても、そこで実行中のトランザクションのデータに対するロック情報は保持したままにし、クライアント10から別のサーバ20を利用して、実行中であったトランザクションと同じトランザクションスコープで、再度、同じSQL文を発行するようにする。
より詳細には、次のような動作を行う。
第一に、クライアント10が、発行したSQL文をログする。
第二に、各トランザクションを、トランザクションID等でクライアント10からも識別できるようにする。
第三に、データベースシステムにおけるあるサーバ20がダウンしても、そのサーバ20で実行中のトランザクションのロック情報は保持し、全てのサーバ20で共有できるようにする。
第四に、サーバ20で障害が発生した旨を受信し、又は、サーバ20での障害の発生を検出したクライアント10は、別のサーバ20を利用して、同じトランザクションIDで、SQL文を再実行する。
第五に、このSQL文を受信したサーバ20は、指定されたトランザクションIDで、SQL文を処理する。
以下、このような概略動作を実現するデータベースシステムについて、詳細に説明する。
まず、図1のデータベースシステムにおけるソフトウェア構成について説明する。
図4は、本実施の形態のクライアント10及びサーバ20a,20b,20c,20dにおけるソフトウェア構成について示した図である。
図示するように、クライアント10は、クライアントアプリケーション51と、データベースクライアント52とを含む。
また、サーバ20a,20b,20c,20dは、それぞれ、データベースサーバ53a及び障害検出ソフトウェア54a、データベースサーバ53b及び障害検出ソフトウェア54b、データベースサーバ53c及び障害検出ソフトウェア54c、データベースサーバ53d及び障害検出ソフトウェア54dを含む。尚、図では、データベースサーバ53a,53b,53c,53d、障害検出ソフトウェア54a,54b,54c,54dを示したが、これらを区別する必要がない場合は、それぞれ、データベースサーバ53、障害検出ソフトウェア54と称する。
まず、図1のデータベースシステムにおけるソフトウェア構成について説明する。
図4は、本実施の形態のクライアント10及びサーバ20a,20b,20c,20dにおけるソフトウェア構成について示した図である。
図示するように、クライアント10は、クライアントアプリケーション51と、データベースクライアント52とを含む。
また、サーバ20a,20b,20c,20dは、それぞれ、データベースサーバ53a及び障害検出ソフトウェア54a、データベースサーバ53b及び障害検出ソフトウェア54b、データベースサーバ53c及び障害検出ソフトウェア54c、データベースサーバ53d及び障害検出ソフトウェア54dを含む。尚、図では、データベースサーバ53a,53b,53c,53d、障害検出ソフトウェア54a,54b,54c,54dを示したが、これらを区別する必要がない場合は、それぞれ、データベースサーバ53、障害検出ソフトウェア54と称する。
クライアントアプリケーション51は、SQL文を発行する。例えば、SQL文61を発行したとする。
データベースクライアント52は、トランザクションIDを取得し、クライアントアプリケーション51からの要求に応じたSQL文を実行する。また、データベースクライアント52は、サーバ20a,20b,20c,20dの障害を検出する。図では、サーバ20aに対してSQL文621を実行した時点で、サーバ20aに障害が発生したものとしている。すると、データベースクライアント52は、別の正常なサーバ20bに接続し、同じトランザクションIDを使用して、同じSQL文を実行する。その後、SQL文61のうち、未実行のSQLを実行する。即ち、データベースクライアント52は、サーバ20bに対してSQL文622を実行する。
データベースサーバ53は、トランザクション開始時にトランザクションIDをデータベースクライアント52に返す。具体的には、データベース40(図1参照)への接続時、トランザクションのコミット時等に、次のトランザクションIDを返す。また、データのロック情報は、全てのデータベースサーバ53で共有し、障害が発生してもロックは解除しない。更に、トランザクションIDを指定してデータベースクライアント52からSQL文を受けると、そのトランザクションIDに対応するロック情報を引き継ぐ。
尚、データベースサーバ53は、SQL文を発行する前に、最低限、以下の処理を行う。
即ち、発行するSQL文の実行結果が、障害により不整合な状態になっているデータにより、異なる結果となる場合、既存のリカバリ処理により、そのデータは障害が発生したトランザクションの開始時点のデータに戻し、整合性をとる。
但し、これらの処理は最低限必要な処理であり、全てのSQL文を再発行する前に、障害により不整合となった全てのデータのリカバリ処理を行ってもよい。
尚、データベースサーバ53は、SQL文を発行する前に、最低限、以下の処理を行う。
即ち、発行するSQL文の実行結果が、障害により不整合な状態になっているデータにより、異なる結果となる場合、既存のリカバリ処理により、そのデータは障害が発生したトランザクションの開始時点のデータに戻し、整合性をとる。
但し、これらの処理は最低限必要な処理であり、全てのSQL文を再発行する前に、障害により不整合となった全てのデータのリカバリ処理を行ってもよい。
障害検出ソフトウェア54は、自身が動作するサーバ20におけるデータベースサーバ53のプロセス障害又は自身が動作するサーバ20以外の他のサーバ20におけるハードウェア障害を検出する。具体的には、自身が動作するサーバ20においてデータベースサーバ53のプロセスがなくなったことを検知することにより、前者の障害を検出する。また、自身が動作するサーバ20以外の他のサーバ20の障害検出ソフトウェア54からのハートビートが途絶えたことを検知することにより、後者の障害を検出する。そして、障害を検出すると、その旨を他のサーバ20及び共有情報管理装置30に通知し、自動的に回復処理を行う。
次に、クライアント10及びサーバ20のハードウェア構成について説明する。尚、クライアント10及びサーバ20は同様のハードウェア構成を有するため、ここではコンピュータ90のハードウェア構成として説明する。
図5は、このようなコンピュータ90のハードウェア構成例を示した図である。図示するように、コンピュータ90は、演算手段であるCPU(Central Processing Unit)90aと、M/B(マザーボード)チップセット90bを介してCPU90aに接続されたメインメモリ90cと、同じくM/Bチップセット90bを介してCPU90aに接続された表示機構90dとを備える。また、M/Bチップセット90bには、ブリッジ回路90eを介して、ネットワークインターフェイス90fと、磁気ディスク装置(HDD)90gと、音声機構90hと、キーボード/マウス90iと、フレキシブルディスクドライブ90jとが接続されている。
図5は、このようなコンピュータ90のハードウェア構成例を示した図である。図示するように、コンピュータ90は、演算手段であるCPU(Central Processing Unit)90aと、M/B(マザーボード)チップセット90bを介してCPU90aに接続されたメインメモリ90cと、同じくM/Bチップセット90bを介してCPU90aに接続された表示機構90dとを備える。また、M/Bチップセット90bには、ブリッジ回路90eを介して、ネットワークインターフェイス90fと、磁気ディスク装置(HDD)90gと、音声機構90hと、キーボード/マウス90iと、フレキシブルディスクドライブ90jとが接続されている。
尚、図5において、各構成要素は、バスを介して接続される。例えば、CPU90aとM/Bチップセット90bの間や、M/Bチップセット90bとメインメモリ90cの間は、CPUバスを介して接続される。また、M/Bチップセット90bと表示機構90dとの間は、AGP(Accelerated Graphics Port)を介して接続されてもよいが、表示機構90dがPCI Express対応のビデオカードを含む場合、M/Bチップセット90bとこのビデオカードの間は、PCI Express(PCIe)バスを介して接続される。また、ブリッジ回路90eと接続する場合、ネットワークインターフェイス90fについては、例えば、PCI Expressを用いることができる。また、磁気ディスク装置90gについては、例えば、シリアルATA(AT Attachment)、パラレル転送のATA、PCI(Peripheral Components Interconnect)を用いることができる。更に、キーボード/マウス90i、及び、フレキシブルディスクドライブ90jについては、USB(Universal Serial Bus)を用いることができる。
次いで、クライアント10及びサーバ20の機能及び動作について説明する。尚、以下の説明で、単に「SQL文」というときは、コミット文及びロールバック文(以下、「コミット文等」という)を含まないものとする。
図6は、クライアント10及びサーバ20の機能構成例を示したブロック図である。図において、クライアント10の機能としては、クライアントアプリケーション51以外は、データベースクライアント52により実現される機能を、サーバ20の機能としては、データベースサーバ53により実現される機能を示している。
まず、クライアント10は、受送信部11と、接続処理部12と、トランザクションID記憶部13と、SQL処理部14と、トランザクションログ記憶部15と、障害通知受信部16と、コミット・ロールバック処理部18と、送受信部19とを備えている。
図6は、クライアント10及びサーバ20の機能構成例を示したブロック図である。図において、クライアント10の機能としては、クライアントアプリケーション51以外は、データベースクライアント52により実現される機能を、サーバ20の機能としては、データベースサーバ53により実現される機能を示している。
まず、クライアント10は、受送信部11と、接続処理部12と、トランザクションID記憶部13と、SQL処理部14と、トランザクションログ記憶部15と、障害通知受信部16と、コミット・ロールバック処理部18と、送受信部19とを備えている。
受送信部11は、クライアントアプリケーション51からデータベース接続要求、SQL文及びコミット文等を受信し、処理が終了したら結果を戻す。受送信部11は既存技術と同じインターフェースを提供する。既存のクライアントアプリケーション51は、この技術を修正することなく、使用することができる。既存技術では、複数のデータベース接続をクライアントアプリケーション51が識別できるように接続ハンドルと呼ばれる識別子がデータベース接続時に割り当てられ、利用される。
接続処理部12は、受送信部11がデータベース接続要求をクライアントアプリケーション51から受信すると、データベース接続要求をサーバ20のデータベースサーバ53に送信するよう送受信部19に指示する。また、接続処理部12は、送受信部19がデータベース接続要求に対する応答をデータベースサーバ53から受信すると、要求が正常に処理されたことを示す戻り値が応答に含まれていれば、応答に含まれる接続ハンドルと次のトランザクションID、及びデータベースサーバ53の識別子(例えば、IPアドレス)をトランザクションID記憶部13に記憶する。そして、データベース接続要求が正常に処理されたことを示す応答をクライアントアプリケーション51に送信するよう受送信部11に指示する。本実施の形態では、トランザクションを認識する認識部の一例として、接続処理部12を設けている。
更に、接続処理中のサーバ20で障害が発生した場合には、接続処理部12は、データベース接続要求を別のサーバ20のデータベースサーバ53に送信するよう送受信部19に指示する。また、この場合、接続処理部12は、送受信部19がデータベース接続要求に対する応答をデータベースサーバ53から受信すると、要求が正常に処理されたことを示す戻り値が応答に含まれていれば、その接続ハンドルとデータベースサーバ53の識別子とをトランザクションID記憶部13に記憶する。そして、データベース接続要求が正常に処理されたことを示す応答をクライアントアプリケーション51に送信するよう受送信部11に指示する。
更にまた、接続処理部12は、障害が発生したサーバ20のデータベースサーバ53で処理している処理要求中フラグが処理要求中を示していない全てのトランザクションIDについて、別のサーバ20に接続して順次SQL文を送信する処理を障害通知受信部16に依頼する。
更にまた、接続処理部12は、障害が発生したサーバ20のデータベースサーバ53で処理している処理要求中フラグが処理要求中を示していない全てのトランザクションIDについて、別のサーバ20に接続して順次SQL文を送信する処理を障害通知受信部16に依頼する。
トランザクションID記憶部13は、接続処理部12及びコミット・ロールバック処理部18が出力したトランザクションID、接続ハンドル(クライアントアプリケーション51が利用している接続ハンドル及び障害発生後は更にデータベースサーバ53が利用している実ハンドル)、データベースサーバ53の識別子、そのトランザクションIDがデータベースサーバ53に処理を要求中であるかどうかを示す処理要求中フラグを記憶する。トランザクションID記憶部13は、その他、接続に必要となる情報を保持してもよい。
SQL処理部14は、受送信部11が接続ハンドルと共にSQL文をクライアントアプリケーション51から受信すると、トランザクションID記憶部13に記憶されたトランザクションIDと、このSQL文との対応をトランザクションログ記憶部15に記憶する。同じトランザクションIDにおけるSQL文の発行順序も記憶する。そして、SQL文の処理要求をサーバ20のデータベースサーバ53に送信するよう送受信部19に指示する。また、SQL処理部14は、送受信部19がSQL文の処理要求に対する応答をデータベースサーバ53から受信すると、要求が正常に処理されたことを示す戻り値が応答に含まれていれば、SQL文の処理要求が正常に処理されたことを示す応答をクライアントアプリケーション51に送信するよう受送信部11に指示する。本実施の形態では、SQL文による処理を要求する処理要求部、データを処理するように制御する処理制御部の一例として、SQL処理部14を設けている。
更に、処理中のサーバ20で障害が発生した場合には、SQL処理部14は、トランザクションログ記憶部15に記憶された同じトランザクションIDに対応する最初のSQL文の処理要求を別のサーバ20におけるデータベースサーバ53に送信するよう送受信部19に指示する。また、この場合、送受信部19がSQL文の処理要求に対する応答をデータベースサーバ53から受信すると、要求が正常に処理されたことを示す戻り値が応答に含まれており、トランザクションログ記憶部15に未送信のSQL文があれば、次のSQL文の処理要求をデータベースサーバ53に送信するよう送受信部19に指示し、要求が正常に処理されたことを示す戻り値が応答に含まれており、トランザクションログ記憶部15に未送信のSQL文がなければ、SQL文の処理要求が正常に処理されたことを示す応答をクライアントアプリケーション51に送信するよう受送信部11に指示する。障害発生後は、別のデータベースサーバ53に接続してやり取りすることになるが、クライアントアプリケーション51とのやり取りに使用する接続ハンドルは障害発生前と同じものを使用する。そのため、クライアントアプリケーション51で使用する接続ハンドルと現在データベースサーバ53で使用している実ハンドルの両方の情報を必要に応じてトランザクションID記憶部13に記憶する。本実施の形態では、SQL文による再処理を要求する再処理要求部、データを再処理するように制御する再処理制御部の一例としても、SQL処理部14を設けている。
更にまた、SQL処理部14は、障害が発生したサーバ20のデータベースサーバ53で処理している処理要求中フラグが処理要求中を示していない全てのトランザクションIDについて、別のサーバ20に接続して順次SQL文を送信する処理を障害通知受信部16に依頼する。
更にまた、SQL処理部14は、障害が発生したサーバ20のデータベースサーバ53で処理している処理要求中フラグが処理要求中を示していない全てのトランザクションIDについて、別のサーバ20に接続して順次SQL文を送信する処理を障害通知受信部16に依頼する。
トランザクションログ記憶部15は、SQL処理部14により送られたトランザクションIDとSQL文との対応を記憶する。トランザクションログ記憶部15は、その他、SQL文を発行する際に必要となる情報を保持してもよい。本実施の形態では、SQL文を記憶する記憶部の一例として、トランザクションログ記憶部15を設けている。
障害通知受信部16は、障害検出ソフトウェア54等がデータベースサーバ53の障害を検出すると、その障害の通知を受ける。また、接続処理部12、SQL処理部14及びコミット・ロールバック処理部18からもデータベースサーバ53の障害の通知を受ける。このとき、障害通知受信部16は、処理要求中フラグが処理要求中を示していない全てのトランザクションIDについて、次の処理を行う。即ち、まず、別のサーバ20に接続し、その実ハンドルをトランザクションID記憶部13の該当するトランザクションIDの実ハンドルに登録する。その後、そのトランザクションIDに対応する最初のSQL文の処理要求を別のサーバ20におけるデータベースサーバ53に送信するよう送受信部19に指示する。また、この場合、送受信部19がSQL文の処理要求に対する応答をデータベースサーバ53から受信すると、要求が正常に処理されたことを示す戻り値が応答に含まれており、トランザクションログ記憶部15に未送信のSQL文があれば、次のSQL文の処理要求をデータベースサーバ53に送信するよう送受信部19に指示し、要求が正常に処理されたことを示す戻り値が応答に含まれており、トランザクションログ記憶部15に未送信のSQL文がなければ、そのトランザクションIDに関する処理は終了とする。
コミット・ロールバック処理部18は、受送信部11がコミット文をクライアントアプリケーション51から受信すると、コミット文の処理要求をサーバ20のデータベースサーバ53に送信するよう送受信部19に指示する。また、コミット・ロールバック処理部18は、送受信部19がコミット文の処理要求に対する応答をデータベースサーバ53から受信すると、要求が正常に処理されたことを示す戻り値が応答に含まれていれば、現在のトランザクションIDに関する全ての情報をトランザクションログ記憶部15及びトランザクションID記憶部13から削除すると共に、応答に含まれる次のトランザクションIDをトランザクションID記憶部13に記憶する。そして、コミット文の処理要求が正常に処理されたことを示す応答をクライアントアプリケーション51に送信するよう受送信部11に指示する。本実施の形態では、SQL文による処理を要求する処理要求部、データを処理するように制御する処理制御部の一例として、コミット・ロールバック処理部18を設けている。
更に、処理中のサーバ20で障害が発生した場合には、コミット・ロールバック処理部18は、トランザクションログ記憶部15に記憶された同じトランザクションIDに対応する最初のSQL文の処理要求を別のサーバ20におけるデータベースサーバ53に送信するよう送受信部19に指示する。また、この場合、送受信部19がSQL文の処理要求に対する応答をデータベースサーバ53から受信すると、要求が正常に処理されたことを示す戻り値が応答に含まれており、トランザクションログ記憶部15に未送信のSQL文があれば、次のSQL文の処理要求をデータベースサーバ53に送信するよう送受信部19に指示し、要求が正常に処理されたことを示す戻り値が応答に含まれており、トランザクションログ記憶部15に未送信のSQL文がなければ、コミット文の処理要求をデータベースサーバ53に送信するよう送受信部19に指示する。更に、要求が正常に処理されたことを示す戻り値が応答に含まれていれば、現在のトランザクションIDに関する全ての情報をトランザクションログ記憶部15及びトランザクションID記憶部13から削除すると共に、応答に含まれる次のトランザクションIDをトランザクションID記憶部13に記憶する。そして、コミット文の処理要求が正常に処理されたことを示す応答をクライアントアプリケーション51に送信するよう受送信部11に指示する。本実施の形態では、SQL文による処理を要求する処理要求部、データを処理するように制御する処理制御部の一例としても、コミット・ロールバック処理部18を設けている。
更にまた、コミット・ロールバック処理部18は、障害が発生したサーバ20のデータベースサーバ53で処理している処理要求中フラグが処理要求中を示していない全てのトランザクションIDについて、別のサーバ20に接続して順次SQL文を送信する処理を障害通知受信部16に依頼する。
更にまた、コミット・ロールバック処理部18は、障害が発生したサーバ20のデータベースサーバ53で処理している処理要求中フラグが処理要求中を示していない全てのトランザクションIDについて、別のサーバ20に接続して順次SQL文を送信する処理を障害通知受信部16に依頼する。
また、コミット・ロールバック処理部18は、受送信部11がロールバック文をクライアントアプリケーション51から受信すると、ロールバック文の処理要求をサーバ20のデータベースサーバ53に送信するよう送受信部19に指示する。また、コミット・ロールバック処理部18は、送受信部19がロールバック文の処理要求に対する応答をデータベースサーバ53から受信すると、要求が正常に処理されたことを示す戻り値が応答に含まれていれば、現在のトランザクションIDに関する全ての情報をトランザクションログ記憶部15及びトランザクションID記憶部13から削除すると共に、応答に含まれる次のトランザクションIDをトランザクションID記憶部13に記憶する。そして、ロールバック文の処理要求が正常に処理されたことを示す応答をクライアントアプリケーション51に送信するよう受送信部11に指示する。
更に、ロールバック処理中のサーバ20で障害が発生した場合には、コミット・ロールバック処理部18は、ロールバック文の処理要求を別のサーバ20におけるデータベースサーバ53に送信するよう送受信部19に指示する。また、この場合、送受信部19がロールバック文の処理要求に対する応答をデータベースサーバ53から受信すると、要求が正常に処理されたことを示す戻り値が応答に含まれていれば、現在のトランザクションIDに関する全ての情報をトランザクションログ記憶部15及びトランザクションID記憶部13から削除すると共に、応答に含まれる次のトランザクションIDをトランザクションID記憶部13に記憶する。そして、ロールバック文の処理要求が正常に処理されたことを示す応答をクライアントアプリケーション51に送信するよう受送信部11に指示する。
尚、本実施の形態では、トランザクションを認識する認識部の一例としても、コミット・ロールバック処理部18を設けている。
送受信部19は、サーバ20のデータベースサーバ53にデータベース接続要求、SQL文の処理要求及びコミット文等の処理要求を送信し、処理が終了したら結果を受信する。結果には、要求が正常に処理されたかどうかを示す戻り値が含まれ、次のトランザクションIDが引数として含まれることもある。
尚、これらの機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、クライアント10において、CPU90aが、データベースクライアント52のうちの受送信部11、接続処理部12、SQL処理部14、障害通知受信部16、コミット・ロールバック処理部18、送受信部19を実現する部分を例えば磁気ディスク装置90gからメインメモリ90cに読み込んで実行することにより、これらの機能部は実現される。
また、トランザクションID記憶部13及びトランザクションログ記憶部15は、例えば磁気ディスク装置90gにより実現される。
また、トランザクションID記憶部13及びトランザクションログ記憶部15は、例えば磁気ディスク装置90gにより実現される。
また、サーバ20は、受送信部21と、接続処理部22と、トランザクションID取得部23と、SQL処理部24と、ロック情報処理部26と、更新データ情報記憶部27と、コミット・ロールバック処理部28と、共有情報送受信部29とを備えている。
受送信部21は、データベースクライアント52からデータベース接続要求、SQL文の処理要求及びコミット文等の処理要求を受信し、その処理が終了すると、その結果を戻す。
接続処理部22は、受送信部21がデータベース接続要求をデータベースクライアント52から受信すると、データベース40(図1参照)への接続処理を行う。そして、トランザクションID取得部23に共有情報管理装置30aから未使用のトランザクションIDを取得させ、このトランザクションIDをデータベースクライアント52に送信するよう受送信部21に指示する。
トランザクションID取得部23は、接続処理部22又はコミット・ロールバック処理部28からの要求に応じて、トランザクションIDの取得要求を共有情報管理装置30aに送信するよう共有情報送受信部29に指示し、共有情報送受信部29がトランザクションIDを共有情報管理装置30aから受信すると、このトランザクションIDを要求元に返す。
SQL処理部24は、受送信部21がSQL文の処理要求をデータベースクライアント52から受信した場合に、ロック情報処理部26にトランザクションIDとロック対象のデータとを対応付けたロック情報の保持要求を出力させ、SQL文による更新内容と更新が確定しているかを示す情報とを対応付けた更新データ情報を更新データ情報記憶部27に記憶する。そして、SQL文の処理要求に対する応答をデータベースクライアント52に送信するよう受送信部21に指示する。本実施の形態では、データを処理する処理部、データを再処理する再処理部の一例として、SQL処理部24を設けている。
ロック情報処理部26は、SQL処理部24からの要求に応じて、トランザクションIDとロック対象のデータとを対応付けたロック情報の保持要求を共有情報管理装置30aに送信するよう共有情報送受信部29に指示し、共有情報送受信部29がロック情報を保持した旨を共有情報管理装置30aから受信すると、その旨をSQL処理部24に伝える。また、ロック情報処理部26は、コミット・ロールバック処理部28からの要求に応じて、トランザクションIDに対応するロック情報の削除要求を共有情報管理装置30aに送信するよう共有情報送受信部29に指示し、共有情報送受信部29がロック情報を削除した旨を共有情報管理装置30aから受信すると、その旨をコミット・ロールバック処理部28に伝える。
更新データ情報記憶部27は、SQL処理部24により送られたSQL文による更新内容と更新が確定しているかを示す情報とを対応付けた更新データ情報を記憶する。本実施の形態では、データに対するSQL文による更新内容を示す更新情報の一例として、更新情報を用いている。
コミット・ロールバック処理部28は、受送信部21がコミット文の処理要求をデータベースクライアント52から受信した場合に、処理要求に含まれるトランザクションIDに対応するロック情報の削除要求を出力させ、コミット文に対応する更新データ情報を確定させる。また、コミット・ロールバック処理部28は、受送信部21がロールバック文の処理要求をデータベースクライアント52から受信した場合に、そのトランザクションの更新データを全て取り消すと共に、処理要求に含まれるトランザクションIDに対応するロック情報の削除要求を出力させる。
共有情報送受信部29は、トランザクションID取得部23及びロック情報処理部26からの要求を共有情報管理装置30aに送信し、結果を受信する。
尚、これらの機能部は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、サーバ20において、CPU90aが、データベースサーバ53のうちの受送信部21、接続処理部22、トランザクションID取得部23、SQL処理部24、ロック情報処理部26、コミット・ロールバック処理部28、共有情報送受信部29を実現する部分を例えば磁気ディスク装置90gからメインメモリ90cに読み込んで実行することにより、これらの機能部は実現される。
また、更新データ情報記憶部27は、例えば磁気ディスク装置90gにより実現される。
また、更新データ情報記憶部27は、例えば磁気ディスク装置90gにより実現される。
図7は、クライアントアプリケーション51、データベースクライアント52、データベースサーバ53aの間での処理の流れの一例を示したシーケンス図である。ここでは、サーバ20aで障害が発生しない場合について示している。
まず、クライアントアプリケーション51は、データベース接続要求をデータベースクライアント52に送信する(ステップ101)。
すると、データベースクライアント52は、データベース接続要求をデータベースサーバ53aに送信する(ステップ201)。具体的には、受送信部11が、データベース接続要求をクライアントアプリケーション51から受信し、接続処理部12が、データベース接続要求の送信を送受信部19に指示し、送受信部19が、データベース接続要求をデータベースサーバ53aに送信する。
まず、クライアントアプリケーション51は、データベース接続要求をデータベースクライアント52に送信する(ステップ101)。
すると、データベースクライアント52は、データベース接続要求をデータベースサーバ53aに送信する(ステップ201)。具体的には、受送信部11が、データベース接続要求をクライアントアプリケーション51から受信し、接続処理部12が、データベース接続要求の送信を送受信部19に指示し、送受信部19が、データベース接続要求をデータベースサーバ53aに送信する。
これにより、データベースサーバ53aは、「接続OK」の応答にトランザクションID「10」を含めてデータベースクライアント52に送信する(ステップ202)。具体的には、受送信部21が、データベース接続要求を受信し、接続処理部22が、データベース40への接続処理を行うと共に、トランザクションID取得部23によりトランザクションID「10」を取得し、データベース接続要求が正常に処理されたことを示す「接続OK」とトランザクションID「10」とを含む応答の送信を受送信部21に指示し、受送信部21が、応答をデータベースクライアント52に送信する。
すると、データベースクライアント52は、「OK」の応答を既存技術で得られた接続ハンドルと共にクライアントアプリケーション51に送信する(ステップ102)。その際、データベースクライアント52は、トランザクションID情報131に示すように、トランザクションID「10」及び接続ハンドル等を保持しておく。具体的には、送受信部19が、データベース接続要求に対する応答をデータベースサーバ53aから受信し、接続処理部12が、応答に含まれるトランザクションID「10」、接続ハンドル、実ハンドル(接続ハンドルと同じ)、データベースサーバ53aの識別子、処理要求中フラグの初期値(処理要求中でないことを示す「0」)をトランザクションID記憶部13に記憶すると共に、要求が正常に処理されたことを示す「OK」の応答の送信を受送信部11に指示し、受送信部11が、応答をクライアントアプリケーション51に送信する。
次に、クライアントアプリケーション51が、SQL文「insert into t1 values (100, 200)」をデータベースクライアント52に送信したとする(ステップ103)。
すると、データベースクライアント52は、トランザクションログ151に示すように、このSQL文をトランザクションID「10」の発行順「1」の行に保持する。そして、SQL文「insert into t1 values (100, 200)」の処理要求をデータベースサーバ53aに送信する(ステップ203)。具体的には、受送信部11が、SQL文をクライアントアプリケーション51から受信し、SQL処理部14が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを処理要求中であることを示す「1」にし、トランザクションID記憶部13に記憶されたトランザクションIDと受信したSQL文とを対応付けてトランザクションログ記憶部15に記憶すると共に、SQL文の処理要求の送信を送受信部19に指示し、送受信部19が、SQL文の処理要求をデータベースサーバ53aに送信する。
すると、データベースクライアント52は、トランザクションログ151に示すように、このSQL文をトランザクションID「10」の発行順「1」の行に保持する。そして、SQL文「insert into t1 values (100, 200)」の処理要求をデータベースサーバ53aに送信する(ステップ203)。具体的には、受送信部11が、SQL文をクライアントアプリケーション51から受信し、SQL処理部14が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを処理要求中であることを示す「1」にし、トランザクションID記憶部13に記憶されたトランザクションIDと受信したSQL文とを対応付けてトランザクションログ記憶部15に記憶すると共に、SQL文の処理要求の送信を送受信部19に指示し、送受信部19が、SQL文の処理要求をデータベースサーバ53aに送信する。
これにより、データベースサーバ53aは、共有情報管理装置30a(図1参照)がロック情報261を保持するようにし、自身が更新データ情報271を保持するようにする。尚、ロック情報及び更新データ情報において、表ID「1」はSQL文の表「t1」を示し、行ID「123」はSQL文の「values (100, 200)」を挿入する行を示す。また、ロック情報の「Lock」欄の「X」は、排他ロック(eXclusive lock)が掛けられていることを意味しており、更新データ情報の「Dirty」欄の「D」は、対応する更新がコミットされておらず未確定であることを意味する。そして、データベースサーバ53は、「OK」の応答をデータベースクライアント52に送信する(ステップ204)。具体的には、受送信部21が、SQL文の処理要求を受信し、SQL処理部24が、ロック情報処理部26によりロック情報261の保持要求を共有情報管理装置30aに出力し、更新データ情報271を更新データ情報記憶部27に記憶すると共に、要求が正常に処理されたことを示す「OK」の応答の送信を受送信部21に指示し、受送信部21が、応答をデータベースクライアント52に送信する。
すると、データベースクライアント52は、「OK」の応答をクライアントアプリケーション51に送信する(ステップ104)。具体的には、送受信部19が、SQL文の処理要求に対する応答を受信し、SQL処理部14が、要求が正常に処理されたことを示す「OK」応答の送信を受送信部11に指示し、受送信部11が、応答をクライアントアプリケーション51に送信し、SQL処理部14が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「0」にする。
次いで、クライアントアプリケーション51が、コミット文をデータベースクライアント52に送信したとする(ステップ105)。
すると、データベースクライアント52は、コミット文の処理要求をデータベースサーバ53aに送信する(ステップ205)。具体的には、受送信部11が、コミット文をクライアントアプリケーション51から受信し、コミット・ロールバック処理部18が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「1」にすると共に、コミット文の処理要求の送信を送受信部19に指示し、送受信部19が、コミット文の処理要求をデータベースサーバ53aに送信する。
すると、データベースクライアント52は、コミット文の処理要求をデータベースサーバ53aに送信する(ステップ205)。具体的には、受送信部11が、コミット文をクライアントアプリケーション51から受信し、コミット・ロールバック処理部18が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「1」にすると共に、コミット文の処理要求の送信を送受信部19に指示し、送受信部19が、コミット文の処理要求をデータベースサーバ53aに送信する。
これにより、データベースサーバ53aは、自身が更新データ情報272を確定する。また、共有情報管理装置30a(図1参照)が、このトランザクションのロック情報261を解放し、ロック情報262の状態となるようにする。そして、「OK」の応答に次のトランザクションID「11」を含めてデータベースクライアント52に送信する(ステップ206)。具体的には、受送信部21が、コミット文の処理要求を受信し、コミット・ロールバック処理部28が、更新データ情報記憶部27に記憶された更新データ情報271を確定させると共に、ロック情報処理部26によりロック情報261の解放要求を共有情報管理装置30に出力し、要求が正常に処理されたことを示す「OK」と次のトランザクションID「11」とを含む応答の送信を受送信部21に指示し、受送信部21が、応答をデータベースクライアント52に送信する。
すると、データベースクライアント52は、トランザクションログ152に示すように、保持していたSQL文を削除し、トランザクションID情報132に示すように、トランザクションID「11」を保持する。そして、「OK」の応答をクライアントアプリケーション51に送信する(ステップ106)。具体的には、送受信部19が、コミット文の処理要求に対する応答を受信し、コミット・ロールバック処理部18が、トランザクションログ記憶部15の対象のトランザクションIDに対応するSQL文を削除し、応答に含まれるトランザクションID「11」をトランザクションID記憶部13に記憶し、コミット文の処理要求が正常に処理されたことを示す「OK」の応答の送信を受送信部11に指示し、受送信部11が、応答をクライアントアプリケーション51に送信し、コミット・ロールバック処理部18が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「0」にする。
図8は、クライアントアプリケーション51、データベースクライアント52、データベースサーバ53aの間での処理の流れの一例を示したシーケンス図である。ここでは、サーバ20aで障害が発生する場合について示している。尚、図8の処理の流れは、図7の処理の流れに引き続いて行われることを前提とするので、処理開始時に、データベースクライアント52は、トランザクションID情報133に示すように、トランザクションID「11」を保持しているものとする。
まず、クライアントアプリケーション51が、SQL文「update t1 set c2=c2+50 where c1=100」をデータベースクライアント52に送信したとする(ステップ111)。
すると、データベースクライアント52は、トランザクションログ154に示すように、このSQL文をトランザクションID「11」の発行順「1」の行に保持する。そして、SQL文「update t1 set c2=c2+50 where c1=100」の処理要求をデータベースサーバ53aに送信する(ステップ211)。具体的には、受送信部11が、SQL文をクライアントアプリケーション51から受信し、SQL処理部14が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「1」にし、トランザクションID記憶部13に記憶されたトランザクションIDと受信したSQL文とを対応付けてトランザクションログ記憶部15に記憶すると共に、SQL文の処理要求の送信を送受信部19に指示し、送受信部19が、SQL文の処理要求をデータベースサーバ53aに送信する。
まず、クライアントアプリケーション51が、SQL文「update t1 set c2=c2+50 where c1=100」をデータベースクライアント52に送信したとする(ステップ111)。
すると、データベースクライアント52は、トランザクションログ154に示すように、このSQL文をトランザクションID「11」の発行順「1」の行に保持する。そして、SQL文「update t1 set c2=c2+50 where c1=100」の処理要求をデータベースサーバ53aに送信する(ステップ211)。具体的には、受送信部11が、SQL文をクライアントアプリケーション51から受信し、SQL処理部14が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「1」にし、トランザクションID記憶部13に記憶されたトランザクションIDと受信したSQL文とを対応付けてトランザクションログ記憶部15に記憶すると共に、SQL文の処理要求の送信を送受信部19に指示し、送受信部19が、SQL文の処理要求をデータベースサーバ53aに送信する。
これにより、データベースサーバ53aは、共有情報管理装置30a(図1参照)がロック情報264を保持するようにし、自身が更新データ情報274を保持するようにする。そして、「OK」の応答をデータベースクライアント52に送信する(ステップ212)。具体的には、受送信部21が、SQL文の処理要求を受信し、SQL処理部24が、ロック情報処理部26によりロック情報264の保持要求を共有情報管理装置30aに出力し、更新データ情報274を更新データ情報記憶部27に記憶すると共に、要求が正常に処理されたことを示す「OK」の応答の送信を受送信部21に指示し、受送信部21が、応答をデータベースクライアント52に送信する。
すると、データベースクライアント52は、「OK」の応答をクライアントアプリケーション51に送信する(ステップ112)。具体的には、送受信部19が、SQL文の処理要求に対する応答を受信し、SQL処理部14が、要求が正常に処理されたことを示す「OK」応答の送信を受送信部11に指示し、受送信部11が、応答をクライアントアプリケーション51に送信し、SQL処理部14が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「0」にする。
次いで、クライアントアプリケーション51が、SQL文「insert into t1 values (120, 300)」をデータベースクライアント52に送信したとする(ステップ113)。
すると、データベースクライアント52は、トランザクションログ155に示すように、このSQL文をトランザクションID「11」の発行順「2」の行に保持する。そして、SQL文の処理要求をデータベースサーバ53aに送信する(ステップ213)。具体的には、受送信部11が、SQL文をクライアントアプリケーション51から受信し、SQL処理部14が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「1」にし、トランザクションID記憶部13に記憶されたトランザクションIDと受信したSQL文とを対応付けてトランザクションログ記憶部15に記憶すると共に、SQL文の処理要求の送信を送受信部19に指示し、送受信部19が、SQL文の処理要求をデータベースサーバ53aに送信する。
すると、データベースクライアント52は、トランザクションログ155に示すように、このSQL文をトランザクションID「11」の発行順「2」の行に保持する。そして、SQL文の処理要求をデータベースサーバ53aに送信する(ステップ213)。具体的には、受送信部11が、SQL文をクライアントアプリケーション51から受信し、SQL処理部14が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「1」にし、トランザクションID記憶部13に記憶されたトランザクションIDと受信したSQL文とを対応付けてトランザクションログ記憶部15に記憶すると共に、SQL文の処理要求の送信を送受信部19に指示し、送受信部19が、SQL文の処理要求をデータベースサーバ53aに送信する。
ここで、このデータベースサーバ53aが動作するサーバ20aで障害が発生したとする。
すると、データベースサーバ53aは、データベースクライアント52に障害の発生を通知する(ステップ214)。但し、サーバ20aでハードウェア障害が発生した場合等、データベースサーバ53aがサーバ20aでの障害の発生を通知できないこともある。そのような場合は、サーバ20aで動作する障害検出ソフトウェア54aからのハートビートが途絶えることにより、サーバ20a以外のサーバ20で動作する障害検出ソフトウェア54が、サーバ20aでの障害の発生を検知できるので、この障害検出ソフトウェア54がデータベースクライアント52に障害の発生を通知してもよい。
すると、データベースサーバ53aは、データベースクライアント52に障害の発生を通知する(ステップ214)。但し、サーバ20aでハードウェア障害が発生した場合等、データベースサーバ53aがサーバ20aでの障害の発生を通知できないこともある。そのような場合は、サーバ20aで動作する障害検出ソフトウェア54aからのハートビートが途絶えることにより、サーバ20a以外のサーバ20で動作する障害検出ソフトウェア54が、サーバ20aでの障害の発生を検知できるので、この障害検出ソフトウェア54がデータベースクライアント52に障害の発生を通知してもよい。
図9は、クライアントアプリケーション51、データベースクライアント52、データベースサーバ53bの間での処理の流れの一例を示したシーケンス図である。ここでは、サーバ20aで障害が発生したので、サーバ20bを接続先とした場合について示している。
まず、図8のステップ214で障害の発生が通知されたが、共有情報管理装置30a(図1参照)は、ロック情報266に示すように、図8のロック情報264をそのまま保持しているものとする。
また、サーバ20aのみが未確定の更新データ情報を保持していた場合は、その未確定の更新データ情報は、サーバ20aの障害により失われるため、処理は不要であるが、サーバ20bも未確定の更新データ情報を保持している場合は、所定の処理を行う必要がある。尚、サーバ20bが未確定の更新データ情報を保持しているという状況は、例えば、サーバ20bが対象のデータを含むページをキャッシュしているような場合に生じ得る。そして、この場合は、復旧処理を行うことにより、自身が、直前のコミット済みの更新データ情報である更新データ情報276(図7の更新データ情報272と同じ)を保持するようにする。尚、この復旧処理を行う機能は、更新情報をトランザクションが開始される前の状態に復旧する復旧部の一例である。
まず、図8のステップ214で障害の発生が通知されたが、共有情報管理装置30a(図1参照)は、ロック情報266に示すように、図8のロック情報264をそのまま保持しているものとする。
また、サーバ20aのみが未確定の更新データ情報を保持していた場合は、その未確定の更新データ情報は、サーバ20aの障害により失われるため、処理は不要であるが、サーバ20bも未確定の更新データ情報を保持している場合は、所定の処理を行う必要がある。尚、サーバ20bが未確定の更新データ情報を保持しているという状況は、例えば、サーバ20bが対象のデータを含むページをキャッシュしているような場合に生じ得る。そして、この場合は、復旧処理を行うことにより、自身が、直前のコミット済みの更新データ情報である更新データ情報276(図7の更新データ情報272と同じ)を保持するようにする。尚、この復旧処理を行う機能は、更新情報をトランザクションが開始される前の状態に復旧する復旧部の一例である。
さて、障害の発生が通知されると、データベースクライアント52は、トランザクションID「11」での接続要求をデータベースサーバ53bに送信する(ステップ221)。具体的には、送受信部19が、障害発生通知を例えばデータベースサーバ53aから受信し、接続処理部12が、トランザクションID記憶部13からトランザクションID「11」を取得し、トランザクションID「11」での接続要求の送信を送受信部19に指示し、送受信部19が、トランザクションID「11」での接続要求をデータベースサーバ53bに送信する。
これにより、データベースサーバ53bは、「OK」の応答をデータベースクライアント52に送信する(ステップ222)。具体的には、受送信部21が、接続要求を受信し、接続処理部22が、要求が正常に処理されたことを示す「OK」の応答の送信を受送信部21に指示し、受送信部21が、応答をデータベースクライアント52に送信する。
すると、データベースクライアント52は、トランザクションID情報136に示すように、トランザクションID記憶部13に記憶されている該当トランザクションIDに対する実ハンドル及び接続先のデータベースサーバ53の識別子を更新し、トランザクションログ156に示すように保持されているトランザクションID「11」に対応するSQL文を順に発行する。
即ち、まず、データベースクライアント52は、SQL文「update t1 set c2=c2+50 where c1=100」の処理要求をデータベースサーバ53bに送信する(ステップ223)。具体的には、SQL処理部14が、トランザクションログ記憶部15からトランザクションID「11」の発行順「1」のSQL文を読み出し、SQL文の処理要求の送信を送受信部19に指示し、送受信部19が、SQL文の処理要求をデータベースサーバ53bに送信する。
即ち、まず、データベースクライアント52は、SQL文「update t1 set c2=c2+50 where c1=100」の処理要求をデータベースサーバ53bに送信する(ステップ223)。具体的には、SQL処理部14が、トランザクションログ記憶部15からトランザクションID「11」の発行順「1」のSQL文を読み出し、SQL文の処理要求の送信を送受信部19に指示し、送受信部19が、SQL文の処理要求をデータベースサーバ53bに送信する。
これにより、データベースサーバ53bは、共有情報管理装置30a(図1参照)がロック情報267を保持するようにし、自身が更新データ情報277を保持するようにする。そして、「OK」の応答をデータベースクライアント52に送信する(ステップ224)。具体的には、受送信部21が、SQL文の処理要求を受信し、SQL処理部24が、ロック情報処理部26によりロック情報267の保持要求を共有情報管理装置30aに出力し、更新データ情報277を更新データ情報記憶部27に記憶すると共に、要求が正常に処理されたことを示す「OK」の応答の送信を受送信部21に指示し、受送信部21が、応答をデータベースクライアント52に送信する。尚、ロック情報267の保持要求を受けた共有情報管理装置30aは、ロック情報267と同じ内容のロック情報266を既に保持しているので、特に処理は行わない。
また、データベースクライアント52は、SQL文「insert into t1 values (120, 300)」の処理要求をデータベースサーバ53bに送信する(ステップ225)。具体的には、SQL処理部14が、トランザクションログ記憶部15からトランザクションID「11」の発行順「2」のSQL文を読み出し、SQL文の処理要求の送信を送受信部19に指示し、送受信部19が、SQL文の処理要求をデータベースサーバ53bに送信する。
これにより、データベースサーバ53bは、共有情報管理装置30a(図1参照)がロック情報268を保持するようにし、自身が更新データ情報278を保持するようにする。そして、「OK」の応答をデータベースクライアント52に送信する(ステップ226)。具体的には、受送信部21が、SQL文の処理要求を受信し、SQL処理部24が、ロック情報処理部26によりロック情報268の保持要求を共有情報管理装置30aに出力し、更新データ情報278を更新データ情報記憶部27に記憶すると共に、要求が正常に処理されたことを示す「OK」の応答の送信を受送信部21に指示し、受送信部21が、応答をデータベースクライアント52に送信する。
すると、データベースクライアント52は、「OK」の応答をクライアントアプリケーション51に送信する(ステップ121)。具体的には、送受信部19が、SQL文の処理要求に対する応答をデータベースサーバ53から受信し、SQL処理部14が、トランザクションID「11」に対応する未処理のSQL文がトランザクションログ記憶部15に記憶されていないことを確認し、要求が正常に処理されたことを示す「OK」の応答の送信を受送信部11に指示し、受送信部11が、応答をクライアントアプリケーション51に送信し、SQL処理部14が、トランザクションID記憶部13の該当するトランザクションIDの処理要求中フラグを「0」にする。
以上述べたように、本実施の形態では、クライアントアプリケーション51が発行したSQL文をデータベースクライアント52がログしておき、あるトランザクションIDで処理中にサーバ20aがダウンした場合に、そのトランザクションIDに対応するロック情報は他のサーバ20と共有可能な状態で保持したまま、データベースクライアント52はログしておいたSQL文を同じトランザクションIDで再度実行するようにした。これにより、データベース40に障害があったことをクライアントアプリケーション51に知られることなく、クライアントアプリケーション51が発行したSQL文の実行を継続することが可能となった。
ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム(装置又は機器)、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ(RAM)、リードオンリーメモリ(ROM)、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ(CD−ROM)、コンパクトディスク−リード/ライト(CD−R/W)及びDVDが含まれる。
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。
10…クライアント、20…サーバ、11,21…受送信部、12,22…接続処理部、13…トランザクションID記憶部、23…トランザクションID取得部、14,24…SQL処理部、15…トランザクションログ記憶部、16…障害通知受信部、26…ロック情報処理部、27…更新データ情報記憶部、18,28…コミット・ロールバック処理部、19…送受信部、29…共有情報送受信部、30…共有情報管理装置、40…データベース、51…クライアントアプリケーション、52…データベースクライアント、53…データベースサーバ、54…障害検出ソフトウェア、81,82,83…ネットワーク
Claims (9)
- データベースに対する処理を要求するクライアントと、当該クライアントによる要求に応じて当該データベースに対する処理を行う複数のサーバとを含み、当該データベースに対する処理を行うシステムであって、
前記クライアントは、
自身で動作するアプリケーションから前記データベースにおけるデータを処理するSQL文を受け付けると、当該SQL文を記憶する記憶部と、
前記複数のサーバのうちの一のサーバに特定のトランザクションとして前記SQL文による処理を要求する処理要求部と、
前記一のサーバにおいて前記特定のトランザクションがコミットされる前に障害が発生すると、前記複数のサーバのうちの他のサーバに、当該特定のトランザクションとして、前記記憶部に記憶された前記SQL文による再処理を要求する再処理要求部と
を含み、
前記複数のサーバのそれぞれは、
前記処理要求部による要求に応じて、前記データに前記特定のトランザクションによるロックを掛けた状態で当該データを処理する処理部と、
前記データを処理したサーバにおいて前記特定のトランザクションがコミットされる前に障害が発生すると、前記データに前記ロックを掛けたままの状態で、前記再処理要求部による要求に応じて、当該データを再処理する再処理部と
を含む、システム。 - 前記クライアントは、前記複数のサーバの何れかに前記データベースへの接続又はトランザクションのコミットを要求したときの応答に基づいて、前記特定のトランザクションを認識する認識部を更に含む、請求項1のシステム。
- 前記複数のサーバのそれぞれは、前記データを処理したサーバにおいて前記特定のトランザクションがコミットされる前に障害が発生すると、当該データに対する前記SQL文による更新内容を示す更新情報を自身が保持していれば、当該更新情報を当該特定のトランザクションが開始される前の状態に復旧する復旧部を更に含む、請求項1又は請求項2のシステム。
- 前記データに前記特定のトランザクションによるロックが掛けられていることを示すロック情報を、前記複数のサーバにより共有される情報として管理する共有情報管理装置を更に含む、請求項1乃至請求項3の何れかのシステム。
- データベースに対する処理を要求するクライアントと、当該クライアントによる要求に応じて当該データベースに対する処理を行う複数のサーバとを含むシステムにおいて、当該データベースに対する処理を行う方法であって、
前記クライアントが、自身で動作するアプリケーションから前記データベースにおけるデータを処理するSQL文を受け付けると、当該SQL文を所定の記憶部に記憶するステップと、
前記クライアントが、前記複数のサーバのうちの一のサーバに特定のトランザクションとして前記SQL文による処理を要求するステップと、
前記一のサーバが、前記クライアントによる処理の要求に応じて、前記データに前記特定のトランザクションによるロックを掛けた状態で当該データを処理するステップと、
前記クライアントが、前記一のサーバにおいて前記特定のトランザクションがコミットされる前に障害が発生すると、前記複数のサーバのうちの他のサーバに、当該特定のトランザクションとして、前記所定の記憶部に記憶された前記SQL文による再処理を要求するステップと、
前記他のサーバが、前記一のサーバにおいて前記特定のトランザクションがコミットされる前に障害が発生すると、前記データに前記ロックを掛けたままの状態で、前記クライアントによる再処理の要求に応じて、当該データを処理するステップと
を含む、方法。 - データベースに対する処理を要求するクライアントと、当該クライアントによる要求に応じて当該データベースに対する処理を行う複数のサーバとを含むシステムにおいて、当該データベースに対する処理を行う方法であって、
前記クライアントが、前記複数のサーバのうちの一のサーバから次のトランザクションを識別する識別情報を受信するステップと、
前記クライアントが、自身で動作するアプリケーションから前記データベースにおけるデータを処理するSQL文を受け付けると、前記識別情報と当該SQL文とを対応付けて所定の記憶部に記憶するステップと、
前記クライアントが、前記一のサーバに前記識別情報と前記SQL文による処理要求とを送信するステップと、
前記一のサーバが、前記クライアントから前記識別情報と前記処理要求とを受信すると、前記データと当該識別情報と当該データにロックが掛けられていることを示す情報とを対応付けたロック情報が前記複数のサーバで共有される記憶領域に記憶された状態で、当該データを処理するステップと、
前記クライアントが、前記一のサーバにおいて前記データの処理がコミットされる前に障害が発生すると、前記複数のサーバのうちの他のサーバに、前記識別情報と、前記所定の記憶部に当該識別情報に対応付けて記憶された前記SQL文による再処理要求とを送信するステップと、
前記他のサーバが、前記一のサーバにおいて前記データの処理がコミットされる前に障害が発生すると、前記ロック情報が前記記憶領域に記憶されたままの状態で、前記クライアントから前記識別情報と前記再処理要求とを受信すると、当該データを処理するステップと
を含む、方法。 - 前記識別情報を受信するステップでは、前記一のサーバに送信した前記データベースへの接続要求に対する応答又は前記一のサーバに送信したトランザクションのコミット要求に対する応答に含まれる当該識別情報を受信する、請求項6の方法。
- データベースに対する処理を要求するクライアントと、当該クライアントによる要求に応じて当該データベースに対する処理を行う複数のサーバとを含むシステムにおいて、当該クライアントとして、コンピュータを機能させるプログラムであって、
前記コンピュータを、
自身で動作するアプリケーションから前記データベースにおけるデータを処理するSQL文を受け付けると、当該SQL文を記憶する記憶部と、
前記複数のサーバのうちの一のサーバに特定のトランザクションとして前記SQL文による処理を要求することにより、当該一のサーバが、前記データに当該特定のトランザクションによるロックを掛けた状態で当該データを処理するように制御する処理制御部と、
前記一のサーバにおいて前記特定のトランザクションがコミットされる前に障害が発生すると、前記複数のサーバのうちの他のサーバに、当該特定のトランザクションとして、前記記憶部に記憶された前記SQL文による再処理を要求することにより、当該他のサーバが、前記データにロックを掛けたままの状態で、当該データを再処理するように制御する再処理制御部と
して機能させる、プログラム。 - データベースに対する処理を要求するクライアントと、当該クライアントによる要求に応じて当該データベースに対する処理を行う複数のサーバとを含むシステムにおいて、当該サーバとして、コンピュータを機能させるプログラムであって、
前記コンピュータを、
前記クライアントから特定のトランザクションとしてなされた、前記データベースにおけるデータを処理するSQL文による処理の要求に応じて、当該データに当該特定のトランザクションによるロックを掛けた状態で当該データを処理する処理部と、
前記データを処理したサーバにおいて前記特定のトランザクションがコミットされる前に障害が発生すると、前記データに前記ロックを掛けたままの状態で、前記クライアントから前記特定のトランザクションとしてなされた、前記SQL文による再処理の要求に応じて、当該データを再処理する再処理部と
して機能させる、プログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012181880A JP2014038564A (ja) | 2012-08-20 | 2012-08-20 | データベースに対する処理を行うシステム及び方法 |
US13/969,980 US9386073B2 (en) | 2012-08-20 | 2013-08-19 | Techniques for performing processing for database |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012181880A JP2014038564A (ja) | 2012-08-20 | 2012-08-20 | データベースに対する処理を行うシステム及び方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2014038564A true JP2014038564A (ja) | 2014-02-27 |
Family
ID=50100867
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012181880A Pending JP2014038564A (ja) | 2012-08-20 | 2012-08-20 | データベースに対する処理を行うシステム及び方法 |
Country Status (2)
Country | Link |
---|---|
US (1) | US9386073B2 (ja) |
JP (1) | JP2014038564A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017042890A1 (ja) * | 2015-09-08 | 2017-03-16 | 株式会社東芝 | データベースシステム、サーバ装置、プログラムおよび情報処理方法 |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110580232B (zh) * | 2018-06-08 | 2021-10-29 | 杭州宏杉科技股份有限公司 | 一种锁管理的方法及装置 |
CN111444081B (zh) * | 2019-01-17 | 2023-05-02 | 阿里巴巴集团控股有限公司 | 确定、响应和生成方法、客户端、服务器、设备和介质 |
CN116662059B (zh) * | 2023-07-24 | 2023-10-24 | 上海爱可生信息技术股份有限公司 | MySQL数据库CPU故障诊断及自愈方法及可读存储介质 |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH05334163A (ja) | 1992-05-29 | 1993-12-17 | Hitachi Ltd | 複数システム間共用メモリ排他制御方式 |
JP2507235B2 (ja) | 1994-06-24 | 1996-06-12 | インターナショナル・ビジネス・マシーンズ・コーポレイション | クライアント・サ―バ・コンピュ―タ・システム、及びそのクライアント・コンピュ―タ、サ―バ・コンピュ―タ、並びにオブジェクト更新方法 |
JPH08235039A (ja) | 1995-02-27 | 1996-09-13 | Hitachi Ltd | トランザクション処理における履歴情報解析方法 |
US6594667B2 (en) * | 1999-08-23 | 2003-07-15 | International Business Machines Corporation | Method, system and program products for modifying coupling facility structures |
JP2003036196A (ja) | 2001-05-18 | 2003-02-07 | Hitachi Ltd | キューファイル回復制御方法及びその実施装置並びにその処理プログラム |
US7051052B1 (en) * | 2002-06-20 | 2006-05-23 | Unisys Corporation | Method for reading audit data from a remote mirrored disk for application to remote database backup copy |
JP2004086543A (ja) | 2002-08-27 | 2004-03-18 | Hitachi Ltd | 障害時におけるキュー制御方法およびシステム |
US7103619B1 (en) * | 2002-09-26 | 2006-09-05 | Unisys Corporation | System and method for automatic audit data archiving within a remote database backup system |
US7346905B2 (en) | 2003-06-10 | 2008-03-18 | International Business Machines Corporation | Apparatus and method for maintaining resource integrity without a unified transaction manager in a software environment |
JP2005250998A (ja) | 2004-03-05 | 2005-09-15 | Nec Corp | 分散トランザクションシステム及び分散トランザクションの障害復旧方法並びにサーバ装置及びプログラム |
US8086811B2 (en) * | 2008-02-25 | 2011-12-27 | International Business Machines Corporation | Optimizations of a perform frame management function issued by pageable guests |
US20130205108A1 (en) * | 2012-02-06 | 2013-08-08 | Kaminario Technologies Ltd. | Managing reservation-control in a storage system |
-
2012
- 2012-08-20 JP JP2012181880A patent/JP2014038564A/ja active Pending
-
2013
- 2013-08-19 US US13/969,980 patent/US9386073B2/en active Active
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017042890A1 (ja) * | 2015-09-08 | 2017-03-16 | 株式会社東芝 | データベースシステム、サーバ装置、プログラムおよび情報処理方法 |
Also Published As
Publication number | Publication date |
---|---|
US9386073B2 (en) | 2016-07-05 |
US20140052826A1 (en) | 2014-02-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9916201B2 (en) | Write performance in fault-tolerant clustered storage systems | |
US6665814B2 (en) | Method and apparatus for providing serialization support for a computer system | |
US8868514B2 (en) | Transaction support for distributed data | |
US7702741B2 (en) | Configuring or reconfiguring a multi-master information sharing environment | |
JP4833590B2 (ja) | 同時トランザクション(concurrenttransactions)とページ同期(pagesynchronization) | |
US8548945B2 (en) | Database caching utilizing asynchronous log-based replication | |
US7996363B2 (en) | Real-time apply mechanism in standby database environments | |
US7693882B2 (en) | Replicating data across the nodes in a cluster environment | |
US7917596B2 (en) | Super master | |
JP4286786B2 (ja) | 分散トランザクション処理装置、分散トランザクション処理プログラムおよび分散トランザクション処理方法 | |
EP1704480B1 (en) | Cluster database with remote data mirroring | |
US20120011100A1 (en) | Snapshot acquisition processing technique | |
US20050160315A1 (en) | Geographically distributed clusters | |
US9652492B2 (en) | Out-of-order execution of strictly-ordered transactional workloads | |
US20120278429A1 (en) | Cluster system, synchronization controlling method, server, and synchronization controlling program | |
WO2022048358A1 (zh) | 数据处理方法、装置及存储介质 | |
US20030065971A1 (en) | System-managed duplexing of coupling facility structures | |
US20140089260A1 (en) | Workload transitioning in an in-memory data grid | |
JP2014038564A (ja) | データベースに対する処理を行うシステム及び方法 | |
KR100745878B1 (ko) | 저장 제어 장치 및 방법, 컴퓨터 프로그램 제품 | |
US7899785B2 (en) | Reconfiguring propagation streams in distributed information sharing | |
US9910893B2 (en) | Failover and resume when using ordered sequences in a multi-instance database environment | |
US11762821B2 (en) | Moving window data deduplication in distributed storage | |
US11422715B1 (en) | Direct read in clustered file systems | |
US11669516B2 (en) | Fault tolerance for transaction mirroring |