1. Microservices Architectureドキュメント
  2. 準備
  3. データベースの準備
  4. MySQL
  5. 処理のための表の準備

処理のための表の準備

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

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

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

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

  1. 主キー

  2. タイムスタンプまたはマテリアライズされていない計算結果列を含まない英数字順で最初の一意キー。

  3. 前述のキー・タイプのいずれも存在しない場合(その他の種類のキーが表に定義されている場合でも)、Oracle GoldenGateは、データベースで一意キーでの使用を許可されているすべての列(キー内での使用がOracle GoldenGateでサポートされていない列やOracle GoldenGate構成から除外されている列は除く)で疑似キーを作成します。

    ノート:

    表に使用可能な他のキーがない場合や、表にキーがまったくない場合、Oracle GoldenGateは該当するメッセージをレポート・ファイルに記録します。すべての列からキーを作成すると、ソース・システムのOracle GoldenGateのパフォーマンスが低下します。ターゲットでは、このキーはReplicatであまり効率的でないより大きいWHERE句が使用される原因となります。

  4. 表に適切なキーがない場合、あるいは既存のキーを使用しない場合は、表に一意の値が常に含まれる列があれば、代替キーを定義できます。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を参照してください。

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