JP6062855B2

JP6062855B2 - ＭｙＳＱＬデータベース−異種ログベースレプリケーション

Info

Publication number: JP6062855B2
Application number: JP2013521774A
Authority: JP
Inventors: パリーク，アロック; ラクシュミナラヤナン，マハデバン; デュベイ，アビナシュ; コービン，スコット
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 2010-07-27
Filing date: 2011-05-13
Publication date: 2017-01-18
Anticipated expiration: 2031-05-13
Also published as: EP2599014A2; US20120030172A1; EP2599014B1; EP3410320A1; WO2012018424A3; US20130318044A1; JP2013535737A; US9442995B2; WO2012018424A2; EP3410320B1; CN103221949A; USRE48243E1; US8510270B2; CN103221949B

Description

著作権表示
本特許文献の開示の一部は、著作権保護の対象となる内容を含む。本著作権所有者は、特許文献または特許開示について、特許商標庁の特許ファイルまたは記録に記載されたとおりのものが複製されることに対して異議を唱えないが、他の点では何であれすべての著作権を保持するものとする。

発明の分野
本発明は一般に異種システム間でのデータ転送に関し、特にＭｙＳＱＬデータベースまたはシステムと、別の種類のデータベースまたはシステムとの間でデータを転送するために、ログベースレプリケーションを用いるシステムおよび方法に関する。

背景：
ＭｙＳＱＬオープンソースデータベースといったデータベースプロダクトは、世界中でますます多くの組織で用いられている。１日当たり５万回のダウンロードが推定されるが、ＭｙＳＱＬデータベースは信頼性の高い手頃な価格で使い易い高性能データベースを必要とするデータベース開発者、管理者（ＤＢＡ）およびＩＴマネージャにとっては人気のある選択である。一部の組織では、このようなデータベースは主要なプロダクション環境となっており、事業の中核であるアプリケーションを実行するために用いられている。事業が拡大すると、複雑なデータ管理の必要も出てくる。これらの組織の多くは、スケーラビリティ(scalability)上の理由により、たとえば自己のＭｙＳＱＬデータベースからOracle（登録商標）/DB2/SqlServerといった他の商業的データベースにデータを移行したいと考えている。

データ移行に加えて、自己のオリジナルのデータベースとしてＭｙＳＱＬを用いる一部の組織は、そのデータを他の運用システムやデータベースに統合したいと思うかもしれない。たとえば、他のリアルタイムデータウェハウスシステムとの統合や異なるデータベースシステムで実行される財務アプリケーションとの統合を挙げることができる。このような組織は、ゼロダウンタイム移行のために、レイテンシが低い異種レプリケーションを提供するソリューションを必要とする。

さらに組織では、頻繁なレポートクエリーのためにプロダクションサーバに負担を掛けたくない場合も多い。なぜなら、レポート用のリードオンリクエリーの膨大な数は、運用サーバの性能を低下させ得るからである。組織によっては、レポート系のクエリーを他の、おそらくはより性能が低い非プロダクションデータベースにオフロードしたいかもしれない。たとえば、一部の組織では、第１の種類のデータベースサーバを、たとえばＭｙＳＱＬがLinux（登録商標）またはWindows（登録商標）ＯＳで実行される、レポートサーバとして使用し、第２の種類のデータベースサーバを、たとえばオラクル（登録商標）で実行される高性能運用サーバとして使用したいかもしれない。

ＭｙＳＱＬデータベースにあるデータを他の非ＭｙＳＱＬシステムと統合可能にするためには、カスタムプログラムまたはETL / EAI / EIIといったソフトウェアコンポーネントを（ゲートウェイまたは付加的プロダクトを介して）用いることができる。このような技術の問題は、非バルクデータ（ＥＴＬ）の処理が不十分であり、アプリケーションからデータを公開するのにアプリケーションの変更が必要であり（ＥＡＩ）、またはＭｙＳＱＬシステムおよび非ＭｙＳＱＬシステムへのアプリケーションアクセスおよび必要なデータの統合を要することである。多くの場合、変更データを統合するのに連続的にＥＴＬを実行することはコンピュータ上負担があり、ＥＡＩ統合はアプリケーションへの変更／アクセスを必要とし、それによりアプリケーションの応答時間に影響し、ＥＩＩは異なる（遠隔）ネットワークを介して複数のシステムへのアクセスに係わるので、遅い。

したがって、たとえばＭｙＳＱＬトランザクションデータのＭｙＳＱＬデータベースから非ＭｙＳＱＬデータベースへの論理的レプリケーションを実行するための、ログベース変更データキャプチャ（ＣＤＣ）プログラムは、このような統合／同期を処理する周期的（毎晩）ＥＴＬ、ＥＡＩまたはＥＩＩによる方法以外には、現在存在しない。一般にこのような分野が、本発明の実施の形態の対象分野である。

概要：
異種システム間でデータを転送するためのシステムおよび方法が記載され、特にたとえばＭｙＳＱＬデータベースまたはシステムと、他の種類のデータベースまたはシステムとの間でデータを転送するためにログベースレプリケーションが用いられる。ある実施例に従うと、システムを用いてソースデータベースシステムからターゲットデータベースシステムへのＭｙＳＱＬデータの１回限りのコピーまたは最初のコピーを行ない、および／またはＭｙＳＱＬデータベースのバイナリログからキャプチャされた進行中のトランザクションを、連続した態様で１つ以上の非ＭｙＳＱＬデータベースにレプリケートし、２つのシステムは対象トランザクションのために同期化される。ある実施例に従うと、すべてのもしくは部分的データ変更は、ＭｙＳＱＬバイナリログから抽出(extract)でき、任意に変換、スキップまたは拡大され、ファイルに出力または書込まれ（一実施例に従うと、トレールファイル、またはOracle（登録商標） GoldenGateトレールファイルとして実施でき）、次に１つ以上のターゲットシステム（たとえば別のＭｙＳＱＬデータベース、または非ＭｙＳＱＬデータベース）で与えることができ、それによりソースおよびターゲットのシステムを同期させる。

一実施例に従う異種ログベースレプリケーション用のシステムの全体のアーキテクチャを示す図である。一実施例に従う現在のバイナリログファイルを定めるための、ログインデックスファイルの使用を示す図である。一実施例に従う異種ログベースレプリケーション用の処理のフローチャート図である。一実施例に従うログ回転の使用を示す図である。一実施例に従うＭｙＳＱＬバイナリログにおけるイベント順序を示す図である。一実施例に従うイベントヘッダ構造の例を示す図である。一実施例に従うフィールドメタデータの例を示す図である。一実施例に従うテーブルマップイベント構造の例を示す図である。一実施例に従う書込ローイベント構造の例を示す図である。一実施例に従う更新ローイベント構造の例を示す図である。一実施例に従うイベント順序の例を示す図である。一実施例に従うイベント順序の別の例を示す図である。一実施例に従うＶＡＭバイナリログリーダ用のクラスダイヤグラムの例を示す図である。一実施例に従うＶＡＭバイナリログプロセッサ用のクラスダイヤグラムの例を示す図である。

詳細な説明：
異種システムの間でデータを転送するためのシステムおよび方法が記載され、特にログベースレプリケーションを用いて、たとえばＭｙＳＱＬデータベースまたはシステムと、他の種類のデータベースまたはシステムとの間でデータを転送する。一実施例に従うと、システムを用いてソースデータベースシステムからターゲットデータベースシステムへのＭｙＳＱＬデータの１回限りのコピーまたは最初のコピーを行ない、および／またはＭｙＳＱＬデータベースのバイナリログからキャプチャされた進行中のトランザクションを、連続した態様で１つ以上の非ＭｙＳＱＬデータベースにレプリケートし、２つのシステムは対象トランザクションのために同期化される。一実施例に従うと、すべてのもしくは部分的データ変更は、ＭｙＳＱＬバイナリログから抽出でき、任意に変換、スキップまたは拡大され、ファイルに出力または書込まれ（一実施例に従うと、トレールファイル、またはOracle（登録商標） GoldenGateトレールファイルとして実施でき）、次に１つ以上のターゲットシステム（たとえば別のＭｙＳＱＬデータベース、または非ＭｙＳＱＬデータベース）で与えることができ、それによりソースおよびターゲットのシステムを同期させる。本発明のさまざまな実施例の利点は以下を含む：
１．ログベースレプリケーションは、ＭｙＳＱＬデータベースシステムと非ＭｙＳＱＬデータベースシステムとの間のトランザクションレプリケーションについて、非常に低いレイテンシを可能にする。トランザクションがＭｙＳＱＬシステムにコミットされてから非ＭｙＳＱＬシステムにレプリケーションされるまでの一般的に予想される時間は数秒以下である。

２．ＭｙＳＱＬシステムのオーバーヘッドは、従来の方法と比べて著しく低い。なぜなら、変更はログからキャプチャされるのであって、ＭｙＳＱＬシステムのデータページではないからである。ネットワーク上で転送されるバイトの数も著しく低い。

３．アプリケーションテーブルは、ＳＱＬまたは他のＳＱＬを組込んだプログラミング言語（またはＳＱＬ様言語）を介してクエリーされない。それにより、レプリケーションは非侵襲性のものとなる。

４．本システムは第３のゲートウェイプロダクトの使用を必要とせず、ネットワークまたはシステムの障害の場合、およびデータサイト全体に影響を及ぼすほとんどの障害に対しても、トランザクションの配信を保証することができる。

５．オペレーショナルレポーティングアプリケーションを用いて、ＭｙＳＱＬデータベースにアクセスすることなく、リアルタイムベースで非ＭｙＳＱＬデータベースからデータを得ることができる。

６．本システムは、ＭｙＳＱＬデータベースで実行されるアプリケーションの非ＭｙＳＱＬデータベースへの移行をほぼゼロに近いダウンタイムで可能にし、さらにＭｙＳＱＬデータベースからのトランザクションが、ほぼリアルタイム（またはアクティブ）データウェハウス用に、データベースマシンで使われることを可能にする。

７．本システムはログベース変更データキャプチャ（ＣＤＣ）を可能にし、他のシステムへのスケーリングを求めているがアプリケーションの停止を受入れることができないＭｙＳＱＬベースの組織が、２つのシステムを同期して維持し、十分なテストを行ない、ダウンタイムを発生することなく、自己のＭｙＳＱＬシステムを他のシステムに最終的に移行することを可能にする。現在、ＭｙＳＱＬデータベースからのリアルタイム操作は、リアルタイムベースで企業データウェハウスとの統合は一般になされていない。一実施例に従うと、該方法は企業がＭｙＳＱＬシステムからデータを得る方法を提供する。

一実施例に従うと、システムはＭｙＳＱＬのバイナリログフィーチャを用いてデータをキャプチャする。ＭｙＳＱＬバイナリログはデータをたとえばＤＭＬ操作で変更するステートメントデータを含む。ステートメントは「イベント」の形で格納され、イベントはデータへの変更を記述する。一実施例に従うと、バイナリログは２つの重要な役割を果たす：（１）レプリケーションであって、バイナリログは、スレーブサーバに送られるステートメントの記録として、マスタレプリケーションサーバで用いられる。マスタサーバはそのバイナリログに含まれるイベントをスレーブに送り、そこでマスタで行なわれたのと同じデータ変更を行なうためにイベントが実行され、および（２）データリカバリであって、特定のデータリカバリ操作はバイナリログの使用を必要とする。バックアップファイルが回復されると、バックアップが行なわれた後に記録されたバイナリログは再実行される。これらのイベントにより、データベースはバックアップ時点のものから現在のものになる。

バイナリログがトランザクションデータを記憶可能にすることは、ＭｙＳＱＬの設置によってデフォルトでは設定されない。一実施例に従うと、「ログ-ビン」のパラメータを用いてバイナリロギングを可能にする。このパラメータはＭｙＳＱＬ初期ファイルで指定される（これはウインドウズ（登録商標）プラットフォームではｍｙ．ｉｎｉであり、他のプラットフォームではｍｙ．ｃｏｎｆである）。ＭｙＳＱＬの以前のリリースでは、バイナリログはステートメントレベル情報を含んでいた、すなわち、完全なＤＤＬおよびＤＭＬステートメントをログしていた。異種性を支持するために、データが汎用的なデータフォーマットで利用可能にするためには、純粋なテキストＳＱＬステートメントに基づいてログベースキャプチャを構築することは難しい。ＭｙＳＱＬの後のバージョンでは、上記の問題を軽減するために、バイナリロギングサポートを導入している。ＭｙＳＱＬバージョン５．１は、バイナリデータへのアクセスを提供するために新しい内部Ｃ＋＋クラスを導入している。

一実施例に従うと、IngressおよびSybaseといった他のデータベースで見られる循環型ロギングスタイルと比べて、ＭｙＳＱＬバイナリログは順次作成され番号が付けられる。ＭｙＳＱＬは古いログファイルを自動的にはアーカイブしないので、古いログファイルを保つ／バックアップするために、管理者は十分に注意しなければならない。

一実施例に従うと、非トランザクションテーブルへの更新は、実行の後すぐにバイナリログに記憶される。拘束のないトランザクションでは、ＩｎｎｏＤＢテーブルといったトランザクションテーブルを変更するすべての更新（INSERT、DELETE、UPDATE）は、COMMITステートメントがサーバによって受取られるまでキャッシュされる。その時点で、サーバデーモン（ｍｙｓｑｌｄ）はトランザクション全体をバイナリログに書込む。サーバデーモンはROLLBACKステートメントが発行されたのなら、トランザクションデータを書込まない。バイナリログについて、ロールバック操作はｎｏ−ｏｐの非記録操作である。

図１は、一実施例に係わる、異種ログベースレプリケーション用のシステムのアーキテクチャの全体を示す図である。図１に示されるように、アーキテクチャ１０２はＭｙＳＱＬまたは同様のデータベース１０４を含み、これは上記の構成設定およびパラメータを用いて、データを現行のバイナリログファイル１０６（または複数のバイナリログファイル１０８）にログするよう構成されている。

一実施例に従うと、システムは、ファイルリーダ、ファイルＣＡＣＨＥおよびデータ変換クラスを与えるために、任意に１つ以上のＭｙＳＱＬライブラリ１１０を含むことができる。別の実施例では、この特定のコンポーネントは必要ない。

