JP6517753B2 - マスターサーバ、テーブル更新方法、およびプログラム - Google Patents

Description

本発明の実施形態は、マスターサーバ、テーブル更新方法、およびプログラムに関する。

データベースに格納されたテーブルへのデータの書き込み処理において、レプリケーションと称される処理が行われている。「レプリケーション」とは、クライアントからデータの書込要求を受信した場合、マスターサーバのテーブル（ラベル付けされたデータ書き込み領域あるいはデータ）だけでなく、スレーブサーバのテーブルにもデータの書き込みを行う処理である。

また、マスターサーバのテーブルに対する書き込み性能を向上させるため、非同期レプリケーションが行われている。「非同期レプリケーション」とは、マスターサーバのテーブルへのデータの書き込みが完了した場合、スレーブサーバのテーブルへのデータの書き込み完了を待たずに、クライアントに書き込み完了通知を送信する処理である。

しかしながら、非同期レプリケーションが行われると、スレーブサーバのテーブルへのデータの書き込みに遅延が発生する場合があった。特に、マスターサーバが一時的に大量の書込み要求を受信すると、スレーブサーバのテーブルに対するデータの書き込み遅延が大きくなる。このため、迅速に更新する必要のある優先度の高いテーブルに対する更新処理が、大量の書込要求の影響で遅延する場合があった。

特開２０１２−６４１３０号公報

本発明が解決しようとする課題は、優先度の高いテーブルに対する更新処理を迅速に行うことができるマスターサーバ、テーブル更新方法、およびプログラムを提供することである。

実施形態のマスターサーバは、記憶部と、テーブル更新部と、スケジュール部と、差分送信部とを持つ。前記記憶部は、テーブルで管理されるデータを記憶する。前記テーブル更新部は、クライアントから受信した書込要求に基づき、前記記憶部におけるテーブルを更新すると共に、前記更新の内容を認識可能な更新差分情報を生成する。前記スケジュール部は、前記テーブル更新部により生成された前記更新差分情報を自装置と並行してデータを記憶するスレーブサーバに送信する順番を、前記テーブルごとに設定される優先度に基づいて制御する。前記差分送信部は、前記スケジュール部によって制御された順番に応じて、前記更新差分情報を前記スレーブサーバに送信する。

実施形態に係るストレージシステム１０の全体構成を示す図。 実施形態に係るマスターサーバ１００およびスレーブサーバ２００の動作を示す図。 実施形態に係る記憶部１５０に格納されている設定情報Ｓの一例を示す図。 実施形態に係るマスターサーバ１００の動作の一例を示す図。 実施形態に係るマスターサーバ１００の動作の一例を示す図。 実施形態に係るマスターサーバ１００の動作の一例を示す図。 実施形態に係るスケジュール部１２０によって取得される更新差分の順番の一例を示す図。 実施形態に係る差分送信部１３０によって送信される更新差分の順番の一例を示す図。 実施形態に係る優先度の設定によって得られる効果の一例を示す図。 実施形態に係る更新順序の一貫性を説明するための図。 実施形態に係るマスターサーバ１００の動作の一例を示す図。 実施形態に係るマスターサーバ１００の動作の一例を示す図。 実施形態に係るマスターサーバ１００の動作の一例を示す図。 実施形態に係るマスターサーバ１００の動作の一例を示す図。 実施形態に係るマスターサーバ１００の動作の一例を示す図。 実施形態に係るＳＱＬ処理部１１０の動作を示すフローチャート。 実施形態に係るスケジュール部１２０の動作を示すフローチャート。 実施形態に係る差分送信部１３０の動作を示すフローチャート。 実施形態に係るＳＱＬ処理部２１０の動作を示すフローチャート。

以下、実施形態のマスターサーバ、テーブル更新方法、およびプログラムを、図面を参照して説明する。

図１は、実施形態に係るストレージシステム１０の全体構成を示す図である。図１に示されるように、本実施形態のストレージシステム１０は、マスターサーバ１００と、スレーブサーバ２００と、クライアント端末３００とを備える。マスターサーバ１００、スレーブサーバ２００、およびクライアント端末３００は、ネットワークＮＷを介して互いに接続される。ネットワークＮＷは、例えば、ＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）等である。

マスターサーバ１００は、クライアント端末３００からの要求に応じて、データを記憶するサーバである。マスターサーバ１００は、ＳＱＬ処理部１１０と、スケジュール部１２０と、差分送信部１３０と、書込要求受信部１４０と、記憶部１５０とを備える。

ＳＱＬ処理部１１０、スケジュール部１２０、差分送信部１３０、および書込要求受信部１４０は、例えば、マスターサーバ１００のプロセッサがプログラムを実行することで実現されてもよいし、ＬＳＩ（Large Scale Integration）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードウェアによって実現されてもよいし、ソフトウェアとハードウェアが協働することで実現されてもよい。

