MySQL

この項では、Oracle GoldenGate for MySQLの構成の詳細を示します。

トピック:

親トピック: 構成

データベース・ユーザーおよび権限の準備

データベース・ユーザーの作成およびOracle GoldenGate for MySQLの権限の割当てについて学習します。

トピック:

データベース・ユーザーの準備およびGoldenGate for MySQLの権限の割当て

親トピック: MySQL

データベース・ユーザーの準備およびGoldenGate for MySQLの権限の割当て

Oracle GoldenGateプロセスのデータベース・ユーザーの要件は次のとおりです。

Oracle GoldenGate専用のデータベース・ユーザーを作成します。データベースに接続する必要のあるすべてのOracle GoldenGateプロセスに対して同じユーザーでもかまいません。
DDLレプリケーションをサポートするには、MySQLユーザーにデータベース・プラグインをインストールする権限が必要です。プラグインに必要なアクセス権は、MySQL 5.7でのみ必要です。mysql.pluginシステム表に対するINSERT権限が必要です。
データのセキュリティを維持したり、Oracle GoldenGateの処理を的確に監視したりするには、他のユーザー、アプリケーションまたはプロセスに対してOracle GoldenGateデータベース・ユーザーでのログインまたは操作を許可しないでください。
データベース・ユーザーを記録します。それらをOracle GoldenGateパラメータ・ファイルのUSERIDパラメータを使用して指定する必要があります。
Oracle GoldenGateユーザーは、INFORMATION_SCHEMAデータベースに読取りアクセスできる必要があります。

Oracle GoldenGateユーザーには、次の権限が必要です。

権限	ソースExtract	ターゲットReplicat	目的
`SELECT`	はい	はい	データベースに接続し、オブジェクト定義を選択します
`REPLICATION SLAVE`	はい	NA	レプリケーション・マスターのバイナリ・ログに接続し、そこから更新を受信します
`CREATE` `CREATE VIEW` `EVENT` `INSERT` `UPDATE` `DELETE`	はい	はい	ソースおよびターゲット・データベースのハートビートとチェックポイント表の作成、およびデータ・レコードの生成とパージ
`DROP`	はい	はい	Replicatチェックポイント表の削除またはハートビート表実装の削除
`EXECUTE`	はい	はい	ストアド・プロシージャを実行する
ターゲット表の`INSERT`、`UPDATE`、`DELETE`	NA	はい	レプリケートされたDMLをターゲット・オブジェクトに適用
ターゲット・オブジェクトのDDL権限(DDLサポートを使用している場合)	NA	はい	レプリケートされたDDLをターゲット・オブジェクトに発行

バイナリ・ログ・イベントをキャプチャするためには、管理者がExtractユーザーに次の権限を指定する必要があります。
- MySQL構成ファイル(my.cnf)があるディレクトリの読取り権限と実行権限
- MySQL構成ファイル(my.cnf).の読取り権限
- バイナリ・ログがあるディレクトリの読取り権限と実行権限
- tmpディレクトリの読取り権限と実行権限tmpディレクトリは/tmpです。MySQL 8.0より前のバージョンでは、MySQLデータベース接続に/tmp/mysql.sockファイルへのアクセスが必要です。

親トピック: データベース・ユーザーおよび権限の準備

データベース接続、システムおよびパラメータ設定の準備

Oracle GoldenGate for MySQLのデータベース接続、システムおよびパラメータ設定の構成について学習します。

トピック:

親トピック: MySQL

データベース接続の構成

Oracle GoldenGateは、接続先のデータベースの名前をSOURCEDBパラメータから取得します。SOURCEDBパラメータで接続を構成するには、次の形式を使用します。

SOURCEDB dbname@hostname:port, USERID mysqluser, PASSWORD welcome

dbnameはMySQLインスタンスの名前、hostnameはMySQLデータベース・サーバーの名前またはIPアドレス、portはMySQLインスタンスのポート番号です。修飾されていないホスト名を使用する場合、名前はDNSデータベースに適切に構成されている必要があります。そうでない場合、完全修飾されたホスト名(myhost.company.comなど)を使用します。