ベンダーアクセスモジュール（ＶＡＭ）プラグインもしくはアプリケーションプログラムインターフェイス（ＡＰＩ）１１１または同様のコンポーネントを用いて、Oracle GoldenGateまたは類似のレプリケーションプロダクトといったデータキャプチャおよびレプリケーションシステムまたはプロダクトにより、バイナリログファイルへのアクセスが与えられる。一実施例に従うと、ＶＡＭは、複数のＭｙＳＱＬＶＡＭイベントクラス１１２を含み、これを用いてたとえば現行のバイナリログを開く、イベントを読む、ＶＡＭ記録に変換する、ログ回転を取扱うなどといった、ＭｙＳＱＬバイナリログからのイベントの処理をもたらし、さらにＭｙＳＱＬライブラリをラップアラウンドするために用いることができる複数のＭｙＳＱＬＶＡＭバイナリログクラス１１４、ならびにビンログクラスからレコードを読取り処理し、それらをレコードキューに入れるために用いることができる複数のＶＡＭリーダおよびプロセッサクラス１１６を含む。一実施例に従うと、これらのクラスの一部または全部はextractコールによって、ブロックではなく自己の専用スレッドを有することができる。他の実施例に従うと、上記はＭｙＳＱＬ環境およびＭｙＳＱＬＶＡＭの使用を示しているが、他の種類のＶＡＭを他の種類のデータベースまたはシステムで実施できることは明らかである。

一実施例に従うと、ＶＡＭｒｅａｄ（）コールにより、後で使用されるよう、レコードを保持するためにレコードキュー１１８が設けられる。複数のＶＡＭレコードクラス１２０を用いてレコードキューからデータを読出し、ＶＡＭＡＰＩを用いて、extractにデータを送ることができる。Oracle GoldenGateまたは同様のレプリケーション処理といったextractプロセス１２２がコンパイルされて、データをＶＡＭＡＰＩから取込み、データをターゲットシステム１２６および／またはターゲットデータベース１２８に与えるために、トレール１２４に、またはGoldenGateトレールファイルといったトレールファイルに、書込む。

一実施例に従うと、ＭｙＳＱＬはイベント入力としてデータをバイナリログ内にストアし、ＳＱＬステートメントおよび操作の性質に基づきさまざまなイベントを支持し、イベントデータを読出すためにＣ＋＋クラスを与える。一実施例に従うと、ＶＡＭはこれらバイナリログイベントのサブセットを認識するために一般に構成される。たとえば、ＶＡＭはトランザクション、ＤＭＬステートメントデータ、ログ回転などを表わすバイナリログイベントを認識するよう構成することができる。表１は一実施例に従うと、ＭｙＳＱＬＶＡＭがバイナリログから認識することができるよう構成可能であるＭｙＳＱＬイベントのリストを示す。他の実施例に従うと、他の種類のイベントも認識できることは明らかである。

一実施例に従うと、ＶＡＭの実施はＣ＋＋を用いて書込むことができ、ＶＡＭモジュールの実施は２つの主要な部分に分けることができる：第１の部分は、内部的に立てられたイベントＣ＋＋クラスを用いてバイナリログイベントを読出し、データレコードに処理し、レコードを既存フォーマット（送信できる形）にして、制限された大きさのキューに記憶し、第２の部分は、ＡＰＩからリクエストを受取るたびに、キューからレコードを取ってきてＡＰＩに送信する。

ログインデックスファイル
図２は現行のバイナリログファイルを定めるためのログインデックスファイルの使用を示す図である。一実施例に従うと、ＭｙＳＱＬはログインデックスファイルを用いて、現行のバイナリログファイルおよびより古いログファイルを識別するリストを維持する。このログインデックスファイルは、バイナリログと、同じディレクトリ場所にある。システムはログファイルフォーマットが、たとえばROW、STATEMENT、またはMIXEDフォーマットのいずれであるかを判断するために構成ファイルから読出し、ROWでない場合に、アベンド(abend)する。初期化の際、ＶＡＭはアクティブバイナリログファイルの名前を得る必要がある。図２に示されるように、実施例１３２に従うと、ＭｙＳＱＬデータベース１０４は、上記の構成設定およびパラメータを用いて、現行のバイナリログファイル１０６（または複数のバイナリログファイル１０８）にデータ変更を書込むことができる。アクティブバイナリログを定めるために、ＶＡＭ１１１は環境変数または与えられたＶＡＭパラメータからＭｙＳＱＬ設置ホームを得て、ＭｙＳＱＬ初期化ファイルを読出し（すなわち、ウインドウズ（登録商標）プラットフォームではｍｙ．ｉｎｉであり、他のプラットフォームではｍｙ．ｃｏｎｆファイルであり）；「ログ-ビン」パラメータの値を得て、ログディレクトリ場所およびログインデックスファイル名を得て、ログインデックスファイル１４０を開けて内容１４２を読出す。この内容から、ＶＡＭはリストの最後のログファイルを判断し、この情報を用いて特定のログファイルを開き１４４、そのログファイルがまだサーバによって使用されているかどうかをチェックする（たとえば、フォーマット記述イベントのフラグ値がLOG_EVENT_BINLOG_IN_USE_Fであるかチェックする）。イエスなら、ＭｙＳＱＬサーバは現在書込のためにこのログファイルを使用しているのであり、ＶＡＭはこのログファイルをアクティブログファイルとして扱う。

図３は、一実施例に従う異種ログベースレプリケーション用の処理のフローチャートである。図３に示されるように、ステップ１６０において、ソースシステム（たとえばＭｙＳＱＬデータベース）は、トランザクションデータをバイナリログに書込むよう構成されている。ステップ１６２において、ランタイム中に、１つ以上のバイナリログが作成され、たとえばＳＱＬまたは他のデータベースステートメントに対応するイベント入力として、トランザクションまたは変更データが中に記憶される。ステップ１６４において、ＶＡＭ（ＭｙＳＱＬデータベースの場合、ＭｙＳＱＬＶＡＭ）はバイナリログイベントを読出し、これらをデータレコードのキューに処理する。ステップ１６６において、トランザクションデータのリクエストが受取られると、ＶＡＭはキューからデータレコードを取ってきて、ＶＡＭＡＰＩに送る。ステップ１６８において、extractプロセス（たとえば、Oracle GoldenGate）はＡＰＩから読出し、トランザクションまたは変更データを反映して、トレール情報またはトレールファイル（たとえばOracle GoldenGateトレールファイル）を作成する。ステップ１７０において、トレール情報またはトレールファイルは、１つ以上のターゲットシステム（たとえば、ターゲットデータベース）に通信または「ポンプ」され、そのトレール情報またはトレールファイルは、（ここでも、Oracle GoldenGateまたは他のプロダクトを使用して）そのターゲットシステムでトランザクションをレプリケーションするのに使用される。

ログ回転
一実施例に従うと、バイナリログと係わる特定の種類のイベントは回転イベントであり、これは可能なログ回転を示す、すなわち、ＭｙＳＱＬサーバが現行のバイナリログを閉じて新しいバイナリログを開くたびに、バイナリログにログされる。ログ回転の可能な理由は、たとえばログファイルのサイズがmax_binlog_sizeパラメータを超える、または明確な「フラッシュログ」コマンドが、ＭｙＳＱＬコマンドコンソールから発せられた場合を含む。この場合、ＭｙＳＱＬは現行のバイナリログに回転イベントを作成し、現行のバイナリログを閉じて、さらに処理するために新しいバイナリログを開く。回転イベントは、作成するべき新しいログファイルを示す。一実施例に従うと、ＶＡＭはこの値を用いて既存のバイナリログファイルを閉じ、新しいバイナリログファイルを開け、その読出を続けることができる。

一実施例に従うと、回転イベントは、CRotateEvent C++クラスによって表わされ、これは以下のように定義される：

一実施例に従うと、以下のシナリオはＭｙＳＱＬのログ回転を引き起こす（すなわち、既存のアクティブログファイルを閉じて、新しいログファイルを開く）：
１．アクティブログファイルのサイズが、max_binlog_size値を超えた場合（ｍｙ．ｉｎｉまたはｍｙ．ｃｏｎｆファイルで指定されている）。このシナリオでは：
ａ．ＭｙＳＱＬはアクティブバイナリログにおいて’Rotate Event’をログする。回転イベントデータ部は、新しいアクティブバイナリログの場所および名前を含む。

ｂ．ＭｙＳＱＬはアクティブバイナリログを閉じて、フォーマット記述イベントフラグをＮＵＬＬにリセットする（このフラグは前にLOG_EVENT_BINLOG_IN_USE_F値に設定されている）。

ｃ．ＭｙＳＱＬは新しいバイナリログを作成し、フォーマット記述イベントフラグをLOG_EVENT_BINLOG_IN_USE_F値に設定する。

２．明確な「フラッシュログ」コマンドがＭｙＳＱＬＳＱＬプロンプトで発行された場合。このシナリオでは：
ａ．ＭｙＳＱＬはアクティブバイナリログにおいて’Rotate Event’をログする。回転イベントデータ部は、新しいアクティブバイナリログの場所および名前を含む。

３．サーバシャットダウンの際。このシナリオでは：
ａ．ＭｙＳＱＬはアクティブバイナリログに’Stop Event’をログする。

ｂ．ＭｙＳＱＬはバイナリログを閉じ、さらにフォーマット記述イベントフラグをＮＵＬＬ値にリセットする（このフラグは前にLOG_EVENT_BINLOG_IN_USE_F値に設定されている）。

４．サーバスタートアップの際。このシナリオでは：
ａ．ＭｙＳＱＬは新しいバイナリログを作成し、フォーマット記述イベントフラグをLOG_EVENT_BINLOG_IN_USE_F値に設定する。

一実施例に従うと、上記のシナリオ１および２では、ＶＡＭはログ回転が起こったことを識別するために回転イベントを使用し、次のバイナリログの名前を得るために、回転イベントデータを用いる。ＶＡＭは次のバイナリログを開き、そのバイナリログ読出を続ける。上記のシナリオ３および４では、ＶＡＭがストップイベントに出合うと、使用しているバイナリログを閉じて、次のバイナリログがあるかログインデックスファイルをチェックする。ＶＡＭがインデックスファイルにおいて次のバイナリログを見つけると、そのバイナリログを開いて読出を続ける。ＶＡＭがインデックスファイルにおいて新しいログファイル名を見つけることができなかった（たとえば、サーバがまだシャットダウンモードにあるか、シャットダウン後、スタートしていない）場合、ＶＡＭはextractに対してアベンドすることを知らせる。

サーバクラッシュの際、フォーマット記述イベントのフラグがサーバの再スタートのときにサーバによってリセットされない可能性は小さく、またはＭｙＳＱＬサーバがアクティブバイナリログファイルに回転イベントもしくはストップイベントのどちらもログしない可能性は小さい。後のスタートアップの際、サーバはより古いバイナリログのフラグをリセットすることなく、新しいバイナリログファイルを作成する。一実施例に従うと、この状況では、２つのバイナリログがLOG_EVENT_BINLOG_IN_USE_F状態のフラグを設定していることになる。ＶＡＭがこのシナリオに出合うのは以下の条件の場合である：（１）ＶＡＭは現在アクティブバイナリログを処理している。サーバクラッシュが読出のときに起こる。この場合、extractを停止させ、クラッシュリカバリを行ない、サーバスタートアップの後ＶＡＭを再度スタートさせるのがよい；および（２）ＶＡＭはより古いログファイルを読むよう位置付けられている。１つのファイルから別のファイルに読出す間（すなわちログ回転の間）、LOG_EVENT_BINLOG_IN_USE_Fの値のログファイルフラグに出合う。このログファイルは最新のログファイルではないことに注意しなければならない（すなわち、アクティブなバイナリログではない）。ＥＯＦが起こると、ＭｙＳＱＬＶＡＭは次のログファイルがあるかどうかについて、ログインデックスファイルをチェックする。この場合、ＶＡＭはサーバクラッシュが前に起こっているとみなし、既存のログファイルを閉じ、次のログファイルを開けてログリーディングを続ける。

図４は、一実施例に従う、ログ回転の使用１８２を示す。図４に示されるように、ステップ１８４において、ＶＡＭはログインデックスファイルを解析してバイナリログファイルをリストする。ステップ１８６において、シーケンスＩＤが読取られて、ログファイル名および場所が得られる。ステップ１８８において、ログファイルが開けられる。ステップ１９０において、ファイルのＥＯＦがチェックされ、ステップ１９８において、ＥＯＦに達しなければ、イベントは順次ファイルログから読出される。ステップ２００から２０４において、ＶＡＭはクエリーイベント、ローイベント、回転イベント、および／またはストップイベントといったイベントを判断する。ステップ２０８において、次のログファイルは回転イベント情報から得ることができる。

ＶＡＭ実施
上記のように、一実施例に従うと、当該システムおよび方法は、たとえばＭｙＳＱＬデータベースまたはシステムと別の種類のデータベースまたはシステムとの間でデータを転送するために、ログベースレプリケーションを用いること、またはＭｙＳＱＬのようなデータベースプロダクトもしくはOracle GoldenGateのようなデータレプリケーションプロダクトを用いることを可能にする。以下の部分は、このような実施の形態および対応するベンダーアクセスモジュール（ＶＡＭ）またはアプリケーションプログラムインターフェイス（ＡＰＩ）の特定の実施を説明する。

バイナリログサポート
上記のように、一実施例に従うと、ＶＡＭ（ＭｙＳＱＬＶＡＭ）は、データをキャプチャするためにＭｙＳＱＬバイナリログを使用する。ＭｙＳＱＬバイナリログは、ＤＭＬ操作といったような、データを変更するステートメントデータを含む。ステートメントは、変更を記述する「イベント」の形で記憶される。

バイナリログは２つの重要な役割を果たす：レプリケーションであって、バイナリログは、スレーブサーバに送られるステートメントの記録として、マスタレプリケーションサーバで用いられる。マスタサーバはそのバイナリログに含まれるイベントをスレーブに送り、そこでマスタで行なわれたのと同じデータ変更を行なうためにイベントが実行され；およびデータリカバリであって、特定のデータリカバリ操作はバイナリログの使用を必要とする。

バックアップファイルが回復されると、バックアップが行なわれた後に記録されたバイナリログのイベントは再実行される。これらのイベントにより、データベースはバックアップ時点のものから現在のものになる。完全なバックアップのためには、ユーザー（例えば、顧客）はＭｙＳＱＬDumpユーティリティを使用し、その後増分バックアップ用にバイナリログを使用することができる。

バイナリログ構成
一実施例に従うと、バイナリログがトランザクションデータを記憶可能にすることは、ＭｙＳＱＬの設置によってデフォルトでは設定されない。その代わりに、「ログ-ビン」のパラメータを用いてバイナリロギングを可能にする。このパラメータは初期化ファイルにおいて、ウインドウズ（登録商標）プラットフォームではｍｙ．ｉｎｉとして、他のプラットフォームではｍｙ．ｃｏｎｆとして指定される）。