記憶部１５０は、例えば、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ、またはこれらのうち複数が組み合わされたハイブリッド型記憶装置などにより実現される。記憶部１５０は、テーブルで管理されるデータを記憶する。テーブルとは、例えば、ラベル付けされたデータ書き込み領域あるいはデータである。詳細は後述するが、テーブルには優先度が設定されている。また、詳細は後述するが、記憶部１５０は、テーブルの優先度と、テーブルが属するグループとが関連付けられた設定情報Ｓを記憶している。

スレーブサーバ２００は、レプリケーションを行うために設けられたサーバであり、マスターサーバ１００に記憶されたテーブルと同じテーブルを記憶する。すなわち、スレーブサーバ２００は、マスターサーバ１００と並行してデータを記憶する。スレーブサーバ２００は、ＳＱＬ処理部２１０と、差分受信部２２０と、記憶部２３０とを備える。

ＳＱＬ処理部２１０および差分受信部２２０は、例えば、スレーブサーバ２００のプロセッサがプログラムを実行することで実現されてもよいし、ＬＳＩ、ＡＳＩＣ、ＦＰＧＡなどのハードウェアによって実現されてもよいし、ソフトウェアとハードウェアが協働することで実現されてもよい。

記憶部２３０は、例えば、ＲＡＭ、ＲＯＭ、ＨＤＤ、ＳＳＤ、フラッシュメモリ、またはこれらのうち複数が組み合わされたハイブリッド型記憶装置などにより実現される。

クライアント端末３００は、ネットワークＮＷを介してマスターサーバ１００にデータの書き込みを要求する端末である。クライアント端末３００は、デスクトップ型のコンピュータまたはノート型のコンピュータであるが、これに限られない。例えば、クライアント端末３００は、タブレット端末、スマートフォンなどの携帯電話、またはＰＤＡ（Personal Digital Assistant）であってもよい。

クライアント端末３００は、表示部３１０と、入力部３２０と、書込要求送信部３３０とを備える。表示部３１０は、液晶表示装置などの表示装置である。入力部３２０は、キーボードやマウスなどの入力装置である。クライアント端末３００がスマートフォンなどの携帯電話またはタブレット端末である場合には、入力部３２０はタッチパネルなどの入力装置であってもよい。

書込要求送信部３３０は、例えば、クライアント端末３００のプロセッサがプログラムを実行することで実現されてもよいし、ＬＳＩ、ＡＳＩＣ、ＦＰＧＡなどのハードウェアによって実現されてもよいし、ソフトウェアとハードウェアが協働することで実現されてもよい。

ユーザは、入力部３２０を用いてマスターサーバ１００の記憶部１５０に書き込むデータを指定する。書込要求送信部３３０は、指定されたデータを記憶部１５０に書き込むための書込要求を、マスターサーバ１００に送信する。書込要求には、記憶部１５０に書き込まれるデータの他、データの書き込み先のアドレスおよびデータの書き込みにより更新されるテーブルの識別情報などが含まれる。

図２は、実施形態に係るマスターサーバ１００およびスレーブサーバ２００の動作を示す図である。まず、マスターサーバ１００の書込要求受信部１４０は、クライアント端末３００から送信された書込要求を受信する。次に、書込要求受信部１４０は、受信した書込要求をＳＱＬ処理部１１０に出力する。

ＳＱＬ処理部１１０は、クライアント端末３００から受信した書込要求に基づき、記憶部１５０におけるテーブルを更新すると共に、更新の内容を認識可能な更新差分（更新差分情報）を生成するテーブル更新部として機能する。具体的に、ＳＱＬ処理部１１０は、書込要求受信部１４０から入力された書込要求に基づいてデータを記憶部１５０に書き込むことで、記憶部１５０に記憶されたテーブルを更新する。その後、ＳＱＬ処理部１１０は、更新の内容を認識可能な更新差分を生成し、生成した更新差分をＦＩＦＯ（First-In, First-Out）のキュー１６１に格納する。

更新差分は、ＳＱＬ処理部１１０が記憶部１５０に対して行った更新の内容を認識可能な情報であり、例えば、更新が行われるごとに付与される一連番号、更新されたテーブルの識別情報、更新されたデータそのもの（更新の内容が削除であれば削除された旨を示す情報）等を含む。ＳＱＬ処理部１１０は、記憶部１５０に記憶されたテーブルを更新する度に、更新差分をキュー１６１に格納していく。

スケジュール部１２０は、ＳＱＬ処理部１１０により生成された更新差分をマスターサーバ１００と並行してデータを記憶するスレーブサーバ２００に送信する順番を、テーブルごとに設定される優先度に基づいて制御する。具体的に、スケジュール部１２０は、キュー１６１から更新差分を一つ取得し、取得した更新差分を３つのキュー１６２から１６４のいずれかに格納する。キュー１６２から１６４は、ＦＩＦＯのキューであり、それぞれ優先度が割り当てられている。具体的には、キュー１６２は優先度１（高優先度）のキューであり、キュー１６３は優先度２（中優先度）のキューであり、キュー１６４は優先度３（低優先度）のキューである。例えば、スケジュール部１２０は、優先度１のテーブルの更新差分をキュー１６２に格納し、優先度２のテーブルの更新差分をキュー１６３に格納し、優先度３のテーブルの更新差分をキュー１６４に格納する。