MySQLキャプチャおよび配信での双方向SSL接続の構成

親トピック: データベース接続、システムおよびパラメータ設定の準備

MySQLキャプチャおよび配信での双方向SSL接続の構成

MySQLの取得および配信にOracle GoldenGateで双方向SSLを使用するには、認証局(ca.pem)、クライアント証明書(client-cert.pem)およびクライアント・キー(client-key.pem)ファイルのフルパスを取得および配信に指定する必要があります。

証明書ファイルの生成の詳細は、次を参照してください。

https://dev.mysql.com/doc/refman/5.7/en/creating-ssl-rsa-files-using-mysql.html

これらのパスは、ExtractとReplicatのパラメータ・ファイルでSETENVパラメータを使用して指定する必要があります。

双方向SSL接続を設定するためのSETENV環境パラメータは次のとおりです。

OGG_MYSQL_OPT_SSL_CA: 認証局のフルパスを設定します。
OGG_MYSQL_OPT_SSL_CERT: クライアント証明書のフルパスを設定します。
OGG_MYSQL_OPT_SSL_KEY: クライアント・キーのフルパスを設定します。

次の例では、MySQL SSL認証局、クライアント証明書およびクライアント・キーのパスがOracle GoldenGate MySQL ExtractおよびReplicatパラメータに設定されます。

SETENV (OGG_MYSQL_OPT_SSL_CA='/var/lib/mysql.pem') 
SETENV (OGG_MYSQL_OPT_SSL_CERT='/var/lib/mysql/client-cert.pem') 
SETENV (OGG_MYSQL_OPT_SSL_KEY='/var/lib/mysql/client-key.pem')

X509暗号化スキームで構成されたMySQLユーザーの場合、MySQLデータベースには、ログイン時にssl-keyおよびssl-certオプションが必要です。そのため、このユーザーに対してOracle GoldenGate資格証明ストア・エントリを作成する場合、使用するsslModeに関係なく、資格証明ストアの別名でSSLオプションにsslKeyおよびsslCertを含める必要があります。

親トピック: データベース接続の構成

データベース構成

サポートされているデータベース、データベース・ストレージ・エンジン、データベース文字セット、およびOracle GoldenGate for MySQLの構成の一部として処理する表の準備方法について学習します。

トピック:

親トピック: データベース接続、システムおよびパラメータ設定の準備

サポートされているデータベース

Oracle GoldenGate for MySQLは、MySQL、Oracle MySQL Database Service、Amazon Aurora MySQL、Amazon RDS for MariaDB、Amazon RDS for MySQL、Azure Database for MySQL、Google Cloud SQL for MySQLおよびMariaDBに対するキャプチャと配信をサポートしています。

Oracle GoldenGateリリース21.10では、Oracle GoldenGate for MySQL Replicatを使用して、SingleStoreDBおよびSingleStoreDB Cloudが配信のみでサポートされるようになりました。

Oracle GoldenGate 21c (21.7) for MySQL 8.0以上から、単一プライマリ・モードでGroup Replicationで構成されたMySQLのキャプチャおよび配信がサポートされます。詳細は、「MySQL Group ReplicationでのOracle GoldenGateの使用」を参照してください。

サポートされているデータベースおよびバージョンの完全なリストについては、使用しているバージョンのOracle GoldenGateの認定マトリックスを参照してください。

サポートの制限事項

親トピック: データベース構成

サポートの制限事項

Oracle GoldenGate for MySQLのサポートの制限を次に示します:

バイナリ・ログ・トランザクション圧縮が有効であるMySQLデータベースは、Oracle GoldenGate Extractではサポートされません。
バイナリ・ログ暗号化が有効であるMySQLデータベースは、Oracle GoldenGate Extractではサポートされません。

親トピック: サポートされているデータベース

データベース・ストレージ・エンジン

データベース・ストレージ・エンジンの要件は次のとおりです。