ＭｙＳＱＬバージョン５．１の前のリリースでは、バイナリログはステートメントレベル情報を含んでいた、すなわち、完全なＤＤＬおよびＤＭＬステートメントをログしていた。異種性を支持するために、データが汎用的なデータフォーマットで利用可能にするためには、純粋なテキストＳＱＬステートメントに基づいてログベースキャプチャを構築することは難しい。しかしＭｙＳＱＬ５．１リリースは、上記の問題を軽減するために、バイナリロギングサポートを導入している。さらに、ＭｙＳＱＬは、バイナリデータへのアクセスのために内部Ｃ＋＋クラスを提供している。

一実施例に従うと、バイナリロギングを可能にするために、ＭｙＳＱＬサーバを構成するのに、以下のステップが必要である：ＭｙＳＱＬサーバ構成ファイルを開く（ウインドウズ（登録商標）プラットフォームではｍｙ．ｉｎｉであり、他のプラットフォームではｍｙ．ｃｏｎｆである）；「ログ-ビン」パラメータを用いてバイナリロギングを能動化する。このオプションの値は、ログファイル用のディレクトリ場所を特定する。たとえば：
log-bin="C:/MySQL/MySQL Server 5.1/log/test.bin"
上記の例では、ログファイルの名前は‘test.00001, test.00002 …’などで作成される。これらのファイルは、"ｃ:/MySQL/MySQL Server 5.1/log"ディレクトリに記憶される。構成ファイルにおいて、ロギングフォーマットはROWモードでのみ構成されるべきである。MIXEDモードはサポートされていない。このオプションにより、ＤＭＬステートメントはデータをバイナリフォーマットでログすることができる。これは、‘binlog_format’パラメータを用いることにより達成することができる。‘max_binlog_size’オプションを用いて、バイナリログファイルのサイズ（バイト単位）を指定することができる。最小値は４０９６となるべきである。

IngressおよびSybaseといった他のベンダで見られる循環型ロギングスタイルと比べて、ＭｙＳＱＬのバイナリログは順次作成され番号が付けられる。ＭｙＳＱＬはより古いログファイルを自動的にはアーカイブしないので、古いログファイルを保つ／バックアップするために、エンドユーザ／顧客は十分に注意しなければならない。一実施例に従うと、以下の処理は新しいバイナリログファイルを作成し、既存ログファイルを閉じる：サーバデーモン、mysqldが開始された場合；FLUSH LOGSまたはFLUSH MASTERといったＭｙＳＱＬコマンドコンソールプログラム（ｍｙｓｑｌ）からフラッシュコマンドを明示する。現行のログサイズがmax_binlog_sizeパラメータに達すると、サーバはさらに新しいバイナリログファイルを自動的に作成する。

一実施例に従うと、ＭｙＳＱＬはアクティブなおよび古いバイナリログファイルを含めたリストを含むインデックスファイルを維持する。このインデックスファイルは、他のバイナリログと同じディレクトリ場所にある。ＭｙＳＱＬバイナリログは、特定テーブル／カラムのロギングのターンオフ／オンをサポートしない。

トランザクションおよびバイナリログ
一実施例に従うと、非トランザクションテーブルへの更新は、実行の後すぐにバイナリログに記憶される。拘束のないトランザクションでは、ＩｎｎｏＤＰテーブルといったトランザクションテーブルを変更するすべての更新（INSERT、DELETE、UPDATE）は、COMMITステートメントがサーバによって受取られるまでキャッシュされる。ＭｙＳＱＬは、更新操作からより多くのデータを収容するために、一時ファイルを開いてキャッシュをフラッシュする。その時点で、ｍｙｓｑｌｄ（サーバデーモン）はトランザクション全体をバイナリログに書込む。サーバデーモンはROLLBACKステートメントが発行されたのなら、トランザクションデータを書込まない。バイナリログに関するかぎり、ロールバック操作はｎｏ−ｏｐの非記録操作である。

更新が混合しているトランザクションを、トランザクションテーブルおよび非トランザクションテーブルの両方にロールバックする場合、サーバデーモンはROLLBACKステートメントをログに明示する。SAVEPOINTステートメントは、ある名前の付けられたトランザクションセーブポイントを任意の名前に設定するために用いられる。ROLLBACK TO SAVEPOINTステートメントを用いて、トランザクションを示されたセーブポイントにロールバックする。ＭｙＳＱＬはネストされたトランザクションまたはトランザクションのネーミングをサポートしない。新しいトランザクションが開始された場合、または前回のものがCOMMITもしくはROLLBACKで終了することなくサーバが閉じられた場合、ＭｙＳＱＬは新しいトランザクショを開始させる前、またはサーバがシャットダウンされる前に、自動的により古いトランザクションのデータをディスクにコミットする。ＭｙＳＱＬはトランザクションを複数のバイナリファイル間で分割しない。

一実施例に従うと、トランザクションデータのサイズが‘max_binlog_size’パラメータ値を超えた場合、バイナリログファイルの大きさが‘max_binlog_size’パラメータを用いて指定された値を超えることができる。非操作の更新（更新が「ゼロ」カラムをもたらす）は、バイナリログに書込まれない。これは空のトランザクションの場合にも当てはまる。カラムを自己に更新するためにトリガが用いられた場合、ＭｙＳＱＬはステートメント更新の結果よりも、トリガ更新の結果をログする。たとえば、以下のトリガの場合、年齢を２０に更新すると、ＭｙＳＱＬは２０ではなく、２５の値（トリガの結果）をログさせる：

プラットフォームサポート
さまざまな実施例に従うと、本システムはWindows、Linux Operating system、HPUX、およびSolaris OS（登録商標）をサポートすることができる。ＭｙＳＱＬＶＡＭがバイナリログイベントをキャプチャするためには、ＭｙＳＱＬextractプロセスには以下の許可が必要である（以下の許可は、非ウインドウズプラットフォームに適用可能である）：構成ファイル（ｍｙ．ｃｎｆ）があるディレクトリ用のおよびバイナリログが生成されるディレクトリ用の読出しおよび実行許可；構成ファイル（ｍｙ．ｃｎｆ）用の読出許可；読出、書込（ＭｙＳＱＬデーモンプロセスで使用）；ｔｍｐディレクトリ（規定）用の実行許可。

バージョンサポート
ＭｙＳＱＬは３．ｘ以降のリリースからバイナリログをサポートする。リリース５．１以前では、ＤＭＬ操作によるデータベーステーブルへの変更は、ＳＱＬステートメント（テキスト形式）でバイナリログにログされた。リリース５．１以降では、ＭｙＳＱＬバイナリログは、ＤＭＬ操作をバイナリ形式でローデータとしてストアする。一実施例に従うと、テキストに基づくＳＱＬステートメントでの処理と比べて、このバイナリデータを読出し、これらをたとえばOracle GoldenGate汎用フォーマットに変換することは、ＭｙＳＱＬＶＡＭにとってより容易である。

データタイプサポート
表２は一実施例に従うサポートされるデータタイプを示す。

ストレージエンジンサポート
一実施例に従うと、ＭｙＳＱＬＶＡＭは以下のストレージエンジンをサポートする：ＭｙＩＳＡＭ-非トランザクションストレージエンジン；およびＩｎｎｏＤＢ−トランザクションストレージエンジン。

サポートされているデータベース操作
一実施例に従うと、ＭｙＳＱＬＶＡＭはバイナリログから以下のデータベース操作をキャプチャすることができる：Ｓｔａｒｔトランザクション、Ｃｏｍｍｉｔトランザクション、Ｒｏｌｌｂａｃｋトランザクション−ＭｙＳＱＬはバイナリログにロールバックされたトランザクションを送信するのではなく、ＭｙＳＱＬはトランザクションがＩｎｎｏＤＢのテーブルおよび同じトランザクションに関与しているｍｙｌＳＡＭタイプに係わる場合、「トランザクションロールバック操作」をログする；挿入操作；更新操作；削除操作；切捨て操作。

最大ローサイズおよびカラムサポート
一実施例に従うと、ＭｙＳＱＬの最大データベースローサイズ（現在６４ｋ）はすべて、たとえばOracle GoldenGateアプリケーションによってサポートされている。所与のＭｙＳＱＬテーブル用の最大カラム数（現在３３９８）；ＭｙＳＱＬ用の最大オブジェクト名長さ（schema.table）；およびＭｙＳＱＬの最大オブジェクト名長さ（schema.table）が支持される。ＩｎｎｏＤＢストレージエンジンを有するＭｙＳＱＬは、カラム数が１０００を超えてはならないという制限を含む。

圧縮更新および削除のサポート
一実施例に従うと、バイナリログは、ＤＭＬ操作の一部ではないカラム値を記憶する。ＭｙＳＱＬＶＡＭとキャプチャモジュールとの間のデータ転送を最小にするために、圧縮更新および削除がサポートされる。

AUTO_INCREMENTカラム
一実施例に従うと、AUTO_INCREMENTカラム属性を用いて新しいローの一意的識別を生成することができる。このカラム値はほとんどの場合システムで生成されるので、以下の２つの要件が支持される：ターゲット側へのAUTO_INCREMENTカラム値の伝搬−ＭｙＳＱＬログは、このAUTO_INCREMENTカラム値をバイナリログに記憶する。アプライ(apply)側（すなわちターゲット）では、replicatプロセスがオートインクリメントなカラム値の明示挿入操作を挿入する。ＭｙＳＱＬは挿入操作の際、AUTO INCREMENTカラムを特定の値に強制することをサポートし；およびＢｉ方向サポート−INSERT操作の際、AUTO_INCREMENTカラム値は次のより高い値で挿入される。

ＭｙＳＱＬは双方向の‘auto_increment_’カラム問題を解決するために、‘auto_increment_increment’および‘auto_increment_offset’の２つの変数（初期化ファイルmy.iniを介して構成）をサポートする。これらサーバ側変数は、双方向設定の競合を解決するために、ソース側およびターゲット側で異なって設定できる。

双方向データレプリケーションサポート
一実施例に従うと、双方向ループ検出をサポートするために、ＭｙＳＱＬＶＡＭモジュールは、ユーザid、トランザクションidに基づき、レコードをフィルタ処理する。ＭｙＳＱＬバイナリログは、これらの値をイベントには記憶しない。双方向ループ検出は、ターゲット側で、トレーステーブルまたはチェックポイントテーブル（FILTERTABLE オプションを用いて構成）を介してサポートされるべきである。ＭｙＳＱＬ双方向構成は、キャプチャから除外するためにReplicatトランザクションを識別するため、Replicatチェックポイントテーブルの使用を必要とする。extractは、チェックポイントテーブルでの操作で終わるトランザクションは無視する。この機能をサポートするために、TRANLOGOPTIONSはチェックポイントテーブルの名前を特定する新しいFILTERTABLE＜テーブル＞オプションを与える。Replicatデータベースユーザは、‘sql_log_bin’変数を用いてセッションレベルバイナリロギングをオフにすることができる。アプライ側では、Replicatユーザはこの値を０に設定して、バイナリロギングをオフにする。

ＬＳＮおよびタイムスタンプによる位置付け
一実施例に従うと、ＭｙＳＱＬＶＡＭはタイムスタンプによる位置付けおよびＬＳＮによる位置付けをサポートする。タイムスタンプ位置は、ADD/ALTER抽出コマンドを用いて設定される。たとえば：
ADD/ALTER EXTRACT extract_name,MYSQL VAM, begin timestamp_value
ここで有効なタイムスタンプ値は以下のとおりである：
ＮＯＷ（またはnow）−extractは、加えるまたは変更されたときの現行タイムスタンプ値を取る。ＭｙＳＱＬＭｙＳＱＬＶＡＭはタイムスタンプ値がこのタイムスタンプ値と等しいまたはより大きいトランザクションレコードを読出す。

今までのタイムスタンプ値−ＭｙＳＱＬＶＡＭはログファイルを検索し、タイムスタンプ値がこのタイムスタンプ値と等しいまたはより大きいトランザクションレコードを読出す。

今後のタイムスタンプ値−ＭｙＳＱＬＶＡＭは待機し、タイムスタンプ値がこのタイムスタンプ値と等しいまたはより大きいトランザクションレコードを読出す。

ＬＳＮ値による位置付けは、ADD/ALTER抽出コマンドを用いて設定される。たとえば：
ADD/ALTER EXTRACT extract_name,MYSQL VAM,lognum log_num , logpos log_pos
ここでlog_numはログファイル番号である。たとえば、ログファイル名がｔeｓｔ．００００３４である場合、この値は３４となる。ＭｙＳＱＬＭｙＳＱＬＶＡＭはこのログファイルを検索し、さらに読出すために開く：およびlog_posはログファイル内のオフセット値である。この場所後で利用可能なトランザクションレコードは、ＭｙＳＱＬＶＡＭによって読出される。

アーカイブログサポート
上記のように、一実施例に従うと、IngressおよびSybaseといった他のベンダで見られる循環型ロギングスタイルと比べて、ＭｙＳＱＬのバイナリログは順次作成され番号が付けられる。ＭｙＳＱＬは古いログファイルを自動的にはアーカイブしない。ログファイルは初期ファイルで指定されたログディレクトリに保持される。したがって顧客はより古いログファイルを保つ／バックアップするよう、注意しなければならない。一実施例に従うと、ＭｙＳＱＬＶＡＭを用いて位置付けおよびより古いログファイルの読み出しがサポートされる。ＭｙＳＱＬＶＡＭは、管理者または他のバックアップツールによって他の場所に移動させられたより古いログファイルを位置付けることが要求された場合、エラーを返すか、操作をアベンドする。

ＤＤＬレプリケーション
一実施例に従うと、バイナリログはＤＤＬステートメントをテキストに基づくＳＱＬステートメントとして記憶し、ＭｙＳＱＬＶＡＭはこの特徴をサポートする。

FetchColsおよびFetchModColsサポート
一実施例に従うと、FetchColsおよびFETCHCOLSEXCEPTを用いて、値がトランザクションログレコードにない場合に、カラム値をデータベースから取ってくることができる。このオプションは、データベースが圧縮更新を用いる場合（カラム値は変更されない限りログされない）に使用することができる。FETCHCOLS およびFETCHCOLSEXCEPTは、FILTER操作に必要なカラム値が利用可能であることを確実にする：
FETCHCOLSは特定カラムを取ってくる。

FETCHCOLSEXCEPTは、指定されているもの以外は、すべてのカラムを取ってくる。多くのカラムを有するテーブルでは、FETCHCOLSEXCEPTは各カラムをFETCHCOLSでリストするよりも有効であり得る。

FETCHMODCOLS およびFETCHMODCOLSEXCEPTは、カラムがトランザクションログにある場合でも、カラム値をデータベースから取ってくることを強制するために使用することができる。トランザクションログで存在し得る値は、変更されたカラムまたは補足ロギングで含まれたカラムのものである：
FETCHMODCOLSは特定カラムを取ってくる。