図３は、実施形態に係る記憶部１５０に格納されている設定情報Ｓの一例を示す図である。設定情報Ｓには、「テーブル名」の項目と、「優先度」の項目と、「グループ」の項目とが含まれる。テーブル名は、記憶部１５０に記憶されているテーブルの名称を示す情報である。優先度は、記憶部１５０に記憶されているテーブルの優先度を示す情報である。グループは、記憶部１５０に記憶されているテーブルの属するグループを示す情報である。

図３において、テーブル名が“Normal”であるテーブルは、定期的に更新されるテーブルである。テーブル名が“Log”であるテーブルは、頻繁に更新されるテーブルである。テーブル名が“Error”であるテーブルは、エラー発生時にのみ更新されるテーブルである。このため、更新差分の発生頻度は“Log”が最も高く、“Error”が最も低い。

優先度が高いテーブルほど、優先的にスレーブサーバ２００の記憶部２３０に格納される。“Normal”の優先度は２であり、“Log”の優先度は３であり、“Error”の優先度は１である。このため、“Error”の更新差分が最も優先的にスレーブサーバ２００に送信され、記憶部２３０内の“Error”のテーブルがスレーブサーバ２００において最も優先的に更新される。

図４から図６は、実施形態に係るマスターサーバ１００の動作の一例を示す図である。図４に示される例において、スケジュール部１２０は、“Log”の更新差分Ｌ−１、“Normal”の更新差分Ｎ−１、および“Log”の更新差分Ｌ−２を、この順番でキュー１６１から取得している。前述したように、“Log”の優先度は３（低優先度）であり、“Normal”の優先度は２（中優先度）である。

この場合、図５に示されるように、スケジュール部１２０は、１番目に取得した更新差分Ｌ−１を、優先度３のキュー１６４に格納する。次に、スケジュール部１２０は、２番目に取得した更新差分Ｎ−１を、優先度２のキュー１６３に格納する。その後、スケジュール部１２０は、３番目に取得した更新差分Ｌ−２を、優先度３のキュー１６４に格納する。

差分送信部１３０は、優先度１のキュー１６２、優先度２のキュー１６３、優先度３のキュー１６４から、優先度に基づく順番で更新差分を取得する。図６に示される例においては、優先度１のキュー１６２に更新差分が格納されていないため、差分送信部１３０は、優先度２のキュー１６３から更新差分Ｎ−１を取得し、取得した更新差分Ｎ−１をスレーブサーバ２００に送信する。次に、差分送信部１３０は、優先度３のキュー１６４から更新差分Ｌ−１を取得し、取得した更新差分Ｌ−１をスレーブサーバ２００に送信する。その後、差分送信部１３０は、優先度３のキュー１６４から更新差分Ｌ−２を取得し、取得した更新差分Ｌ−２をスレーブサーバ２００に送信する。

このように、スケジュール部１２０は、ＳＱＬ処理部１１０から更新差分Ｌ−１を取得した後、更新差分Ｎ−１を取得した場合、更新差分Ｌ−１に係るテーブルの優先度と、更新差分Ｎ−１に係るテーブルの優先度とを比較し、更新差分Ｌ−１をスレーブサーバ２００に送信する順番と、更新差分Ｎ−１をスレーブサーバ２００に送信する順番とを入れ替えるか否かを判定する。具体的には、更新差分Ｎ−１に係るテーブルの優先度２の方が更新差分Ｌ−１に係るテーブルの優先度３よりも高いため、スケジュール部１２０は、更新差分Ｌ−１の順番と更新差分Ｎ−１の順番とを、キュー１６３およびキュー１６４を用いて入れ替える。

これによって、マスターサーバ１００は、優先度の高いテーブルに対する更新処理を迅速にスレーブサーバ２００に行わせることができる。また、スケジュール部１２０は、複数のキュー１６２から１６４を用いて更新差分を入れ替えるため、更新差分の送信順序を効率的に制御することができる。

また、差分送信部１３０は、優先度の高いキューから順に更新差分を取得し、取得した更新差分をスレーブサーバ２００に送信する。これによって、マスターサーバ１００は、スケジュール部１２０によって制御された順番に従って更新差分をスレーブサーバ２００に送信することができる。

図７は、実施形態に係るスケジュール部１２０によって取得される更新差分の順番の一例を示す図である。図７に示される例において、スケジュール部１２０は、更新差分Ｌ−１、更新差分Ｎ−１、更新差分Ｌ−２、更新差分Ｎ−２、…、更新差分Ｌ−ｎ、更新差分Ｎ−ｎを、この順番で取得している。

図８は、実施形態に係る差分送信部１３０によって送信される更新差分の順番の一例を示す図である。本実施形態においては、“Log”の優先度よりも“Normal”の優先度の方が高いため、差分送信部１３０は、“Log”の更新差分よりも“Normal”の更新差分を優先的にスレーブサーバ２００に送信する。したがって、図８に示されるように、差分送信部１３０は、更新差分Ｎ−１、更新差分Ｎ−２、…、更新差分Ｎ−ｎ、更新差分Ｌ−１、更新差分Ｌ−２、…、更新差分Ｌ−ｎを、この順番で送信する。