Oracle GoldenGateでは、ソースMySQLデータベース用にInnoDBストレージ・エンジンがサポートされます。
MySQL用のOracle GoldenGateのすべてのコンポーネント(Extract、Replicat、管理クライアントなど)は、MySQLネイティブAPIを使用してデータベースに接続します。
Oracle GoldenGateは、InnoDBエンジンからの取得および適用をサポートします。MyISAMエンジンへの適用は機能しますが、非トランザクションでMyISAMエンジンとしてデータ整合性の問題が発生する可能性があります。

親トピック: データベース構成

データベース文字セット

MySQLには、ユーザーが異なるレベルで異なる文字セットを指定できる機能があります。

レベル	例
データベース	create database test charset utf8;
表	create table test( id int, name char(100)) charset utf8;
列	create table test ( id int, name1 char(100) charset gbk, name2 char(100) charset utf8));

サポートの制限事項

データベースの文字セットをutf8mb4/utf8に指定すると、デフォルトの照合はutf8mb4_unicode_ci/utf8_general_ciになります。collation_server=utf8mb4_binを指定すると、データベースはデータをバイナリとして解釈します。たとえば、CHAR列の長さを4に指定した場合、4バイトを超えるデータを挿入しようとすると、データが長すぎることがターゲット・データベースから警告されますが、返されるバイト長は16 (utf8mb4の場合)になります。これはデータベースの制限のため、Oracle GoldenGateではバイナリ照合をサポートしていません。この問題を解決するには、文字セットがutf8mb4およびcollation_server=utf8_bin (UTF-8)に設定されている場合に、collation_server=utf8mb4_binを指定します。
次の文字セットはサポートされていません。
- armscii8
- keybcs2
- utf16le
- geostd8

親トピック: データベース構成

セッション文字セットの設定

ExtractおよびReplicatプロセスは、コマンドライン・インタフェース(管理クライアント)からデータベースに接続するときにセッション文字セットを使用します。MySQLの場合、セッション文字セットはSOURCEDBおよびTARGETDBのSESSIONCHARSETオプションから取得されます。Oracle GoldenGateを構成する際、これらのいずれかでセッション文字セットを必ず指定してください。

親トピック: データベース構成

処理のための表の準備

この項では、処理のための表の準備方法について説明します。表の準備では次のタスクが必要です。

トピック:

親トピック: データベース構成

表における行の一意性の保証

Oracle GoldenGateでは、レプリケートされた更新および削除に対して正しいターゲット行を見つけるために、ソース表とターゲット表にある形式の一意の行識別子が必要です。

TABLEまたはMAP文でKEYCOLS句が使用されないかぎり、Oracle GoldenGateは、使用する行識別子を次の優先順位に従って選択します。

主キー
タイムスタンプまたはマテリアライズされていない計算結果列を含まない英数字順で最初の一意キー。
前述のキー・タイプのいずれも存在しない場合(その他の種類のキーが表に定義されている場合でも)、Oracle GoldenGateは、データベースで一意キーでの使用を許可されているすべての列(キー内での使用がOracle GoldenGateでサポートされていない列やOracle GoldenGate構成から除外されている列は除く)で疑似キーを作成します。

ノート:

表に使用可能な他のキーがない場合や、表にキーがまったくない場合、Oracle GoldenGateは該当するメッセージをレポート・ファイルに記録します。すべての列からキーを作成すると、ソース・システムのOracle GoldenGateのパフォーマンスが低下します。ターゲットでは、このキーはReplicatであまり効率的でないより大きいWHERE句が使用される原因となります。
表に適切なキーがない場合、あるいは既存のキーを使用しない場合は、表に一意の値が常に含まれる列があれば、代替キーを定義できます。ExtractのTABLEパラメータおよびReplicatのMAPパラメータ内にKEYCOLS句を含めることで、この代替キーを定義します。指定したキーにより、Oracle GoldenGateで検出される既存の主キーまたは一意キーはオーバーライドされます。Oracle GoldenGateリファレンスのTABLE | MAPを参照してください。

親トピック: 処理のための表の準備

一意索引から導出される主キーを持つ表