FETCHMODCOLSEXCEPTは、指定されているもの以外は、トランザクションログにあるすべてのカラムを取ってくる。多くのカラムを有するテーブルでは、FETCHMODCOL。

一実施例に従うと、この特徴はキャプチャする側でサポートされる。
初期ロードサポート
一実施例に従うと、ＭｙＳＱＬＶＡＭは初期ロードサポートを含む。

オープンソースデータベースおよびオープンソースオペレーティングシステムの人気に伴い、ますます多くの顧客はＭｙＳＱＬを仕事の一部として使い始めている。事業が成長するにつれ、組織は複雑なデータ管理を管理するために、ＭｙＳＱＬからOracle/DB2/SQLServerに移行したいと考え、一般に以下の工程をたどる：
ステップ１、既存のＭｙＳＱＬデータを顧客の選択されたデータベースに移行。この課題のために、キャプチャ側初期ロードサポートを用いることができる；
ステップ２、移行がうまく行けば、リアルタイムレプリケーション（またはデータキャプチャを変更）を能動化する。ＭｙＳＱＬＶＡＭを用いてこの課題を達成することができる。

以下の初期ロード方法がサポートされている：Replicatでデータをロードする−extractプロセスは、データをテーブルから直接抽出する。この方法は実際はより遅い。なぜなら、アプライ側では１レコードずつ与えられるからである；バルクロードユーティリティでデータをロードする−extractプロセスはレコードをＡＳＣＩＩフォーマットで出力し、これは後でSQLLOADERまたはBCPで使われる；GoldenGate直接ロードでデータをロードする−extractプロセスはデータを直接テーブルから抽出し、replicatプロセスを呼出す。データを直接ＳＱＬ＊ローダにロードする。

その他の要件
一実施例に従うと、ＭｙＳＱＬＶＡＭモジュールは、たとえば付加的切捨点を加える（ＳｙＢＡＳＥcase）により、バイナリログ内容を変更しない。したがって、同じバイナリログでの２つ以上のextractプロセスの読出しのサポートが可能である。一実施例に従うと、ＭｙＳＱＬＶＡＭはレプリケーションオプションで構成されるＭｙＳＱＬデータベースと共存する。extractにおいて新しいパラメータを追加したりＭｙＳＱＬに特有のパラメータファイルを用いないよう注意しなければならない。