図９は、実施形態に係る優先度の設定によって得られる効果の一例を示す図である。時刻Ｔ０は、差分送信部１３０からスレーブサーバ２００への、更新差分Ｎ−１の送信開始時刻を示す。時刻Ｔ１は、更新差分Ｎ−１の送信完了時刻を示す。時刻Ｔ２は、更新差分Ｎ−２の送信完了時刻を示す。時刻Ｔｎは、更新差分Ｎ−ｎの送信完了時刻を示す。時刻Ｗ１は、スレーブサーバ２００における更新差分Ｎ−１についての更新完了時刻を示す。時刻Ｗ２は、スレーブサーバ２００における更新差分Ｎ−２についての更新完了時刻を示す。時刻Ｗｎは、スレーブサーバ２００における更新差分Ｎ−ｎについての更新完了時刻を示す。

図９において、送信時間ｔは１つの更新差分の送信に要する時間を示し、書込時間ｗは１つの更新差分の書き込みに要する時間を示す。なお、送信時間ｔは、書込時間ｗより長い。また、スレーブサーバ２００は、更新差分の受信と記憶部２３０への書込みを並行して実行できるものとする。この場合、送信開始時刻Ｔ０から更新完了時刻Ｗｎまでに要する時間は、ｔ×ｎ＋ｗとなる。

一方、従来技術と同様に、スケジュール部１２０によって取得された更新差分の送信順序を制御せずに、差分送信部１３０が更新差分をスレーブサーバ２００に送信する場合（図７に示される順番で更新差分を送信する場合）、送信開始時刻Ｔ０から更新完了時刻Ｗｎまでに要する時間は、ｔ×２ｎ＋ｗとなる。したがって、本発明によれば、送信開始時刻Ｔ０から更新完了時刻Ｗｎまでに要する時間を従来の約半分まで短くすることができるため、優先度の高いテーブルに対する更新処理を迅速に行うことができる。

設定情報Ｓに含まれるグループに同じ値が設定されているテーブルは、同じグループに属する。図３においては、“Normal”のグループは２であり、“Log”のグループは１であり、“Error”のグループは１である。このため、“Log”のテーブルおよび“Error”のテーブルは、同一のグループに属する。同一のグループに属するテーブルは、更新順序の一貫性が保たれる。

図１０は、実施形態に係る更新順序の一貫性を説明するための図である。図１０に示されるように、マスターサーバ１００は、記憶部１５０に対して更新処理１を行った後、更新処理２を行う。マスターサーバ１００は、更新処理１が完了すると、更新処理１の更新差分１をスレーブサーバ２００に送信する。また、マスターサーバ１００は、更新処理２が完了すると、更新処理２の更新差分２をスレーブサーバ２００に送信する。

もし、スレーブサーバ２００が、更新差分１に基づく更新処理よりも先に、更新差分２に基づく更新処理を実行すると、記憶部２３０における更新順序の一貫性が損なわれることとなる。更新順序の一貫性が損なわれると、例えば、２つのテーブルをＪＯＩＮ（結合）する場合に、一方のテーブルが新しく、他方のテーブルが古いという状況が発生してしまう。

本実施形態においては、前述したように、優先度の高いテーブルの更新が優先的に行われる。しかしながら、図１０に示される例において、更新処理２のテーブルの優先度が、更新処理１のテーブルの優先度よりも高い場合、更新差分１に基づく更新処理よりも先に、更新差分２に基づく更新処理が実行されることとなり、スレーブサーバ２００において更新順序の一貫性が損なわれてしまう。このため、本実施形態においては、更新順序の一貫性が保証されるグループが、設定情報Ｓに予め設定されている。

図１１から図１５は、実施形態に係るマスターサーバ１００の動作の一例を示す図である。図１１に示される例において、スケジュール部１２０は、“Normal”の更新差分Ｎ、“Log”の更新差分Ｌ、および“Error”の更新差分Ｅを、この順番でキュー１６１から取得している。前述したように、“Normal”の優先度は２（中優先度）であり、“Log”の優先度は３（低優先度）であり、“Error”の優先度は１（高優先度）である。

この場合、図１１に示されるように、スケジュール部１２０は、１番目に取得した更新差分Ｎを、優先度２のキュー１６３に格納する。次に、スケジュール部１２０は、２番目に取得した更新差分Ｌを、優先度３のキュー１６４に格納する。図１２は、更新差分Ｎおよび更新差分Ｌが、それぞれキュー１６３およびキュー１６４に格納された状態を示す。

