| Oracle® Fusion Middleware MySQLのためのOracle GoldenGateのインストールおよび構成 12c (12.2.0.1) E70105-02 |
|
 前 |
 次 |
この章では、Oracle GoldenGateを実行するためのシステムの準備の手順について説明します。次の項で構成されます。
十分なバイナリ・ログ・データを保持し、Extractを停止した場合、または計画外の停止が発生した場合に、Extractをチェックポイントから再開できるようにします。Extractには、コミットされていない最も古い作業単位の開始点を含むバイナリ・ログ、およびそれ以降のすべてのバイナリ・ログへのアクセス権が必要です。推奨される保存期間は、少なくとも24時間は対応可能な、アクティブな情報とアーカイブされた情報の両方を含むトランザクション・データです。データ・ボリュームやビジネス要件に応じた最適な保存時間を判断するために、なんらかのテストが必要になる場合があります。
処理中にExtractで必要とされる、アクティブまたはバックアップ・ログのデータが保存されていない場合、次のいずれかの修正処理が必要になる場合があります。
バイナリ・ログ・データが使用可能な最新の時点からキャプチャを行う(およびターゲットで発生した可能性のあるデータ損失を受け入れる)ようにExtractを修正します。
ソース表とターゲット表を再同期化して、Oracle GoldenGate環境を設定からやり直します。
Extractのチェックポイントの場所を確認するには、INFO EXTRACTコマンドを使用します。詳細は、『Oracle GoldenGate for Windows and UNIXリファレンス』を参照してください。
MySQLのトランザクション・ログからキャプチャするには、Oracle GoldenGate Extractプロセスが索引ファイルを検索できる必要があります。その索引ファイルにはすべてのバイナリ・ログ・ファイルのパスが含まれます。
|
注意: Extractは、すべての表列がバイナリ・ログに存在するものと想定します。その結果、fullと設定されているbinlog_row_imageのみがサポートされ、これがデフォルトになります。他の値のbinlog_row_imageはサポートされません。 |
Extractは次のパラメータ設定を確認してこの索引ファイル・パスを取得します。
ALTLOGDESTオプションを指定したExtract TRANLOGOPTIONSパラメータ: このパラメータでログ索引ファイルの場所が指定されている場合、Extractは、MySQLサーバー構成ファイルで指定されたデフォルトよりこの場所を優先します。ALTLOGDESTが使用される場合、バイナリ・ログ索引ファイルも指定されたディレクトリに格納される必要があります。このパラメータは、MySQL構成ファイルで索引ファイルのフル・パス名が指定されていないか、間違った場所が指定されている場合、または同じマシンに複数のMySQLのインストールがある場合に使用されます。
索引ファイル・パスをTRANLOGICOPTIONS、ALTLOGDESTとともに指定するには、次のコマンド形式をWindowsで使用します。
TRANLOGOPTIONS ALTLOGDEST "C:\\Program Files\\MySQL\\logs\\binlog.index"
Linuxでは次の形式を使用します。
TRANLOGOPTIONS ALTLOGDEST "/mnt/rdbms/mysql/data/logs/binlog.index"
MySQLサーバー構成ファイル: 構成ファイルには、MySQLのサーバーとクライアントのデフォルト起動オプションが格納されます。Windowsでは、構成ファイルの名前はmy.iniです。他のプラットフォームでは、my.cnfです。ALTLOGDESTを指定したTRANLOGOPTIONSがない場合、Extractは構成ファイルからログ・ファイルの場所に関する情報を取得します。ただし、ALTLOGDESTが指定されている場合でも、Extractで必要とするパラメータがいくつかあり、正しく設定されている必要があります。
log-bin: このパラメータは、バイナリ・ロギングの有効化に使用されます。このパラメータはバイナリ・ログ索引ファイルの場所も指定します。ALTLOGDESTが使用される場合でもOracle GoldenGateの必須パラメータです。log-binが指定されていないと、バイナリ・ロギングが無効になり、Extractからエラーが返されます。
log-bin-index: このパラメータでは、バイナリ・ログ索引の場所を指定します。使用されていない場合、Extractは索引ファイルがログ・ファイルと同じ場所にあるとみなします。このパラメータが使用され、バイナリ・ログが含まれるディレクトリとは異なるディレクトリが指定されている場合、Extractの起動後、バイナリ・ログは移動できません。
max_binlog_size: このパラメータでは、バイナリ・ログ・ファイルのサイズをバイト単位で指定します。
|
注意: 現在のログのサイズがmax_binlog_size値に達すると、新しいファイルにロールオーバーする前にトランザクションの記録を終了する必要がある場合を除き、サーバーでは新しいバイナリ・ログ・ファイルが自動的に作成されます。 |
binlog_format: このパラメータでは、ログの形式を設定します。ROWという値に設定する必要があります。これによって、DML文をバイナリ形式で記録するようデータベースに指示されます。その他のログ形式(MIXEDまたはSTATEMENT)を使用すると、Extractは異常終了します。
|
注意: MySQLのバイナリ・ロギングでは、特定の表についてロギングを有効または無効にすることはできません。データベースのすべての表にグローバルに適用されます。 |
構成ファイルを検出するために、ExtractはMYSQL_HOME環境変数を確認します。MYSQL_HOMEが設定されている場合、Extractは指定されたディレクトリの構成ファイルを使用します。MYSQL_HOMEが設定されていない場合、Extractはinformation_schema.global_variables表に問い合せてMySQLのインストール・ディレクトリを決定します。構成ファイルがそのディレクトリにある場合、Extractはそれを使用します。
Oracle GoldenGateは、接続先のデータベースの名前をSOURCEDBパラメータから取得します。接続の成功は、システム・ホスト・ファイルで適切に構成されているlocalhostエントリに依存します。不適切なローカル・ホスト構成によって問題が生じないようにするには、SOURCEDBを次のように使用します。
SOURCEDB database_name@host_name
説明: database_nameはMySQLインスタンスの名前で、host_nameはローカル・ホストの名前またはIPアドレスです。修飾されていないホスト名を使用する場合、名前はDNSデータベースに適切に構成されている必要があります。そうでない場合、完全修飾されたホスト名(myhost.company.comなど)を使用します。
ExtractプロセスとReplicatプロセスは、データベースの接続時、セッション・キャラクタ・セットを使用します。MySQLでは、セッション・キャラクタ・セットは、SOURCEDBおよびTARGETDBのSESSIONCHARSETオプションから取得されます。Oracle GoldenGateを構成する際、これらのいずれかでセッション・キャラクタ・セットを必ず指定してください。
双方向構成では、各システムのトランザクション変更をもう一方のシステムにレプリケーションすることをサポートするために、ソースおよびターゲットの両方のシステムにExtractおよびReplicatプロセスがあります。この構成をサポートするには、適用されたトランザクションが再キャプチャされてソースに送られることが繰り返されることのないよう、各ExtractがローカルのReplicatで適用されたトランザクションをフィルタできる必要があります。さらに、各システムで値の不整合が起こらないようにAUTO_INCREMENT列も設定する必要があります。
Oracle GoldenGate Windows and UNIXの管理の説明に従って、Oracle GoldenGateの高可用性またはアクティブ/アクティブ型のレプリケーションを構成します。
適用された操作がキャプチャされてソースに再度ループバックされないように、双方向構成のReplicat操作をフィルタの対象外にするには、各MySQLデータベースで次のステップを実行します。
チェックポイント表を使用するように各Replicatプロセスを構成します。Replicatでは、各トランザクションの最後にチェックポイントをこの表に書き込みます。1つのグローバルなチェックポイント表を使用することも、Replicatプロセスごとに1つの表を使用することもできます。Oracle GoldenGate Windows and UNIXの管理を参照してください。
Extractパラメータ・ファイルに含まれるTRANLOGOPTIONSパラメータのFILTERTABLEオプションを使用して、チェックポイント表の名前を指定します。Extractプロセスでは、指定された表に対する操作(Replicat操作のみ)で終了するトランザクションは無視されます。
|
注意: チェックポイント表の使用は、サポートされている他のデータベースではリカバリを拡張するためのオプションですが、MySQLで双方向レプリケーションを使用する際には必須です(同様にリカバリも拡張されます)。 |
双方向操作で発生する可能性のある不一致を回避するよう、MySQLサーバー構成ファイルを編集して、auto_increment_incrementおよびauto_increment_offsetパラメータを設定します。ServerAとServerBの2つのサーバーを例として、これらのパラメータを次に示します。
ServerA:
auto-increment-increment = 2 auto-increment-offset = 1
ServerB:
auto-increment-increment = 2 auto-increment-offset = 2
MySQLインストールで次のパラメータを使用できます。デフォルト以外の設定がMySQLデータベースに対して使用される場合、必須です。ビジネス要件や構成によっては、これら以外のOracle GoldenGateパラメータも必要です。
表3-1 MySQLに関するその他のOracle GoldenGateパラメータ
| パラメータ | 説明 |
|---|---|
|
|
MySQLがデフォルトである3306で実行されない場合、Oracle GoldenGateプロセスの接続先のMySQLインスタンスのTCP/IP接続ポート番号をVAMに指定するために必要です。 DBOPTIONS CONNECTIONPORT 3307 |
|
|
Replicatの接続先のシステムをホストしているMySQLのDNS名またはIPアドレスを指定します。 |
|
|
レプリケートするLOBデータがターゲットMySQLの |
|
|
MySQLデータベースに接続するOracle GoldenGateプロセスによって使用されるデータベース、ユーザー名およびパスワードで構成されるデータベース接続情報を指定します。MySQLがデフォルト・ポートである3306で実行されていない場合、
MySQLデータベースをポート3306で実行中ではない場合、GGSCI経由でデータベースに影響するコマンドを発行する際に、 DBLOGIN SOURCEDB dbname@hostname:port, USERID user, PASSWORD password 例: GGSCI> DBLOGIN SOURCEDB mydb@mymachine:3307, USERID myuser, PASSWORD mypassword |
|
|
ReplicatでMySQLの接続タイムアウトを回避できるようにするため、Replicatパラメータ・ファイルの
説明: |
Oracle GoldenGateのパラメータの詳細は、Oracle GoldenGateリファレンスfor Windows and UNIXを参照してください。
ビジネス要件に合うようOracle GoldenGateを構成する方法の詳細は、Oracle GoldenGate Windows and UNIXの管理を参照してください。
この項では、処理のための表の準備方法について説明します。表の準備では次のタスクが必要です。
Oracle GoldenGateでは、レプリケートされた更新や削除に対応する正しいターゲット行を検出するために、ソース表およびターゲット表で特定の形式の一意の行識別子が必要です。
TABLE文またはMAP文でKEYCOLS句を使用しない場合には、Oracle GoldenGateにより、使用される行識別子が次の優先順位で選択されます。
主キー
タイムスタンプまたはマテリアライズされていない計算結果列を含まない英数字順で最初の一意キー
前述のキー・タイプのいずれも存在しない場合(その他の種類のキーが表に定義されている場合でも)、Oracle GoldenGateは、一意キーでデータベースが使用を許可されているすべての列(Oracle GoldenGateによってキーでサポートされていない列やOracle GoldenGate構成から除外される列は除く)の疑似キーを作成します。
|
注意: 表に使用可能な他のキーがない場合や、表にキーがまったくない場合、Oracle GoldenGateは該当するメッセージをレポート・ファイルに記録します。すべての列からキーを作成すると、ソース・システムのOracle GoldenGateのパフォーマンスが低下します。ターゲットでは、このキーはReplicatであまり効率的でないより大きいWHERE句が使用される原因となります。 |
表に主キーがなく、索引付けされた列がNOT NULLである場合、MySQLでは一意索引が主キーにプロモートされます。これらのNOT NULL索引が複数ある場合、最初に作成された索引が主キーになります。Replicatでエラーが発生しないようにするには、ソース表とターゲット表でこれらの索引を同じ順序で作成します。
たとえば、ggvam.empという名前のソース表とターゲット表のそれぞれにfirst、middle、lastという列があり、それらすべてがNOT NULLとして定義されているとします。次の順序で一意索引を作成した場合、表定義が一致しないため、Oracle GoldenGateはターゲットで異常終了します。
ソース:
mysql> create unique index uq1 on ggvam.emp(first); mysql> create unique index uq2 on ggvam.emp(middle); mysql> create unique index uq3 on ggvam.emp(last);
ターゲット:
mysql> create unique index uq1 on ggvam.emp(last); mysql> create unique index uq2 on ggvam.emp(first); mysql> create unique index uq3 on ggvam.emp(middle);
この順序の結果、MySQLでは、ソースの"first"列の索引と、ターゲットの"last"列の索引が主キーにプロモートされます。Oracle GoldenGateでは、メタデータ・レコードの作成時に主キーが識別子として選択されるため、メタデータが一致しなくなります。このエラーを回避するには、主キーにプロモートする列を決定し、ソースおよびターゲットでその索引を最初に作成します。
ターゲット表に主キーまたは一意のキーがない場合、重複する行が存在する可能性があります。この場合、Oracle GoldenGateで更新または削除されるターゲット表の行数が多くなりすぎ、ソース・データとターゲット・データの同期がとれなくなる可能性があります。警告するエラー・メッセージは表示されません。更新される行数を制限するには、Replicatパラメータ・ファイルで、DBOPTIONSパラメータをLIMITROWSオプションとともに使用します。LIMITROWSを使用すると1行しか処理されないため、ターゲット・システムにおけるOracle GoldenGateのパフォーマンスが向上する可能性があります。
ターゲット表のトリガー、カスケード削除制約、カスケード更新制約を無効にするか、これらを変更してOracle GoldenGateデータベース・ユーザーによる変更が無視されるようにします。Oracle GoldenGateでは、トリガーまたはカスケード制約の結果として生成されるDMLがレプリケートされます。同じトリガーや制約がターゲット表でアクティブになった場合、レプリケートされたバージョンのために重複となり、データベースでエラーが返されます。ソース表にemp_srcとsalary_src、ターゲット表にemp_targとsalary_targを使用している次の例について考えます。
emp_srcに対して削除が発行されます。
それによって、削除がsalary_srcにカスケードされます。
Oracle GoldenGateによって、両方の削除がターゲットに送信されます。
親削除が先に届き、emp_targに適用されます。
親削除によって、削除がsalary_targにカスケードされます。
カスケードされたsalary_srcの削除がsalary_targに適用されます。
行は手順5ですでに削除されているため検出できません。
次のコマンドを使用して、トランザクション・ログの特定の開始ポイントにADD EXTRACTおよびALTER EXTRACTコマンドを配置できます。
{ADD | ALTER EXTRACT} group, VAM, LOGNUM log_num, LOGPOS log_pos
groupは、開始ポイントが必要なOracle GoldenGate Extractのグループ名です。
log_numはログ・ファイル番号です。たとえば、必要なログ・ファイルの名前がtest.000034である場合、この値は34です。Extractでは、このログ・ファイルが検索されます。
log_posは、特定のトランザクション・レコードを識別する、ログ・ファイル内のイベント・オフセット値です。イベント・オフセット値は、ログ・レコードのヘッダー・セクションに格納されます。
MySQLログでは、イベント・オフセット値は所定のバイナリ・ファイル内でのみ一意にできます。位置の値とログ番号の組合せにより、トランザクション・レコードが一意に識別されますが、この組合せの長さは37文字を超えることはできません。指定したログ内でこの位置の後に使用可能なトランザクション・レコードが、Extractによってキャプチャされます。
log-bin変数をMYSQL構成ファイルで使用してバイナリ・ログの場所を変更すると、索引ファイル内に2つの異なるパス・エントリが生じることになり、エラーが発生する場合があります。エラーの可能性を避けるため、次の操作を行ってlog-binの場所を変更します。
あらゆる新規のDML操作を停止します。
Extractで既存バイナリ・ログのすべての処理を終了します。これは、チェックポイント位置が最終ログのオフセットに達した時間を注記することで確認できます。
Extractがデータの処理を終了したら、Extractグループを停止して、必要ならばバイナリ・ログのバックアップを取ります。
MySQLデータベースを停止します。
新しい場所のlog-binパスを変更します。
MySQLデータベースを起動します。
索引ファイルから古いログ名エントリを消去するには、flush masterまたはflush logsを(MySQLのバージョンに応じて)使用します。
Extractを起動します。