表に主キーがなく、索引付けされた列がNOT NULLである場合、MySQLでは一意索引が主キーにプロモートされます。これらのNOT NULL索引が複数ある場合、最初に作成された索引が主キーになります。Replicatでエラーが発生しないようにするには、ソース表とターゲット表でこれらの索引を同じ順序で作成します。

たとえば、ggvam.empという名前のソース表とターゲット表のそれぞれにfirst、middle、lastという列があり、それらすべてがNOT NULLとして定義されているとします。次の順序で一意索引を作成した場合、表定義が一致しないため、Oracle GoldenGateはターゲットで異常終了します。

ソース:

CREATE UNIQUE INDEX UQL ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ2 on ggvam.emp(middle); 
CREATE UNIQUE INDEX UQ3 on ggvam.emp(last);

ターゲット:

CREATE UNIQUE INDEX UQ1 ON ggvam.emp(last); 
CREATE UNIQUE INDEX UQ2 ON ggvam.emp(first); 
CREATE UNIQUE INDEX UQ3 ON ggvam.emp(middle);

この順序の結果、MySQLでは、ソースのfirst列の索引と、ターゲットのlast列の索引が主キーにプロモートされます。Oracle GoldenGateでは、メタデータ・レコードの作成時に主キーが識別子として選択されるため、メタデータが一致しなくなります。このエラーを回避するには、主キーにプロモートする列を決定し、ソースおよびターゲットでその索引を最初に作成します。

親トピック: 表における行の一意性の保証

Oracle GoldenGateで使用する独自キーの指定

前述のキー・タイプの行識別子が表に存在しないか、または、それらの識別子を使用しない場合は、常に一意の値が含まれている列が表にあれば、代替キーを定義できます。ExtractのTABLEパラメータおよびReplicatのMAPパラメータ内にKEYCOLS句を含めることで、この代替キーを定義します。指定したキーにより、Oracle GoldenGateで検出される既存の主キーまたは一意キーはオーバーライドされます。

親トピック: 表における行の一意性の保証

キーのない表での行の変更の制限

ターゲット表に主キーまたは一意のキーがない場合、重複する行が存在する可能性があります。この場合、Oracle GoldenGateで更新または削除されるターゲット表の行数が多くなりすぎ、ソース・データとターゲット・データの同期がとれなくなる可能性があります。警告するエラー・メッセージは表示されません。更新される行数を制限するには、Replicatパラメータ・ファイルでDBOPTIONSパラメータにLIMITROWSオプションを使用します。LIMITROWSを使用すると1行しか処理されないため、ターゲット・システムにおけるOracle GoldenGateのパフォーマンスが向上する可能性があります。

親トピック: 処理のための表の準備

トリガーおよびカスケード制約に関する考慮事項

親トピック: 処理のための表の準備

トリガー

ターゲット表のトリガーを無効にするか、Oracle GoldenGateデータベース・ユーザーによる変更を無視するように変更します。Oracle GoldenGateでは、トリガーの結果として生成されるDMLがレプリケートされます。同じトリガーがターゲット表でアクティブになった場合、レプリケートされたバージョンのために重複となり、データベースでエラーが返されます。

親トピック: トリガーおよびカスケード制約に関する考慮事項

カスケード制約に関する考慮事項

Oracle GoldenGateによって取得されるカスケード更新および削除はバイナリ・ログに記録されないため、取得されません。これはMySQLとMariaDBの両方で有効です。たとえば、表間に親子関係がある親表でdelete文を実行すると、子表ではカスケード削除が適宜発生しますが、バイナリ・ログには記録されません。親表の削除または更新レコードのみがバイナリ・ログに記録され、Oracle GoldenGateによって取得されます。

詳細は、https://mariadb.com/kb/en/replication-and-foreign-keys/およびhttps://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.htmlを参照してください。

カスケード操作のレプリケーションを正しく処理するには、ソースでカスケード削除および更新を無効にし、親レコードを変更する前に子レコードを明示的に削除または更新するようにアプリケーションをコーディングすることをお薦めします。または、ターゲット親表にソース親表と同じカスケード制約が構成されていることを確認する必要がありますが、これにより、特に双方向レプリケーションの場合にソースとターゲットの間で非同期状態が発生する可能性があります。