次の更新差分Ｅの優先度は１であるため、スケジュール部１２０は、更新差分Ｅを優先度１のキュー１６２に格納することとなる。しかしながら、図３に示されるように、更新差分Ｅ（Error）の属するグループは、更新差分Ｌ（Log）の属するグループと同一であり、更新差分Ｌは既に優先度３のキュー１６４に格納されている。前述したように、同一グループの更新差分については、更新順序の一貫性を保証する必要がある。更新順序の一貫性を保証するためには、更新差分Ｅと同じグループに属する更新差分Ｌの優先度を、更新差分Ｅの優先度１（高優先度）に変更する必要がある。

このため、スケジュール部１２０は、更新差分Ｅと同一のグループに属する更新差分Ｌを優先度３のキュー１６４から、優先度１のキュー１６２に移動させる。図１３は、更新差分Ｌが、優先度３のキュー１６４から、優先度１のキュー１６２に移動された状態を示す。更新差分Ｌが優先度１のキュー１６２に格納されると、図１４に示されるように、スケジュール部１２０は、優先度が１である更新差分Ｅを優先度１のキュー１６２に格納する。

このように、更新差分Ｅに係るテーブルの優先度が更新差分Ｌに係るテーブルの優先度より高く、更新差分Ｌに係るテーブルと更新差分Ｅに係るテーブルとが同一のグループに属する場合、スケジュール部１２０は、更新差分Ｌを、更新差分Ｌに係るテーブルの優先度３に対応するキュー１６４から、更新差分Ｅに係るテーブルの優先度１に対応するキュー１６２に移動させる。これによって、同一のグループに属する更新差分については更新順序の一貫性を保証することができる。

差分送信部１３０は、優先度１のキュー１６２、優先度２のキュー１６３、優先度３のキュー１６４から、優先度に基づく順番で更新差分を取得する。図１５に示される例においては、差分送信部１３０は、優先度１のキュー１６２から更新差分Ｌを取得し、取得した更新差分Ｌをスレーブサーバ２００に送信する。次に、差分送信部１３０は、優先度１のキュー１６２から更新差分Ｅを取得し、取得した更新差分Ｅをスレーブサーバ２００に送信する。その後、差分送信部１３０は、優先度２のキュー１６３から更新差分Ｎを取得し、取得した更新差分Ｎをスレーブサーバ２００に送信する。

図１１から図１５に示される例において、スケジュール部１２０は、記憶部１５０に記憶された設定情報Ｓ（図３）を参照して、更新差分Ｌに係るテーブルと更新差分Ｅに係るテーブルとが同一のグループに属する否かを判定する。更新差分Ｌに係るテーブルと更新差分Ｅに係るテーブルとが同一のグループに属する場合、スケジュール部１２０は、更新差分Ｅに係るテーブルの優先度が更新差分Ｌに係るテーブルの優先度より高い場合であっても、更新差分Ｌをスレーブサーバ２００に送信する順番と、更新差分Ｅをスレーブサーバ２００に送信する順番とを入れ替えない。

これによって、同一のグループに属する更新差分については更新順序の一貫性を保証することができる。更新順序の一貫性が保証されることによって、例えば、２つのテーブルをＪＯＩＮ（結合）する場合に、一方のテーブルが新しく、他方のテーブルが古いという状況が発生するのを防止することができる。

図１６は、実施形態に係るＳＱＬ処理部１１０の動作を示すフローチャートである。本フローチャートを実行するためのプログラムは、マスターサーバ１００のプログラムメモリに格納されている。

マスターサーバ１００の書込要求受信部１４０がクライアント端末３００から書込要求を受信すると、書込要求受信部１４０は、受信した書込要求をＳＱＬ処理部１１０に出力する。ＳＱＬ処理部１１０は、書込要求受信部１４０から書込要求を受信したか否かを判定する（Ｓ１０）。ＳＱＬ処理部１１０は、書込要求受信部１４０から書込要求を受信したと判定した場合、受信した書込要求に従って記憶部１５０内のテーブルにデータを書き込む（Ｓ１１）。

次に、ＳＱＬ処理部１１０は、記憶部１５０内のテーブルへのデータの書き込みが成功したか否かを判定する（Ｓ１２）。ＳＱＬ処理部１１０は、記憶部１５０内のテーブルへのデータの書き込みが成功したと判定した場合、キュー１６１に更新差分を格納する（Ｓ１３）。その後、ＳＱＬ処理部１１０は、クライアント端末３００に書き込み成功を通知し（Ｓ１４）、前述のＳ１０の処理に戻る。

このように、ＳＱＬ処理部１１０は、記憶部１５０内のテーブルへのデータの書き込みが完了した場合、スレーブサーバ２００の記憶部２３０内のテーブルへのデータの書き込み完了を待たずに、クライアント端末３００に書き込み完了通知を送信する。このように、非同期レプリケーションを行うことによって、マスターサーバ１００の記憶部１５０内のテーブルに対する書き込み性能を向上させることができる。

一方、Ｓ１２において、ＳＱＬ処理部１１０は、記憶部１５０内のテーブルへのデータの書き込みが失敗したと判定した場合、クライアント端末３００に書き込み失敗を通知し（Ｓ１５）、前述のＳ１０の処理に戻る。クライアント端末３００は、マスターサーバ１００から書き込み失敗が通知されると、再度書込要求をマスターサーバ１００に送信する。これによって、マスターサーバ１００は、記憶部１５０内のテーブルに対する書き込み動作をリトライすることができる。