大文字および小文字の区別
一実施例に従うと、ＭｙＳＱＬはデータベース名をディレクトリ名として、およびテーブル名をファイル名としてマッピングする(.frmファイルはテーブルについてのメタデータを保持する）。大文字および小文字によって区別されるテーブル名は、ＭｙＳＱＬが実行される下地となるオペレーティングシステムに依存する。ＭｙＳＱＬはウインドウズ（登録商標）プラットフォームにおいて大文字小文字が混合しているテーブル名を区別せず、UNIX（登録商標）プラットフォームのほとんどの種類において大文字小文字の区別をする。

文字設定サポート
一実施例に従うと、ＭｙＳＱＬはCHAR、VARCHAR、 TEXT およびENUMカラムタイプ用にUNICODE文字セットをサポートする。ＭｙＳＱＬはそのストリングカラムについてＵＴＦ８およびＵＴＦ１６（ｕｃｓ２）符号化の両方をサポートする。UNICODE文字セットでは、データはＵＴＦ１６値としてトレールファイルに記憶されなければならない。ストリングカラム用のＵＴＦ８符号化の場合、ＭｙＳＱＬＶＡＭモジュール、初期ロードモジュール、およびアプライ側モジュールは、内部変換ライブラリを用いてデータをＵＴＦ１６値に（またはから）変換する。ＭｙＳＱＬはNCHAR, NVARCHARカラムタイプをサポートする。これらは、ＵＴＦ８文字セットを有するカラムとして内部的にマッピングされる。ＭｙＳＱＬキャプチャは、最初のリリースから、ＵＴＦ８およびＵＳＣ２文字セットをサポートする。一実施例に従うと、ＭｙＳＱＬキャプチャおよびアプライモジュールはUNICODE文字セットで認定されている。

付加的構成要件
一実施例に従うと、ＭｙＳＱＬＶＡＭは環境変数‘MYSQL_HOME’が正しく設定されることを必要とする。この変数は、ＭｙＳＱＬデータベースの設置場所を示さなければならない。ＭｙＳＱＬＶＡＭはこの変数を用いてＭｙＳＱＬ構成ファイルを検索する（ウインドウズ（登録商標）プラットフォームではｍｙ．ｉｎｉであり、ウインドウズでないプラットフォームではｍｙ．ｃｏｎｆである）。さらに、以下のパラメータがＭｙＳＱＬ構成ファイルの中に設定されなければならない（ｍｙ．ｉｎｉまたはｍｙ．ｃｏｎｆ）：「ログービン」パラメータを用いてバイナリロギングを能動化する−このオプションの値はログファイル用のディレクトリ場所を特定する；‘binlog_format’パラメータを用いてログフォーマットを指定する−これはＲＯＷモードとしてのみ構成されるべきである。‘MIXED’ および‘STATEMENT’モードはサポートされていない。たとえば：

この例では、ログファイルの名前は‘test.00001, test.00002’などで作成される。これらのファイルは“c:/MySQL/MySQL Server 5.1/log”ディレクトリに記憶される。

ＭｙＳＱＬＣ＋＋クラスの直接使用
ＭｙＳＱＬは外の世界に対して利用可能な十分に規定されたログＡＰＩを持たないが、バイナリログの内容を写す十分に定義されたファイルアクセスIO_CACHEクラスおよびイベントクラス（Ｃ＋＋で公開）を有する。ＭｙＳＱＬはログイベントについて別個の読出および処理を有する。内部IO_CACHEクラスはバイナリログデータをかたまりとしてオンデマンドで読出す（ディスクＩＯオーバーヘッドを避けるために、最小６４ｋサイズ）。これらクラスにより、ＡＰＩはこのブロックから読出することができる。処理側では、ＭｙＳＱＬはデータをイベント特有のＣ＋＋クラスの型に変換するために用いることができるイベントクラスを有する。この公的に利用可能なＭｙＳＱＬクラスは以下の欠点を有する：IO_CACHEクラスはメモリへの１回のショットでバイナリログイベントデータを読出す（サイズが６４ｋを超えた場合）。より大きいデータを含むイベント（たとえば、サイズが２ＧＢであるＬＯＢデータ）では、これは問題となり得る；IO_CACHEクラスは自己でｐｔｈｒｅａｄ特有機能を再度実施する。これはＭｙＳＱＬＶＡＭがextractモジュールでリンクする際、一連のリンカーエラー（再定義）を発生させる。

一実施例に従うと、ＭｙＳＱＬＶＡＭはIO_CACHEクラスおよびイベントプロセッサクラスの両方を再度実施することができる。これはバイナリログをアクセスするＭｙＳＱＬＶＡＭに完全な制御を与える。さらに、これはリンカーエラー、より大きいＬＯＢデータフェッチング(fetching)およびＭｙＳＱＬ特有ソースコードファイルまたはヘッダファイルの依存といった問題を緩和する。

一実施例に従うと、ＭｙＳＱＬＶＡＭは処理イベント用にＣ＋＋クラスを再度実施し、バッファIO読出用にIO_CACHEクラスを使用することができる。このアプローチは、ＭｙＳＱＬソースコードが、たとえばGoldenGate作成環境にいなければならないという依存性を減らす。このアプローチはさらにＭｙＳＱＬＶＡＭがどのようにイベントデータを処理するかについての完全な制御を与える。頻繁に用いられるイベント状況も同様にリサイクルすることができる。

一実施例に従うと、ＭｙＳＱＬＶＡＭはＭｙＳＱＬに特有のイベントクラスおよびIO_CACHEクラスを用いてバイナリログをアクセスすることができる。ＭｙＳＱＬＶＡＭクラスは、ＭｙＳＱＬＶＡＭに特有の必要な機能を提供するために、イベントクラスから受け継ぐ必要がある。

符号付きまたは符号のない整数
ＭｙＳＱＬは符号付きまたは符号なし（デフォルトは符号付き）のいずれかで定義される整数カラムをサポートする。たとえば、２バイトの符号付き整数カラムは、−３２ｋから＋３２ｋの値をサポートし、符号がないものは０から＋６４ｋをサポートする。バイナリログは、数値カラムの符号について、すなわちそのカラムが符号付きまたは符号なしモードを支持しているのなら、メタデータを返さない。２つの設計上のアプローチが可能である：常に符号付きの値を返す、−ターゲット側でreplicatはカラムの種類に基づき変換を行なう；またはextractからＭｙＳＱＬカラムのメタデータを得て、extractするために正しい値を返す。一実施例に従うと、ＭｙＳＱＬＶＡＭは数値を符号付きの値としてＭｙＳＱＬＶＡＭＡＰＩに返す。

シーケンスＩｄによる位置付け
一実施例に従うと、バイナリログの中では、ＭｙＳＱＬイベントはそのヘッダ部に場所値を有する。この値の寿命はバイナリファイルに特有である。すなわち、この場所値は所与のバイナリファイル内では固有のものであり得るが、バイナリファイルの外では固有ではない。２つの異なるバイナリファイルにおける２つの異なるイベントは同じ値を有し得る。場所によってトランザクションレコードを固有に識別するためには、ＭｙＳＱＬＶＡＭはこのイベント場所値をログファイル名と結合する。たとえば、‘binlog.00054:123’では、‘binlog.00054’はバイナリログの名前であり、１２３はトランザクションレコードの場所である。ＭｙＳＱＬＶＡＭはGG_ATTR_DS_SEQIDを用いてこの値をＡＳＣＩＩストリング属性として送る。

一実施例に従うと、再スタートシナリオの際、extractはこの最後に受取られたシーケンスＩｄ値をMYSQL VAMIntialize()コールの際にＭｙＳＱＬＶＡＭに送る。ＭｙＳＱＬＶＡＭはこの値を用いて正しい読出場所を設定する。ＭｙＳＱＬＶＡＭはこのシーケンスＩｄをextractから解析し、ログファイル名およびイベント場所を得る。次に、対応するログファイルを開き、イベントのスキャンを開始する。イベントの場所がシーケンスIdで特定されているものと一致すると、ＭｙＳＱＬＶＡＭはこの場所を現行の読出場所として設定し、この場所からバイナリログ内容の読出を開始する。

トランザクションＩＤ
ＤＭＬ操作を表わすイベントでは、ＭｙＳＱＬはトランザクションＩｄをイベントデータの一部として持たない。したがって、ＭｙＳＱＬＶＡＭはこのトランザクションＩｄ（固有のもの）をＭｙＳＱＬＶＡＭＡＰＩに送るための方法が必要である。一実施例に従うと、この問題を解決するために、ＭｙＳＱＬＶＡＭＡＰＩは‘START Transaction’ステートメントのシーケンスＩｄをトランザクションＩｄとして扱う。このシーケンスＩｄは、ログファイル名＋ファイル内のイベントオフセットの組合せであるので、トランザクションＩｄの固有性は複数のログファイル間で保証される。さらに、ＭｙＳＱＬＶＡＭはこの擬似トランザクションＩｄを内部で維持し、この値を特定のトランザクション内のすべてのＤＭＬステートメントに対してＭｙＳＱＬＶＡＭＡＰＩに送る。ＭｙＳＱＬＶＡＭは「コミット」または「ロールバック」ステートメントに出くわすと、この値をクリアする。

ＬＯＢデータへのアクセス
ＭｙＳＱＬバイナリログにおいて、ＬＯＢカラム値は他の非ＬＯＢカラム値とインラインで記憶される。これは他のデータベースと異なる。なぜなら、値はインラインでストアされず、データがオンデマンドでフェッチ(fetch)することができるロケータまたはクーポンを用いてアクセスされないからである。ＭｙＳＱＬデータベースの場合では違う（ストレージエンジンMyISAM およびInnoDBを有する）。バイナリログからＬＯＢカラム値を読出すため、ＭｙＳＱＬ内部IO_CACHEクラスは、ログファイルからこのＬＯＢカラム値の全体の値をフェッチしてメモリに渡す、すなわち、メモリはこのクラスにより１回でこのＬＯＢカラム用に完全に割当てられる。

一実施例に従うと、ＭｙＳＱＬＶＡＭＡＰＩはより大きいサイズのＬＯＢデータは塊でＭｙＳＱＬＶＡＭＡＰＩに送られるべきであるという仕様概要を与える。しかし、ＭｙＳＱＬの場合、データは既にＭｙＳＱＬ内部クラスで完全に既にフェッチされている（すなわち、メモリはIO_CACHEオブジェクトによって完全に割当てられており）、ＬＯＢデータは３２ｋバイトのサイズの塊で、１つのコールや複数のコールで、ＭｙＳＱＬＶＡＭＡＰＩに送ることができる。一実施例に従うと、上記のように、ＭｙＳＱＬのIO_CACHEクラスはＬＯＢデータの全体の値を他のローデータとともに、ワンショットでフェッチする。これは、ＬＯＢのサイズが２ＧＢである場合問題となる。１つの方法は、ＭｙＳＱＬＶＡＭがデータを塊でファイルから読出すことができるよう、IO_CACHEクラスの実施を書き直すことである。GoldenGate（あれば）から既存のファイルマネージャライブラリを用いることができる。一実施例に従うと、システムはIO_CACHEクラスを使用し、ログデータを塊でＭｙＳＱＬＶＡＭＡＰＩに送る。

一実施例に従うと、ＭｙＳＱＬＶＡＭ実施は、バイナリログファイルを読出すために、IO_CACHEクラスを使用することができる。ＬＯＢデータ制限を除き、IO_CACHEクラスはうまく他のＭｙＳＱＬデータの読出を扱う。さらに、ＬＯＢデータを２ＧＢのサイズで処理することは実質的に珍しい（または滅多にない）。ＬＯＢカラムの内部記憶機構と無関係に、ＭｙＳＱＬＶＡＭＡＰＩが必要ならページアウトできるよう、ＭｙＳＱＬＶＡＭはＬＯＢデータを塊でＭｙＳＱＬＶＡＭＡＰＩに返すべきである。

ＯＧ処理およびＭｙＳＱＬＶＡＭＡＰＩ通信
一実施例に従うと、ＭｙＳＱＬＶＡＭ実施は２つの部分に分割することができる：第１の部分はＬＯＧデータをバイナリログから読出し、データを準備し、データをＭｙＳＱＬＶＡＭＡＰＩ用に用意する−これは別のスレッドで実行される；第２の部分は用意ができたデータ（レコード）をリクエスト毎にＡＰＩに送る。この従来の設計での主な欠点は、すべて（完全な処理）はＭｙＳＱＬＶＡＭＡＰＩがリクエストした場合にしか起こらないことであり、ＭｙＳＱＬＶＡＭモジュールが処理を完了するのに何らかの実行時間を必要とする。この間、ＭｙＳＱＬＶＡＭＡＰＩはアイドル状態にあり、ＭｙＳＱＬＶＡＭのパフォーマンスを低下させる。設計を２つの部分に分割することにより、ＭｙＳＱＬＶＡＭＡＰＩのアイドル時間がなくなる。第１の部分が独立してバイナリログを読出す間、システムはＡＰＩに送るべきデータの準備を行ない、制限されたサイズQueue（キュー）に記憶する。次に、第２の部分はQueueから用意ができたレコードをフェッチし、ＭｙＳＱＬＶＡＭＡＰＩ側からリクエストが来ると直ちにＭｙＳＱＬＶＡＭＡＰＩに送る。

アーキテクチャ設計
上記のように、一実施例に従うと、ＭｙＳＱＬＶＡＭモジュールの全体のアーキテクチャは以下を含む：
ＭｙＳＱＬライブラリ−ファイルリーダ、ファイルCACHE、データ変換クラスを与えるライブラリ。

ＭｙＳＱＬＶＡＭイベントクラス−ＭｙＳＱＬバイナリログからイベントを処理するＭｙＳＱＬＶＡＭのインハウス実施。

ＭｙＳＱＬＶＡＭバイナリログクラス−ＭｙＳＱＬライブラリをラップアラウンドするクラス、ＭｙＳＱＬＶＡＭイベントクラス。現行のバイナリログを開き、イベントを読出し、ＭｙＳＱＬＶＡＭレコードに変換し、ログ回転を処理するなど。

ＭｙＳＱＬＶＡＭリーダ、プロセッサクラス−ビンログクラスからレコードを読出しおよび処理し、レコードキューに入れるクラス。これらクラスはextractコールによりブロックではなく自己の専用スレッドを有する。

レコードキュー−後でMYSQL VAMRead ()コールによって使われるためにレコードを保持するキュー。

ＭｙＳＱＬＶＡＭレコードクラス−レコードキューからデータを読出し、ＭｙＳＱＬＶＡＭＡＰＩを用いてextractに送るクラス。

Extractプロセス−ＭｙＳＱＬＶＡＭＡＰＩからデータをキャプチャするためにコンパイルされた標準のGoldenGateextractプロセス。

バイナリログ構造およびログイベント
図５は一実施例に従うと、ＭｙＳＱＬバイナリログでのイベント順序を示す。一実施例に従うと、ＭｙＳＱＬはデータをイベント入力としてバイナリログ内に記憶する。ＭｙＳＱＬは、ＳＱＬステートメントおよび操作の性質に基づき、さまざまなイベントをサポートする。ＭｙＳＱＬはイベントデータを読出すためにＣ＋＋クラスを与える。一般に、バイナリログ構造は以下のイベント入力を含む：
１．４バイトの魔法数で始まる。これは"＼xfe＼x62＼x69＼x6e"の値を有する定数BINLOG_MAGICとして定義される。この値は無視することができる。

２．次の入力はフォーマット記述イベントである。このイベントは所与のバイナリログファイルにわたって包括的である。ＭｙＳＱＬはこのイベントを各バイナリログ毎に１回しか書込まない。このイベントは現行のバイナリログが使用されているかまたは正しく閉じられたかを追跡する。

３．一連のイベントが続く残りの入力は、図５に示される。
一実施例に従うと、ＭｙＳＱＬＶＡＭはバイナリログイベントのサブセットに興味を持つ。たとえば、ＭｙＳＱＬＶＡＭはトランザクション、ＤＭＬステートメントデータ、ログ回転などを表わすバイナリログイベントに興味を持つ。表３は、一実施例に係わる、ＭｙＳＱＬＶＡＭが興味を持つＭｙＳＱＬイベントのリストを示す。

イベント構造
図６は一実施例に従うイベントヘッダ構造を示す。すべてのイベントは汎用ヘッダ部と後に続くデータ部とを有する。一部のイベントは、任意のデータヘッダ部を有する。イベント構造は一般に次のように表わされる。

１．イベントヘッダ‐構造のサイズは１９バイトである。この部分は、すべてのイベントに汎用的である以下のイベント特有データを含む。

４バイト−イベントのタイムスタンプ。１９７０年の開始からの秒数。
１バイト−イベントのタイプコード。タイプコードの対象の値および意味は次のとおりである： QUERY_EVENT= 2; STOP_EVENT= 3; ROTATE_EVENT= 4; FORMAT_DESCRIPTION_EVENT= 15; XID_EVENT= 16; TABLE_MAP_EVENT = 19; WRITE_ROWS_EVENT = 23; UPDATE_ROWS_EVENT = 24; DELETE_ROWS_EVENT = 25。

４バイト−サーバＩＤ。レプリケーションピア間でサーバを一意に識別。ＭｙＳＱＬＶＡＭはこの値を無視する。

４バイト−ヘッダを含むイベント全体の長さをバイトで表わす。
４バイト−ログにおけるイベントのオフセットをバイトで表わす。この値はＬＳＮまたはシーケンス番号に類似している。

２バイト−イベントフラグ。ＭｙＳＱＬＶＡＭはこの値を無視する。
このイベントヘッダは、CLogEvent C++クラスによって表わされる。すべてのバイナリログ系イベント特有Ｃ＋＋クラスはこのクラスから継承する。このクラスの構造は以下のように表わされる：

２．データヘッダ−構造のサイズは８バイトである。変数データを含むイベント（たとえば、テーブルマップイベント、書込ローイベントなど）はこの部分を含む。この部分は、以下を含む
６バイト−テーブル＿ｉｄを含む。これは、テーブルバージョンとして扱うことができる。ＭｙＳＱＬＶＡＭはこの値を用いて、下地のテーブルメタデータが変更されたか否かをチェックする。

２バイト−データヘッダフラグ。ＭｙＳＱＬＶＡＭはこの値を無視する。
３．データ部−イベント特有データを保持する。たとえば、書込ローイベント用のカラム値のシーケンス、テーブルマップイベント用のカラムメタデータ。より詳細については、次の箇所参照。

イベントデータ部
一実施例に従うと、イベントデータ部はイベント特有データを保持する。データ部のサイズは動的である。すなわち、イベントの種類に応じて値は異なりかつ特定的であり、データの変数リストを保持する。次の箇所は、ＭｙＳＱＬＶＡＭが興味を持つイベントタイプのイベントデータ部の構造を説明する。

クエリーイベント
一実施例に従うと、このイベントはＳＱＬクエリーを表わす。このイベントは、ＭｙＳＱＬ内部Ｃ＋＋クラス‘CQueryEvent’によって表わされる。このイベントのデータ部は、データベース名、クエリーストリング値、および他の情報を含む。ＭｙＳＱＬＶＡＭはCQueryEventイベントを用いて、以下のメンバー変数を使ってこれらの値を引出す：

ＭｙＳＱＬの‘BEGIN Transaction’および‘ROLLBACK Transaction’ならびに‘Truncate’ステートメントは、このCQueryEventクラスによって表わされる。これらのステートメントについて、メンバー「クエリー」は、“BEGIN”または“ROLLBACK”または“TRUNCATE table_name”といった値を含む。ログからこれらのステートメントをフィルタ処理するために、通常のストリングを用いることができる。

ＸＩＤ＿イベント
一実施例に従うと、このイベントはトランザクションのコミットを表わす。このイベントは、ＭｙＳＱＬ内部Ｃ＋＋クラス‘CXidEvent’によって表わされる。このイベントのデータ部は、ＭｙＳＱＬＶＡＭが無視する２相コミットトランザクションのトランザクションｉｄを含む（ＭｙＳＱＬレプリケーションもこの値を無視する）。ＭｙＳＱＬＶＡＭはこのイベント入力を用いてトランザクションがコミットされ、トランザクション特有オブジェクトと切離されていることと見なす。

テーブルマップイベント
一実施例に従うと、このイベントはトランザクションに係わる（ＤＭＬステートメントによって）テーブルのメタデータを表わす。このイベントは、書込、更新および削除ローイベントといったＤＭＬ操作を表わすイベントより先に来る。たとえば、簡単な挿入操作はバイナリログにおいて２つの入力を引き起こす。最初の入力は、テーブルメタデータを含む「テーブルマップイベント」であり、次の入力はINSERT操作の一部として加えられるローデータを含む「書出ローイベント」である。汎用ヘッダ部とは別に、このイベントは付加的データヘッダ部＋データ部を含む。（８バイトの）データヘッダ部は、以下のデータを含む：table_id：６バイト長−テーブルのメタデータ変更を追跡し；およびフラグを立てる：ＭｙＳＱＬＶＡＭはこのフラグを無視することができる。

所与のテーブルの時間テーブルマップイベントの大部分は、下地のテーブル構造が同じままであるのなら、変更されずに残る。バイナリログは同じテーブルマップイベントの複数の入力を含むが、これらを一度に処理して、後で再度用いる方がよい。これは、読出バイナリログのパフォーマンスの速度を上げる。Table_map_log_eventログクラスのインスタンスを記憶するのにハッシュテーブルを用いるのがよく、さらに処理するためにテーブル名を用いて後で引出すことができる。

データ構造が変更された場合（「テーブル変更…」ステートメントを使用）、ＭｙＳＱＬは同じテーブルに対して新しいテーブルidを作成する。ＭｙＳＱＬはテーブルidの履歴を記憶しない。バイナリログを読出す際にテーブルメタデータを変更する場合、ＭｙＳＱＬは次のように扱う。１）プロセスをアベンドする。２）ＭｙＳＱＬＶＡＭは付加的処理のために変えられた（最新の）テーブル定義を用いる。一実施例に従うと、ＭｙＳＱＬＶＡＭは所与のテーブル名について既存のテーブルｉｄをチェックし、異なれば、これはテーブルメタデータの変更として見なされ、ＭｙＳＱＬＶＡＭはextractにアベンドすることを知らせることができる。

テーブルマップイベントのデータ部は、以下のテーブルメタデータ情報を含む：
１バイト−データベース名の長さ。

ｎバイト−データベースネーム＋ｎｕｌｌ終了文字が続く。
１バイト−テーブル名の長さ。

ｎバイト−テーブル名＋ｎｕｌｌ終了文字が続く。
ｎバイト−カラム数。カラム数が２５５バイト以下である場合は１バイトであり、それ以外は２バイトである。

ｎバイト−テーブルの各カラムのタイプを記憶し、左から右側に示される。各バイトはＭｙＳＱＬ内部カラムタイプにマッピングされる。

ｎバイト−フィールドメタデータのサイズ。より詳細については、フィールドメタデータ部（次の箇所）参照。

ｎバイト−フィールドメタデータ値。より詳細については、フィールドメタデータ部（次の箇所）参照。

ｎバイト−ｎｕｌｌカラムビットであり、直近のバイトに切上げられる。各カラムについて、そのカラムのデータがｎｕｌｌであり得るか否かを示すビット。これに必要なバイト数はint((column_count+7)/8)である。左から最初のカラムのフラグは、第１のバイトの最下位ビットにあり、２番目は第１のバイトのつぎの最下位ビットにあり、９番目は第２バイトの最下位ビットにある、など。

フィールドメタデータ
図７は、一実施例に従うフィールドメタデータを示す。フィールドメタデータは一般にカラムメタデータのサイズに関連する付加的情報を表わす。これはパック長として扱うことができる、すなわち特定のカラム値を圧縮するのに必要な合計バイト数。これらの値は後で用いられて、実際の値を得るために適切なバイトを読出すために用いられる。固定長のカラムタイプ（たとえば、整数、日付など）については、このフィールドメタデータは通常ゼロである。たとえば、VARCHARのカラムタイプでは、このフィールドメタデータはVARCHARカラムの最大サイズを表わす。表４は異なるカラムタイプに対するフィールドメタデータ部の内容を示す。

‘MEDIUM BLOB’タイプのブロブカラムを有するテーブルがあるとする。ブロブカラムの最大サイズは１６７７７２１６バイト（１６ＭＢ）であり得る。このサイズは通常３バイト必要である。このテーブルに簡単な挿入操作が行なわれる。この挿入操作はバイナリログに、テーブルマップイベント(Table Map Event)、および書込ローイベント(Write Rows Event)を作成する。バイナリログは、書込ローイベント部にBLOBカラムおよび実際のBLOBデータを記憶する。このBLOBデータを検索するためには、ＭｙＳＱＬＶＡＭは以下のステップを行なわなければならない：
１．ＭｙＳＱＬＶＡＭはこのBLOBカラムの長さを計算するのに必要なバイト記憶領域を知る必要がある（この例では、１６７７７２１６の長さを記憶するのに３バイト必要である）。この値は、‘テーブルマップイベント’の‘フィールドメタデータ(field metadata)’部から引出される。

２．上記の値に基づき、実際のデータ長を特定するために、ＭｙＳＱＬＶＡＭは‘書込ローイベント’から実際のローデータ値の最初の１つまたは２つまたは３つまたは４つのバイトを読出す。この場合、ＭｙＳＱＬＶＡＭはBLOBデータの実際の長さ値を得るために最初の３バイトを読出さなければならない。

３．ＭｙＳＱＬＶＡＭは実際の長さに基づき十分なメモリを割当て、バイナリログからデータをコピーする。

‘テーブルマップイベント’から、BLOBカラムに必要な最大カラムバイトストアを得る。これによって、３が返される。

column_max_datasize = uint2korr(m_field_metadata);
上記の値は‘書込ローイベント’から実際のデータを得るために用いることができる。

以下の例はテーブル′ｔ１′のテーブルマップイベントのバイトシーケンス順序を示し、データベース′テスト（ｔｅｓｔ）′は以下のように記述される：

図８は一実施例に従うテーブルマップイベント構造のテーブルを示す。テーブルマップイベントはＣ＋＋クラス‘CTableMapEvent’によって表わされ、そのクラス構造は以下のとおりである：

書込ローイベント
図９は一実施例に従う書込ローイベント構造を示す。このイベントはＭｙＳＱＬINSERT操作を表わす。このイベントの前に、テーブルマップイベントが来る。汎用ヘッダ部とは別に、このイベントは付加的データヘッダ部＋データ部を含む。（８バイトの）データヘッダ部は以下のデータを含み、これはより古いテーブルマップイベントと類似している。

table＿id：６バイト長。これはより古いテーブルマップイベントのtable＿idと比較できるが、あまり役に立たない。ＭｙＳＱＬＶＡＭはこの値を無視する。

flags：ＭｙＳＱＬＶＡＭはこのフラグを無視することができる。
書込ローイベントのデータ部は、カラムの順序に基づき配置されるカラム値を含む。書込ローイベントはCWriteRowsEventクラスによって表わされる。データ部は以下の情報を含む：
１または２バイト−カラムの数を記憶する。ＭｙＳＱＬがサポートしている最大カラム数は３３９８である。

ｎバイト−カラムビットマップ。これはＭｙＳＱＬレプリケーションで用いられる内部データ構造である。ＭｙＳＱＬＶＡＭは通常この値を無視する。サイズは((no_of_cols+7)/8) である。

ｎバイト−（リトルエンディアンオーダ）でｎｕｌｌカラム値を示す。総合サイズは通常((no_of_cols+7)/8)である。左から最初のカラムのフラグは、第１のバイトの最下位ビットにあり、２番目は第１のバイトのつぎの最下位ビットにあり、９番目は第２バイトの最下位ビットにある、など。

ｎバイト−挿入値のバイトシーケンス。可変カラム値（たとえばVARCHAR, LOB, CHARタイプ)の前にはその長さがくる。