親トピック: トリガーおよびカスケード制約に関する考慮事項

リモート・キャプチャのためのMySQLの構成

MySQLのためのOracle GoldenGateリモート・キャプチャ、Amazon RDS for MySQL、Amazon Aurora MySQL、Azure Database for MySQLを使用して、Oracle GoldenGateインストールにリモートに配置されているデータベースからトランザクション・ログ・データを取得します。

データベース・サーバー構成

リモート取得が機能するには、MySQLサーバーを次のように構成します。

Oracle GoldenGateリモート取得ユーザーにアクセス権を付与します。

リモート・データベースに対して次の文を実行し、ユーザーを作成してリモート・キャプチャに必要な権限を付与します。
```
CREATE USER 'username'@'host' IDENTIFIED BY 'Password'; 
GRANT ALL PRIVILEGES ON *.* TO 'username'@'host’ WITH GRANT OPTION; 
FLUSH PRIVILEGES;
```
リモートのMySQLサーバーのserver_id値は0より大きくする必要があります。この値は、MySQLリモート・サーバーで次の文を発行して検証できます。
```
SHOW VARIABLES LIKE ‘server_id’;
```
server_idの値が0の場合は、my.cnf構成ファイルを変更して0より大きい値を設定します。

Oracle GoldenGate構成

Oracle GoldenGate構成には、次のステップがあります。

Extractのパラメータ・ファイルにリモート・データベースの接続情報を指定します。
```
SOURCEDB remotedb@mysqlserver.company.com:port, USERID username, PASSWORD
password
```
Extractのパラメータ・ファイルの接続情報の後に、次のパラメータを追加します。
```
TRANLOGOPTIONS ALTLOGDEST REMOTE
```

MySQL用Oracle GoldenGateリモート取得の制限

Oracle GoldenGate for MySQLとMySQLのネイティブ・レプリケーション・スレーブの共存は、次の条件と制限でサポートされています。

ネイティブ・レプリケーション・スレーブには、現在実行中のスレーブとは異なるserver_idを割り当てる必要があります。スレーブserver_idの値は、マスター・サーバーで次のMySQLコマンドを使用して表示できます。
```
SHOW SLAVE HOSTS;
```
- Oracle GoldenGate取得が、A slave with the same server_uuid or server_id as this slave has connected to the masterで異常終了した場合は、取得の名前を変更して取得を再開します。
- ネイティブ・レプリケーション・スレーブが、A slave with the same server_uuid or server_id as this slave has connected to the masterで異常終了した場合は、ネイティブ・レプリケーション・スレーブのserver_idを変更して再起動します。
リモート取得は、Linuxで実行中のOracle GoldenGateでサポートされており、LinuxまたはWindowsで実行されているデータベースをサポートできます。

親トピック: データベース構成

トランザクション・ログの設定と要件

Oracle GoldenGate for MySQLのトランザクション・ログの設定および要件の詳細を確認してください。

トピック:

親トピック: MySQL

データ使用可能性の確保

十分なバイナリ・ログ・データを保持し、Extractを停止した場合、または計画外の停止が発生した場合に、Extractをチェックポイントから再開できるようにします。Extractには、コミットされていない最も古い作業単位の開始点を含むバイナリ・ログ、およびそれ以降のすべてのバイナリ・ログへのアクセス権が必要です。推奨される保存期間は、少なくとも24時間は対応可能な、アクティブな情報とアーカイブされた情報の両方を含むトランザクション・データです。データ量とビジネス要件を考慮して最適な保存時間を決定するためにテストを実行しなければならない場合があります。

処理中にExtractで必要とされる、アクティブまたはバックアップ・ログのデータが保存されていない場合、次のいずれかの修正処理が必要になる場合があります。

バイナリ・ログ・データが使用可能な最新の時点からキャプチャを行う(およびターゲットで発生した可能性のあるデータ損失を受け入れる)ようにExtractを修正します。
ソース表とターゲット表を再同期してから、Oracle GoldenGate環境を再開します。