図１７は、実施形態に係るスケジュール部１２０の動作を示すフローチャートである。本フローチャートを実行するためのプログラムは、マスターサーバ１００のプログラムメモリに格納されている。

スケジュール部１２０は、キュー１６１から更新差分を取得したか否かを判定する（Ｓ２０）。次に、スケジュール部１２０は、キュー１６１から更新差分を取得したと判定した場合、取得した更新差分に係るテーブルの優先度ＰおよびグループＧを、記憶部１５０内の設定情報Ｓ（図３）を参照して判別する（Ｓ２１）。例えば、受信した更新差分が“Normal”の更新差分である場合、優先度Ｐは２であり、グループＧは２である。受信した更新差分が“Log”の更新差分の場合、優先度Ｐは３であり、グループＧは１である。受信した更新差分が“Error”の更新差分の場合、優先度Ｐは１であり、グループＧは１である。

次に、スケジュール部１２０は、優先度Ｐよりも低い優先度のキューに、同一グループの更新差分が存在するか否かを判定する（Ｓ２２）。スケジュール部１２０は、優先度Ｐよりも低い優先度のキューに、同一グループの更新差分が存在すると判定した場合、同一グループの更新差分を優先度Ｐのキューに移動させる（Ｓ２３）。その後、スケジュール部１２０は、前述のＳ２２の処理に戻る。

一方、Ｓ２２において、スケジュール部１２０は、優先度Ｐよりも低い優先度のキューに、同一グループの更新差分が存在しないと判定した場合、Ｓ２０において受信した更新差分を優先度Ｐのキューに追加する（Ｓ２４）。その後、スケジュール部１２０は、前述のＳ２０の処理に戻る。

図１８は、実施形態に係る差分送信部１３０の動作を示すフローチャートである。本フローチャートを実行するためのプログラムは、マスターサーバ１００のプログラムメモリに格納されている。

まず、差分送信部１３０は、優先度Ｐを１に設定する（Ｓ３０）。次に、差分送信部１３０は、優先度Ｐのキューに更新差分が存在するか否かを判定する（Ｓ３１）。差分送信部１３０は、優先度Ｐのキューに更新差分が存在すると判定した場合、優先度Ｐのキューから更新差分を一つ取り出す（Ｓ３２）。その後、差分送信部１３０は、取り出した更新差分をスレーブサーバ２００に送信する（Ｓ３３）。

次に、差分送信部１３０は、優先度Ｐより高い優先度Ｑのキューに更新差分が存在するか否かを判定する（Ｓ３４）。差分送信部１３０は、優先度Ｐより高い優先度Ｑのキューに更新差分が存在すると判定した場合、優先度ＰをＱに設定し（Ｓ３５）、前述のＳ３２の処理に戻る。一方、Ｓ３４において、差分送信部１３０は、優先度Ｐより高い優先度Ｑのキューに更新差分が存在しないと判定した場合、前述のＳ３１の処理に戻る。

Ｓ３１において、差分送信部１３０は、優先度Ｐのキューに更新差分が存在しないと判定した場合、優先度Ｐが最も低い優先度であるか否かを判定する（Ｓ３６）。例えば、図３に示される例においては、優先度３が最も低い優先度である。差分送信部１３０は、優先度Ｐが最も低い優先度であると判定した場合、前述のＳ３０の処理に戻る。一方、Ｓ３６において、差分送信部１３０は、優先度Ｐが最も低い優先度ではないと判定した場合、優先度Ｐに１を加算し（Ｓ３７）、前述のＳ３１の処理に戻る。

図１９は、実施形態に係るＳＱＬ処理部２１０の動作を示すフローチャートである。本フローチャートを実行するためのプログラムは、スレーブサーバ２００のプログラムメモリに格納されている。

スレーブサーバ２００の差分受信部２２０がマスターサーバ１００から更新差分を受信すると、差分受信部２２０は、受信した更新差分をＳＱＬ処理部２１０に出力する。ＳＱＬ処理部２１０は、差分受信部２２０から更新差分を受信したか否かを判定する（Ｓ４０）。ＳＱＬ処理部２１０は、差分受信部２２０から更新差分を受信したと判定した場合、受信した更新差分に従って記憶部２３０内のテーブルにデータを書き込む（Ｓ４１）。

次に、ＳＱＬ処理部２１０は、記憶部２３０内のテーブルへのデータの書き込みが成功したか否かを判定する（Ｓ４２）。ＳＱＬ処理部２１０は、記憶部２３０内のテーブルへのデータの書き込みが成功したと判定した場合、マスターサーバ１００に書き込み成功を通知し（Ｓ４３）、前述のＳ４０の処理に戻る。