以下の例は、テーブルｔ２の書込ローイベントのバイトシーケンス順序を示す。

更新ログイベント
図１０は一実施例に従う、更新ローイベント構造を示す。このイベントはＭｙＳＱＬＵＰＤＡＴＥ操作を表わす。このイベントの前に、テーブルマップイベントが来る。汎用ヘッダ部とは別に、このイベントは付加的データヘッダ部＋データ部を含む。（８バイトの）データヘッダ部は以下のデータを含み、これはより古いテーブルマップイベントと類似している。

table＿id：６バイト長。これはより古いテーブルマップイベントのtable＿idと比較できる。flags：ＭｙＳＱＬＶＡＭはこのフラグを無視することができる。

更新ローイベントのデータ部は、カラムの順序に基づき配置されるカラム値を含む。更新ローイベントは、事前画像および事後画像データ値を含む。他のロギングシステムと違って、ＭｙＳＱＬバイナリログは単にプライマリキーや更新されたカラムを記憶するのではなく、カラム値の全体のコピー（事前画像値および事後画像値の両方）を記憶する。たとえば、１００カラムを含むテーブルで１つのカラムを更新すると、１００カラム値の事前画像コピーおよび同じ１００カラムの事後画像コピーが作成される。ＭｙＳＱＬＶＡＭがデータをＭｙＳＱＬＶＡＭＡＰＩ（extract）に送る前にデータを圧縮（またはフィルタ処理）することが重要である。更新ローイベントはCUpdateRowsEventクラスによって表わされる。データ部は以下の情報を含む：
１または２バイト−カラムの数を記憶する。ＭｙＳＱＬがサポートしている最大カラム数は３３９８である。

ｎバイト−カラムビットマップ。これはＭｙＳＱＬレプリケーションで用いられる内部データ構造である。ＭｙＳＱＬＶＡＭは通常この値を無視する。サイズは((no_of_cols+7)/8)である。

ｎバイト−事後画像カラムビットマップ。これはＭｙＳＱＬレプリケーションで用いられる内部データ構造である。ＭｙＳＱＬＶＡＭは通常この値を無視する。サイズは((no_of_cols+7)/8)である。

ｎバイト−事前画像データ用に（リトルエンディアンオーダ）でｎｕｌｌカラム値を示す。総合サイズは通常((no_of_cols+7)/8)ビットである。

ｎバイト−事前画像データ用の値のバイトシーケンス。可変カラム値（たとえばVARCHAR、LOB、CHARタイプ)の前にはその長さがくる。

ｎバイト−事後画像データ用に（リトルエンディアンオーダ）でｎｕｌｌカラム値を示す。総合サイズは通常((no_of_cols+7)/8)ビットである。

ｎバイト−事後画像データ用の値のバイトシーケンス。可変カラム値（たとえばVARCHAR、LOB、CHARタイプ)の前にはその長さがくる。

ロー削除イベント
このイベントはＭｙＳＱＬＤＥＬＥＴＥ操作を表わす。このイベントの前にテーブルマップイベントが来る。汎用ヘッダ部と別に、このイベントは付加的データヘッダ部プラスデータ部を含む。（８バイトの）データヘッダ部は以下のデータを含み、これはより古いテーブルマップイベントと類似している。ロー削除イベントはCDeleteRowsEventクラスによって表わされる。

table＿id：６バイト長。これはより古いテーブルマップイベントのtable＿idフラグと比較できる、flags：ＭｙＳＱＬＶＡＭはこのフラグを無視することができる。

ロー削除イベントのデータ部は、カラムの順序に基づき配置されるカラム値を含む。
データ部は、書き込みローイベントデータ部と類似している。

CRowsLogEvent C++ クラス
CWriteRowsEvent、CUpdateRowsEvent およびCDeleteRowsEvent C++ classesはCRowsLogEvent C++クラスから継承する。このクラスはINSERT、UPDATE およびDELETE操作用にログデータを検索するのに特有の一般的操作の大部分を含む。

回転イベント
回転イベントは可能なログ回転を示すバイナリログにログされる。すなわち、ＭｙＳＱＬサーバは現行のバイナリログを閉じて新しいものを開く。ログ回転の可能なシナリオは以下のとおりである：
１．ログファイルのサイズは‘max_binlog_size’パラメータを超えている。

２．ＭｙＳＱＬコマンドコンソールから、明白な‘flush logs’コマンドが発行された。

どちらの場合でも、ＭｙＳＱＬは現行のバイナリログに回転イベントを作成し、現行のバイナリログを閉じて、付加的処理用に新しいバイナリログを開く。回転イベントは、作成するべき新しいログファイルを含む。ＭｙＳＱＬＶＡＭはこの値を用いて既存のバイナリログファイルを閉じて、新しいバイナリログファイルを開き、読出しを続ける。回転イベントはCRotateEventＣ＋＋クラスによって表わされ、以下のとおり定義される：

ストップイベント
ＭｙＳＱＬサーバはシャットダウンが明確な場合、バイナリクラスにストップイベントをログする。後でＭｙＳＱＬがスタートさせると、新しいバイナリログファイルが作成される。ストップイベントは新しいバイナリログファイル用の入力を含まない。

イベント順序
図１１は一実施例に従うイベント順序例を示す。この部分は、異なるシナリオ用にバイナリログのイベント順序を示す。さまざまなトランザクションシナリオについては、「イベント順序」の箇所参照。一例として、以下のステートメントをバイナリログファイルに記憶することができる：

図１２は一実施例に従う別のイベント順序例を示す。一例として、以下のステートメントをバイナリログファイルに記憶することができる：

データタイプ
この部分はさまざまなサポートされているデータタイプおよびバイナリログ内のストレージ要件を説明する。ＭｙＳＱＬはいくつかのカテゴリにおいて複数のデータタイプをサポートしている：数値型、日時型およびストリング（文字）型。各タイプは１組のバイトとして、ログレコード内に記憶される。用いられるバイト数は、データのタイプ、カラムがＮＵＬＬ可能であるか否か、およびフィールドの長さに依存する。可変長文字フィールド（たとえばVARCHAR、VARBINARY、CHAR、TEXT およびBLOBなど）の前にその長さが来る。

データタイプCHAR、VARCHARおよびTEXTはｕｃｓ２（１文字当たり最大２バイト）フォーマットまたはｕｔｆ８フォーマット（１文字当たり２または３バイト）で記憶することができる。たとえば、VARCHAR（２５５）カラムは、最大２５５文字の長さのストリングを保持することができる。カラムはlatin１文字セット（１文字当たり１バイト）を用いると仮定すると、必要な実際の記憶領域は、ストリング長さプラスストリングの長さを記録するための１バイトである。′ａｂｃｄ′のストリングでは、Lは４であり、記憶領域要件は５バイトである。同じカラムがｕｃｓ２ダブルバイト文字セットを用いるとされるのなら、記憶領域の要件は１０バイトである。′ａｂｃｄ′の長さは８バイトであり、カラムは長さを記憶するのに２バイトを必要とする。なぜなら、最大長は２５５より大きいからである（５１０バイトまで）。

一実施例に従うと、ＬＯＢフィールドはインラインに記憶される。ＬＯＢフィールドの前にはその長さが来る。サポートされているデータタイプおよびそのログサイズは表５に記載されている。

ｎｕｌｌ値の取扱い
一実施例に従うと、バイナリログローイベント（すなわちWriteRowsEvent、UpdateRowsEvent およびDeleteRowsEvent）は他の非ＮＵＬＬカラム値とともにはＮＵＬＬカラム値を記憶しない。ＮＵＬＬカラム値は、データ部の前にＮＵＬＬバイトの組として記憶される。ＮＵＬＬバイトの合計数は通常(カラム数+7)/8である。より詳細にはWriteRowsEvent（todo）参照。

ＮＵＬＬカラムは、リトルエンディアンオーダとしてこれらＮＵＬＬバイト部に記憶される。左から最初のカラムのフラグは、第１のバイトの最下位ビットにあり、２番目は第１のバイトのつぎの最下位ビットにあり、９番目は第２バイトの最下位ビットにある、など。カラムがＮＵＬＬ値を保持しているか否かを見つけるために、ＮＵＬＬバイトの各ビットをマスクすることができる。以下のコードは、カラムがＮＵＬＬであるか否かをチェックする：

空のストリングは、ゼロ長値としてバイナリログに記憶される。
データタイプ変換
一実施例に従うと、CHAR、BINARY、VARCHARおよびVARBINARYタイプ−ストリングデータタイプの長さは可変である。実際のデータ値の前にデータ長が来る。長さの値は１バイト（長さが２５５未満の場合）または２バイト（長さが２５６以上の場合）を必要とする。

上記のように、ストリングカラムの‘フィールドメタデータ（fieldmetadata）’（CHAR、VARCHAR、BINARYおよびVARBINARYタイプタイプに当てはまる）は、長さの最大値を見つけるのに役立つ。この値に基づき、実際の長さは以下のように検索することができる。

uint2korr（）関数はconfig_win.hで規定されるＭｙＳＱＬ提供マクロである。この関数は所与のポインタの最初の２バイトを読取り、対応する整数値を返す。

ＥＮＵＭタイプ
一実施例に従うと、ＥＮＵＭカラムはログファイルにおいてインデックス値として記憶される。たとえば、ＥＮＵＭ（「赤」、「オレンジ」、「青」）のカラムでは０、１および２のインデックス値を有することができる。したがって、「オレンジ」のＥＮＵＭ値を記憶すると、バイナリログファイルではインデックス値２となる。サポートされる最大列挙インデックス値は６５，５３５バイトである。

ＥＮＵＭカラムタイプのフィールドメタデータは、ＥＮＵＭインデックス値に必要な最大バイトを含む。この値に基づき、実際の長さは以下のように読出すことができる。

ＳＥＴタイプ
一実施例に従うと、ＳＥＴカラムは０またはより大きい値を有することができるストリングカラムであり、各々はテーブルを作成した場合に指定される許容値のリストから選択されなければならない。たとえば、ＳＥＴ（「１」、「２」）と指定されたカラムは、「１」「２」、「１，２」のいずれかの値を有することができる。ＳＥＴは最大６４個の異なるメンバーを有することができる。セットカラムはログファイルにおいてバイナリ値として記憶される。たとえば、SET('a','b','c','d')として指定されるカラムでは、メンバーは以下の１０進数および２進数の値を有する：

したがって、SET('a','b')を記憶すると、３の１０進数の値をもたらす（すなわち、２進数では００１１）。ＳＥＴカラムは最大６４個の異なるメンバーを有することができるので、これらの値を記憶するのに要する最大バイトは最大８バイトとなる。ＳＥＴカラムタイプのフィールドメタデータは、ＳＥＴ１０進数に必要な最大バイトを含む。この値に基づき、実際の長さは以下のように取出すことができる：

整数タイプ
一実施例に従うと、整数値はバイナリログにおいて符号付きおよび符号なしの整数として記憶される。整数は符号付きの整数として読取られ、ＭｙＳＱＬＶＡＭによってextractに送られる。整数のＣタイプは、整数カラムのサイズに依存し、これは長さによって定められる。ＭｙＳＱＬではサイズに基づきすべての整数変形にはＣタイプが規定され、関連するマクロを有して、メモリ場所をプラットフォームとは独立している整数値にコピーする。表７は各長さおよび関連するマクロで使用するタイプを示す。

整数値は指定サイズの整数としてGoldenGateＭｙＳＱＬＶＡＭに返すことができるので、データ変換には適切なマクロを用いることだけが必要であり、変換された整数および長さを整数データとして返す。

浮動小数点、倍精度および１０進数タイプ
一実施例に従うと、浮動小数点データタイプには、ＭｙＳＱＬは単精度値には４バイト、倍精度値には８バイト使用する。ＭｙＳＱＬは非標準シンタックス: FLOAT(M,D)またはDOUBLE (M,D)を可能にする。ここで(M,D)は値が合計Ｍ桁まで記憶できることを意味し、そのうちＤ桁は小数点の後ろに来てもよい。ＭｙＳＱＬは浮動小数点および倍精度カラムタイプ用のマクロを有し、メモリ場所をプラットフォームと独立した浮動小数点または倍精度値にコピーする。表８は各長さおよびそれに伴うマクロで使用するタイプを示す。

浮動小数点および倍精度値は、指定サイズの浮動として、GoldenGateＭｙＳＱＬＶＡＭに戻すことができる。それにより、データ変換には適切なマクロを用いることだけが必要であり、変換された整数および長さを整数データとして返却する。

ＤＥＣＩＭＡＬ（またはＮＵＭＥＲＩＣ）のデータタイプは正確な数値データ値を記憶するために用いられる。これらのタイプは正確な精度を保つことが重要な、たとえば通貨データでの値を記憶するために用いられる。ＭｙＳＱＬのリリースの前（５．０．３以前）では、ＤＥＣＩＭＡＬおよびＮＵＭＥＲＩＣ値はストリングフォーマットで記憶される。

ＤＥＣＩＭＡＬカラムの値は、９桁の１０進数（１０進法）を４バイトに圧縮するバイナリフォーマットを用いて表わされる。各値の整数および小数部の記憶領域は別個に定められる。９桁の各倍数は４バイトを要し、「余り」の桁は４バイトの一部を要する。余剰桁に必要な記憶領域は表９によって与えられる：

ＭｙＳＱＬは１０進数値を含むメモリ場所をコピーして、ストリング値に変換するための、１０進数カラムタイプ用の関数を有する。ＭｙＳＱＬＶＡＭは‘bin2decimal’関数を用いてメモリ場所を読取り、この値を‘decimal_t’構造に埋める。別の関数‘decimal_bin_size’はこの‘decimal_t’構造を単に変換し、値をストリングとして返す。これは以下のコードラインで記載される。

