JP2012215937A - データベースのストリーム型レプリケーション機能を用いたスケールアップとダウン方法及びシステム - Google Patents
データベースのストリーム型レプリケーション機能を用いたスケールアップとダウン方法及びシステム Download PDFInfo
- Publication number
- JP2012215937A JP2012215937A JP2011079001A JP2011079001A JP2012215937A JP 2012215937 A JP2012215937 A JP 2012215937A JP 2011079001 A JP2011079001 A JP 2011079001A JP 2011079001 A JP2011079001 A JP 2011079001A JP 2012215937 A JP2012215937 A JP 2012215937A
- Authority
- JP
- Japan
- Prior art keywords
- scale
- database
- rdbms
- replication function
- stream type
- 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
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】 ストリーム型レプリケーション機能を持つデータベースのスケールＵＰ／ＤＯＷＮを、そのストリーム型レプリケーション機能を活用し、Ｗｅｂサービスを止めることなく動的に、かつ低コストで実現すること。
【解決手段】
性能の異なる仮想マシン上で稼動する第１および第２のデータベースを備え、外部からの指示に応じて、システムが利用している仮想マシンを入れ替え、システムの性能をスケールアップ及びスケールダウンさせる方法であって、
前記システムが、
前記データベースが備えるストリーム型レプリケーション機能を用いて前記データベースのデータ同期をとる第１のステップと、データ同期確立後に、ＳＱＬ文を転送する仮想マシンを他の仮想マシンに切り替える第２のステップとを備えることを特徴とする。
【選択図】 図１
【解決手段】
性能の異なる仮想マシン上で稼動する第１および第２のデータベースを備え、外部からの指示に応じて、システムが利用している仮想マシンを入れ替え、システムの性能をスケールアップ及びスケールダウンさせる方法であって、
前記システムが、
前記データベースが備えるストリーム型レプリケーション機能を用いて前記データベースのデータ同期をとる第１のステップと、データ同期確立後に、ＳＱＬ文を転送する仮想マシンを他の仮想マシンに切り替える第２のステップとを備えることを特徴とする。
【選択図】 図１
Description
本発明は、ＩａａＳ（infrastructure as a Service）などで提供される仮想マシンインスタンス上などで動作する、ストリーム型レプリケーション機能を持つリレーショナルデータベースマネージメントシステム（以下、ＲＤＢＭＳ）に対し、ＳＱＬ問い合わせを中継するプロキシを用いて、Ｗｅｂアプリケーションケーションの停止を必要とせず動的に、スケールＵＰ及びスケールＤＯＷＮを実現する技術に関するものである。
現在、仮想マシンインスタンスを提供するＩａａＳが数多く提供されている。その中でもＡｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（以下、ＡＷＳと略す）のＥＣ２のように、様々な性能のインスタンスを時間単位の課金で利用できるＩａａＳは、サービス利用者の増減に伴う負荷の増減に合わせて、計算資源の利用コストをスケールすることが可能であるため、多くのＷｅｂサービスで利用されつつある。
このようなＷｅｂサービスは、一般的にＷｅｂアプリケーションケーションとデータベースで構成されているが、Ｗｅｂアプリケーションケーションについては、負荷に応じて動的にインスタンス（仮想マシン）を増減させるスケールＯＵＴ／ＩＮの手法が一般的に利用されている。また、スケールＯＵＴ／ＩＮ機能は、既にＩａａＳベンダ自身やサードパーティから提供されている。
データベースについても、負荷に応じて処理性能を変化させる方法は幾つか提案されている。
下記の非特許文献１に挙げられるような従来型のクラスタ技術では、参照性能のみではあるが、非特許文献２のようなストリーム型レプリケーション機能を用いることで、動的に参照用のＲＤＢＭＳサーバを作成することができ、簡単に性能向上が可能である。ただし、更新性能は向上しないため、参照比率が高いシステムしか効果を得られない。
このようなＷｅｂサービスは、一般的にＷｅｂアプリケーションケーションとデータベースで構成されているが、Ｗｅｂアプリケーションケーションについては、負荷に応じて動的にインスタンス（仮想マシン）を増減させるスケールＯＵＴ／ＩＮの手法が一般的に利用されている。また、スケールＯＵＴ／ＩＮ機能は、既にＩａａＳベンダ自身やサードパーティから提供されている。
データベースについても、負荷に応じて処理性能を変化させる方法は幾つか提案されている。
下記の非特許文献１に挙げられるような従来型のクラスタ技術では、参照性能のみではあるが、非特許文献２のようなストリーム型レプリケーション機能を用いることで、動的に参照用のＲＤＢＭＳサーバを作成することができ、簡単に性能向上が可能である。ただし、更新性能は向上しないため、参照比率が高いシステムしか効果を得られない。
これに対し、更新性能も向上させる方法もいくつか出てきている。
例えば、インスタンス数を増減させて処理性能を変化させるスケールＯＵＴ／ＩＮを実現する方法としては、下記の非特許文献３に代表されるＮｏＳＱＬと分類されるデータベースがある。
また、下記の非特許文献４や非特許文献５などのように、更新性能も台数に応じてリニアに向上できるクラスタ技術も現れてきている。しかし、これらの方法は従来のＲＤＢＭＳと同様の機能が提供されなかったり、従来のＲＤＢＭＳと同様のインタフェースが提供されなかったり、常に３台以上稼動する構成でないと、１台の性能より劣ってしまうなど、様々な問題がある。また、動的に台数を増減させる方法も確立されていない。
例えば、インスタンス数を増減させて処理性能を変化させるスケールＯＵＴ／ＩＮを実現する方法としては、下記の非特許文献３に代表されるＮｏＳＱＬと分類されるデータベースがある。
また、下記の非特許文献４や非特許文献５などのように、更新性能も台数に応じてリニアに向上できるクラスタ技術も現れてきている。しかし、これらの方法は従来のＲＤＢＭＳと同様の機能が提供されなかったり、従来のＲＤＢＭＳと同様のインタフェースが提供されなかったり、常に３台以上稼動する構成でないと、１台の性能より劣ってしまうなど、様々な問題がある。また、動的に台数を増減させる方法も確立されていない。
一方、ＲＤＢＭＳが稼動するインスタンスを、性能が異なるインスタンスに入れ替えことで負荷に応じた性能に変更するスケールＵＰ／ＤＯＷＮを実現する方法もある。
例えば、pgpool-IIのレプリケーションとオンラインリカバリ機能を用いれば、インスタンスを入れ替えることは可能である。しかし、オンラインリカバリ中でも、一時的にＲＤＢＭＳの接続を止める必要があり、その間はサービスが停止してしまう。
特許文献１に開示された技術を用いれば、停止せずにインスタンスを入れ替えることが可能ではあるが、ＲＤＢＭＳ自体に、特許文献１で示された処理を行う機能を持つ必要がある。このため、既存のＲＤＢＭＳに、この方法を容易に実現することは困難である。
さらに、特許文献１の方法は、実機環境でマシン環境の変化が少ない場面におけるサーバの故障時や、スレーブサーバの追加を想定している。ＩａａＳ上で負荷に応じてＲＤＢＭＳの処理性能を変化させる場合には、数時間や一日単位でインスタンスを入れ替えなければならない。特許文献１の方法では、データ転送量やコピーなどの処理時間が大きく、データ転送量や入れ替えコストが増大してしまう。そのため、入れ替えのための時間が大きくなる上、データ転送量やインスタンスの起動時間で課金されるＩａａＳではコスト増となる。従って、このような場合には特許文献１の方法は適さない。
例えば、pgpool-IIのレプリケーションとオンラインリカバリ機能を用いれば、インスタンスを入れ替えることは可能である。しかし、オンラインリカバリ中でも、一時的にＲＤＢＭＳの接続を止める必要があり、その間はサービスが停止してしまう。
特許文献１に開示された技術を用いれば、停止せずにインスタンスを入れ替えることが可能ではあるが、ＲＤＢＭＳ自体に、特許文献１で示された処理を行う機能を持つ必要がある。このため、既存のＲＤＢＭＳに、この方法を容易に実現することは困難である。
さらに、特許文献１の方法は、実機環境でマシン環境の変化が少ない場面におけるサーバの故障時や、スレーブサーバの追加を想定している。ＩａａＳ上で負荷に応じてＲＤＢＭＳの処理性能を変化させる場合には、数時間や一日単位でインスタンスを入れ替えなければならない。特許文献１の方法では、データ転送量やコピーなどの処理時間が大きく、データ転送量や入れ替えコストが増大してしまう。そのため、入れ替えのための時間が大きくなる上、データ転送量やインスタンスの起動時間で課金されるＩａａＳではコスト増となる。従って、このような場合には特許文献１の方法は適さない。
pgpool-II http://pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-ja.html
Streaming Replication http://wiki.postgresql.org/wiki/Streaming_Replication
CouchDB http://oss.infoscience.co.jp/couchdb/main/docs/overview.html
Postgres-XC http://postgres-xc.sourceforge.net/
VoltDB http://voltdb.com/content/voltdb-oltp-database-youll-never-outgrow
本発明は上記のような問題に鑑みなされたもので、その目的は、ＩａａＳなどで提供される仮想マシンインスタンス上等で動作する、ストリーム型レプリケーション機能を持つＲＤＢＭＳのスケールアップ及びダウンを、そのストリーム型レプリケーション機能を活用し、Ｗｅｂサービスを止めることなく動的に、かつ低コストでインスタンスの入れ替えを行うことで実現する方法及びシステムを提供することにある。
上記目的を達成するために、本発明に係る方法は、性能の異なる仮想マシン上で稼動する第１および第２のデータベースを備え、外部からの指示に応じて、システムが利用している仮想マシンを入れ替え、システムの性能をスケールアップ及びスケールダウンさせる方法であって、
前記システムが、
前記データベースが備えるストリーム型レプリケーション機能を用いて前記データベースのデータ同期をとる第１のステップと、
データ同期確立後に、ＳＱＬ文を転送する仮想マシンを他の仮想マシンに切り替える第２のステップと、
を備えることを特徴とする。
前記システムが、
前記データベースが備えるストリーム型レプリケーション機能を用いて前記データベースのデータ同期をとる第１のステップと、
データ同期確立後に、ＳＱＬ文を転送する仮想マシンを他の仮想マシンに切り替える第２のステップと、
を備えることを特徴とする。
また、本発明に係るシステムは、性能の異なる仮想マシン上で稼動する第１および第２のデータベースを備え、外部からの指示に応じて、システムが利用している仮想マシンを入れ替え、システムの性能をスケールアップ及びスケールダウンさせるデータベースシステムであって、
前記データベースが備えるストリーム型レプリケーション機能を用いて前記データベースのデータ同期をとる第１の手段と、データ同期確立後に、ＳＱＬ文を転送する仮想マシンを他の仮想マシンに切り替える第２の手段とを備えることを特徴とする。
前記データベースが備えるストリーム型レプリケーション機能を用いて前記データベースのデータ同期をとる第１の手段と、データ同期確立後に、ＳＱＬ文を転送する仮想マシンを他の仮想マシンに切り替える第２の手段とを備えることを特徴とする。
本発明によれば、ＲＤＢＭＳが持つストリーム型レプリケーション機能を用いてＤＢデータ同期を行い、同期が出来次第プロキシがＳＱＬ文を転送するＲＤＢＭＳを変更することによりインスタンスを入れ替えるため、Ｗｅｂサービス等で利用されているＲＤＢＭＳを、Ｗｅｂアプリケーションケーション及びそれにより提供されるサービスを止めることなく、動的に、かつ短時間及び低コストでスケールアップ及びダウンすることができる。
以下、本発明を実施する場合の一形態を、図面を参照して具体的に説明する。
図１は、本発明の実施の形態を示すシステム構成図である。
本実施形態のシステムは、ＩａａＳ１００上の仮想マシンサービスを用いたインスタンス群とストレージサービスを用いたストレージ群で構成される。
ＩａａＳ１００上には、Ｗｅｂアプリケーション用インスタンス１１０、コントロール・プロキシ用インスタンス１２０、ＤＢシステムＡ１３０を構成するＤＢＭＳ用インスタンスＡ１４０とデータを保管するストレージＡ１５０、ＤＢシステムＢ１６０を構成するＤＢＭＳ用インスタンスＢ１７０とデータを保管するストレージＢ１８０が配置されている。
図１は、本発明の実施の形態を示すシステム構成図である。
本実施形態のシステムは、ＩａａＳ１００上の仮想マシンサービスを用いたインスタンス群とストレージサービスを用いたストレージ群で構成される。
ＩａａＳ１００上には、Ｗｅｂアプリケーション用インスタンス１１０、コントロール・プロキシ用インスタンス１２０、ＤＢシステムＡ１３０を構成するＤＢＭＳ用インスタンスＡ１４０とデータを保管するストレージＡ１５０、ＤＢシステムＢ１６０を構成するＤＢＭＳ用インスタンスＢ１７０とデータを保管するストレージＢ１８０が配置されている。
Ｗｅｂアプリケーション用インスタンス１１０には、Ｗｅｂアプリケーション１１１及びそれを動作させる一連のプログラムが配置されている。
このＷｅｂアプリケーション１１１は、ＲＤＢＭＳの代わりに後述のコントロール・プロキシ用インスタンス１２０上の制御プロキシ部１２２にＳＱＬ文を発行し、その結果を受け取る。
コントロール・プロキシ用インスタンス１２０には、コントロール部１２１及び制御プロキシ部１２２が配置されている。
コントロール部１２１は、ＲＤＢＭＳのスケールＵＰ／ＤＯＷＮを行う管理者の要求に応じ、スケールＵＰ／ＤＯＷＮに必要となるインスタンスの起動停止や、インスタンス上のＲＤＢＭＳの起動停止、制御プロキシ部１２２のコントロール等を行う。
このＷｅｂアプリケーション１１１は、ＲＤＢＭＳの代わりに後述のコントロール・プロキシ用インスタンス１２０上の制御プロキシ部１２２にＳＱＬ文を発行し、その結果を受け取る。
コントロール・プロキシ用インスタンス１２０には、コントロール部１２１及び制御プロキシ部１２２が配置されている。
コントロール部１２１は、ＲＤＢＭＳのスケールＵＰ／ＤＯＷＮを行う管理者の要求に応じ、スケールＵＰ／ＤＯＷＮに必要となるインスタンスの起動停止や、インスタンス上のＲＤＢＭＳの起動停止、制御プロキシ部１２２のコントロール等を行う。
制御プロキシ部１２２は、Ｗｅｂアプリケーション１１１から受けたＳＱＬ文を、Ｗｅｂアプリケーション１１１の代わりに後述するＤＢシステムＡ１３０やＤＢシステムＢ１６０に転送し、その結果を受けてＷｅｂアプリケーション１１１に返したり、コントロール部１２１の要求に応じて、ＤＢシステムＡ１３０やＤＢシステムＢ１６０へのＳＱＬ文転送を一時中断したり、ＳＱＬ文を転送するＤＢシステムを切り替えたりする。
ＤＢシステムＡ１３０及びＤＢシステムＢ１６０は、入れ替え元及び入れ替え先となるＤＢシステムである。どちらも同じ構成となっており、ＤＢＭＳ用インスタンスＡ１４０及びＤＢＭＳ用インスタンスＢ１７０には、ストリーム型複製処理部１４２及び１７２を内蔵し、ストリーム型レプリケーション機能を持つＲＤＢＭＳ−Ａ１４１、ＲＤＢＭＳ−Ｂ１７１が各々配置されている。
また、ストレージＡ１５０及びストレージＢ１８０には、ＲＤＢＭＳ−Ａ１４１及びＲＤＢＭＳ−Ｂ１７１が各々利用するＤＢデータＡ１５１及びＤＢデータＢ１８１が配置されている。
ＤＢシステムＡ１３０及びＤＢシステムＢ１６０は、入れ替え元及び入れ替え先となるＤＢシステムである。どちらも同じ構成となっており、ＤＢＭＳ用インスタンスＡ１４０及びＤＢＭＳ用インスタンスＢ１７０には、ストリーム型複製処理部１４２及び１７２を内蔵し、ストリーム型レプリケーション機能を持つＲＤＢＭＳ−Ａ１４１、ＲＤＢＭＳ−Ｂ１７１が各々配置されている。
また、ストレージＡ１５０及びストレージＢ１８０には、ＲＤＢＭＳ−Ａ１４１及びＲＤＢＭＳ−Ｂ１７１が各々利用するＤＢデータＡ１５１及びＤＢデータＢ１８１が配置されている。
以下では、入れ替え開始時点で利用されている入れ替え元をＤＢシステムＡ１３０、入れ替え終了時に利用されている入れ替え先をＤＢシステムＢ１６０として説明する。
ここで、入れ替え処理を説明する前に、入れ替え開始前の状態を図２で説明する。
入れ替え開始前の状態では、ＤＢシステムＡ１３０が利用され、ＤＢＭＳ用インスタンスＢ１７０は稼動していない。
入れ替え開始前の状態では、Ｗｅｂアプリケーション１１１が発行したＳＱＬ文は、黒矢印２０１で示すように、コントロール・プロキシ用インスタンス１２０の制御プロキシ部１２２に送られる。
制御プロキシ部１２２は、黒矢印２０２で示すように、全てのＳＱＬ文を、ＤＢＭＳ用インスタンスＡ１４０のＲＤＢＭＳ−Ａ１４１に転送する。
ＲＤＢＭＳ−Ａ１４１はストレージＡ１５０のＤＢデータＡ１５１を用いてＳＱＬ文を処理し、その結果を、制御プロキシ部１２２を経由して、Ｗｅｂアプリケーション１１１に返答する。また、詳細は後述するが、制御プロキシ部１２２では、Ｗｅｂアプリケーション１１１からの接続セッションにおいて、トランザクション開始及び終了を識別する。
ここで、入れ替え処理を説明する前に、入れ替え開始前の状態を図２で説明する。
入れ替え開始前の状態では、ＤＢシステムＡ１３０が利用され、ＤＢＭＳ用インスタンスＢ１７０は稼動していない。
入れ替え開始前の状態では、Ｗｅｂアプリケーション１１１が発行したＳＱＬ文は、黒矢印２０１で示すように、コントロール・プロキシ用インスタンス１２０の制御プロキシ部１２２に送られる。
制御プロキシ部１２２は、黒矢印２０２で示すように、全てのＳＱＬ文を、ＤＢＭＳ用インスタンスＡ１４０のＲＤＢＭＳ−Ａ１４１に転送する。
ＲＤＢＭＳ−Ａ１４１はストレージＡ１５０のＤＢデータＡ１５１を用いてＳＱＬ文を処理し、その結果を、制御プロキシ部１２２を経由して、Ｗｅｂアプリケーション１１１に返答する。また、詳細は後述するが、制御プロキシ部１２２では、Ｗｅｂアプリケーション１１１からの接続セッションにおいて、トランザクション開始及び終了を識別する。
次に、入れ替え処理の概要フローを図３に示す。
入れ替え処理は、コントロール部１２１がＲＤＢＭＳのスケールＵＰ／ＤＯＷＮを行う管理者から要求を受けた後、入れ替え準備処理（ステップ３０１）、ＤＢシステム切り替え処理（ステップ３０２）、入れ替え後処理（ステップ３０３）の３つのフェーズで行う。以後、この順序で詳細な処理を説明する。
入れ替え処理は、コントロール部１２１がＲＤＢＭＳのスケールＵＰ／ＤＯＷＮを行う管理者から要求を受けた後、入れ替え準備処理（ステップ３０１）、ＤＢシステム切り替え処理（ステップ３０２）、入れ替え後処理（ステップ３０３）の３つのフェーズで行う。以後、この順序で詳細な処理を説明する。
入れ替え準備処理（ステップ３０１）の詳細な処理を図４のフローチャートに示す。
まず、コントロール・プロキシ用インスタンス１２０上のコントロール部１２１は、ストレージＢ１８０に接続した状態で、ＤＢＭＳ用インスタンスＢ１７０を起動する（ステップ４０１）。
そして、ＲＤＢＭＳ−Ａ１４１及びＤＢＭＳ用インスタンスＢ１７０を操作し、ＤＢＭＳ用インスタンスＢ１７０上に、ストリーミング型レプリケーション機能を有効にした形で、ＲＤＢＭＳ−Ｂ１７１を起動する（ステップ４０２）。
これは、既存技術であり、たとえばpostgreSQL9.0以降では、前記の非特許文献２に示される方法で実現できる。これにより、図５の５０１の矢印で示されるようにＤＢデータの同期が開始される（ステップ４０３）。ここで、ＤＢデータＢ１８１には、以前の入れ替え時前までのＤＢデータが残っているため、以前の入れ替え時以降に行われた更新データのみ反映させれば良く、全てのＤＢデータをコピーする必要は無い。また、この同期は、ストリーミング型レプリケーション機能を用いているため、データ同期中に、黒矢印２０２で更新系のＳＱＬ文が発行され、ＤＢデータＡ１５１が更新された場合でも、一定のタイムラグの後、自動的にＤＢデータＢ１８１に反映される。最後に、制御プロキシ部１２２にＤＢ切り替え要求を行う（ステップ４０４）。
まず、コントロール・プロキシ用インスタンス１２０上のコントロール部１２１は、ストレージＢ１８０に接続した状態で、ＤＢＭＳ用インスタンスＢ１７０を起動する（ステップ４０１）。
そして、ＲＤＢＭＳ−Ａ１４１及びＤＢＭＳ用インスタンスＢ１７０を操作し、ＤＢＭＳ用インスタンスＢ１７０上に、ストリーミング型レプリケーション機能を有効にした形で、ＲＤＢＭＳ−Ｂ１７１を起動する（ステップ４０２）。
これは、既存技術であり、たとえばpostgreSQL9.0以降では、前記の非特許文献２に示される方法で実現できる。これにより、図５の５０１の矢印で示されるようにＤＢデータの同期が開始される（ステップ４０３）。ここで、ＤＢデータＢ１８１には、以前の入れ替え時前までのＤＢデータが残っているため、以前の入れ替え時以降に行われた更新データのみ反映させれば良く、全てのＤＢデータをコピーする必要は無い。また、この同期は、ストリーミング型レプリケーション機能を用いているため、データ同期中に、黒矢印２０２で更新系のＳＱＬ文が発行され、ＤＢデータＡ１５１が更新された場合でも、一定のタイムラグの後、自動的にＤＢデータＢ１８１に反映される。最後に、制御プロキシ部１２２にＤＢ切り替え要求を行う（ステップ４０４）。
次に、ＤＢシステム切り替え処理（ステップ３０２）の説明を行う前に、制御プロキシ部１２２の動作概要を図６で説明する。
制御プロキシ部１２２は、一般的なプロキシと同様に、管理を行うメイン処理部６０１と、接続セッション毎のＳＱＬ文プロキシ処理を行う複数のセッション処理部６０２から構成される。
メイン処理部６０１は、接続要求を受け、その接続に対応するセッション処理部６０２を割り当てる処理や、後述するＤＢ切り替え処理におけるメイン処理を行うものである。
セッション処理部６０２は、Ｗｅｂアプリケーションケーション１１１からの接続セッションで処理要求されたＳＱＬ文を、後述する処理フローに従い、メイン処理部６０１で定められたＲＤＢＭＳに転送し、その結果を受けてＷｅｂアプリケーションケーション１１１に返すものである。
次に、ＤＢシステム切り替え処理（ステップ３０２）におけるメイン処理部６０１の処理フローを図７に示す。また、ＤＢシステム切り替え処理（ステップ３０２）時を含むすべての場合のセッション処理部６０２の処理フローで図８に示す。
メイン処理部６０１は、ステップ４０４でコントロール部１２１からＤＢ切り替え要求を受けると、全てのセッション処理部６０２に対して、処理中断指示を行う（ステップ７０１）。そして、後述するセッション処理部６０２の処理フロー（図８）により、各セッション処理部６０２から処理中断したことの報告を受け、全てのセッション処理部６０２で処理中断されたかをチェックする（ステップ７０２）。全てのセッション処理部６０２で処理中断されていない場合は、一定期間、例えば数秒の中断待ちを行い（ステップ７０３）、再度ステップ７０２のチェックを行う。
制御プロキシ部１２２は、一般的なプロキシと同様に、管理を行うメイン処理部６０１と、接続セッション毎のＳＱＬ文プロキシ処理を行う複数のセッション処理部６０２から構成される。
メイン処理部６０１は、接続要求を受け、その接続に対応するセッション処理部６０２を割り当てる処理や、後述するＤＢ切り替え処理におけるメイン処理を行うものである。
セッション処理部６０２は、Ｗｅｂアプリケーションケーション１１１からの接続セッションで処理要求されたＳＱＬ文を、後述する処理フローに従い、メイン処理部６０１で定められたＲＤＢＭＳに転送し、その結果を受けてＷｅｂアプリケーションケーション１１１に返すものである。
次に、ＤＢシステム切り替え処理（ステップ３０２）におけるメイン処理部６０１の処理フローを図７に示す。また、ＤＢシステム切り替え処理（ステップ３０２）時を含むすべての場合のセッション処理部６０２の処理フローで図８に示す。
メイン処理部６０１は、ステップ４０４でコントロール部１２１からＤＢ切り替え要求を受けると、全てのセッション処理部６０２に対して、処理中断指示を行う（ステップ７０１）。そして、後述するセッション処理部６０２の処理フロー（図８）により、各セッション処理部６０２から処理中断したことの報告を受け、全てのセッション処理部６０２で処理中断されたかをチェックする（ステップ７０２）。全てのセッション処理部６０２で処理中断されていない場合は、一定期間、例えば数秒の中断待ちを行い（ステップ７０３）、再度ステップ７０２のチェックを行う。
ステップ７０２において、全てのセッション処理部６０２で処理中断が確認できた場合は、次にＲＤＢＭＳ−Ａ１４１及びＲＤＢＭＳ−Ｂ１７１の機能を用いてデータ同期が終了しているか、同期されていないＳＱＬ文処理が無いかを確認する（ステップ７０４）。
postgreSQLの場合、例えば非特許文献２に示されている方法で、ストリーミングレプリケーション機能の状態確認を行ことで同期を確認できる。
ステップ７０４においてデータ同期が終了していない場合は、一定期間、例えば数秒の同期待ちを行い、再度ステップ７０４のチェックを行う。
ステップ７０４において、データ同期が終了していた場合は、各セッション処理部６０２がＳＱＬを転送するＲＤＢＭＳを、ＲＤＢＭＳ−Ａ１４１からＲＤＢＭＳ−Ｂ１７１に変更する（ステップ７０６）。そして、各セッション処理部６０２に処理再開指示を行う（ステップ７０７）。
postgreSQLの場合、例えば非特許文献２に示されている方法で、ストリーミングレプリケーション機能の状態確認を行ことで同期を確認できる。
ステップ７０４においてデータ同期が終了していない場合は、一定期間、例えば数秒の同期待ちを行い、再度ステップ７０４のチェックを行う。
ステップ７０４において、データ同期が終了していた場合は、各セッション処理部６０２がＳＱＬを転送するＲＤＢＭＳを、ＲＤＢＭＳ−Ａ１４１からＲＤＢＭＳ−Ｂ１７１に変更する（ステップ７０６）。そして、各セッション処理部６０２に処理再開指示を行う（ステップ７０７）。
次に、ＤＢシステム切り替え処理を含むすべての場合のセッション処理部６０２の処理を、図８を用いて説明する。
メイン処理部６０１から各々の接続セッションに割り当てられたセッション処理部６０２は、まずＷｅｂアプリケーションケーション１１１からの要求が、接続セッションの終了要求かどうかをチェックする（ステップ８０１）。もし、接続セッションの終了要求であれば、そのまま処理を終了する。しかし、接続セッションの終了要求でなければ、ＳＱＬ文を受信する（ステップ８０２）。
次に、メイン処理部６０１から図７のステップ７０１の中断指示が来ているかどうかをチェックする（ステップ８０３）。ステップ８０３で中断指示されていた場合は、一定期間、例えば数ミリ秒程度の再開指示待ちを行い（ステップ８０４）、メイン処理部６０１から図７のステップ７０７の再開指示が来ているかをチェックする（ステップ８０５）。
ステップ８０５において、再開指示されていなければ、ステップ８０４に戻り、再度再開指示待ちを行う。ステップ８０５において再開指示されていた場合、もしくは、ステップ８０３で中断指示されていなかった場合は、ステップ８０２で受けたＳＱＬ文がトランザクション開始要求かどうかをチェックする（ステップ８０６）。トランザクション開始要求でなければ、そのＳＱＬ文をメイン処理部６０１で定められたＲＤＢＭＳに転送し、その結果Ｗｅｂアプリケーションケーション１１１に返答する（ステップ８０７）。その後、ステップ８０１に戻る。
メイン処理部６０１から各々の接続セッションに割り当てられたセッション処理部６０２は、まずＷｅｂアプリケーションケーション１１１からの要求が、接続セッションの終了要求かどうかをチェックする（ステップ８０１）。もし、接続セッションの終了要求であれば、そのまま処理を終了する。しかし、接続セッションの終了要求でなければ、ＳＱＬ文を受信する（ステップ８０２）。
次に、メイン処理部６０１から図７のステップ７０１の中断指示が来ているかどうかをチェックする（ステップ８０３）。ステップ８０３で中断指示されていた場合は、一定期間、例えば数ミリ秒程度の再開指示待ちを行い（ステップ８０４）、メイン処理部６０１から図７のステップ７０７の再開指示が来ているかをチェックする（ステップ８０５）。
ステップ８０５において、再開指示されていなければ、ステップ８０４に戻り、再度再開指示待ちを行う。ステップ８０５において再開指示されていた場合、もしくは、ステップ８０３で中断指示されていなかった場合は、ステップ８０２で受けたＳＱＬ文がトランザクション開始要求かどうかをチェックする（ステップ８０６）。トランザクション開始要求でなければ、そのＳＱＬ文をメイン処理部６０１で定められたＲＤＢＭＳに転送し、その結果Ｗｅｂアプリケーションケーション１１１に返答する（ステップ８０７）。その後、ステップ８０１に戻る。
ステップ８０６において、トランザクション開始要求である場合は、ステップ８０２で受けたＳＱＬ文に対し、ステップ８０７と同様の処理を行う（ステップ８０８）。ステップ８０８の後、Ｗｅｂアプリケーションケーション１１１から、トランザクションに含まれるＳＱＬ文を受信し（ステップ８０９）、そのＳＱＬ文に対しステップ８０７と同様の処理を行う（ステップ８１０）。
ステップ８１０の後、ステップ８０９で受信したＳＱＬ文がトランザクション終了要求かどうかをチェックする（ステップ８１１）。トランザクション終了要求でなければ、ステップ８０９に戻り、トランザクション内のＳＱＬ文処理を行う。しかし、トランザクション終了要求の場合は、ステップ８０１に戻る。
これにより、トランザクション中は、ステップ８０９からステップ８１１をループするため、中断及び転送するＤＢ切り替えも行われない。このため、トランザクションの処理の一貫性が失われることはない。また、トランザクション終了直後を含め、トランザクション中でない場合は、ステップ８０３の中断指示の判定処理の結果に応じて、メイン処理部６０１によって転送するＤＢ切り替えが行われる。
ステップ８１０の後、ステップ８０９で受信したＳＱＬ文がトランザクション終了要求かどうかをチェックする（ステップ８１１）。トランザクション終了要求でなければ、ステップ８０９に戻り、トランザクション内のＳＱＬ文処理を行う。しかし、トランザクション終了要求の場合は、ステップ８０１に戻る。
これにより、トランザクション中は、ステップ８０９からステップ８１１をループするため、中断及び転送するＤＢ切り替えも行われない。このため、トランザクションの処理の一貫性が失われることはない。また、トランザクション終了直後を含め、トランザクション中でない場合は、ステップ８０３の中断指示の判定処理の結果に応じて、メイン処理部６０１によって転送するＤＢ切り替えが行われる。
ＤＢシステム切り替え処理（ステップ３０２）の後のシステム状況を図９に示す。
ＤＢシステム切り替え処理により、黒矢印９０１に示されるようにＳＱＬ文が転送されるＲＤＢＭＳがＲＤＢＭＳ−Ａ１４１からＲＤＢＭＳ−Ｂ１７１に切り替わっている。
次に、入れ替え後処理（ステップ３０３）の詳細な処理フローを図１０に示す。
まず、コントロール部１２１は、ＤＢＭＳ用インスタンスＡ１４０上で稼働しているＲＤＢＭＳ−Ａ１４１を停止する（ステップ１００１）。ＲＤＢＭＳ−Ａ１４１は、ＤＢシステム切り替え処理（ステップ３０２）により、ＳＱＬ文が転送されてくることはないため、停止してもシステム全体の影響は無い。
ＤＢシステム切り替え処理により、黒矢印９０１に示されるようにＳＱＬ文が転送されるＲＤＢＭＳがＲＤＢＭＳ−Ａ１４１からＲＤＢＭＳ−Ｂ１７１に切り替わっている。
次に、入れ替え後処理（ステップ３０３）の詳細な処理フローを図１０に示す。
まず、コントロール部１２１は、ＤＢＭＳ用インスタンスＡ１４０上で稼働しているＲＤＢＭＳ−Ａ１４１を停止する（ステップ１００１）。ＲＤＢＭＳ−Ａ１４１は、ＤＢシステム切り替え処理（ステップ３０２）により、ＳＱＬ文が転送されてくることはないため、停止してもシステム全体の影響は無い。
次に、ＤＢＭＳ用インスタンスＡ１４０から、ストレージＡ１５０を切り離し、ＤＢＭＳ用インスタンスＡ１４０を停止する（ステップ１００２）。ステップ１００１により、ＲＤＢＭＳ−Ａ１４１は停止しているため、ＤＢＭＳ用インスタンスＡ１４０を停止してもシステム全体に影響はない。また、ストレージＡ１５０上のＤＢデータＡ１５１には、ＤＢシステム切り替え処理（ステップ３０２）で切り替えが行われる以前までのＤＢデータが、保管されることとなる。
入れ替え後処理（ステップ３０３）の後のシステム状態を図１１に示す。図２に示した入れ替え開始前の状態と比較すると、入れ替え元をＤＢシステムＡ１３０と、入れ替え先をＤＢシステムＢ１６０が完全に入れ替わっており、ＤＢの入れ替え処理が終了していることが分かる。
本発明では、再度入れ替えを行うことも可能である。また、Ｗｅｂアプリケーション１１１からのＳＱＬ文は、どの時点でも同期されたデータを持つＤＢシステムＡ１３０もしくはＤＢシステムＢ１６０で処理されるため、動的な入れ替えも実現できている。
さらに、ストレージＡ１５０上のＤＢデータＡ１５１には、切り替えが行われる以前までのＤＢデータが、保管されているため、ステップ４０３で開始されるデータ同期では、前回の切り替えからの差分データのみ同期すればよい。このため、特許文献１のように全てのデータをコピーする必要はない。
以上により、ＩａａＳで提供される異なる性能のインスタンスを、上記のシステムで入れ替えることにより、動的なスケールＵＰ及びＤＯＷＮが実現できる。
さらに、ストレージＡ１５０上のＤＢデータＡ１５１には、切り替えが行われる以前までのＤＢデータが、保管されているため、ステップ４０３で開始されるデータ同期では、前回の切り替えからの差分データのみ同期すればよい。このため、特許文献１のように全てのデータをコピーする必要はない。
以上により、ＩａａＳで提供される異なる性能のインスタンスを、上記のシステムで入れ替えることにより、動的なスケールＵＰ及びＤＯＷＮが実現できる。
１００…ＩａａＳ、１１０…Ｗｅｂアプリケーション用インスタンス、１１１…Ｗｅｂアプリケーション、１２０…コントロール・プロキシ用インスタンス、１２１…コントロール部、１２２…制御プロキシ部、１３０…ＤＢシステムＡ、１４０…ＤＢＭＳ用インスタンスＡ、１４１…ＲＤＢＭＳ−Ａ、１４２…ストリーム複製処理部、１５０…ストレージＡ、１５１…ＤＢデータＡ、１６０…ＤＢシステムＢ、１７０…ＤＢＭＳ用インスタンスＢ、１７１…ＲＳＢＭＳ−Ｂ、１７２…ストリーム複製処理部、１８０…ストレージＢ、１８１…ＤＢデータＢ
Claims (2)
- 性能の異なる仮想マシン上で稼動する第１および第２のデータベースを備え、外部からの指示に応じて、システムが利用している仮想マシンを入れ替え、システムの性能をスケールアップ及びスケールダウンさせる方法であって、
前記システムが、
前記データベースが備えるストリーム型レプリケーション機能を用いて前記データベースのデータ同期をとる第１のステップと、
データ同期確立後に、ＳＱＬ文を転送する仮想マシンを他の仮想マシンに切り替える第２のステップと、
を備えることを特徴とするスケールアップ及びスケールダウン方法。 - 性能の異なる仮想マシン上で稼動する第１および第２のデータベースを備え、外部からの指示に応じて、システムが利用している仮想マシンを入れ替え、システムの性能をスケールアップ及びスケールダウンさせるデータベースシステムであって、
前記データベースが備えるストリーム型レプリケーション機能を用いて前記データベースのデータ同期をとる第１の手段と、
データ同期確立後に、ＳＱＬ文を転送する仮想マシンを他の仮想マシンに切り替える第２の手段と、
を備えることを特徴とするデータベースシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011079001A JP2012215937A (ja) | 2011-03-31 | 2011-03-31 | データベースのストリーム型レプリケーション機能を用いたスケールアップとダウン方法及びシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011079001A JP2012215937A (ja) | 2011-03-31 | 2011-03-31 | データベースのストリーム型レプリケーション機能を用いたスケールアップとダウン方法及びシステム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2012215937A true JP2012215937A (ja) | 2012-11-08 |
Family
ID=47268673
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2011079001A Pending JP2012215937A (ja) | 2011-03-31 | 2011-03-31 | データベースのストリーム型レプリケーション機能を用いたスケールアップとダウン方法及びシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2012215937A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2019219976A (ja) * | 2018-06-21 | 2019-12-26 | 日本電信電話株式会社 | 分散処理システムに用いられるサーバ装置、分散処理方法およびプログラム |
| US10628273B2 (en) | 2015-01-30 | 2020-04-21 | Nec Corporation | Node system, server apparatus, scaling control method, and program |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003345639A (ja) * | 2002-05-27 | 2003-12-05 | Nec Soft Ltd | データベースの交換システム |
| JP2011028328A (ja) * | 2009-07-21 | 2011-02-10 | Toshiba Corp | 仮想マシン配置プログラム及び装置 |
-
2011
- 2011-03-31 JP JP2011079001A patent/JP2012215937A/ja active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003345639A (ja) * | 2002-05-27 | 2003-12-05 | Nec Soft Ltd | データベースの交換システム |
| JP2011028328A (ja) * | 2009-07-21 | 2011-02-10 | Toshiba Corp | 仮想マシン配置プログラム及び装置 |
Non-Patent Citations (2)
| Title |
|---|
| CSND200900698001; 鶴長 鎮一: '大規模サイト運用のプロに学ぶ スケールアウト／スケールアップの鉄則' ＳｏｆｔｗａｒｅＤｅｓｉｇｎ 第２２８号, 20091018, ｐ．１８-２９, （株）技術評論社 * |
| JPN6014015550; 鶴長 鎮一: '大規模サイト運用のプロに学ぶ スケールアウト／スケールアップの鉄則' ＳｏｆｔｗａｒｅＤｅｓｉｇｎ 第２２８号, 20091018, ｐ．１８-２９, （株）技術評論社 * |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10628273B2 (en) | 2015-01-30 | 2020-04-21 | Nec Corporation | Node system, server apparatus, scaling control method, and program |
| JP2019219976A (ja) * | 2018-06-21 | 2019-12-26 | 日本電信電話株式会社 | 分散処理システムに用いられるサーバ装置、分散処理方法およびプログラム |
| WO2019244932A1 (ja) * | 2018-06-21 | 2019-12-26 | 日本電信電話株式会社 | 分散処理システムに用いられるサーバ装置、分散処理方法およびプログラム |
| JP7135489B2 (ja) | 2018-06-21 | 2022-09-13 | 日本電信電話株式会社 | 分散処理システムに用いられるサーバ装置、分散処理方法およびプログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102430869B1 (ko) | 컨테이너화된 환경에서 클러스터의 라이브 마이그레이션 | |
| US11249815B2 (en) | Maintaining two-site configuration for workload availability between sites at unlimited distances for products and services | |
| US10084858B2 (en) | Managing continuous priority workload availability and general workload availability between sites at unlimited distances for products and services | |
| KR102059251B1 (ko) | 노드 시스템, 서버 장치, 스케일링 제어 방법 및 프로그램 | |
| US10482104B2 (en) | Zero-data loss recovery for active-active sites configurations | |
| US20100318608A1 (en) | Systems and methods for efficient live application migration within bandwidth constrained networks | |
| US20150058864A1 (en) | Management and synchronization of batch workloads with active/active sites oltp workloads | |
| CN106100894A (zh) | 一种高可靠的集群运维管理方法 | |
| US20200112628A1 (en) | Heartbeat in failover cluster | |
| CN105721582A (zh) | 多节点文件备份系统 | |
| CN102682117A (zh) | 一种数据库集群数据快速复制的方法 | |
| JP2012215937A (ja) | データベースのストリーム型レプリケーション機能を用いたスケールアップとダウン方法及びシステム | |
| JP2007200085A (ja) | データ複製システムおよびデータ複製方法 | |
| US20200272453A1 (en) | Real-Time Version Controller | |
| TW202001556A (zh) | 虛擬機器群組的容錯方法及其容錯系統 | |
| JP6056408B2 (ja) | フォールトトレラントシステム | |
| JP2012078993A (ja) | リレーショナルデータベースをスケールアップ及びスケールダウンさせる方法及びシステム | |
| CN100563233C (zh) | 一种公共对象请求代理结构应用中的容错性方法 | |
| WO2022121387A1 (zh) | 数据存储方法、装置、服务器及介质 | |
| CN108616597B (zh) | 一种实现服务永不中断的分布式运行方法 | |
| Dufrasne et al. | IBM z/OS Global Mirror Planning, Operations, and Best Practices | |
| CN109753292A (zh) | 一种在多单实例数据库服务中部署多个应用的方法及装置 | |
| US20230305947A1 (en) | Using clusters to create test instances | |
| US20230334026A1 (en) | Asynchronous metadata replication and migration between compute sites | |
| JP2011150459A (ja) | ディザスタリカバリシステムおよびバックアップサイト構築方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20130726 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20140312 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20140414 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20140804 |