一方、Ｓ４２において、ＳＱＬ処理部２１０は、記憶部２３０内のテーブルへのデータの書き込みが失敗したと判定した場合、マスターサーバ１００に書き込み失敗を通知し（Ｓ４４）、前述のＳ４０の処理に戻る。マスターサーバ１００は、スレーブサーバ２００から書き込み失敗が通知されると、再度書込要求をスレーブサーバ２００に送信する。これによって、スレーブサーバ２００は、記憶部２３０内のテーブルに対する書き込み動作をリトライすることができる。以上の処理によって、スレーブサーバ２００は、レプリケーションを行うことができる。

以上説明したように、ＳＱＬ処理部１１０は、クライアント端末３００から受信した書込要求に基づき、記憶部１５０におけるテーブルを更新すると共に、更新の内容を認識可能な更新差分情報を生成する。スケジュール部１２０は、ＳＱＬ処理部１１０により生成された更新差分をスレーブサーバ２００に送信する順番を、テーブルごとに設定される優先度に基づいて制御する。差分送信部１３０は、スケジュール部１２０によって制御された順番に応じて、更新差分情報をスレーブサーバ２００に送信する。これによって、マスターサーバ１００は、優先度の高いテーブルに対する更新処理を迅速にスレーブサーバ２００に行わせることができる。

なお、上記実施形態において、ストレージシステム１０が、レプリケーションを行うためのスレーブサーバを一つだけ備える例について説明したが、これに限られない、例えば、ストレージシステム１０は、二つ以上のスレーブサーバを備えてもよい。この場合、マスターサーバ１００は、各スレーブサーバに同一の更新差分を送信すればよい。

また、上記実施形態において、高優先度の更新差分が長時間続く場合には、低優先度の更新差分が長時間送信されなくなる。このため、スケジュール部１２０は、一定時間以上キューに滞留した更新差分を、優先度が一つ高いキューに移動させてもよい。これによって、低優先度の更新差分がキュー内に長時間滞留することを防止できる。

また、スケジュール部１２０は、厳密にレプリケーションを行う必要が無い場合には、一定時間以上キューに滞留した更新差分を、キューから削除してもよい。更新差分をキューから削除したとしても、マスターサーバ１００内の記憶部１５０には更新されたテーブルが格納されている。このため、ユーザは、クライアント端末３００を用いてマスターサーバ１００内の記憶部１５０にアクセスすることで、最新のテーブルを参照することができる。

なお、上記実施形態によるマスターサーバ１００およびスレーブサーバ２００は、内部にコンピュータシステムを有している。そして、上述したマスターサーバ１００およびスレーブサーバ２００の各処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって上記各種処理が行われる。ここで、コンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしてもよい。

以上説明した少なくともひとつの実施形態によれば、マスターサーバ１００は、記憶部１５０と、ＳＱＬ処理部１１０と、スケジュール部１２０と、差分送信部１３０とを持つ。記憶部１５０は、テーブルで管理されるデータを記憶する。ＳＱＬ処理部１１０は、クライアント端末３００から受信した書込要求に基づき、記憶部１５０におけるテーブルを更新すると共に、更新の内容を認識可能な更新差分情報を生成する。スケジュール部１２０は、ＳＱＬ処理部１１０により生成された更新差分をスレーブサーバ２００に送信する順番を、テーブルごとに設定される優先度に基づいて制御する。差分送信部１３０は、スケジュール部１２０によって制御された順番に応じて、更新差分情報をスレーブサーバ２００に送信する。これによって、優先度の高いテーブルに対する更新処理を迅速に行うことができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１０…ストレージシステム、１００…マスターサーバ、１１０…ＳＱＬ処理部、１２０…スケジュール部、１３０…差分送信部、１４０…書込要求受信部、１５０…記憶部、１６１…キュー、１６２…キュー、１６３…キュー、１６４…キュー、２００…スレーブサーバ、２１０…ＳＱＬ処理部、２２０…差分受信部、２３０…記憶部、３００…クライアント端末

Claims (5)

1. テーブルで管理されるデータを記憶する記憶部と、
   クライアントから受信した書込要求に基づき、前記記憶部におけるテーブルを更新すると共に、前記更新の内容を認識可能な更新差分情報を生成するテーブル更新部と、
   前記テーブル更新部により生成された前記更新差分情報を自装置と並行してデータを記憶するスレーブサーバに送信する順番を、前記テーブルごとに設定される優先度に基づいて制御するスケジュール部と、
   前記スケジュール部によって制御された順番に応じて、前記更新差分情報を前記スレーブサーバに送信する差分送信部と、
   を備えるマスターサーバであって、
   前記記憶部は、前記テーブルの優先度と、前記テーブルが属するグループとが関連付けられた設定情報を記憶し、
   前記スケジュール部は、前記テーブル更新部から第１の更新差分情報を取得した後、第２の更新差分情報を取得した場合、前記第１の更新差分情報に係るテーブルの優先度と、前記第２の更新差分情報に係るテーブルの優先度とを比較し、前記第１の更新差分情報を前記スレーブサーバに送信する順番と、前記第２の更新差分情報を前記スレーブサーバに送信する順番とを入れ替えるか否かを判定するものであって、前記記憶部に記憶された前記設定情報を参照して、前記第１の更新差分情報に係るテーブルと前記第２の更新差分情報に係るテーブルとが同一のグループに属する否かを判定し、前記第１の更新差分情報に係るテーブルと前記第２の更新差分情報に係るテーブルとが同一のグループに属する場合、前記第２の更新差分情報に係るテーブルの優先度が前記第１の更新差分情報に係るテーブルの優先度より高い場合であっても、前記第１の更新差分情報を前記スレーブサーバに送信する順番と、前記第２の更新差分情報を前記スレーブサーバに送信する順番とを入れ替えない、
   マスターサーバ。
