"バイナリログファイルを使用するMySQLデータベースまたはシステムと、他の種類のデータベースまたはシステムとの間でデータを転送するために、ログベースレプリケーションを使用するシステムであって、ベンダーアクセスモジュールを備え、前記ベンダーアクセスモジュールは、イベントデータを第1のもしくはソースのデータベースまたはシステムによってバイナリログファイルに記録されたものとして認識し、前記イベントデータをデータレコードに変換し、前記データレコードを処理し、処理されたデータを含むトレールファイルを生成するために、extractプロセスとやり取りし、前記ベンダーアクセスモジュールは、前記処理されたデータを第2のもしくはターゲットのデータベースまたはシステムに与えるのに使用される、システム。前記第1のもしくはソースのデータベースまたはシステムはMySQLデータベースであり、前記バイナリログファイルはMySQLバイナリログファイルであり、前記第2のもしくはターゲットのデータベースまたはシステムは非MySQLデータベースである、請求項1に記載のシステム。ベンダーアクセスモジュールは、前記バイナリログファイルに記録されているイベントデータタイプのサブセットのみを認識し、これらをデータレコードに変換するよう構成されている、請求項1に記載のシステム。前記extractプロセスはOracle登録商標GoldenGateextractプロセスであり、前記トレールファイルはOracleGoldenGateトレールファイルである、請求項1に記載のシステム。前記ベンダーアクセスモジュールは、extractプロセスが特定のトランザクション用にデータレコードを検索するためにAPIを設ける、請求項1に記載のシステム。前記ベンダーアクセスモジュールは、バイナリログからイベントの処理を与えるために用いることができる、複数のVAMイベントクラスと;前記第1のもしくはソースのデータベースまたはシステムによって与えられるアクセスライブラリをラップアラウンドするために用いることができる、複数のVAMバイナリログクラスと;ビンログクラスからレコードを読出しおよび処理し、これらをデータレコードキューに入れるために用いることができる、複数のVAMリーダおよびプロセッサクラスとを含む、請求項1に記載のシステム。前記ベンダーアクセスモジュールは、ログインデックスファイルを用いて、複数のバイナリログファイルから使用するべき現行のバイナリログファイル、およびその状態を定める、請求項1に記載のシステム。前記ベンダーアクセスモジュールは、前記バイナリログファイルに記録されているログ回転イベントを認識し、この情報を用いて次のバイナリログ名を得る、請求項1に記載のシステム。バイナリログファイルを使用するMySQLデータベースまたはシステムと、他の種類のデータベースまたはシステムとの間でデータを転送するためにログベースレプリケーションを用いる方法であって、ベンダーアクセスモジュールを設けるステップを備え、前記ベンダーアクセスモジュールは、イベントデータを第1のもしくはソースのデータベースまたはシステムによってバイナリログファイルに記録されたものとして認識し、前記イベントデータをデータレコードに変換し、前記データレコードを処理し、処理されたデータを含むトレールファイルを生成するためにextractプロセスとやり取りし、前記ベンダーアクセスモジュールは、前記処理されたデータを第2のもしくはターゲットのデータベースまたはシステムに与えるのに使用される、方法。前記第1のもしくはソースのデータベースまたはシステムはMySQLデータベースであり、前記バイナリログファイルはMySQLバイナリログファイルであり、前記第2のもしくはターゲットのデータベースまたはシステムは非MySQLデータベースである、請求項9に記載の方法。ベンダーアクセスモジュールは、前記バイナリログファイルに記録されているイベントデータタイプのサブセットのみを認識し、これらをデータレコードに変換するよう構成されている、請求項9に記載の方法。前記extractプロセスはOracle登録商標GoldenGateextractプロセスであり、前記トレールファイルはOracleGoldenGateトレールファイルである、請求項9に記載の方法。前記ベンダーアクセスモジュールは、extractプロセスが特定のトランザクション用にデータレコードを検索するためにAPIを設ける、請求項9に記載の方法。前記ベンダーアクセスモジュールは、バイナリログからイベントの処理を与えるために用いることができる、複数のVAMイベントクラスと;前記第1のもしくはソースのデータベースまたはシステムによって与えられるアクセスライブラリをラップアラウンドするために用いることができる、複数のVAMバイナリログクラスと;ビンログクラスからレコードを読出しおよび処理し、これらをデータレコードキューに入れるために用いることができる、複数のVAMリーダおよびプロセッサクラスとを含む、請求項9に記載の方法。前記ベンダーアクセスモジュールは、ログインデックスファイルを用いて、複数のバイナリログファイルから使用するべき現行のバイナリログファイル、およびその状態を定める、請求項9に記載の方法。前記ベンダーアクセスモジュールは、前記バイナリログファイルに記録されているログ回転イベントを認識し、この情報を用いて次のバイナリログ名を得る、請求項9に記載の方法。一時的でないコンピュータ読取可能媒体であって、中に記憶されている命令を含み、命令がコンピュータによって読出および実行されると、コンピュータに、ベンダーアクセスモジュールを設けるステップを実行させ、前記ベンダーアクセスモジュールは、イベントデータを第1のもしくはソースのデータベースまたはシステムによってバイナリログファイルに記録されたものとして認識し、前記イベントデータをデータレコードに変換し、前記データレコードを処理し、処理されたデータを含むトレールファイルを生成するためにextractプロセスとやり取りし、前記ベンダーアクセスモジュールは、前記処理されたデータを第2のもしくはターゲットのデータベースまたはシステムに与えるのに使用される、一時的でないコンピュータ読取可能媒体。概要:異種システム間でデータを転送するためのシステムおよび方法が記載され、特にたとえばMySQLデータベースまたはシステムと、他の種類のデータベースまたはシステムとの間でデータを転送するためにログベースレプリケーションが用いられる。ある実施例に従うと、システムを用いてソースデータベースシステムからターゲットデータベースシステムへのMySQLデータの1回限りのコピーまたは最初のコピーを行ない、および/またはMySQLデータベースのバイナリログからキャプチャされた進行中のトランザクションを、連続した態様で1つ以上の非MySQLデータベースにレプリケートし、2つのシステムは対象トランザクションのために同期化される。ある実施例に従うと、すべてのもしくは部分的データ変更は、MySQLバイナリログから抽出でき、任意に変換、スキップまたは拡大され、ファイルに出力または書込まれ一実施例に従うと、トレールファイル、またはOracle登録商標GoldenGateトレールファイルとして実施でき、次に1つ以上のターゲットシステムたとえば別のMySQLデータベース、または非MySQLデータベースで与えることができ、それによりソースおよびターゲットのシステムを同期させる。詳細な説明:異種システムの間でデータを転送するためのシステムおよび方法が記載され、特にログベースレプリケーションを用いて、たとえばMySQLデータベースまたはシステムと、他の種類のデータベースまたはシステムとの間でデータを転送する。一実施例に従うと、システムを用いてソースデータベースシステムからターゲットデータベースシステムへのMySQLデータの1回限りのコピーまたは最初のコピーを行ない、および/またはMySQLデータベースのバイナリログからキャプチャされた進行中のトランザクションを、連続した態様で1つ以上の非MySQLデータベースにレプリケートし、2つのシステムは対象トランザクションのために同期化される。一実施例に従うと、すべてのもしくは部分的データ変更は、MySQLバイナリログから抽出でき、任意に変換、スキップまたは拡大され、ファイルに出力または書込まれ一実施例に従うと、トレールファイル、またはOracle登録商標GoldenGateトレールファイルとして実施でき、次に1つ以上のターゲットシステムたとえば別のMySQLデータベース、または非MySQLデータベースで与えることができ、それによりソースおよびターゲットのシステムを同期させる。本発明のさまざまな実施例の利点は以下を含む:1.ログベースレプリケーションは、MySQLデータベースシステムと非MySQLデータベースシステムとの間のトランザクションレプリケーションについて、非常に低いレイテンシを可能にする。トランザクションがMySQLシステムにコミットされてから非MySQLシステムにレプリケーションされるまでの一般的に予想される時間は数秒以下である。2.MySQLシステムのオーバーヘッドは、従来の方法と比べて著しく低い。なぜなら、変更はログからキャプチャされるのであって、MySQLシステムのデータページではないからである。ネットワーク上で転送されるバイトの数も著しく低い。3.アプリケーションテーブルは、SQLまたは他のSQLを組込んだプログラミング言語またはSQL様言語を介してクエリーされない。それにより、レプリケーションは非侵襲性のものとなる。4.本システムは第3のゲートウェイプロダクトの使用を必要とせず、ネットワークまたはシステムの障害の場合、およびデータサイト全体に影響を及ぼすほとんどの障害に対しても、トランザクションの配信を保証することができる。5.オペレーショナルレポーティングアプリケーションを用いて、MySQLデータベースにアクセスすることなく、リアルタイムベースで非MySQLデータベースからデータを得ることができる。6.本システムは、MySQLデータベースで実行されるアプリケーションの非MySQLデータベースへの移行をほぼゼロに近いダウンタイムで可能にし、さらにMySQLデータベースからのトランザクションが、ほぼリアルタイムまたはアクティブデータウェハウス用に、データベースマシンで使われることを可能にする。7.本システムはログベース変更データキャプチャCDCを可能にし、他のシステムへのスケーリングを求めているがアプリケーションの停止を受入れることができないMySQLベースの組織が、2つのシステムを同期して維持し、十分なテストを行ない、ダウンタイムを発生することなく、自己のMySQLシステムを他のシステムに最終的に移行することを可能にする。現在、MySQLデータベースからのリアルタイム操作は、リアルタイムベースで企業データウェハウスとの統合は一般になされていない。一実施例に従うと、該方法は企業がMySQLシステムからデータを得る方法を提供する。一実施例に従うと、システムはMySQLのバイナリログフィーチャを用いてデータをキャプチャする。MySQLバイナリログはデータをたとえばDML操作で変更するステートメントデータを含む。ステートメントはイベントの形で格納され、イベントはデータへの変更を記述する。一実施例に従うと、バイナリログは2つの重要な役割を果たす:1レプリケーションであって、バイナリログは、スレーブサーバに送られるステートメントの記録として、マスタレプリケーションサーバで用いられる。マスタサーバはそのバイナリログに含まれるイベントをスレーブに送り、そこでマスタで行なわれたのと同じデータ変更を行なうためにイベントが実行され、および2データリカバリであって、特定のデータリカバリ操作はバイナリログの使用を必要とする。バックアップファイルが回復されると、バックアップが行なわれた後に記録されたバイナリログは再実行される。これらのイベントにより、データベースはバックアップ時点のものから現在のものになる。バイナリログがトランザクションデータを記憶可能にすることは、MySQLの設置によってデフォルトでは設定されない。一実施例に従うと、ログビンのパラメータを用いてバイナリロギングを可能にする。このパラメータはMySQL初期ファイルで指定されるこれはウインドウズ登録商標プラットフォームではmy.iniであり、他のプラットフォームではmy.confである。MySQLの以前のリリースでは、バイナリログはステートメントレベル情報を含んでいた、すなわち、完全なDDLおよびDMLステートメントをログしていた。異種性を支持するために、データが汎用的なデータフォーマットで利用可能にするためには、純粋なテキストSQLステートメントに基づいてログベースキャプチャを構築することは難しい。MySQLの後のバージョンでは、上記の問題を軽減するために、バイナリロギングサポートを導入している。MySQLバージョン5.1は、バイナリデータへのアクセスを提供するために新しい内部Cクラスを導入している。一実施例に従うと、IngressおよびSybaseといった他のデータベースで見られる循環型ロギングスタイルと比べて、MySQLバイナリログは順次作成され番号が付けられる。MySQLは古いログファイルを自動的にはアーカイブしないので、古いログファイルを保つ/バックアップするために、管理者は十分に注意しなければならない。一実施例に従うと、非トランザクションテーブルへの更新は、実行の後すぐにバイナリログに記憶される。拘束のないトランザクションでは、InnoDBテーブルといったトランザクションテーブルを変更するすべての更新INSERT、DELETE、UPDATEは、COMMITステートメントがサーバによって受取られるまでキャッシュされる。その時点で、サーバデーモンmysqldはトランザクション全体をバイナリログに書込む。サーバデーモンはROLLBACKステートメントが発行されたのなら、トランザクションデータを書込まない。バイナリログについて、ロールバック操作はno-opの非記録操作である。図1は、一実施例に係わる、異種ログベースレプリケーション用のシステムのアーキテクチャの全体を示す図である。図1に示されるように、アーキテクチャ102はMySQLまたは同様のデータベース104を含み、これは上記の構成設定およびパラメータを用いて、データを現行のバイナリログファイル106または複数のバイナリログファイル108にログするよう構成されている。一実施例に従うと、システムは、ファイルリーダ、ファイルCACHEおよびデータ変換クラスを与えるために、任意に1つ以上のMySQLライブラリ110を含むことができる。別の実施例では、この特定のコンポーネントは必要ない。ベンダーアクセスモジュールVAMプラグインもしくはアプリケーションプログラムインターフェイスAPI111または同様のコンポーネントを用いて、OracleGoldenGateまたは類似のレプリケーションプロダクトといったデータキャプチャおよびレプリケーションシステムまたはプロダクトにより、バイナリログファイルへのアクセスが与えられる。一実施例に従うと、VAMは、複数のMySQLVAMイベントクラス112を含み、これを用いてたとえば現行のバイナリログを開く、イベントを読む、VAM記録に変換する、ログ回転を取扱うなどといった、MySQLバイナリログからのイベントの処理をもたらし、さらにMySQLライブラリをラップアラウンドするために用いることができる複数のMySQLVAMバイナリログクラス114、ならびにビンログクラスからレコードを読取り処理し、それらをレコードキューに入れるために用いることができる複数のVAMリーダおよびプロセッサクラス116を含む。一実施例に従うと、これらのクラスの一部または全部はextractコールによって、ブロックではなく自己の専用スレッドを有することができる。他の実施例に従うと、上記はMySQL環境およびMySQLVAMの使用を示しているが、他の種類のVAMを他の種類のデータベースまたはシステムで実施できることは明らかである。一実施例に従うと、VAMreadコールにより、後で使用されるよう、レコードを保持するためにレコードキュー118が設けられる。複数のVAMレコードクラス120を用いてレコードキューからデータを読出し、VAMAPIを用いて、extractにデータを送ることができる。OracleGoldenGateまたは同様のレプリケーション処理といったextractプロセス122がコンパイルされて、データをVAMAPIから取込み、データをターゲットシステム126および/またはターゲットデータベース128に与えるために、トレール124に、またはGoldenGateトレールファイルといったトレールファイルに、書込む。一実施例に従うと、MySQLはイベント入力としてデータをバイナリログ内にストアし、SQLステートメントおよび操作の性質に基づきさまざまなイベントを支持し、イベントデータを読出すためにCクラスを与える。一実施例に従うと、VAMはこれらバイナリログイベントのサブセットを認識するために一般に構成される。たとえば、VAMはトランザクション、DMLステートメントデータ、ログ回転などを表わすバイナリログイベントを認識するよう構成することができる。表1は一実施例に従うと、MySQLVAMがバイナリログから認識することができるよう構成可能であるMySQLイベントのリストを示す。他の実施例に従うと、他の種類のイベントも認識できることは明らかである。一実施例に従うと、VAMの実施はCを用いて書込むことができ、VAMモジュールの実施は2つの主要な部分に分けることができる:第1の部分は、内部的に立てられたイベントCクラスを用いてバイナリログイベントを読出し、データレコードに処理し、レコードを既存フォーマット送信できる形にして、制限された大きさのキューに記憶し、第2の部分は、APIからリクエストを受取るたびに、キューからレコードを取ってきてAPIに送信する。ログインデックスファイル図2は現行のバイナリログファイルを定めるためのログインデックスファイルの使用を示す図である。一実施例に従うと、MySQLはログインデックスファイルを用いて、現行のバイナリログファイルおよびより古いログファイルを識別するリストを維持する。このログインデックスファイルは、バイナリログと、同じディレクトリ場所にある。システムはログファイルフォーマットが、たとえばROW、STATEMENT、またはMIXEDフォーマットのいずれであるかを判断するために構成ファイルから読出し、ROWでない場合に、アベンドする。初期化の際、VAMはアクティブバイナリログファイルの名前を得る必要がある。図2に示されるように、実施例132に従うと、MySQLデータベース104は、上記の構成設定およびパラメータを用いて、現行のバイナリログファイル106または複数のバイナリログファイル108にデータ変更を書込むことができる。アクティブバイナリログを定めるために、VAM111は環境変数または与えられたVAMパラメータからMySQL設置ホームを得て、MySQL初期化ファイルを読出しすなわち、ウインドウズ登録商標プラットフォームではmy.iniであり、他のプラットフォームではmy.confファイルであり;ログビンパラメータの値を得て、ログディレクトリ場所およびログインデックスファイル名を得て、ログインデックスファイル140を開けて内容142を読出す。この内容から、VAMはリストの最後のログファイルを判断し、この情報を用いて特定のログファイルを開き144、そのログファイルがまだサーバによって使用されているかどうかをチェックするたとえば、フォーマット記述イベントのフラグ値がLOGEVENTBINLOGINUSEFであるかチェックする。イエスなら、MySQLサーバは現在書込のためにこのログファイルを使用しているのであり、VAMはこのログファイルをアクティブログファイルとして扱う。図3は、一実施例に従う異種ログベースレプリケーション用の処理のフローチャートである。図3に示されるように、ステップ160において、ソースシステムたとえばMySQLデータベースは、トランザクションデータをバイナリログに書込むよう構成されている。ステップ162において、ランタイム中に、1つ以上のバイナリログが作成され、たとえばSQLまたは他のデータベースステートメントに対応するイベント入力として、トランザクションまたは変更データが中に記憶される。ステップ164において、VAMMySQLデータベースの場合、MySQLVAMはバイナリログイベントを読出し、これらをデータレコードのキューに処理する。ステップ166において、トランザクションデータのリクエストが受取られると、VAMはキューからデータレコードを取ってきて、VAMAPIに送る。ステップ168において、extractプロセスたとえば、OracleGoldenGateはAPIから読出し、トランザクションまたは変更データを反映して、トレール情報またはトレールファイルたとえばOracleGoldenGateトレールファイルを作成する。ステップ170において、トレール情報またはトレールファイルは、1つ以上のターゲットシステムたとえば、ターゲットデータベースに通信またはポンプされ、そのトレール情報またはトレールファイルは、ここでも、OracleGoldenGateまたは他のプロダクトを使用してそのターゲットシステムでトランザクションをレプリケーションするのに使用される。ログ回転一実施例に従うと、バイナリログと係わる特定の種類のイベントは回転イベントであり、これは可能なログ回転を示す、すなわち、MySQLサーバが現行のバイナリログを閉じて新しいバイナリログを開くたびに、バイナリログにログされる。ログ回転の可能な理由は、たとえばログファイルのサイズがmaxbinlogsizeパラメータを超える、または明確なフラッシュログコマンドが、MySQLコマンドコンソールから発せられた場合を含む。この場合、MySQLは現行のバイナリログに回転イベントを作成し、現行のバイナリログを閉じて、さらに処理するために新しいバイナリログを開く。回転イベントは、作成するべき新しいログファイルを示す。一実施例に従うと、VAMはこの値を用いて既存のバイナリログファイルを閉じ、新しいバイナリログファイルを開け、その読出を続けることができる。一実施例に従うと、回転イベントは、CRotateEventCクラスによって表わされ、これは以下のように定義される:一実施例に従うと、以下のシナリオはMySQLのログ回転を引き起こすすなわち、既存のアクティブログファイルを閉じて、新しいログファイルを開く:1.アクティブログファイルのサイズが、maxbinlogsize値を超えた場合my.iniまたはmy.confファイルで指定されている。このシナリオでは:a.MySQLはアクティブバイナリログにおいて’RotateEvent’をログする。回転イベントデータ部は、新しいアクティブバイナリログの場所および名前を含む。b.MySQLはアクティブバイナリログを閉じて、フォーマット記述イベントフラグをNULLにリセットするこのフラグは前にLOGEVENTBINLOGINUSEF値に設定されている。c.MySQLは新しいバイナリログを作成し、フォーマット記述イベントフラグをLOGEVENTBINLOGINUSEF値に設定する。2.明確なフラッシュログコマンドがMySQLSQLプロンプトで発行された場合。このシナリオでは:a.MySQLはアクティブバイナリログにおいて’RotateEvent’をログする。回転イベントデータ部は、新しいアクティブバイナリログの場所および名前を含む。b.MySQLはアクティブバイナリログを閉じて、フォーマット記述イベントフラグをNULLにリセットするこのフラグは前にLOGEVENTBINLOGINUSEF値に設定されている。c.MySQLは新しいバイナリログを作成し、フォーマット記述イベントフラグをLOGEVENTBINLOGINUSEF値に設定する。3.サーバシャットダウンの際。このシナリオでは:a.MySQLはアクティブバイナリログに’StopEvent’をログする。b.MySQLはバイナリログを閉じ、さらにフォーマット記述イベントフラグをNULL値にリセットするこのフラグは前にLOGEVENTBINLOGINUSEF値に設定されている。4.サーバスタートアップの際。このシナリオでは:a.MySQLは新しいバイナリログを作成し、フォーマット記述イベントフラグをLOGEVENTBINLOGINUSEF値に設定する。一実施例に従うと、上記のシナリオ1および2では、VAMはログ回転が起こったことを識別するために回転イベントを使用し、次のバイナリログの名前を得るために、回転イベントデータを用いる。VAMは次のバイナリログを開き、そのバイナリログ読出を続ける。上記のシナリオ3および4では、VAMがストップイベントに出合うと、使用しているバイナリログを閉じて、次のバイナリログがあるかログインデックスファイルをチェックする。VAMがインデックスファイルにおいて次のバイナリログを見つけると、そのバイナリログを開いて読出を続ける。VAMがインデックスファイルにおいて新しいログファイル名を見つけることができなかったたとえば、サーバがまだシャットダウンモードにあるか、シャットダウン後、スタートしていない場合、VAMはextractに対してアベンドすることを知らせる。サーバクラッシュの際、フォーマット記述イベントのフラグがサーバの再スタートのときにサーバによってリセットされない可能性は小さく、またはMySQLサーバがアクティブバイナリログファイルに回転イベントもしくはストップイベントのどちらもログしない可能性は小さい。後のスタートアップの際、サーバはより古いバイナリログのフラグをリセットすることなく、新しいバイナリログファイルを作成する。一実施例に従うと、この状況では、2つのバイナリログがLOGEVENTBINLOGINUSEF状態のフラグを設定していることになる。VAMがこのシナリオに出合うのは以下の条件の場合である:1VAMは現在アクティブバイナリログを処理している。サーバクラッシュが読出のときに起こる。この場合、extractを停止させ、クラッシュリカバリを行ない、サーバスタートアップの後VAMを再度スタートさせるのがよい;および2VAMはより古いログファイルを読むよう位置付けられている。1つのファイルから別のファイルに読出す間すなわちログ回転の間、LOGEVENTBINLOGINUSEFの値のログファイルフラグに出合う。このログファイルは最新のログファイルではないことに注意しなければならないすなわち、アクティブなバイナリログではない。EOFが起こると、MySQLVAMは次のログファイルがあるかどうかについて、ログインデックスファイルをチェックする。この場合、VAMはサーバクラッシュが前に起こっているとみなし、既存のログファイルを閉じ、次のログファイルを開けてログリーディングを続ける。図4は、一実施例に従う、ログ回転の使用182を示す。図4に示されるように、ステップ184において、VAMはログインデックスファイルを解析してバイナリログファイルをリストする。ステップ186において、シーケンスIDが読取られて、ログファイル名および場所が得られる。ステップ188において、ログファイルが開けられる。ステップ190において、ファイルのEOFがチェックされ、ステップ198において、EOFに達しなければ、イベントは順次ファイルログから読出される。ステップ200から204において、VAMはクエリーイベント、ローイベント、回転イベント、および/またはストップイベントといったイベントを判断する。ステップ208において、次のログファイルは回転イベント情報から得ることができる。VAM実施上記のように、一実施例に従うと、当該システムおよび方法は、たとえばMySQLデータベースまたはシステムと別の種類のデータベースまたはシステムとの間でデータを転送するために、ログベースレプリケーションを用いること、またはMySQLのようなデータベースプロダクトもしくはOracleGoldenGateのようなデータレプリケーションプロダクトを用いることを可能にする。以下の部分は、このような実施の形態および対応するベンダーアクセスモジュールVAMまたはアプリケーションプログラムインターフェイスAPIの特定の実施を説明する。バイナリログサポート上記のように、一実施例に従うと、VAMMySQLVAMは、データをキャプチャするためにMySQLバイナリログを使用する。MySQLバイナリログは、DML操作といったような、データを変更するステートメントデータを含む。ステートメントは、変更を記述するイベントの形で記憶される。バイナリログは2つの重要な役割を果たす:レプリケーションであって、バイナリログは、スレーブサーバに送られるステートメントの記録として、マスタレプリケーションサーバで用いられる。マスタサーバはそのバイナリログに含まれるイベントをスレーブに送り、そこでマスタで行なわれたのと同じデータ変更を行なうためにイベントが実行され;およびデータリカバリであって、特定のデータリカバリ操作はバイナリログの使用を必要とする。バックアップファイルが回復されると、バックアップが行なわれた後に記録されたバイナリログのイベントは再実行される。これらのイベントにより、データベースはバックアップ時点のものから現在のものになる。完全なバックアップのためには、ユーザー例えば、顧客はMySQLDumpユーティリティを使用し、その後増分バックアップ用にバイナリログを使用することができる。バイナリログ構成一実施例に従うと、バイナリログがトランザクションデータを記憶可能にすることは、MySQLの設置によってデフォルトでは設定されない。その代わりに、ログビンのパラメータを用いてバイナリロギングを可能にする。このパラメータは初期化ファイルにおいて、ウインドウズ登録商標プラットフォームではmy.iniとして、他のプラットフォームではmy.confとして指定される。MySQLバージョン5.1の前のリリースでは、バイナリログはステートメントレベル情報を含んでいた、すなわち、完全なDDLおよびDMLステートメントをログしていた。異種性を支持するために、データが汎用的なデータフォーマットで利用可能にするためには、純粋なテキストSQLステートメントに基づいてログベースキャプチャを構築することは難しい。しかしMySQL5.1リリースは、上記の問題を軽減するために、バイナリロギングサポートを導入している。さらに、MySQLは、バイナリデータへのアクセスのために内部Cクラスを提供している。一実施例に従うと、バイナリロギングを可能にするために、MySQLサーバを構成するのに、以下のステップが必要である:MySQLサーバ構成ファイルを開くウインドウズ登録商標プラットフォームではmy.iniであり、他のプラットフォームではmy.confである;ログビンパラメータを用いてバイナリロギングを能動化する。このオプションの値は、ログファイル用のディレクトリ場所を特定する。たとえば:logbinCMySQLMySQLServer51logtestbin上記の例では、ログファイルの名前は‘test00001test00002...’などで作成される。これらのファイルは、cMySQLMySQLServer51logディレクトリに記憶される。構成ファイルにおいて、ロギングフォーマットはROWモードでのみ構成されるべきである。MIXEDモードはサポートされていない。このオプションにより、DMLステートメントはデータをバイナリフォーマットでログすることができる。これは、‘binlogformat’パラメータを用いることにより達成することができる。‘maxbinlogsize’オプションを用いて、バイナリログファイルのサイズバイト単位を指定することができる。最小値は4096となるべきである。IngressおよびSybaseといった他のベンダで見られる循環型ロギングスタイルと比べて、MySQLのバイナリログは順次作成され番号が付けられる。MySQLはより古いログファイルを自動的にはアーカイブしないので、古いログファイルを保つ/バックアップするために、エンドユーザ/顧客は十分に注意しなければならない。一実施例に従うと、以下の処理は新しいバイナリログファイルを作成し、既存ログファイルを閉じる:サーバデーモン、mysqldが開始された場合;FLUSHLOGSまたはFLUSHMASTERといったMySQLコマンドコンソールプログラムmysqlからフラッシュコマンドを明示する。現行のログサイズがmaxbinlogsizeパラメータに達すると、サーバはさらに新しいバイナリログファイルを自動的に作成する。一実施例に従うと、MySQLはアクティブなおよび古いバイナリログファイルを含めたリストを含むインデックスファイルを維持する。このインデックスファイルは、他のバイナリログと同じディレクトリ場所にある。MySQLバイナリログは、特定テーブル/カラムのロギングのターンオフ/オンをサポートしない。トランザクションおよびバイナリログ一実施例に従うと、非トランザクションテーブルへの更新は、実行の後すぐにバイナリログに記憶される。拘束のないトランザクションでは、InnoDPテーブルといったトランザクションテーブルを変更するすべての更新INSERT、DELETE、UPDATEは、COMMITステートメントがサーバによって受取られるまでキャッシュされる。MySQLは、更新操作からより多くのデータを収容するために、一時ファイルを開いてキャッシュをフラッシュする。その時点で、mysqldサーバデーモンはトランザクション全体をバイナリログに書込む。サーバデーモンはROLLBACKステートメントが発行されたのなら、トランザクションデータを書込まない。バイナリログに関するかぎり、ロールバック操作はno-opの非記録操作である。更新が混合しているトランザクションを、トランザクションテーブルおよび非トランザクションテーブルの両方にロールバックする場合、サーバデーモンはROLLBACKステートメントをログに明示する。SAVEPOINTステートメントは、ある名前の付けられたトランザクションセーブポイントを任意の名前に設定するために用いられる。ROLLBACKTOSAVEPOINTステートメントを用いて、トランザクションを示されたセーブポイントにロールバックする。MySQLはネストされたトランザクションまたはトランザクションのネーミングをサポートしない。新しいトランザクションが開始された場合、または前回のものがCOMMITもしくはROLLBACKで終了することなくサーバが閉じられた場合、MySQLは新しいトランザクショを開始させる前、またはサーバがシャットダウンされる前に、自動的により古いトランザクションのデータをディスクにコミットする。MySQLはトランザクションを複数のバイナリファイル間で分割しない。一実施例に従うと、トランザクションデータのサイズが‘maxbinlogsize’パラメータ値を超えた場合、バイナリログファイルの大きさが‘maxbinlogsize’パラメータを用いて指定された値を超えることができる。非操作の更新更新がゼロカラムをもたらすは、バイナリログに書込まれない。これは空のトランザクションの場合にも当てはまる。カラムを自己に更新するためにトリガが用いられた場合、MySQLはステートメント更新の結果よりも、トリガ更新の結果をログする。たとえば、以下のトリガの場合、年齢を20に更新すると、MySQLは20ではなく、25の値トリガの結果をログさせる:プラットフォームサポートさまざまな実施例に従うと、本システムはWindows、LinuxOperatingsystem、HPUX、およびSolarisOS登録商標をサポートすることができる。MySQLVAMがバイナリログイベントをキャプチャするためには、MySQLextractプロセスには以下の許可が必要である以下の許可は、非ウインドウズプラットフォームに適用可能である:構成ファイルmy.cnfがあるディレクトリ用のおよびバイナリログが生成されるディレクトリ用の読出しおよび実行許可;構成ファイルmy.cnf用の読出許可;読出、書込MySQLデーモンプロセスで使用;tmpディレクトリ規定用の実行許可。バージョンサポートMySQLは3.x以降のリリースからバイナリログをサポートする。リリース5.1以前では、DML操作によるデータベーステーブルへの変更は、SQLステートメントテキスト形式でバイナリログにログされた。リリース5.1以降では、MySQLバイナリログは、DML操作をバイナリ形式でローデータとしてストアする。一実施例に従うと、テキストに基づくSQLステートメントでの処理と比べて、このバイナリデータを読出し、これらをたとえばOracleGoldenGate汎用フォーマットに変換することは、MySQLVAMにとってより容易である。データタイプサポート表2は一実施例に従うサポートされるデータタイプを示す。ストレージエンジンサポート一実施例に従うと、MySQLVAMは以下のストレージエンジンをサポートする:MyISAM非トランザクションストレージエンジン;およびInnoDB-トランザクションストレージエンジン。サポートされているデータベース操作一実施例に従うと、MySQLVAMはバイナリログから以下のデータベース操作をキャプチャすることができる:Startトランザクション、Commitトランザクション、Rollbackトランザクション-MySQLはバイナリログにロールバックされたトランザクションを送信するのではなく、MySQLはトランザクションがInnoDBのテーブルおよび同じトランザクションに関与しているmylSAMタイプに係わる場合、トランザクションロールバック操作をログする;挿入操作;更新操作;削除操作;切捨て操作。最大ローサイズおよびカラムサポート一実施例に従うと、MySQLの最大データベースローサイズ現在64kはすべて、たとえばOracleGoldenGateアプリケーションによってサポートされている。所与のMySQLテーブル用の最大カラム数現在3398;MySQL用の最大オブジェクト名長さschematable;およびMySQLの最大オブジェクト名長さschematableが支持される。InnoDBストレージエンジンを有するMySQLは、カラム数が1000を超えてはならないという制限を含む。圧縮更新および削除のサポート一実施例に従うと、バイナリログは、DML操作の一部ではないカラム値を記憶する。MySQLVAMとキャプチャモジュールとの間のデータ転送を最小にするために、圧縮更新および削除がサポートされる。AUTOINCREMENTカラム一実施例に従うと、AUTOINCREMENTカラム属性を用いて新しいローの一意的識別を生成することができる。このカラム値はほとんどの場合システムで生成されるので、以下の2つの要件が支持される:ターゲット側へのAUTOINCREMENTカラム値の伝搬-MySQLログは、このAUTOINCREMENTカラム値をバイナリログに記憶する。アプライ側すなわちターゲットでは、replicatプロセスがオートインクリメントなカラム値の明示挿入操作を挿入する。MySQLは挿入操作の際、AUTOINCREMENTカラムを特定の値に強制することをサポートし;およびBi方向サポート-INSERT操作の際、AUTOINCREMENTカラム値は次のより高い値で挿入される。MySQLは双方向の‘autoincrement’カラム問題を解決するために、‘autoincrementincrement’および‘autoincrementoffset’の2つの変数初期化ファイルmyiniを介して構成をサポートする。これらサーバ側変数は、双方向設定の競合を解決するために、ソース側およびターゲット側で異なって設定できる。双方向データレプリケーションサポート一実施例に従うと、双方向ループ検出をサポートするために、MySQLVAMモジュールは、ユーザid、トランザクションidに基づき、レコードをフィルタ処理する。MySQLバイナリログは、これらの値をイベントには記憶しない。双方向ループ検出は、ターゲット側で、トレーステーブルまたはチェックポイントテーブルFILTERTABLEオプションを用いて構成を介してサポートされるべきである。MySQL双方向構成は、キャプチャから除外するためにReplicatトランザクションを識別するため、Replicatチェックポイントテーブルの使用を必要とする。extractは、チェックポイントテーブルでの操作で終わるトランザクションは無視する。この機能をサポートするために、TRANLOGOPTIONSはチェックポイントテーブルの名前を特定する新しいFILTERTABLE<テーブル>オプションを与える。Replicatデータベースユーザは、‘sqllogbin’変数を用いてセッションレベルバイナリロギングをオフにすることができる。アプライ側では、Replicatユーザはこの値を0に設定して、バイナリロギングをオフにする。LSNおよびタイムスタンプによる位置付け一実施例に従うと、MySQLVAMはタイムスタンプによる位置付けおよびLSNによる位置付けをサポートする。タイムスタンプ位置は、ADDALTER抽出コマンドを用いて設定される。たとえば:ADDALTEREXTRACTextractnameMYSQLVAMbegintimestampvalueここで有効なタイムスタンプ値は以下のとおりである:NOWまたはnow-extractは、加えるまたは変更されたときの現行タイムスタンプ値を取る。MySQLMySQLVAMはタイムスタンプ値がこのタイムスタンプ値と等しいまたはより大きいトランザクションレコードを読出す。今までのタイムスタンプ値-MySQLVAMはログファイルを検索し、タイムスタンプ値がこのタイムスタンプ値と等しいまたはより大きいトランザクションレコードを読出す。今後のタイムスタンプ値-MySQLVAMは待機し、タイムスタンプ値がこのタイムスタンプ値と等しいまたはより大きいトランザクションレコードを読出す。LSN値による位置付けは、ADDALTER抽出コマンドを用いて設定される。たとえば:ADDALTEREXTRACTextractnameMYSQLVAMlognumlognumlogposlogposここでlognumはログファイル番号である。たとえば、ログファイル名がtest.000034である場合、この値は34となる。MySQLMySQLVAMはこのログファイルを検索し、さらに読出すために開く:およびlogposはログファイル内のオフセット値である。この場所後で利用可能なトランザクションレコードは、MySQLVAMによって読出される。アーカイブログサポート上記のように、一実施例に従うと、IngressおよびSybaseといった他のベンダで見られる循環型ロギングスタイルと比べて、MySQLのバイナリログは順次作成され番号が付けられる。MySQLは古いログファイルを自動的にはアーカイブしない。ログファイルは初期ファイルで指定されたログディレクトリに保持される。したがって顧客はより古いログファイルを保つ/バックアップするよう、注意しなければならない。一実施例に従うと、MySQLVAMを用いて位置付けおよびより古いログファイルの読み出しがサポートされる。MySQLVAMは、管理者または他のバックアップツールによって他の場所に移動させられたより古いログファイルを位置付けることが要求された場合、エラーを返すか、操作をアベンドする。DDLレプリケーション一実施例に従うと、バイナリログはDDLステートメントをテキストに基づくSQLステートメントとして記憶し、MySQLVAMはこの特徴をサポートする。FetchColsおよびFetchModColsサポート一実施例に従うと、FetchColsおよびFETCHCOLSEXCEPTを用いて、値がトランザクションログレコードにない場合に、カラム値をデータベースから取ってくることができる。このオプションは、データベースが圧縮更新を用いる場合カラム値は変更されない限りログされないに使用することができる。FETCHCOLSおよびFETCHCOLSEXCEPTは、FILTER操作に必要なカラム値が利用可能であることを確実にする:FETCHCOLSは特定カラムを取ってくる。FETCHCOLSEXCEPTは、指定されているもの以外は、すべてのカラムを取ってくる。多くのカラムを有するテーブルでは、FETCHCOLSEXCEPTは各カラムをFETCHCOLSでリストするよりも有効であり得る。FETCHMODCOLSおよびFETCHMODCOLSEXCEPTは、カラムがトランザクションログにある場合でも、カラム値をデータベースから取ってくることを強制するために使用することができる。トランザクションログで存在し得る値は、変更されたカラムまたは補足ロギングで含まれたカラムのものである:FETCHMODCOLSは特定カラムを取ってくる。FETCHMODCOLSEXCEPTは、指定されているもの以外は、トランザクションログにあるすべてのカラムを取ってくる。多くのカラムを有するテーブルでは、FETCHMODCOL。一実施例に従うと、この特徴はキャプチャする側でサポートされる。初期ロードサポート一実施例に従うと、MySQLVAMは初期ロードサポートを含む。オープンソースデータベースおよびオープンソースオペレーティングシステムの人気に伴い、ますます多くの顧客はMySQLを仕事の一部として使い始めている。事業が成長するにつれ、組織は複雑なデータ管理を管理するために、MySQLからOracleDB2SQLServerに移行したいと考え、一般に以下の工程をたどる:ステップ1、既存のMySQLデータを顧客の選択されたデータベースに移行。この課題のために、キャプチャ側初期ロードサポートを用いることができる;ステップ2、移行がうまく行けば、リアルタイムレプリケーションまたはデータキャプチャを変更を能動化する。MySQLVAMを用いてこの課題を達成することができる。以下の初期ロード方法がサポートされている:Replicatでデータをロードする-extractプロセスは、データをテーブルから直接抽出する。この方法は実際はより遅い。なぜなら、アプライ側では1レコードずつ与えられるからである;バルクロードユーティリティでデータをロードする-extractプロセスはレコードをASCIIフォーマットで出力し、これは後でSQLLOADERまたはBCPで使われる;GoldenGate直接ロードでデータをロードする-extractプロセスはデータを直接テーブルから抽出し、replicatプロセスを呼出す。データを直接SQLローダにロードする。その他の要件一実施例に従うと、MySQLVAMモジュールは、たとえば付加的切捨点を加えるSyBASEcaseにより、バイナリログ内容を変更しない。したがって、同じバイナリログでの2つ以上のextractプロセスの読出しのサポートが可能である。一実施例に従うと、MySQLVAMはレプリケーションオプションで構成されるMySQLデータベースと共存する。extractにおいて新しいパラメータを追加したりMySQLに特有のパラメータファイルを用いないよう注意しなければならない。大文字および小文字の区別一実施例に従うと、MySQLはデータベース名をディレクトリ名として、およびテーブル名をファイル名としてマッピングするおよびMySQL特有ソースコードファイルまたはヘッダファイルの依存といった問題を緩和する。一実施例に従うと、MySQLVAMは処理イベント用にCクラスを再度実施し、バッファIO読出用にIOCACHEクラスを使用することができる。このアプローチは、MySQLソースコードが、たとえばGoldenGate作成環境にいなければならないという依存性を減らす。このアプローチはさらにMySQLVAMがどのようにイベントデータを処理するかについての完全な制御を与える。頻繁に用いられるイベント状況も同様にリサイクルすることができる。一実施例に従うと、MySQLVAMはMySQLに特有のイベントクラスおよびIOCACHEクラスを用いてバイナリログをアクセスすることができる。MySQLVAMクラスは、MySQLVAMに特有の必要な機能を提供するために、イベントクラスから受け継ぐ必要がある。符号付きまたは符号のない整数MySQLは符号付きまたは符号なしデフォルトは符号付きのいずれかで定義される整数カラムをサポートする。たとえば、2バイトの符号付き整数カラムは、-32kから32kの値をサポートし、符号がないものは0から64kをサポートする。バイナリログは、数値カラムの符号について、すなわちそのカラムが符号付きまたは符号なしモードを支持しているのなら、メタデータを返さない。2つの設計上のアプローチが可能である:常に符号付きの値を返す、-ターゲット側でreplicatはカラムの種類に基づき変換を行なう;またはextractからMySQLカラムのメタデータを得て、extractするために正しい値を返す。一実施例に従うと、MySQLVAMは数値を符号付きの値としてMySQLVAMAPIに返す。シーケンスIdによる位置付け一実施例に従うと、バイナリログの中では、MySQLイベントはそのヘッダ部に場所値を有する。この値の寿命はバイナリファイルに特有である。すなわち、この場所値は所与のバイナリファイル内では固有のものであり得るが、バイナリファイルの外では固有ではない。2つの異なるバイナリファイルにおける2つの異なるイベントは同じ値を有し得る。場所によってトランザクションレコードを固有に識別するためには、MySQLVAMはこのイベント場所値をログファイル名と結合する。たとえば、‘binlog00054123’では、‘binlog00054’はバイナリログの名前であり、123はトランザクションレコードの場所である。MySQLVAMはGGATTRDSSEQIDを用いてこの値をASCIIストリング属性として送る。一実施例に従うと、再スタートシナリオの際、extractはこの最後に受取られたシーケンスId値をMYSQLVAMIntializeコールの際にMySQLVAMに送る。MySQLVAMはこの値を用いて正しい読出場所を設定する。MySQLVAMはこのシーケンスIdをextractから解析し、ログファイル名およびイベント場所を得る。次に、対応するログファイルを開き、イベントのスキャンを開始する。イベントの場所がシーケンスIdで特定されているものと一致すると、MySQLVAMはこの場所を現行の読出場所として設定し、この場所からバイナリログ内容の読出を開始する。トランザクションIDDML操作を表わすイベントでは、MySQLはトランザクションIdをイベントデータの一部として持たない。したがって、MySQLVAMはこのトランザクションId固有のものをMySQLVAMAPIに送るための方法が必要である。一実施例に従うと、この問題を解決するために、MySQLVAMAPIは‘STARTTransaction’ステートメントのシーケンスIdをトランザクションIdとして扱う。このシーケンスIdは、ログファイル名ファイル内のイベントオフセットの組合せであるので、トランザクションIdの固有性は複数のログファイル間で保証される。さらに、MySQLVAMはこの擬似トランザクションIdを内部で維持し、この値を特定のトランザクション内のすべてのDMLステートメントに対してMySQLVAMAPIに送る。MySQLVAMはコミットまたはロールバックステートメントに出くわすと、この値をクリアする。LOBデータへのアクセスMySQLバイナリログにおいて、LOBカラム値は他の非LOBカラム値とインラインで記憶される。これは他のデータベースと異なる。なぜなら、値はインラインでストアされず、データがオンデマンドでフェッチすることができるロケータまたはクーポンを用いてアクセスされないからである。MySQLデータベースの場合では違うストレージエンジンMyISAMおよびInnoDBを有する。バイナリログからLOBカラム値を読出すため、MySQL内部IOCACHEクラスは、ログファイルからこのLOBカラム値の全体の値をフェッチしてメモリに渡す、すなわち、メモリはこのクラスにより1回でこのLOBカラム用に完全に割当てられる。一実施例に従うと、MySQLVAMAPIはより大きいサイズのLOBデータは塊でMySQLVAMAPIに送られるべきであるという仕様概要を与える。しかし、MySQLの場合、データは既にMySQL内部クラスで完全に既にフェッチされているすなわち、メモリはIOCACHEオブジェクトによって完全に割当てられており、LOBデータは32kバイトのサイズの塊で、1つのコールや複数のコールで、MySQLVAMAPIに送ることができる。一実施例に従うと、上記のように、MySQLのIOCACHEクラスはLOBデータの全体の値を他のローデータとともに、ワンショットでフェッチする。これは、LOBのサイズが2GBである場合問題となる。1つの方法は、MySQLVAMがデータを塊でファイルから読出すことができるよう、IOCACHEクラスの実施を書き直すことである。GoldenGateあればから既存のファイルマネージャライブラリを用いることができる。一実施例に従うと、システムはIOCACHEクラスを使用し、ログデータを塊でMySQLVAMAPIに送る。一実施例に従うと、MySQLVAM実施は、バイナリログファイルを読出すために、IOCACHEクラスを使用することができる。LOBデータ制限を除き、IOCACHEクラスはうまく他のMySQLデータの読出を扱う。さらに、LOBデータを2GBのサイズで処理することは実質的に珍しいまたは滅多にない。LOBカラムの内部記憶機構と無関係に、MySQLVAMAPIが必要ならページアウトできるよう、MySQLVAMはLOBデータを塊でMySQLVAMAPIに返すべきである。OG処理およびMySQLVAMAPI通信一実施例に従うと、MySQLVAM実施は2つの部分に分割することができる:第1の部分はLOGデータをバイナリログから読出し、データを準備し、データをMySQLVAMAPI用に用意する-これは別のスレッドで実行される;第2の部分は用意ができたデータレコードをリクエスト毎にAPIに送る。この従来の設計での主な欠点は、すべて完全な処理はMySQLVAMAPIがリクエストした場合にしか起こらないことであり、MySQLVAMモジュールが処理を完了するのに何らかの実行時間を必要とする。この間、MySQLVAMAPIはアイドル状態にあり、MySQLVAMのパフォーマンスを低下させる。設計を2つの部分に分割することにより、MySQLVAMAPIのアイドル時間がなくなる。第1の部分が独立してバイナリログを読出す間、システムはAPIに送るべきデータの準備を行ない、制限されたサイズQueueキューに記憶する。次に、第2の部分はQueueから用意ができたレコードをフェッチし、MySQLVAMAPI側からリクエストが来ると直ちにMySQLVAMAPIに送る。アーキテクチャ設計上記のように、一実施例に従うと、MySQLVAMモジュールの全体のアーキテクチャは以下を含む:MySQLライブラリ-ファイルリーダ、ファイルCACHE、データ変換クラスを与えるライブラリ。MySQLVAMイベントクラス-MySQLバイナリログからイベントを処理するMySQLVAMのインハウス実施。MySQLVAMバイナリログクラス-MySQLライブラリをラップアラウンドするクラス、MySQLVAMイベントクラス。現行のバイナリログを開き、イベントを読出し、MySQLVAMレコードに変換し、ログ回転を処理するなど。MySQLVAMリーダ、プロセッサクラス-ビンログクラスからレコードを読出しおよび処理し、レコードキューに入れるクラス。これらクラスはextractコールによりブロックではなく自己の専用スレッドを有する。レコードキュー-後でMYSQLVAMReadコールによって使われるためにレコードを保持するキュー。MySQLVAMレコードクラス-レコードキューからデータを読出し、MySQLVAMAPIを用いてextractに送るクラス。Extractプロセス-MySQLVAMAPIからデータをキャプチャするためにコンパイルされた標準のGoldenGateextractプロセス。バイナリログ構造およびログイベント図5は一実施例に従うと、MySQLバイナリログでのイベント順序を示す。一実施例に従うと、MySQLはデータをイベント入力としてバイナリログ内に記憶する。MySQLは、SQLステートメントおよび操作の性質に基づき、さまざまなイベントをサポートする。MySQLはイベントデータを読出すためにCクラスを与える。一般に、バイナリログ構造は以下のイベント入力を含む:1.4バイトの魔法数で始まる。これは\xfe\x62\x69\x6eの値を有する定数BINLOGMAGICとして定義される。この値は無視することができる。2.次の入力はフォーマット記述イベントである。このイベントは所与のバイナリログファイルにわたって包括的である。MySQLはこのイベントを各バイナリログ毎に1回しか書込まない。このイベントは現行のバイナリログが使用されているかまたは正しく閉じられたかを追跡する。3.一連のイベントが続く残りの入力は、図5に示される。一実施例に従うと、MySQLVAMはバイナリログイベントのサブセットに興味を持つ。たとえば、MySQLVAMはトランザクション、DMLステートメントデータ、ログ回転などを表わすバイナリログイベントに興味を持つ。表3は、一実施例に係わる、MySQLVAMが興味を持つMySQLイベントのリストを示す。イベント構造図6は一実施例に従うイベントヘッダ構造を示す。すべてのイベントは汎用ヘッダ部と後に続くデータ部とを有する。一部のイベントは、任意のデータヘッダ部を有する。イベント構造は一般に次のように表わされる。1.イベントヘッダ‐構造のサイズは19バイトである。この部分は、すべてのイベントに汎用的である以下のイベント特有データを含む。4バイト-イベントのタイムスタンプ。1970年の開始からの秒数。1バイト-イベントのタイプコード。タイプコードの対象の値および意味は次のとおりである:QUERYEVENT2STOPEVENT3ROTATEEVENT4FORMATDESCRIPTIONEVENT15XIDEVENT16TABLEMAPEVENT19WRITEROWSEVENT23UPDATEROWSEVENT24DELETEROWSEVENT25。4バイト-サーバID。レプリケーションピア間でサーバを一意に識別。MySQLVAMはこの値を無視する。4バイト-ヘッダを含むイベント全体の長さをバイトで表わす。4バイト-ログにおけるイベントのオフセットをバイトで表わす。この値はLSNまたはシーケンス番号に類似している。2バイト-イベントフラグ。MySQLVAMはこの値を無視する。このイベントヘッダは、CLogEventCクラスによって表わされる。すべてのバイナリログ系イベント特有Cクラスはこのクラスから継承する。このクラスの構造は以下のように表わされる:2.データヘッダ-構造のサイズは8バイトである。変数データを含むイベントたとえば、テーブルマップイベント、書込ローイベントなどはこの部分を含む。この部分は、以下を含む6バイト-テーブル_idを含む。これは、テーブルバージョンとして扱うことができる。MySQLVAMはこの値を用いて、下地のテーブルメタデータが変更されたか否かをチェックする。2バイト-データヘッダフラグ。MySQLVAMはこの値を無視する。3.データ部-イベント特有データを保持する。たとえば、書込ローイベント用のカラム値のシーケンス、テーブルマップイベント用のカラムメタデータ。より詳細については、次の箇所参照。イベントデータ部一実施例に従うと、イベントデータ部はイベント特有データを保持する。データ部のサイズは動的である。すなわち、イベントの種類に応じて値は異なりかつ特定的であり、データの変数リストを保持する。次の箇所は、MySQLVAMが興味を持つイベントタイプのイベントデータ部の構造を説明する。クエリーイベント一実施例に従うと、このイベントはSQLクエリーを表わす。このイベントは、MySQL内部Cクラス‘CQueryEvent’によって表わされる。このイベントのデータ部は、データベース名、クエリーストリング値、および他の情報を含む。MySQLVAMはCQueryEventイベントを用いて、以下のメンバー変数を使ってこれらの値を引出す:MySQLの‘BEGINTransaction’および‘ROLLBACKTransaction’ならびに‘Truncate’ステートメントは、このCQueryEventクラスによって表わされる。これらのステートメントについて、メンバークエリーは、BEGINまたはROLLBACKまたはTRUNCATEtablenameといった値を含む。ログからこれらのステートメントをフィルタ処理するために、通常のストリングを用いることができる。XID_イベント一実施例に従うと、このイベントはトランザクションのコミットを表わす。このイベントは、MySQL内部Cクラス‘CXidEvent’によって表わされる。このイベントのデータ部は、MySQLVAMが無視する2相コミットトランザクションのトランザクションidを含むMySQLレプリケーションもこの値を無視する。MySQLVAMはこのイベント入力を用いてトランザクションがコミットされ、トランザクション特有オブジェクトと切離されていることと見なす。テーブルマップイベント一実施例に従うと、このイベントはトランザクションに係わるDMLステートメントによってテーブルのメタデータを表わす。このイベントは、書込、更新および削除ローイベントといったDML操作を表わすイベントより先に来る。たとえば、簡単な挿入操作はバイナリログにおいて2つの入力を引き起こす。最初の入力は、テーブルメタデータを含むテーブルマップイベントであり、次の入力はINSERT操作の一部として加えられるローデータを含む書出ローイベントである。汎用ヘッダ部とは別に、このイベントは付加的データヘッダ部データ部を含む。8バイトのデータヘッダ部は、以下のデータを含む:tableid:6バイト長-テーブルのメタデータ変更を追跡し;およびフラグを立てる:MySQLVAMはこのフラグを無視することができる。所与のテーブルの時間テーブルマップイベントの大部分は、下地のテーブル構造が同じままであるのなら、変更されずに残る。バイナリログは同じテーブルマップイベントの複数の入力を含むが、これらを一度に処理して、後で再度用いる方がよい。これは、読出バイナリログのパフォーマンスの速度を上げる。Tablemaplogeventログクラスのインスタンスを記憶するのにハッシュテーブルを用いるのがよく、さらに処理するためにテーブル名を用いて後で引出すことができる。データ構造が変更された場合テーブル変更...ステートメントを使用、MySQLは同じテーブルに対して新しいテーブルidを作成する。MySQLはテーブルidの履歴を記憶しない。バイナリログを読出す際にテーブルメタデータを変更する場合、MySQLは次のように扱う。1プロセスをアベンドする。2MySQLVAMは付加的処理のために変えられた最新のテーブル定義を用いる。一実施例に従うと、MySQLVAMは所与のテーブル名について既存のテーブルidをチェックし、異なれば、これはテーブルメタデータの変更として見なされ、MySQLVAMはextractにアベンドすることを知らせることができる。テーブルマップイベントのデータ部は、以下のテーブルメタデータ情報を含む:1バイト-データベース名の長さ。nバイト-データベースネームnull終了文字が続く。1バイト-テーブル名の長さ。nバイト-テーブル名null終了文字が続く。nバイト-カラム数。カラム数が255バイト以下である場合は1バイトであり、それ以外は2バイトである。nバイト-テーブルの各カラムのタイプを記憶し、左から右側に示される。各バイトはMySQL内部カラムタイプにマッピングされる。nバイト-フィールドメタデータのサイズ。より詳細については、フィールドメタデータ部次の箇所参照。nバイト-フィールドメタデータ値。より詳細については、フィールドメタデータ部次の箇所参照。nバイト-nullカラムビットであり、直近のバイトに切上げられる。各カラムについて、そのカラムのデータがnullであり得るか否かを示すビット。これに必要なバイト数はint8である。左から最初のカラムのフラグは、第1のバイトの最下位ビットにあり、2番目は第1のバイトのつぎの最下位ビットにあり、9番目は第2バイトの最下位ビットにある、など。フィールドメタデータ図7は、一実施例に従うフィールドメタデータを示す。フィールドメタデータは一般にカラムメタデータのサイズに関連する付加的情報を表わす。これはパック長として扱うことができる、すなわち特定のカラム値を圧縮するのに必要な合計バイト数。これらの値は後で用いられて、実際の値を得るために適切なバイトを読出すために用いられる。固定長のカラムタイプたとえば、整数、日付などについては、このフィールドメタデータは通常ゼロである。たとえば、VARCHARのカラムタイプでは、このフィールドメタデータはVARCHARカラムの最大サイズを表わす。表4は異なるカラムタイプに対するフィールドメタデータ部の内容を示す。‘MEDIUMBLOB’タイプのブロブカラムを有するテーブルがあるとする。ブロブカラムの最大サイズは16777216バイト16MBであり得る。このサイズは通常3バイト必要である。このテーブルに簡単な挿入操作が行なわれる。この挿入操作はバイナリログに、テーブルマップイベント、および書込ローイベントを作成する。バイナリログは、書込ローイベント部にBLOBカラムおよび実際のBLOBデータを記憶する。このBLOBデータを検索するためには、MySQLVAMは以下のステップを行なわなければならない:1.MySQLVAMはこのBLOBカラムの長さを計算するのに必要なバイト記憶領域を知る必要があるこの例では、16777216の長さを記憶するのに3バイト必要である。この値は、‘テーブルマップイベント’の‘フィールドメタデータ’部から引出される。2.上記の値に基づき、実際のデータ長を特定するために、MySQLVAMは‘書込ローイベント’から実際のローデータ値の最初の1つまたは2つまたは3つまたは4つのバイトを読出す。この場合、MySQLVAMはBLOBデータの実際の長さ値を得るために最初の3バイトを読出さなければならない。3.MySQLVAMは実際の長さに基づき十分なメモリを割当て、バイナリログからデータをコピーする。‘テーブルマップイベント’から、BLOBカラムに必要な最大カラムバイトストアを得る。これによって、3が返される。columnmaxdatasizeuint2korr上記の値は‘書込ローイベント’から実際のデータを得るために用いることができる。以下の例はテーブル′t1′のテーブルマップイベントのバイトシーケンス順序を示し、データベース′テストtest′は以下のように記述される:図8は一実施例に従うテーブルマップイベント構造のテーブルを示す。テーブルマップイベントはCクラス‘CTableMapEvent’によって表わされ、そのクラス構造は以下のとおりである:書込ローイベント図9は一実施例に従う書込ローイベント構造を示す。このイベントはMySQLINSERT操作を表わす。このイベントの前に、テーブルマップイベントが来る。汎用ヘッダ部とは別に、このイベントは付加的データヘッダ部データ部を含む。8バイトのデータヘッダ部は以下のデータを含み、これはより古いテーブルマップイベントと類似している。table_id:6バイト長。これはより古いテーブルマップイベントのtable_idと比較できるが、あまり役に立たない。MySQLVAMはこの値を無視する。flags:MySQLVAMはこのフラグを無視することができる。書込ローイベントのデータ部は、カラムの順序に基づき配置されるカラム値を含む。書込ローイベントはCWriteRowsEventクラスによって表わされる。データ部は以下の情報を含む:1または2バイト-カラムの数を記憶する。MySQLがサポートしている最大カラム数は3398である。nバイト-カラムビットマップ。これはMySQLレプリケーションで用いられる内部データ構造である。MySQLVAMは通常この値を無視する。サイズは8である。nバイト-リトルエンディアンオーダでnullカラム値を示す。総合サイズは通常8である。左から最初のカラムのフラグは、第1のバイトの最下位ビットにあり、2番目は第1のバイトのつぎの最下位ビットにあり、9番目は第2バイトの最下位ビットにある、など。nバイト-挿入値のバイトシーケンス。可変カラム値たとえばVARCHARLOBCHARタイプの前にはその長さがくる。以下の例は、テーブルt2の書込ローイベントのバイトシーケンス順序を示す。更新ログイベント図10は一実施例に従う、更新ローイベント構造を示す。このイベントはMySQLUPDATE操作を表わす。このイベントの前に、テーブルマップイベントが来る。汎用ヘッダ部とは別に、このイベントは付加的データヘッダ部データ部を含む。8バイトのデータヘッダ部は以下のデータを含み、これはより古いテーブルマップイベントと類似している。table_id:6バイト長。これはより古いテーブルマップイベントのtable_idと比較できる。flags:MySQLVAMはこのフラグを無視することができる。更新ローイベントのデータ部は、カラムの順序に基づき配置されるカラム値を含む。更新ローイベントは、事前画像および事後画像データ値を含む。他のロギングシステムと違って、MySQLバイナリログは単にプライマリキーや更新されたカラムを記憶するのではなく、カラム値の全体のコピー事前画像値および事後画像値の両方を記憶する。たとえば、100カラムを含むテーブルで1つのカラムを更新すると、100カラム値の事前画像コピーおよび同じ100カラムの事後画像コピーが作成される。MySQLVAMがデータをMySQLVAMAPIextractに送る前にデータを圧縮またはフィルタ処理することが重要である。更新ローイベントはCUpdateRowsEventクラスによって表わされる。データ部は以下の情報を含む:1または2バイト-カラムの数を記憶する。MySQLがサポートしている最大カラム数は3398である。nバイト-カラムビットマップ。これはMySQLレプリケーションで用いられる内部データ構造である。MySQLVAMは通常この値を無視する。サイズは8である。nバイト-事後画像カラムビットマップ。これはMySQLレプリケーションで用いられる内部データ構造である。MySQLVAMは通常この値を無視する。サイズは8である。nバイト-事前画像データ用にリトルエンディアンオーダでnullカラム値を示す。総合サイズは通常8ビットである。nバイト-事前画像データ用の値のバイトシーケンス。可変カラム値たとえばVARCHAR、LOB、CHARタイプの前にはその長さがくる。nバイト-事後画像データ用にリトルエンディアンオーダでnullカラム値を示す。総合サイズは通常8ビットである。nバイト-事後画像データ用の値のバイトシーケンス。可変カラム値たとえばVARCHAR、LOB、CHARタイプの前にはその長さがくる。ロー削除イベントこのイベントはMySQLDELETE操作を表わす。このイベントの前にテーブルマップイベントが来る。汎用ヘッダ部と別に、このイベントは付加的データヘッダ部プラスデータ部を含む。8バイトのデータヘッダ部は以下のデータを含み、これはより古いテーブルマップイベントと類似している。ロー削除イベントはCDeleteRowsEventクラスによって表わされる。table_id:6バイト長。これはより古いテーブルマップイベントのtable_idフラグと比較できる、flags:MySQLVAMはこのフラグを無視することができる。ロー削除イベントのデータ部は、カラムの順序に基づき配置されるカラム値を含む。データ部は、書き込みローイベントデータ部と類似している。CRowsLogEventCクラスCWriteRowsEvent、CUpdateRowsEventおよびCDeleteRowsEventCclassesはCRowsLogEventCクラスから継承する。このクラスはINSERT、UPDATEおよびDELETE操作用にログデータを検索するのに特有の一般的操作の大部分を含む。回転イベント回転イベントは可能なログ回転を示すバイナリログにログされる。すなわち、MySQLサーバは現行のバイナリログを閉じて新しいものを開く。ログ回転の可能なシナリオは以下のとおりである:1.ログファイルのサイズは‘maxbinlogsize’パラメータを超えている。2.MySQLコマンドコンソールから、明白な‘flushlogs’コマンドが発行された。どちらの場合でも、MySQLは現行のバイナリログに回転イベントを作成し、現行のバイナリログを閉じて、付加的処理用に新しいバイナリログを開く。回転イベントは、作成するべき新しいログファイルを含む。MySQLVAMはこの値を用いて既存のバイナリログファイルを閉じて、新しいバイナリログファイルを開き、読出しを続ける。回転イベントはCRotateEventCクラスによって表わされ、以下のとおり定義される:ストップイベントMySQLサーバはシャットダウンが明確な場合、バイナリクラスにストップイベントをログする。後でMySQLがスタートさせると、新しいバイナリログファイルが作成される。ストップイベントは新しいバイナリログファイル用の入力を含まない。イベント順序図11は一実施例に従うイベント順序例を示す。この部分は、異なるシナリオ用にバイナリログのイベント順序を示す。さまざまなトランザクションシナリオについては、イベント順序の箇所参照。一例として、以下のステートメントをバイナリログファイルに記憶することができる:図12は一実施例に従う別のイベント順序例を示す。一例として、以下のステートメントをバイナリログファイルに記憶することができる:データタイプこの部分はさまざまなサポートされているデータタイプおよびバイナリログ内のストレージ要件を説明する。MySQLはいくつかのカテゴリにおいて複数のデータタイプをサポートしている:数値型、日時型およびストリング文字型。各タイプは1組のバイトとして、ログレコード内に記憶される。用いられるバイト数は、データのタイプ、カラムがNULL可能であるか否か、およびフィールドの長さに依存する。可変長文字フィールドたとえばVARCHAR、VARBINARY、CHAR、TEXTおよびBLOBなどの前にその長さが来る。データタイプCHAR、VARCHARおよびTEXTはucs21文字当たり最大2バイトフォーマットまたはutf8フォーマット1文字当たり2または3バイトで記憶することができる。たとえば、VARCHAR255カラムは、最大255文字の長さのストリングを保持することができる。カラムはlatin1文字セット1文字当たり1バイトを用いると仮定すると、必要な実際の記憶領域は、ストリング長さプラスストリングの長さを記録するための1バイトである。′abcd′のストリングでは、Lは4であり、記憶領域要件は5バイトである。同じカラムがucs2ダブルバイト文字セットを用いるとされるのなら、記憶領域の要件は10バイトである。′abcd′の長さは8バイトであり、カラムは長さを記憶するのに2バイトを必要とする。なぜなら、最大長は255より大きいからである510バイトまで。一実施例に従うと、LOBフィールドはインラインに記憶される。LOBフィールドの前にはその長さが来る。サポートされているデータタイプおよびそのログサイズは表5に記載されている。null値の取扱い一実施例に従うと、バイナリログローイベントすなわちWriteRowsEvent、UpdateRowsEventおよびDeleteRowsEventは他の非NULLカラム値とともにはNULLカラム値を記憶しない。NULLカラム値は、データ部の前にNULLバイトの組として記憶される。NULLバイトの合計数は通常8である。より詳細にはWriteRowsEventtodo参照。NULLカラムは、リトルエンディアンオーダとしてこれらNULLバイト部に記憶される。左から最初のカラムのフラグは、第1のバイトの最下位ビットにあり、2番目は第1のバイトのつぎの最下位ビットにあり、9番目は第2バイトの最下位ビットにある、など。カラムがNULL値を保持しているか否かを見つけるために、NULLバイトの各ビットをマスクすることができる。以下のコードは、カラムがNULLであるか否かをチェックする:空のストリングは、ゼロ長値としてバイナリログに記憶される。データタイプ変換一実施例に従うと、CHAR、BINARY、VARCHARおよびVARBINARYタイプ-ストリングデータタイプの長さは可変である。実際のデータ値の前にデータ長が来る。長さの値は1バイト長さが255未満の場合または2バイト長さが256以上の場合を必要とする。上記のように、ストリングカラムの‘フィールドメタデータfieldmetadata’CHAR、VARCHAR、BINARYおよびVARBINARYタイプタイプに当てはまるは、長さの最大値を見つけるのに役立つ。この値に基づき、実際の長さは以下のように検索することができる。uint2korr関数はconfigwinhで規定されるMySQL提供マクロである。この関数は所与のポインタの最初の2バイトを読取り、対応する整数値を返す。ENUMタイプ一実施例に従うと、ENUMカラムはログファイルにおいてインデックス値として記憶される。たとえば、ENUM赤、オレンジ、青のカラムでは0、1および2のインデックス値を有することができる。したがって、オレンジのENUM値を記憶すると、バイナリログファイルではインデックス値2となる。サポートされる最大列挙インデックス値は65,535バイトである。ENUMカラムタイプのフィールドメタデータは、ENUMインデックス値に必要な最大バイトを含む。この値に基づき、実際の長さは以下のように読出すことができる。SETタイプ一実施例に従うと、SETカラムは0またはより大きい値を有することができるストリングカラムであり、各々はテーブルを作成した場合に指定される許容値のリストから選択されなければならない。たとえば、SET1、2と指定されたカラムは、12、1,2のいずれかの値を有することができる。SETは最大64個の異なるメンバーを有することができる。セットカラムはログファイルにおいてバイナリ値として記憶される。たとえば、SETとして指定されるカラムでは、メンバーは以下の10進数および2進数の値を有する:したがって、SETを記憶すると、3の10進数の値をもたらすすなわち、2進数では0011。SETカラムは最大64個の異なるメンバーを有することができるので、これらの値を記憶するのに要する最大バイトは最大8バイトとなる。SETカラムタイプのフィールドメタデータは、SET10進数に必要な最大バイトを含む。この値に基づき、実際の長さは以下のように取出すことができる:整数タイプ一実施例に従うと、整数値はバイナリログにおいて符号付きおよび符号なしの整数として記憶される。整数は符号付きの整数として読取られ、MySQLVAMによってextractに送られる。整数のCタイプは、整数カラムのサイズに依存し、これは長さによって定められる。MySQLではサイズに基づきすべての整数変形にはCタイプが規定され、関連するマクロを有して、メモリ場所をプラットフォームとは独立している整数値にコピーする。表7は各長さおよび関連するマクロで使用するタイプを示す。整数値は指定サイズの整数としてGoldenGateMySQLVAMに返すことができるので、データ変換には適切なマクロを用いることだけが必要であり、変換された整数および長さを整数データとして返す。浮動小数点、倍精度および10進数タイプ一実施例に従うと、浮動小数点データタイプには、MySQLは単精度値には4バイト、倍精度値には8バイト使用する。MySQLは非標準シンタックスFLOATまたはDOUBLEを可能にする。ここでは値が合計M桁まで記憶できることを意味し、そのうちD桁は小数点の後ろに来てもよい。MySQLは浮動小数点および倍精度カラムタイプ用のマクロを有し、メモリ場所をプラットフォームと独立した浮動小数点または倍精度値にコピーする。表8は各長さおよびそれに伴うマクロで使用するタイプを示す。浮動小数点および倍精度値は、指定サイズの浮動として、GoldenGateMySQLVAMに戻すことができる。それにより、データ変換には適切なマクロを用いることだけが必要であり、変換された整数および長さを整数データとして返却する。DECIMALまたはNUMERICのデータタイプは正確な数値データ値を記憶するために用いられる。これらのタイプは正確な精度を保つことが重要な、たとえば通貨データでの値を記憶するために用いられる。MySQLのリリースの前5.0.3以前では、DECIMALおよびNUMERIC値はストリングフォーマットで記憶される。DECIMALカラムの値は、9桁の10進数10進法を4バイトに圧縮するバイナリフォーマットを用いて表わされる。各値の整数および小数部の記憶領域は別個に定められる。9桁の各倍数は4バイトを要し、余りの桁は4バイトの一部を要する。余剰桁に必要な記憶領域は表9によって与えられる:MySQLは10進数値を含むメモリ場所をコピーして、ストリング値に変換するための、10進数カラムタイプ用の関数を有する。MySQLVAMは‘bin2decimal’関数を用いてメモリ場所を読取り、この値を‘decimalt’構造に埋める。別の関数‘decimalbinsize’はこの‘decimalt’構造を単に変換し、値をストリングとして返す。これは以下のコードラインで記載される。10進数値はストリングとしてGoldenGateMySQLVAMに返すことができ、データ変換は単に適切なマクロを用いることだけが必要であり、変換された10進数値を返す。BITタイプ一実施例に従うと、BITタイプカラムは1つの値当たり64ビットまで記憶する。必要な最大記憶領域はM7/8バイトであり、Mは値当たりのビット数を示す。MySQLVAMは以下のコードを用いてバイナリログからBITカラム値を読出す。DATE、TIME、YEAR、DATETIMEおよびTIMESTAMPタイプ日時タイプ変換はすべての変換の中で最も複雑なものである。他のデータタイプと比較して、MySQLは日時タイプを扱うマクロまたは公的関数を公開していない。MySQL内部実施はこれらのコールを扱うための適切な方法を見つけるためにデバッグされた。MySQLVAMはMySQL内部実施に基づき、自己のコードバージョンを書き直している。MySQLVAMはログからバイナリデータを読出し、これらを共通構造MySQLTIMEに変換するこの構造はMySQLによって定義され、使用される。後でこれらの構造はextractに渡される前にストリングに変換することができる。MySQLTIMEは以下のように規定されるDATEタイプは、DDMM×32YYYY×16×32として、圧縮3バイト整数形式に記憶される。サポートされている範囲は1000-01-01から9999-12-31である。DATEカラムは以下のコードを用いてバイナリログから読出される。TIMEタイプはDD×24×3600HH×3600MM×60SSとして、圧縮3バイト整数で記憶される。TIMEカラムは以下のコードを用いてバイナリログから読出される。YEARタイプは1バイトの整数で記憶される。値はYYYY値の範囲は1901から2155またはYY値の範囲は701970から692069形式であり得る。YEARカラム値は以下のコードを用いてバイナリログから読出される。DATETIMEタイプは、日付および時刻情報の両方を含む値が必要である場合に用いられる。サポートされている範囲は′1000-01-0100:00:00′から′9999-12-3123:59:59′である。DATETIMEタイプはYYYY×1000MM×100DDとして圧縮される4バイトの整数を含む8バイトの整数として;HH×10000MM×100SSとして圧縮される4バイトの整数として記憶される。DATETIMEカラム値は以下のコードを用いてバイナリログから読出される:TIMESTAMPタイプは4バイトの整数であり、エポックからの秒数UTCを表わす範囲は′1970-01-0100:00:01′UTCから′2038-01-1903:14:07′UTCである。TIMESTAMPカラム値は以下のコードを用いてバイナリログから読出される:LOBデータタイプ一実施例に従うと、MySQLLOBMySQLは、他のカラム値に従ってLOBレコードを記憶する大型オブジェクト-すなわちTINYBLOB、BLOB、MEDIUMBLOB、LONGBLOBおよびTEXTタイプ。BLOBおよびTEXTカラムデータは、VARBINARYまたはVARCHARフィールドと同様の方法で記憶される。すなわち、最初のいくつかのバイトは、長さを記憶し、その後にオリジナルのLOB値が続く。LOBカラムでは、テーブルマップイベントのフィールドメタデータは、所与のLOBフィールドに必要な最大バイトの記憶領域を含む。この値は、LOB値を読出すときに必要なメモリを割当てる際に便利である。TINYTEXTおよびTINYBLOBカラムの最大サイズは255である。これはCHARおよびbinaryカラムを扱う場合と同様である。TEXTおよびBLOBブロブカラムの最大サイズは64kである。これはまたはVARCHARおよびVARBINARYカラムを取扱うのと類似している。TINYTEXT、TEXT、TINYBLOBおよびBLOBカラムに記憶されている値は1回のショットでextractに送ることができる。他のLOBタイプでは、データは一度に64kのサイズの一塊として、読出すことができ、extractに送られる。以下のコード行はMySQLLOBカラムの取扱いを説明する。65kバイト以上のデータを保持することができるMEDIUMBLOBおよびLONGBLOBのような他のLOBタイプでは、データは一度に32kの大きさの一塊として読出すことができ、複数のコールでextractに送られる。上記のように、LOBカラム値は他の非LOBカラム値に従って記憶される。これは他のデータベースと異なる。なぜなら、値はインラインで記憶されないし、データがオンデマンドで取ってくることができるロケータまたはクーポンを用いてアクセスされないからである。MySQLデータベースの場合では違うストレージエンジンMyISAMおよびInnoDBを有する。バイナリログからLOBカラム値を読出すため、MySQL内部IOCACHEクラスは、ログファイルからこのLOBカラム値の全体の値をフェッチしてメモリに渡す、すなわち、メモリはこのクラスにより1回でこのLOBカラム用に完全に割当てられる。一実施例に従うと、より大きいサイズのLOBデータが塊でMySQLVAMAPIに送られるべきであるというMySQLVAMAPI仕様概要が示される。しかし、MySQLの場合、データは既にMySQL内部クラスで完全に既にフェッチされているすなわち、メモリはIOCACHEオブジェクトによって完全に割当てられており、LOBデータは32kバイトのサイズの塊で、1つのコールや複数のコールで、MySQLVAMAPIに送ることができる。バイナリログを使った作業一実施例に従うと上記のように、MySQLはバイナリログインデックスファイルを用いて、現行のバイナリログファイルおよびより古いログファイルを含むリストを維持する。このインデックスファイルは、バイナリログと同じディレクトリ場所にある。これにより、システムは構成ファイルから読出してログファイルフォーマットを見つける、たとえばROW、STATEMENT、またはMIXEDフォーマットをさがし、ROWでなければアベンドする。MySQLサーバが新しいバイナリログファイルを作成する場合スタートアップ時、または明白なフラッシュログコマンドによる、BINLOGMAGIC値4バイトおよびフォーマット記述イベントを書込む。このフォーマット記述は所与のバイナリログについて一度しか書込まれない。このフォーマット記述イベントのフラグ属性は、現行のバイナリログがサーバによって使用中であるか否かを追跡する。MySQLサーバはスタートアップの際にこの状態をLOGEVENTBINLOGINUSEF値に設定し、シャットダウンまたはログ回転の際にはこの値をクリアする。これは、バイナリログが正しく閉じられているか否かをチェックする信頼性のあるインジケータとして扱うことができる。初期化の際、MySQLVAMは活性バイナリログファイルの名前を得る必要がある。MySQLVAMは以下のステップを用いてアクティブバイナリログの名前を得る。MySQLサーバは同じプロシージャを用いて現行のバイナリログを得る:1.環境変数または供給されたMySQLVAMパラメータのどちらから、MySQL設置ホームを得る。2.MySQL初期化ファイルを読出す-ウインドウズ登録商標プラットフォームではmy.iniであり、他のプラットフォームではmy.confである。3.ログビンパラメータの値を得る。この値から、ログディレクトリ場所およびログインデックスファイル名を見つける。4.ログインデックスファイル名を開き、内容を読出す。この内容から、リストの最後のログファイルを見つける。5.このログファイルを開き、ログファイルがまだサーバによって使用されているかをチェックするフォーマット記述イベントのフラグ値がLOGEVENTBINLOGINUSEFであるかをチェックする。イエスなら、MySQLサーバは書込のためにこのログファイルを現在使用している。MySQLVAMはこのログファイルをアクティブログファイルとして扱う。バイナリログの位置付け一実施例に従うと、MySQLVAMAPIはタイムスタンプ値またはシーケンス番号のどちらかによって位置付けることをMySQLVAMに要求することができる。extractにおいて、位置付けはGGSCIにおいてADDまたはALTERコマンドのどちらかによって要求できる。MySQLVAMにおいてタイムスタンプおよびシーケンス番号による位置付けのサポートに加えて、本システムはアクティブバイナリログを終わりおよび先頭への位置付けをサポートする。シーケンス番号による位置付け一実施例に従うと、extractにトランザクションレコードを送信する場合、MySQLVAMはextractにシーケンス番号値をも送信する。再スタートシナリオの際、extractはこの最後に受取ったシーケンス番号値をMYSQLVAMIntializeコールの際にMySQLVAMに送る。VAMはこの値を用いて正しい読出場所を設定する。MySQLVAMはGGATTRDSSEQIDを用いてこのシーケンス番号値をASCIIストリングとして送る。MySQLVAMはこのASCIIストリングを、現行のログファイルおよび現行のイベント場所すなわちlog00000110045の組合せとして、この値をextractに送る前に作成する。MYSQLVAMIntializeコールの際にシーケンス番号によって位置付けるために、MySQLVAMはextractからシーケンス番号値を解析し、ログファイル名をイベント場所として得る。次に、対応するログファイルを開き、イベントのスキャンを開始する。イベントの場所がシーケンス番号で指定されたものと一致するなら、MySQLVAMはこの場所を現行の読出場所として設定し、この場所からバイナリログの内容の読出を始める。タイムスタンプ値による位置付けタイムスタンプによる位置付けのため、システムは必要なタイムスタンプ値以上のタイムスタンプを有するアクティブバイナリログすなわちBEGINストリングを含むQueryEventにおいてビギントランザクションレコードを見つけなければならない。タイムスタンプ値が未来の時間であるのなら、必要なタイムスタンプ場所以上のタイムスタンプを有するビギントランザクションレコードを見つけるまで、システムはログの終わりにおいて読出を続ける。バイナリログ内またはバイナリログとともに起こり得る2つのシナリオがある:シナリオ1:BeginEndトランザクションレコードはアクティブバイナリログにあり、最初にこのようなレコードのタイムスタンプは要求されるタイムスタンプ位置よりも低い。このシナリオの場合、MySQLVAMはアクティブバイナリログファイルをスキャンして、タイムスタンプ値が要求されるタイムスタンプ場所以上であるビギントランザクションレコードを見つける。MySQLVAMが要求されるレコードを見つけられなかった場合、ログの終わりに位置付けられる。シナリオ2:アクティブバイナリログにおける最初のBeginEndトランザクションレコードは、要求されるタイムスタンプ場所以上のタイムスタンプ値を有する。このシナリオは微妙である。このシナリオにおいて、より古いバイナリログも要求されるタイムスタンプ値に等しいタイムスタンプを有するBeginトランザクションレコードを持っている可能性がある。一実施例に従うと、MySQLVAMは最新のものから古いものへと、バイナリログをスキャンする順序はログインデックスファイルで維持される。MySQLVAMが要求されるタイムスタンプに等しいタイムスタンプを有するBeginEnd了トランザクションレコードを見つけなかった場合、MySQLVAMはエラーを返すかまたは最も古いログファイルの先頭に位置付ける。タイムスタンプによる位置付けは時間の掛かる処理となり得る。なぜなら、MySQLVAMはより古いログファイルを開けて、そのタイムスタンプに一致するイベントエントリを見つける必要があるかもしれないからである。ログの終わりへの位置付け一実施例に従うと、アクティブバイナリログの終わりに位置付けるために、MySQLVAMは、IOCACHE関数クラスにログの終わりを見つけることを要求するために、mybseek関数を使用する。ログの先頭への位置付け一実施例に従うと、トランザクションログの先頭に位置付けるために、MySQLVAMはmybseek関数をコールして、ログの先頭を、BINLOGMAGICプラスグローバルフォーマット記述イベントデータの後ろに位置付ける。バイナリログの読出一実施例に従うと、MySQLVAMはMySQLのIOCACHECクラスおよびファイルユーティリティ関数を用いてMySQLバイナリログを開いて読出す。MySQLのIOCACHECクラスmysqlclientlibの一部は、バイナリログの内容を64kのサイズの塊で読出す。このバッファ読出はIO使用の減少に役立つ。バイナリログファイルを読出す正しいシーケンスを見つけるために、‘mysqlbinlog’ユーティリティおよび‘replicationslavethread’モジュールといったMySQLのさまざまな内部モジュールがデバッグされる。以下のコード行は、IOCACHEクラスを初期化し、バイナリログファイルを開いて読出す。ログ回転一実施例に従うと、以下のシナリオによりMySQLのログ回転を引き起こすすなわち、既存のアクティブログファイルを閉じて、新しいログファイルを開く。1.アクティブログファイルのサイズが、maxbinlogsize値を超えた場合my.iniまたはmy.confファイルで指定されている。a.MySQLはアクティブバイナリログにおいて’RotateEvent’をログする。回転イベントデータ部は、新しいアクティブバイナリログの場所および名前を含む。b.MySQLはアクティブバイナリログを閉じて、フォーマット記述イベントフラグをNULLにリセットするこのフラグは前にLOGEVENTBINLOGINUSEF値に設定されている。c.MySQLは新しいバイナリログを作成し、フォーマット記述イベントフラグをLOGEVENTBINLOGINUSEF値に設定する。2.明確なフラッシュログコマンドがMySQLSQLプロンプトで発行された場合。a.MySQLはアクティブバイナリログにおいてRotateEventをログする。回転イベントデータ部は、新しいアクティブバイナリログの場所および名前を含む。b.MySQLはアクティブログを閉じて、フォーマット記述イベントフラグをNULLにリセットするこのフラグは前にLOGEVENTBINLOGINUSEF値に設定されている。c.MySQLは新しいバイナリログを作成し、フォーマット記述イベントフラグをLOGEVENTBINLOGINUSEF値に設定する。3.サーバシャットダウンの際。a.MySQLはアクティブバイナリログにStopEventをログする。b.MySQLはバイナリログを閉じ、さらにフォーマット記述イベントフラグをNULL値にリセットするこのフラグは前にLOGEVENTBINLOGINUSEF値に設定されている。4.サーバスタートアップの際。a.MySQLは新しいバイナリログを作成し、フォーマット記述イベントフラグをLOGEVENTBINLOGINUSEF値に設定する。上記のように、一実施例に従うと、MySQLVAMはログ回転が起こったことを識別するために回転イベントを使用し、次のバイナリログの名前を得るために、回転イベントデータを用いる。MySQLVAMは次のバイナリログを開き、そのバイナリログ読出を続ける。シナリオ3および4では、MySQLVAMがストップイベントに出合うと、使用しているバイナリログを閉じて、次のバイナリログがあるかログインデックスファイルをチェックする。MySQLVAMがインデックスファイルにおいて次のバイナリログを見つけると、そのバイナリログを開いて読出を続ける。MySQLVAMがインデックスファイルにおいて新しいログファイル名を見つけることができなかったたとえば、サーバがまだシャットダウンモードにあるか、シャットダウン後、スタートしていない場合、MySQLVAMはextractに対してアベンドすることを知らせる。考慮するべきもう一つの興味のあるシナリオがある。サーバクラッシュの際、フォーマット記述イベントのフラグがサーバの再スタートのときにサーバによってリセットされない可能性は小さく、またはMySQLサーバがアクティブバイナリログファイルに回転イベントもしくはストップイベントのどちらもログしない。後のスタートアップの際、サーバはより古いバイナリログのフラグをリセットすることなく、新しいバイナリログファイルを作成する。このような特有の状況では、2つのバイナリログがLOGEVENTBINLOGINUSEF状態のフラグを設定していることになる。MySQLVAMがこのシナリオに出合うのは以下の条件の場合である:1MySQLVAMは現在アクティブバイナリログを処理している。サーバクラッシュは読出のときに起こる。この場合、extractを停止させ、クラッシュリカバリを行ない、サーバスタートアップの後MySQLVAMを再度スタートさせるのがよい。2MySQLVAMはより古いログファイルを読むよう位置付けられている。1つのファイルから別のファイルに読出す場合すなわちログ回転の場合、LOGEVENTBINLOGINUSEFの値のログファイルフラグに出合う。このログファイルは最新のログファイルではないことに注意しなければならないすなわち、アクティブなバイナリログではない。EOFが起こると、MySQLVAMは次のログファイルがあるかどうかについて、ログインデックスファイルをチェックする。この場合、MySQLVAMはサーバクラッシュが前に起こっていると見なし、既存のログファイルを閉じ、次のログファイルを開けてログ読出を続ける。MySQLVAMクラス設計上記のように、一実施例に従うと、MySQLVAM実施はCを用いて書込まれ、MySQLVAMモジュールの実施は2つの主な部分に分けられる。最初の部分では、内部で開発されたイベントCクラスを用いてバイナリログイベントを読出し、これらをデータレコードに処理し、レコードを用意ができたフォーマット送信できる状態にして、制限されたサイズのQueueに記憶する。第2の部分では、Queueからレコードを取ってきて、APIからリクエストを受けるたびにAPIに送る。バイナリログリーダ図13は、一実施例に従うVAMバイナリログリーダのクラスダイヤグラムを示す。CMySQLBinLogManagerクラスは主要制御クラスであり、全体の処理を管理し、作業を異なるクラスにコミットする。データをバイナリログから読出し、バイナリログデータを処理しMySQLイベントをデータレコードに変換、レコード既成フォーマットを制限されたサイズのQueueに入れることを主に担当する。これはすべての関数を純粋仮想として有するCLogManagerクラスから派生している。設計はCMySQLBinLogReaderクラスを有し、データをバイナリログから取ってくることを担う。さまざまなCイベントクラスおよびMySQLのIOCACHEクラスを用いて、バイナリログのライフサイクルおよびイベントインスタンスを管理する。さらに、イベントをフィルタ処理するためにCFilterBinLogログを用いる。CLogProcessorクラスはバイナリログデータを処理するのであって、制限されたサイズQueueを準備した既成オブジェクトで埋める。後で、これらのオブジェクトはAPIに送られるために他のクラスによってフェッチされる。CRecordQueueクラスは既成レコードの記憶を担う。先頭から、処理はCMySQLBinLogManagerクラスのscanLog機能から始まり、これは別個の実行エンティティスレッドであり、独立して実行され、全体の処理実行を担う。まずCMySQLBinLogReaderにバイナリログの読出を求め、そこから生のイベントインスタンスを得る。このレコードをさらに処理するためCLogProcessorに渡して、制限されたサイズのQueueに入力される。バイナリログプロセッサ図14は一実施例に従うと、バイナリログプロセッサのクラスダイヤグラムを示す。CMySQLVAMModuleは全体のMYSQLVAMモジュールの主要制御クラスである。これはシングルトンクラスであり、MYSQLVAMモジュールの寿命の間中1つのオブジェクトしか持たない。中にすべてのコアビジネスロジックがあり、タスクをさまざまなクラスにわたってデリゲートする。MYSQLVAMモジュールはAPIに4つの関数を公開しており、これはMYSQLVAMInitialize、MYSQLVAMRead、MYSQLVAMMesageおよびMYSQLVAMControlである。これらの関数のビジネスロジックはCMySQLVAMModuleクラスの中にある。CRecordQueueキューからCRecordレコード設計の第1の部分により、Queueに入れられた既成レコードをフェッチして、CMySQLVAMCommunicatorクラスによってAPIに送る。CMySQLVAMCommunicatorクラスはどのようにデータをAPIに対して送るおよび得るかを担う。CMySQLVAMApiクラスを用いてAPIからの公開された関数を用いる。CMySQLVAMApiクラスはAPI公開関数のラッパである。CErrorContainerクラスは中にエラーオブジェクトを記憶し、エラーになりがちなシナリオを取扱う。MySQLVAM公開関数すなわち、MYSQLVAMInitializeがAPIからコールされるたびに、フローはCMySQLVAMModuleクラスに向けられ、そのフローを別の他のクラスにリダイレクトし、データをAPIに返す。たとえば、MYSQLVAMRead読出しがAPIからコールされたのなら、CMySQLVAMModuleのMySQLVAMReadがコールされ、CRecordQueueキューからデータをフェッチして、CMySQLVAMCommunicatorクラスを介してAPIに送られる。本発明は、1つ以上のプロセッサ、メモリおよび/または本開示の教示に従うプログラミングされたコンピュータ読取可能記憶媒体を含む、1つ以上の従来の汎用もしくは特殊なデジタルコンピュータ、演算装置、マシンまたはマイクロプロセッサを用いて、好都合に実施できる。適切なソフトウェアコード化は、ソフトウェア技術の当業者にとって明らかなように、本開示の教示に基づき、熟練したプログラマーによって容易に用意することができる。一部の実施例において、本発明は一時的ではない記憶媒体またはコンピュータ読取可能媒体であるコンピュータプログラムプロダクトを含み、そこに命令が記憶されて、コンピュータに本発明のいずれかの処理を実行するようプログラミングするために用いることができる。記憶媒体は、フロッピー登録商標ディスク、光学ディスク、DVD、CD-ROM、マイクロドライブ、光磁気ディスク、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、フラッシュメモリ装置、磁気または光カード、ナノシステム分子メモリICを含むを有するすべての種類の物理媒体、ならびに命令および/またはデータを記憶するのに適するすべての種類の媒体または装置を含むことができるが、これらに限定されない。本発明の記載は、図示および説明のために提供されている。本発明を開示されたそのままの形に制限する意図はない。多くの変形および変更は当業者にとって明らかである。特に、実施例はMySQL環境およびMYSQLVAMを用いて記載されているが、他の種類のVAMを他の種類のデータベースまたはシステムで実施できることは明らかである。実施例は本発明の原理および実用的アプリケーションを最もよく説明する目的のために選択および記載されており、それにより当業者がさまざまな実施例について、および意図される特定の使用に適するさまざまな変形について、本発明を理解することができる。本発明の範囲は特許請求の範囲およびその均等の意味によって定義されるものとする。"