Extractのチェックポイントの位置を決定するには、INFO EXTRACTコマンドを使用します。詳細は、『Oracle GoldenGateコマンド・ライン・インタフェース・リファレンス』のINFO EXTRACTを参照してください。

親トピック: トランザクション・ログの設定および要件

ログ・パラメータの設定

MySQLのトランザクション・ログから取得するには、Oracle GoldenGate Extractプロセスがすべてのバイナリ・ログ・ファイルのパスを含む索引ファイルを検索できる必要があります。

Extractは、すべての表列がバイナリ・ログに存在するものと想定します。その結果、完全として設定されたbinlog_row_imageがサポートされ、これがデフォルトになります。他の値のbinlog_row_imageはサポートされません。

ノート:

バイナリ・ログは少なくとも24時間保持することをお薦めします。

MySQL 5.7では、server_idオプションをlog-binとともに指定する必要があり、そのようにしないとサーバーが起動しません。MySQL 8.0では、server_idはデフォルトで有効化されます。

Extractは次のパラメータ設定を確認してこの索引ファイル・パスを取得します。

ExtractのTRANLOGOPTIONSパラメータとALTLOGDESTオプション。このパラメータでログ索引ファイルの場所が指定されている場合、Extractでは、MySQLサーバー構成ファイルで指定されているデフォルトよりもこの場所を優先します。ALTLOGDESTが使用される場合、バイナリ・ログ索引ファイルも指定されたディレクトリに格納される必要があります。このパラメータは、MySQL構成ファイルで索引ファイルのフル・パス名が指定されていないか、間違った場所が指定されている場合、または同じマシンに複数のMySQLのインストールがある場合に使用されます。Oracle GoldenGate 21c以降、ALTLOGDESTパラメータはローカルExtractではオプションですが、リモートExtractの場合、このパラメータは必須です。ALTLOGDESTが指定されていない場合、バイナリ・ログ索引およびバイナリ・ログ・ファイルパスはデータベースから直接フェッチされます。このようにフェッチされるパスも、既存のプロセスと同じアクセシビリティ・チェックの対象となります。

TRANLOGOPTIONSをALTLOGDEST,とともに使用して索引ファイル・パスを指定するには、次のようなコマンドを使用します。

TRANLOGOPTIONS ALTLOGDEST "/mnt/rdbms/mysql/data/logs/binlog.index"

リモート・サーバーから取得する場合、またはリモート取得の場合は、リモート・サーバー上の索引ファイル・パスのかわりにREMOTEオプションを指定するのみで済みます。リモート取得の場合は、Extractパラメータ・ファイルで次のように指定します。

TRANLOGOPTIONS ALTLOGDEST REMOTE
MySQLサーバー構成ファイル: 構成ファイルには、MySQLのサーバーとクライアントのデフォルト起動オプションが格納されます。Windowsでは、構成ファイルの名前はmy.iniです。他のプラットフォームでは、my.cnfです。ALTLOGDEST付きのTRANLOGOPTIONSが指定されていない場合、Extractは構成ファイルからログ・ファイルの場所に関する情報を取得します。ただし、ALTLOGDESTを指定している場合でも、次のExtractパラメータは正しく設定する必要があります。
- binlog-ignore-db=oggddl: DDLログ履歴表がbinlogに入力されないようにします。これはmy.cnfまたはmy.iniファイルで設定されます。
- log-bin: このパラメータは、バイナリ・ロギングの有効化に使用されます。このパラメータはバイナリ・ログ索引ファイルの場所も指定します。ALTLOGDESTが使用される場合でもOracle GoldenGateの必須パラメータです。log-binが指定されていないと、バイナリ・ロギングが無効になり、Extractからエラーが返されます。
- log-bin-index: このパラメータでは、バイナリ・ログ索引の場所を指定します。使用されていない場合、Extractは索引ファイルがログ・ファイルと同じ場所にあるとみなします。このパラメータが使用され、バイナリ・ログが含まれるディレクトリとは異なるディレクトリが指定されている場合、Extractの起動後、バイナリ・ログは移動できません。
- max_binlog_size: このパラメータでは、バイナリ・ログ・ファイルのサイズをバイト単位で指定します。
  
  ノート:
  
  現在のログのサイズがmax_binlog_size値に達すると、新しいファイルにロールオーバーする前にトランザクションの記録を終了する必要がある場合を除き、サーバーでは新しいバイナリ・ログ・ファイルが自動的に作成されます。