１０進数値はストリングとしてGoldenGateＭｙＳＱＬＶＡＭに返すことができ、データ変換は単に適切なマクロを用いることだけが必要であり、変換された１０進数値を返す。

ＢＩＴタイプ
一実施例に従うと、ＢＩＴタイプカラムは１つの値当たり６４ビットまで記憶する。必要な最大記憶領域は（Ｍ＋７）／８バイトであり、'Ｍ'は値当たりのビット数を示す。ＭｙＳＱＬＶＡＭは以下のコードを用いてバイナリログからＢＩＴカラム値を読出す。

DATE、TIME、YEAR、DATETIMEおよびTIMESTAMPタイプ
日時タイプ変換はすべての変換の中で最も複雑なものである。他のデータタイプと比較して、ＭｙＳＱＬは日時タイプを扱うマクロまたは公的関数を公開していない。ＭｙＳＱＬ内部実施はこれらのコールを扱うための適切な方法を見つけるためにデバッグされた。ＭｙＳＱＬＶＡＭはＭｙＳＱＬ内部実施に基づき、自己のコードバージョンを書き直している。ＭｙＳＱＬＶＡＭはログからバイナリデータを読出し、これらを共通構造MySQL_TIMEに変換する（この構造はＭｙＳＱＬによって定義され、使用される）。後でこれらの構造はextractに渡される前にストリングに変換することができる。

MySQL_TIMEは以下のように規定される

ＤＡＴＥタイプは、ＤＤ＋ＭＭ×３２＋ＹＹＹＹ×１６×３２として、圧縮３バイト整数形式に記憶される。サポートされている範囲は１０００−０１−０１から９９９９−１２−３１である。ＤＡＴＥカラムは以下のコードを用いてバイナリログから読出される。

ＴＩＭＥタイプはＤＤ×２４×３６００＋ＨＨ×３６００＋ＭＭ×６０＋ＳＳとして、圧縮３バイト整数で記憶される。ＴＩＭＥカラムは以下のコードを用いてバイナリログから読出される。

ＹＥＡＲタイプは１バイトの整数で記憶される。値はＹＹＹＹ（値の範囲は１９０１から２１５５）またはＹＹ（値の範囲は７０（１９７０）から６９（２０６９））形式であり得る。ＹＥＡＲカラム値は以下のコードを用いてバイナリログから読出される。

ＤＡＴＥＴＩＭＥタイプは、日付および時刻情報の両方を含む値が必要である場合に用いられる。サポートされている範囲は′１０００−０１−０１００：００：００′から′９９９９−１２−３１２３：５９：５９′である。ＤＡＴＥＴＩＭＥタイプはＹＹＹＹ×１０００＋ＭＭ×１００＋ＤＤとして圧縮される４バイトの整数を含む８バイトの整数として；ＨＨ×１００００＋ＭＭ×１００＋ＳＳとして圧縮される４バイトの整数として記憶される。ＤＡＴＥＴＩＭＥカラム値は以下のコードを用いてバイナリログから読出される：

ＴＩＭＥＳＴＡＭＰタイプは４バイトの整数であり、エポックからの秒数ＵＴＣを表わす（範囲は′１９７０−０１−０１００：００：０１′ＵＴＣから′２０３８−０１−１９０３：１４：０７′ＵＴＣである）。ＴＩＭＥＳＴＡＭＰカラム値は以下のコードを用いてバイナリログから読出される：

ＬＯＢデータタイプ
一実施例に従うと、ＭｙＳＱＬＬＯＢＭｙＳＱＬは、他のカラム値に従ってＬＯＢレコードを記憶する（大型オブジェクト−すなわちTINYBLOB、BLOB、MEDIUM BLOB、LONG BLOBおよびTEXTタイプ）。BLOBおよびTEXTカラムデータは、VARBINARY またはVARCHARフィールドと同様の方法で記憶される。すなわち、最初のいくつかのバイトは、長さを記憶し、その後にオリジナルのＬＯＢ値が続く。ＬＯＢカラムでは、テーブルマップイベントのフィールドメタデータは、所与のＬＯＢフィールドに必要な最大バイトの記憶領域を含む。この値は、ＬＯＢ値を読出すときに必要なメモリを割当てる際に便利である。TINYTEXTおよびTINYBLOBカラムの最大サイズは２５５である。これはＣＨＡＲおよびｂｉｎａｒｙカラムを扱う場合と同様である。

TEXTおよびＢＬＯＢブロブカラムの最大サイズは６４ｋである。これはまたはVARCHARおよびVARBINARYカラムを取扱うのと類似している。TINYTEXT、TEXT、TINYBLOBおよびBLOBカラムに記憶されている値は１回のショットでextractに送ることができる。他のＬＯＢタイプでは、データは一度に６４ｋのサイズの一塊として、読出すことができ、extractに送られる。以下のコード行はＭｙＳＱＬＬＯＢカラムの取扱いを説明する。

（６５ｋバイト以上のデータを保持することができる）MEDIUM BLOBおよびLONG BLOBのような他のＬＯＢタイプでは、データは一度に３２ｋの大きさの一塊として読出すことができ、複数のコールでextractに送られる。上記のように、ＬＯＢカラム値は他の非ＬＯＢカラム値に従って記憶される。これは他のデータベースと異なる。なぜなら、値はインラインで記憶されないし、データがオンデマンドで取ってくることができるロケータまたはクーポンを用いてアクセスされないからである。ＭｙＳＱＬデータベースの場合では違う（ストレージエンジンMyISAM およびInnoDBを有する）。バイナリログからＬＯＢカラム値を読出すため、ＭｙＳＱＬ内部IO_CACHEクラスは、ログファイルからこのＬＯＢカラム値の全体の値をフェッチしてメモリに渡す、すなわち、メモリはこのクラスにより１回でこのＬＯＢカラム用に完全に割当てられる。

一実施例に従うと、より大きいサイズのＬＯＢデータが塊でＭｙＳＱＬＶＡＭＡＰＩに送られるべきであるというＭｙＳＱＬＶＡＭＡＰＩ仕様概要が示される。しかし、ＭｙＳＱＬの場合、データは既にＭｙＳＱＬ内部クラスで完全に既にフェッチされている（すなわち、メモリはIO_CACHEオブジェクトによって完全に割当てられており）、ＬＯＢデータは３２ｋバイトのサイズの塊で、１つのコールや複数のコールで、ＭｙＳＱＬＶＡＭＡＰＩに送ることができる。

バイナリログを使った作業
一実施例に従うと上記のように、ＭｙＳＱＬはバイナリログインデックスファイルを用いて、現行のバイナリログファイルおよびより古いログファイルを含むリストを維持する。このインデックスファイルは、バイナリログと同じディレクトリ場所にある。これにより、システムは構成ファイルから読出してログファイルフォーマットを見つける、たとえばROW、 STATEMENT、またはMIXEDフォーマットをさがし、ROWでなければアベンドする。

ＭｙＳＱＬサーバが新しいバイナリログファイルを作成する場合（スタートアップ時、または明白な「フラッシュログ」コマンドによる）、BINLOG_MAGIC値（４バイト）および「フォーマット記述イベント」を書込む。このフォーマット記述は所与のバイナリログについて一度しか書込まれない。

このフォーマット記述イベントの「フラグ」属性は、現行のバイナリログがサーバによって使用中であるか否かを追跡する。ＭｙＳＱＬサーバはスタートアップの際にこの状態をLOG_EVENT_BINLOG_IN_USE_F値に設定し、シャットダウンまたはログ回転の際にはこの値をクリアする。これは、バイナリログが正しく閉じられているか否かをチェックする信頼性のあるインジケータとして扱うことができる。

初期化の際、ＭｙＳＱＬＶＡＭは活性バイナリログファイルの名前を得る必要がある。ＭｙＳＱＬＶＡＭは以下のステップを用いてアクティブバイナリログの名前を得る。ＭｙＳＱＬサーバは同じプロシージャを用いて現行のバイナリログを得る：
１．環境変数または供給されたＭｙＳＱＬＶＡＭパラメータのどちらから、ＭｙＳＱＬ設置ホームを得る。

２．ＭｙＳＱＬ初期化ファイルを読出す−ウインドウズ（登録商標）プラットフォームではｍｙ．ｉｎｉであり、他のプラットフォームではｍｙ．ｃｏｎｆである。

３．「ログ-ビン」パラメータの値を得る。この値から、ログディレクトリ場所およびログインデックスファイル名を見つける。

４．ログインデックスファイル名を開き、内容を読出す。この内容から、リストの最後のログファイルを見つける。

５．このログファイルを開き、ログファイルがまだサーバによって使用されているかをチェックする（フォーマット記述イベントのフラグ値がLOG_EVENT_BINLOG_IN_USE_Fであるかをチェックする）。イエスなら、ＭｙＳＱＬサーバは書込のためにこのログファイルを現在使用している。ＭｙＳＱＬＶＡＭはこのログファイルをアクティブログファイルとして扱う。

バイナリログの位置付け
一実施例に従うと、ＭｙＳＱＬＶＡＭＡＰＩはタイムスタンプ値またはシーケンス番号のどちらかによって位置付けることをＭｙＳＱＬＶＡＭに要求することができる。extractにおいて、位置付けはＧＧＳＣＩにおいてＡＤＤまたはＡＬＴＥＲコマンドのどちらかによって要求できる。ＭｙＳＱＬＶＡＭにおいてタイムスタンプおよびシーケンス番号による位置付けのサポートに加えて、本システムはアクティブバイナリログを終わりおよび先頭への位置付けをサポートする。

シーケンス番号による位置付け
一実施例に従うと、extractにトランザクションレコードを送信する場合、ＭｙＳＱＬＶＡＭはextractにシーケンス番号値をも送信する。再スタートシナリオの際、extractはこの最後に受取ったシーケンス番号値をMYSQL VAMIntialize()コールの際にＭｙＳＱＬＶＡＭに送る。ＶＡＭはこの値を用いて正しい読出場所を設定する。

ＭｙＳＱＬＶＡＭはGG_ATTR_DS_SEQIDを用いてこのシーケンス番号値をＡＳＣＩＩストリングとして送る。ＭｙＳＱＬＶＡＭはこのＡＳＣＩＩストリングを、現行のログファイルおよび現行のイベント場所（すなわちlog.000001:10045）の組合せとして、この値をextractに送る前に作成する。

MYSQL VAMIntialize()コールの際にシーケンス番号によって位置付けるために、ＭｙＳＱＬＶＡＭはextractからシーケンス番号値を解析し、ログファイル名をイベント場所として得る。次に、対応するログファイルを開き、イベントのスキャンを開始する。イベントの場所がシーケンス番号で指定されたものと一致するなら、ＭｙＳＱＬＶＡＭはこの場所を現行の読出場所として設定し、この場所からバイナリログの内容の読出を始める。

タイムスタンプ値による位置付け
タイムスタンプによる位置付けのため、システムは必要なタイムスタンプ値以上のタイムスタンプを有するアクティブバイナリログ（すなわちＢＥＧＩＮストリングを含むQueryEvent）においてビギントランザクションレコードを見つけなければならない。タイムスタンプ値が未来の時間であるのなら、必要なタイムスタンプ場所以上のタイムスタンプを有するビギントランザクションレコードを見つけるまで、システムはログの終わりにおいて読出を続ける。バイナリログ内またはバイナリログとともに起こり得る２つのシナリオがある：
シナリオ１：Begin/Endトランザクションレコードはアクティブバイナリログにあり、最初にこのようなレコードのタイムスタンプは要求されるタイムスタンプ位置よりも低い。

このシナリオの場合、ＭｙＳＱＬＶＡＭはアクティブバイナリログファイルをスキャンして、タイムスタンプ値が要求されるタイムスタンプ場所以上であるビギントランザクションレコードを見つける。ＭｙＳＱＬＶＡＭが要求されるレコードを見つけられなかった場合、ログの終わりに位置付けられる。

シナリオ２：アクティブバイナリログにおける最初のBegin/Endトランザクションレコードは、要求されるタイムスタンプ場所以上のタイムスタンプ値を有する。

このシナリオは微妙である。このシナリオにおいて、より古いバイナリログも要求されるタイムスタンプ値に等しいタイムスタンプを有するBeginトランザクションレコードを持っている可能性がある。

一実施例に従うと、ＭｙＳＱＬＶＡＭは最新のものから古いものへと、バイナリログをスキャンする（順序はログインデックスファイルで維持される）。ＭｙＳＱＬＶＡＭが要求されるタイムスタンプに等しいタイムスタンプを有するBegin/End了トランザクションレコードを見つけなかった場合、ＭｙＳＱＬＶＡＭはエラーを返すかまたは最も古いログファイルの先頭に位置付ける。タイムスタンプによる位置付けは時間の掛かる処理となり得る。なぜなら、ＭｙＳＱＬＶＡＭはより古いログファイルを開けて、そのタイムスタンプに一致するイベントエントリを見つける必要があるかもしれないからである。

ログの終わりへの位置付け
一実施例に従うと、アクティブバイナリログの終わりに位置付けるために、ＭｙＳＱＬＶＡＭは、IO_CACHE関数クラスにログの終わりを見つけることを要求するために、my_b_seek()関数を使用する。

ログの先頭への位置付け
一実施例に従うと、トランザクションログの先頭に位置付けるために、ＭｙＳＱＬＶＡＭはmy_b_seek()関数をコールして、ログの先頭を、BINLOG_MAGICプラスグローバルフォーマット記述イベントデータの後ろに位置付ける。

バイナリログの読出
一実施例に従うと、ＭｙＳＱＬＶＡＭはＭｙＳＱＬのIO_CACHE C++クラスおよびファイルユーティリティ関数を用いてＭｙＳＱＬバイナリログを開いて読出す。ＭｙＳＱＬのIO_CACHE C++クラス（mysql_client.libの一部）は、バイナリログの内容を６４ｋのサイズの塊で読出す。このバッファ読出はＩＯ使用の減少に役立つ。

バイナリログファイルを読出す正しいシーケンスを見つけるために、‘mysqlbinlog’ユーティリティおよび‘replication slave thread’モジュールといったＭｙＳＱＬのさまざまな内部モジュールがデバッグされる。以下のコード行は、IO_CACHEクラスを初期化し、バイナリログファイルを開いて読出す。

ログ回転
一実施例に従うと、以下のシナリオによりＭｙＳＱＬのログ回転を引き起こす（すなわち、既存のアクティブログファイルを閉じて、新しいログファイルを開く）。

１．アクティブログファイルのサイズが、max_binlog_size値を超えた場合（ｍｙ．ｉｎｉまたはｍｙ．ｃｏｎｆファイルで指定されている）。

ａ．ＭｙＳＱＬはアクティブバイナリログにおいて’Rotate Event’をログする。回転イベントデータ部は、新しいアクティブバイナリログの場所および名前を含む。