2. 前記テーブルに対して設定され得る優先度ごとに設けられた複数のキューを更に備え、
   前記スケジュール部は、前記複数のキューのうち、前記テーブル更新部から取得した前記更新差分情報に係るテーブルの優先度に関連付けられたキューに前記更新差分情報を格納し、
   前記差分送信部は、前記優先度の高いキューから順に前記更新差分情報を取得し、取得した前記更新差分情報を前記スレーブサーバに送信する
   請求項１に記載のマスターサーバ。
3. 前記第２の更新差分情報に係るテーブルの優先度が前記第１の更新差分情報に係るテーブルの優先度より高く、前記第１の更新差分情報に係るテーブルと前記第２の更新差分情報に係るテーブルとが同一のグループに属する場合、前記スケジュール部は、前記第１の更新差分情報を、前記第１の更新差分情報に係るテーブルの優先度に対応するキューから、前記第２の更新差分情報に係るテーブルの優先度に対応するキューに移動させる
   請求項２記載のマスターサーバ。
4. クライアントから受信した書込要求に基づき、記憶部におけるテーブルを更新すると共に、前記更新の内容を認識可能な更新差分情報を生成するテーブル更新工程と、
   前記テーブル更新工程で生成された前記更新差分情報を自装置と並行してデータを記憶するスレーブサーバに送信する順番を、前記テーブルごとに設定される優先度に基づいて制御するスケジュール工程と、
   前記スケジュール工程で制御された順番に応じて、前記更新差分情報を前記スレーブサーバに送信する差分送信工程と、
   を備えるテーブル更新方法であって、
   前記差分送信工程において、第１の更新差分情報を取得した後、第２の更新差分情報を取得した場合、前記第１の更新差分情報に係るテーブルの優先度と、前記第２の更新差分情報に係るテーブルの優先度とを比較し、前記第１の更新差分情報を前記スレーブサーバに送信する順番と、前記第２の更新差分情報を前記スレーブサーバに送信する順番とを入れ替えるか否かを判定し、前記記憶部に記憶された設定情報を参照して、前記第１の更新差分情報に係るテーブルと前記第２の更新差分情報に係るテーブルとが同一のグループに属する否かを判定し、前記第１の更新差分情報に係るテーブルと前記第２の更新差分情報に係るテーブルとが同一のグループに属する場合、前記第２の更新差分情報に係るテーブルの優先度が前記第１の更新差分情報に係るテーブルの優先度より高い場合であっても、前記第１の更新差分情報を前記スレーブサーバに送信する順番と、前記第２の更新差分情報を前記スレーブサーバに送信する順番とを入れ替えない、
   テーブル更新方法。
5. コンピュータを、
   クライアントから受信した書込要求に基づき、記憶部におけるテーブルを更新すると共に、前記更新の内容を認識可能な更新差分情報を生成するテーブル更新部、
   前記テーブル更新部により生成された前記更新差分情報を自装置と並行してデータを記憶するスレーブサーバに送信する順番を、前記テーブルごとに設定される優先度に基づいて制御するスケジュール部、
   前記スケジュール部によって制御された順番に応じて、前記更新差分情報を前記スレーブサーバに送信する差分送信部、
   として機能させるためのプログラムであって、
   前記記憶部は、前記テーブルの優先度と、前記テーブルが属するグループとが関連付けられた設定情報を記憶し、
   前記スケジュール部は、前記テーブル更新部から第１の更新差分情報を取得した後、第２の更新差分情報を取得した場合、前記第１の更新差分情報に係るテーブルの優先度と、前記第２の更新差分情報に係るテーブルの優先度とを比較し、前記第１の更新差分情報を前記スレーブサーバに送信する順番と、前記第２の更新差分情報を前記スレーブサーバに送信する順番とを入れ替えるか否かを判定し、前記記憶部に記憶された前記設定情報を参照して、前記第１の更新差分情報に係るテーブルと前記第２の更新差分情報に係るテーブルとが同一のグループに属する否かを判定し、前記第１の更新差分情報に係るテーブルと前記第２の更新差分情報に係るテーブルとが同一のグループに属する場合、前記第２の更新差分情報に係るテーブルの優先度が前記第１の更新差分情報に係るテーブルの優先度より高い場合であっても、前記第１の更新差分情報を前記スレーブサーバに送信する順番と、前記第２の更新差分情報を前記スレーブサーバに送信する順番とを入れ替えない、
   プログラム。

Images