- binlog_format: このパラメータでは、ログの形式を設定します。ROWという値に設定する必要があります。これによって、DML文をバイナリ形式で記録するようデータベースに指示されます。Extractは、ROW以外のbinlog_formatが検出されたときに、異常終了するのではなく、ROW形式で書き込まれていないbinlogイベントを何もせずに無視します。
  
  ノート:
  
  MySQLのバイナリ・ロギングでは、特定の表についてロギングを有効または無効にすることはできません。データベースのすべての表にグローバルに適用されます。
- mysql.rds_set_configuration: MySQL Amazon RDSインスタンスから取得する場合、MySQLコマンドラインでmysql.rds_set_configuratonストアド・プロシージャをコールして、特定の期間のバイナリ・ログを保持する必要があります。デフォルトでは、MySQL Amazon RDSのbinlog_retention_hoursのデフォルト値はNULLに設定されています。これは、バイナリ・ログが保持されないことを意味します。
  
  次の例は、バイナリ・ログを24時間保持するコマンドを示しています。
  
  mysql > call mysql.rds_set_configuration('binlog retention hours', 24);
構成ファイルを検出するために、ExtractはMYSQL_HOME環境変数を確認します。MYSQL_HOMEが設定されている場合、Extractは指定されたディレクトリの構成ファイルを使用します。MYSQL_HOMEが設定されていない場合、Extractはinformation_schema.global_variables表に問い合せてMySQLのインストール・ディレクトリを決定します。構成ファイルがそのディレクトリにある場合、Extractはそれを使用します。
MariaDBバージョン10.2以降では、Oracle GoldenGateはMySQLの場合と同様に動作しますが、my.cnfファイルまたはmy.iniファイルで新しい変数を構成する必要があります。追加する必要がある変数は、binlog-annotate-row-events=OFFです。この変数を構成した後、MariaDBを再起動し、抽出プロセスを開始します。

親トピック: トランザクション・ログの設定および要件

log-binの場所の変更

log-bin変数をMySQL構成ファイルで使用してバイナリ・ログの場所を変更すると、索引ファイル内に2つの異なるパス・エントリが生じることになり、エラーが発生する場合があります。エラーの可能性を避けるため、次の操作を行ってlog-binの場所を変更します。

あらゆる新規のDML操作を停止します。
Extractで既存バイナリ・ログのすべての処理を終了します。これは、チェックポイント位置が最終ログのオフセットに達した時間を注記することで確認できます。
Extractがデータの処理を終了したら、Extractグループを停止して、必要ならばバイナリ・ログのバックアップを取ります。
MySQLデータベースを停止します。
新しい場所のlog-binパスを変更します。
MySQLデータベースを起動します。
索引ファイルから古いログ名エントリを消去するには、flush masterまたはreset masterを(MySQLのバージョンに応じて)使用します。
Extractを起動します。

親トピック: トランザクション・ログの設定および要件

MySQLレプリケーション・スレーブを使用した取得

MySQLレプリケーション・スレーブを構成して、マスターのバイナリ・ログ・イベントをスレーブから取得できます。

通常、スレーブによって適用されるトランザクションは、スレーブのbinlogではなくリレー・ログに記録されます。スレーブがマスターから受け取るトランザクションをbinlogに書き込むには、Oracle GoldenGateの他のバイナリ・ログ・パラメータとともに、my.cnfでlog-slave-updatesオプションを1に指定して、レプリケーション・スレーブを起動する必要があります。マスターのトランザクションがスレーブのbinlogに書き込まれた後で、通常のOracle GoldenGateキャプチャをスレーブに対して設定すると、スレーブのbinlogを取得して処理できます。

親トピック: トランザクション・ログの設定および要件