２．明確な「フラッシュログ」コマンドがＭｙＳＱＬＳＱＬプロンプトで発行された場合。

ａ．ＭｙＳＱＬはアクティブバイナリログにおいてRotate Eventをログする。回転イベントデータ部は、新しいアクティブバイナリログの場所および名前を含む。

ｂ．ＭｙＳＱＬはアクティブログを閉じて、フォーマット記述イベントフラグをＮＵＬＬにリセットする（このフラグは前にLOG_EVENT_BINLOG_IN_USE_F値に設定されている）。

３．サーバシャットダウンの際。
ａ．ＭｙＳＱＬはアクティブバイナリログにStop Eventをログする。

４．サーバスタートアップの際。
ａ．ＭｙＳＱＬは新しいバイナリログを作成し、フォーマット記述イベントフラグをLOG_EVENT_BINLOG_IN_USE_F値に設定する。

上記のように、一実施例に従うと、ＭｙＳＱＬＶＡＭはログ回転が起こったことを識別するために回転イベントを使用し、次のバイナリログの名前を得るために、回転イベントデータを用いる。ＭｙＳＱＬＶＡＭは次のバイナリログを開き、そのバイナリログ読出を続ける。シナリオ３および４では、ＭｙＳＱＬＶＡＭがストップイベントに出合うと、使用しているバイナリログを閉じて、次のバイナリログがあるかログインデックスファイルをチェックする。ＭｙＳＱＬＶＡＭがインデックスファイルにおいて次のバイナリログを見つけると、そのバイナリログを開いて読出を続ける。ＭｙＳＱＬＶＡＭがインデックスファイルにおいて新しいログファイル名を見つけることができなかった（たとえば、サーバがまだシャットダウンモードにあるか、シャットダウン後、スタートしていない）場合、ＭｙＳＱＬＶＡＭはextractに対してアベンドすることを知らせる。

考慮するべきもう一つの興味のあるシナリオがある。サーバクラッシュの際、フォーマット記述イベントのフラグがサーバの再スタートのときにサーバによってリセットされない可能性は小さく、またはＭｙＳＱＬサーバがアクティブバイナリログファイルに回転イベントもしくはストップイベントのどちらもログしない。後のスタートアップの際、サーバはより古いバイナリログのフラグをリセットすることなく、新しいバイナリログファイルを作成する。このような特有の状況では、２つのバイナリログがLOG_EVENT_BINLOG_IN_USE_F状態のフラグを設定していることになる。ＭｙＳＱＬＶＡＭがこのシナリオに出合うのは以下の条件の場合である：
１. ＭｙＳＱＬＶＡＭは現在アクティブバイナリログを処理している。サーバクラッシュは読出のときに起こる。この場合、extractを停止させ、クラッシュリカバリを行ない、サーバスタートアップの後ＭｙＳＱＬＶＡＭを再度スタートさせるのがよい。

２. ＭｙＳＱＬＶＡＭはより古いログファイルを読むよう位置付けられている。１つのファイルから別のファイルに読出す場合（すなわちログ回転の場合）、LOG_EVENT_BINLOG_IN_USE_Fの値のログファイルフラグに出合う。このログファイルは最新のログファイルではないことに注意しなければならない（すなわち、アクティブなバイナリログではない）。ＥＯＦが起こると、ＭｙＳＱＬＶＡＭは次のログファイルがあるかどうかについて、ログインデックスファイルをチェックする。この場合、ＭｙＳＱＬＶＡＭはサーバクラッシュが前に起こっていると見なし、既存のログファイルを閉じ、次のログファイルを開けてログ読出を続ける。

ＭｙＳＱＬＶＡＭクラス設計
上記のように、一実施例に従うと、ＭｙＳＱＬＶＡＭ実施はＣ＋＋を用いて書込まれ、ＭｙＳＱＬＶＡＭモジュールの実施は２つの主な部分に分けられる。最初の部分では、内部で開発されたイベントC++クラスを用いてバイナリログイベントを読出し、これらをデータレコードに処理し、レコードを用意ができたフォーマット（送信できる状態）にして、制限されたサイズのQueueに記憶する。第２の部分では、Queueからレコードを取ってきて、ＡＰＩからリクエストを受けるたびにＡＰＩに送る。

バイナリログリーダ
図１３は、一実施例に従うＶＡＭバイナリログリーダのクラスダイヤグラムを示す。CMySQLBinLogManagerクラスは主要制御クラスであり、全体の処理を管理し、作業を異なるクラスにコミットする。データをバイナリログから読出し、バイナリログデータを処理し（ＭｙＳＱＬイベントをデータレコードに変換）、レコード（既成フォーマット）を制限されたサイズのQueueに入れることを主に担当する。これはすべての関数を「純粋仮想」として有するCLogManagerクラスから派生している。

設計はCMySQLBinLogReaderクラスを有し、データをバイナリログから取ってくることを担う。さまざまなC++イベントクラスおよびＭｙＳＱＬのIO_CACHEクラスを用いて、バイナリログのライフサイクルおよびイベントインスタンスを管理する。さらに、イベントをフィルタ処理するためにCFilterBinLogログを用いる。

CLogProcessorクラスはバイナリログデータを処理するのであって、制限されたサイズQueue(CRecordQueue)を準備した既成オブジェクトで埋める。後で、これらのオブジェクトはＡＰＩに送られるために他のクラスによってフェッチされる。

CRecordQueueクラスは既成レコード(CRecord)の記憶を担う。
先頭から、処理はCMySQLBinLogManagerクラスのscanLog機能から始まり、これは別個の実行エンティティ（スレッド）であり、独立して実行され、全体の処理実行を担う。まずCMySQLBinLogReaderにバイナリログの読出を求め、そこから生のイベントインスタンスを得る。このレコードをさらに処理するためCLogProcessorに渡して、制限されたサイズのQueueに入力される。

バイナリログプロセッサ
図１４は一実施例に従うと、バイナリログプロセッサのクラスダイヤグラムを示す。

CMySQL VAMModuleは全体のMYSQL VAMモジュールの主要制御クラスである。これはシングルトンクラスであり、MYSQL VAMモジュールの寿命の間中１つのオブジェクトしか持たない。中にすべてのコアビジネスロジックがあり、タスクをさまざまなクラスにわたってデリゲート(delegate)する。

MYSQL VAMモジュールはＡＰＩに４つの関数を公開しており、これはMYSQL VAMInitialize、MYSQL VAMRead、MYSQL VAMMesage およびMYSQL VAMControlである。これらの関数のビジネスロジックはCMySQL VAMModuleクラスの中にある。CRecordQueueキューからCRecordレコード（設計の第１の部分により、Queueに入れられた既成レコード）をフェッチして、CMySQL VAMCommunicatorクラスによってＡＰＩに送る。

CMySQL VAMCommunicatorクラスはどのようにデータをＡＰＩに対して送るおよび得るかを担う。CMySQL VAMApiクラスを用いてＡＰＩからの公開された関数を用いる。CMySQL VAMApiクラスはＡＰＩ公開関数のラッパである。

CErrorContainerクラスは中にエラーオブジェクトを記憶し、エラーになりがちなシナリオを取扱う。

ＭｙＳＱＬＶＡＭ公開関数（すなわち、MYSQL VAMInitialize）がＡＰＩからコールされるたびに、フローはCMySQL VAMModuleクラスに向けられ、そのフローを別の他のクラスにリダイレクトし、データをＡＰＩに返す。たとえば、MYSQL VAMRead読出しがＡＰＩからコールされたのなら、CMySQL VAMModuleのMySQL VAMReadがコールされ、CRecordQueueキューからデータをフェッチして、CMySQL VAMCommunicatorクラスを介してＡＰＩに送られる。

本発明は、１つ以上のプロセッサ、メモリおよび／または本開示の教示に従うプログラミングされたコンピュータ読取可能記憶媒体を含む、１つ以上の従来の汎用もしくは特殊なデジタルコンピュータ、演算装置、マシンまたはマイクロプロセッサを用いて、好都合に実施できる。適切なソフトウェアコード化は、ソフトウェア技術の当業者にとって明らかなように、本開示の教示に基づき、熟練したプログラマーによって容易に用意することができる。

一部の実施例において、本発明は一時的ではない記憶媒体またはコンピュータ読取可能媒体であるコンピュータプログラムプロダクトを含み、そこに命令が記憶されて、コンピュータに本発明のいずれかの処理を実行するようプログラミングするために用いることができる。記憶媒体は、フロッピー（登録商標）ディスク、光学ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ装置、磁気または光カード、ナノシステム（分子メモリＩＣを含む）を有するすべての種類の物理媒体、ならびに命令および／またはデータを記憶するのに適するすべての種類の媒体または装置を含むことができるが、これらに限定されない。

本発明の記載は、図示および説明のために提供されている。本発明を開示されたそのままの形に制限する意図はない。多くの変形および変更は当業者にとって明らかである。特に、実施例はＭｙＳＱＬ環境およびMYSQL VAMを用いて記載されているが、他の種類のＶＡＭを他の種類のデータベースまたはシステムで実施できることは明らかである。実施例は本発明の原理および実用的アプリケーションを最もよく説明する目的のために選択および記載されており、それにより当業者がさまざまな実施例について、および意図される特定の使用に適するさまざまな変形について、本発明を理解することができる。本発明の範囲は特許請求の範囲およびその均等の意味によって定義されるものとする。

Claims

バイナリログファイルを使用するＭｙＳＱＬデータベースまたはシステムと、他の種類のデータベースまたはシステムとの間でデータを転送するために、ログベースレプリケーションを使用するシステムであって、
ベンダーアクセスモジュールを備え、前記ベンダーアクセスモジュールは、
ＭｙＳＱＬデータベースまたはシステムによってバイナリログファイルに記録されるバイナリログイベントのうち、前記ＭｙＳＱＬデータベースまたはシステムが記録したヘッダを参照して、予め定められた種類のバイナリログイベントのサブセットのみを特定し、
前記特定したバイナリログイベントのサブセットのバイナリログデータをデータレコードに変換し、
変換されたデータレコードをレコードキューに保持し、
前記レコードキューに保持されたデータレコードを処理するとともに、処理されたデータを含むトレールファイルを生成するために、extractプロセスとやり取りするように構成され、前記処理されたデータは非ＭｙＳＱＬデータベースまたはシステムへの適用に使用される、システム。
前記バイナリログファイルはＭｙＳＱＬバイナリログファイルである、請求項１に記載のシステム。
前記extractプロセスはOracle（登録商標）GoldenGateextractプロセスであり、前記トレールファイルはOracleGoldenGateトレールファイルである、請求項１または２に記載のシステム。
前記ベンダーアクセスモジュールは、extractプロセスが特定のトランザクション用にデータレコードを検索するためにＡＰＩを提供する、請求項１〜３のいずれか１項に記載のシステム。
前記ベンダーアクセスモジュールは、バイナリログからイベントの処理を与えるために用いることができる、複数のＶＡＭイベントクラスと；ＭｙＳＱＬデータベースまたはシステムによって与えられるアクセスライブラリをラップアラウンドするために用いることができる、複数のＶＡＭバイナリログクラスと；ビンログクラスからレコードを読出しおよび処理し、これらをデータレコードキューに入れるために用いることができる、複数のＶＡＭリーダおよびプロセッサクラスとを含む、請求項１〜４のいずれか１項に記載のシステム。
前記ベンダーアクセスモジュールは、ログインデックスファイルを用いて、複数のバイナリログファイルから使用するべき現行のバイナリログファイル、およびその状態を判断する、請求項１〜５のいずれか１項に記載のシステム。
前記ベンダーアクセスモジュールは、前記バイナリログファイルに記録されているログ回転イベントを特定し、当該特定の結果を用いて次のバイナリログファイル名を取得する、請求項１〜６のいずれか１項に記載のシステム。
前記ベンダーアクセスモジュールは、前記バイナリログファイルに記録されているＥＯＦを検出し、次のバイナリログファイルを探索する、請求項１〜７のいずれか１項に記載のシステム。
バイナリログファイルを使用するＭｙＳＱＬデータベースまたはシステムと、他の種類のデータベースまたはシステムとの間でデータを転送するためにログベースレプリケーションを用いる方法であって、
ベンダーアクセスモジュールを設けるステップを備え、前記ベンダーアクセスモジュールは、
ＭｙＳＱＬデータベースまたはシステムによってバイナリログファイルに記録されるバイナリログイベントのうち、前記ＭｙＳＱＬデータベースまたはシステムが記録したヘッダを参照して、予め定められた種類のバイナリログイベントのサブセットのみを特定し、
前記特定したバイナリログイベントのサブセットのバイナリログデータをデータレコードに変換し、
変換されたデータレコードをレコードキューに保持し、
前記レコードキューに保持されたデータレコードを処理するとともに、処理されたデータを含むトレールファイルを生成するために、extractプロセスとやり取りするように構成され、前記処理されたデータは非ＭｙＳＱＬデータベースまたはシステムへの適用に使用される、方法。
前記バイナリログファイルはＭｙＳＱＬバイナリログファイルである、請求項９に記載の方法。
前記extractプロセスはOracle（登録商標）GoldenGateextractプロセスであり、前記トレールファイルはOracleGoldenGateトレールファイルである、請求項９または１０に記載の方法。
前記ベンダーアクセスモジュールは、extractプロセスが特定のトランザクション用にデータレコードを検索するためにＡＰＩを設ける、請求項９〜１１のいずれか１項に記載の方法。
前記ベンダーアクセスモジュールは、バイナリログからイベントの処理を与えるために用いることができる、複数のＶＡＭイベントクラスと；前記ＭｙＳＱＬデータベースまたはシステムによって与えられるアクセスライブラリをラップアラウンドするために用いることができる、複数のＶＡＭバイナリログクラスと；ビンログクラスからレコードを読出しおよび処理し、これらをデータレコードキューに入れるために用いることができる、複数のＶＡＭリーダおよびプロセッサクラスとを含む、請求項９〜１２のいずれか１項に記載の方法。
前記ベンダーアクセスモジュールは、ログインデックスファイルを用いて、複数のバイナリログファイルから使用するべき現行のバイナリログファイル、およびその状態を判断する、請求項９〜１３のいずれか１項に記載の方法。
前記ベンダーアクセスモジュールは、前記バイナリログファイルに記録されているログ回転イベントを特定し、当該特定の結果を用いて次のバイナリログファイル名を取得する、請求項９〜１４のいずれか１項に記載の方法。
前記ベンダーアクセスモジュールは、前記バイナリログファイルに記録されているＥＯＦを検出し、次のバイナリログファイルを探索する、請求項９〜１５のいずれか１項に記載の方法。
請求項９〜１６のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム。