Oracle GoldenGate入門｜データレプリケーションの仕組みと基礎をわかりやすく解説

はじめに
Oracle GoldenGateとは
Oracle GoldenGateのアーキテクチャ
Oracle GoldenGate導入にあたり考慮すべき点
GoldenGate停止に対する対処
1. ディスク容量設計
2. ディスク容量超過時の対応ケース
まとめ
参考文献

はじめに

Oracle GoldenGateは、異なるデータベース間でリアルタイムにデータを複製できる高機能なレプリケーション製品です。本記事では、Oracle GoldenGateの基本的な仕組みや特徴に加えて、導入・設計・運用時に役立つノウハウを解説します。

GoldenGateを活用することで、データベースの高可用性を確保し、災害対策やシステム移行、異種データベース間のデータ連携など幅広い用途に対応できます。他の製品と比較しても優れた機能を持っているため、これから適用を検討している方や、すでに運用している方にとって有益な情報となるでしょう。

Oracle GoldenGateとは

Oracle GoldenGateは、異なるデータベース間でリアルタイムにデータレプリケーションを実現するソフトウェア製品です。高可用性の確保やシステム移行、異種データベース連携など、さまざまな用途で利用されています。主なユースケースは以下の通りです。

遠隔地へのデータレプリケーション（災害対策・分析環境）
商用環境の重要なデータを遠隔地にリアルタイムで複製することで、災害対策（Disaster Recovery）として迅速な復旧が可能になります。さらに、分析用データベースにデータを切り出すことで、本番環境に負荷をかけずにデータ分析を行うこともできます。

データ移行（Database Migration）
ハードウェアリプレースやシステム更改の際、既存データベースから新しい環境へスムーズに移行できます。異なるバージョン間の移行はもちろん、異種データベース間の移行（例：OracleからPostgreSQL）にも対応可能です。他の移行手法と比べて、GoldenGateはダウンタイムを最小限に抑えながら移行を行える点が大きなメリットです。

Oracle GoldenGateのアーキテクチャ

Oracle GoldenGateのコンポーネント

Oracle GoldenGateによるレプリケーションを実現するためのコンポーネントをご紹介します。

ノード	コンポーネント名	主な機能
ノード共通	Manager	・プロセス管理：ExtractやReplicatなど各種プロセスの起動・停止、監視、自動リカバリを行う。ソース・ターゲット両ノードに必要。・Trailファイル管理：Trailファイルの作成や自動削除を実施。
	Trail File	・データ更新情報の記録：データベースの更新内容を保持するバイナリ形式のファイル。・同期：ソースノードからターゲットノードへ連携することで更新内容を反映。
ソースノード	Extract (Capture)	・データ抽出：REDOログから変更内容をリアルタイムで読み取り。条件指定で抽出対象を絞ることも可能。・Trailファイル書き込み：抽出した情報をLocal Trail Fileに保存。
	Extract (Data Pump)	・データ転送：Local Trail Fileの内容をターゲットノードへ送信。
ターゲットノード	Collector	・データ受信：ソースノードから送信されたデータを受信。・Trailファイル作成：受信データからRemote Trail Fileを生成。
	Replicat	・データ適用：Remote Trail Fileの内容をターゲットデータベースに適用。条件指定で適用対象を絞ることも可能。

Oracle GoldenGateによるデータレプリケーションの流れ

ここでは片方向レプリケーションを例に説明します。

ソースデータベースで変更発生
・INSERT、UPDATE、DELETEが発生。
Extractが変更内容を取得
・REDO Log（トランザクションログ）を監視して変更を取得。
・必要な変更だけをLocal Trail Fileに書き出す。
　※Trail Fileを使うことで、データベースを直接参照せずに安全にデータを転送可能。
Data Pumpで転送
・Local Trail Fileを遠隔地のターゲットノードへ送信。
　※ネットワーク障害時も再送可能。
Collectorがデータを受信
・ソースノードから送信されたデータを受信。
・受信データからRemote Trail Fileを生成。
Replicatがターゲットに適用
・Remote Trail Fileを読み込み、ターゲットデータベースに変更を適用。
　※トランザクション単位で適用されるため、一貫性が保たれる。

Oracle Real Application Clusters（RAC）におけるアーキテクチャ

Oracle RAC環境にOracle GoldenGateを導入する場合のアーキテクチャを説明します。
GoldenGateはActive-Active構成をサポートしていないため、Active-Standby構成を採用する必要があります。ここでは、2台構成のNode 1側にGoldenGateを配置する例を示します。

構成と通信の概要
ソースノードにはVIP（Virtual IP）を設定しており、片方のノードで障害が発生しても、ソース側は意識せずターゲット側と通信できます。

フェイルオーバ動作（ソース側）
もしソースNode 1で障害が発生した場合、GoldenGate関連のリソースはソースNode 2にフェイルオーバします。
フェイルオーバ後は、ソースNode 2とターゲットNode 1間でデータの同期が継続されます。

フェイルオーバ動作（ターゲット側）
ターゲットノードで障害が発生した場合も同様に、リソースがもう一方のノードに切り替わり、同期が継続されます。

Oracle GoldenGate導入にあたり考慮すべき点

プロセス監視

GoldenGate の安定稼働には、各種プロセスの死活監視が欠かせません。特に Manager、Extract、Replicat、Collector は障害時に処理が停止してしまうため、監視対象として必ず押さえておく必要があります。

監視方法としては以下が代表的です。

監視ソフトによる監視：Zabbixなどのツールでプロセスの稼働状況を監視する
アクションスクリプトによる監視：プロセスの異常終了や処理遅延をトリガーに、再起動や通知を自動実行する

アクションスクリプトは、あらかじめ定義した条件に応じて実行されるスクリプトであり、GoldenGate運用における自動復旧やリカバリの仕組みとして有効です。たとえば以下のような活用が一般的です。

指定間隔で状態を確認し、停止していたら自動起動する
エラー発生時にログを採取し、通知と同時に再起動を試みる
cron など OS のジョブスケジューラを利用して定期実行する

監視の仕組みを導入することで、障害の早期検知・自動復旧が可能になり、システム全体の可用性を大幅に高めることができます。

ログ監視

Oracle Database の trace ログや alert ログは、GoldenGate 導入に限らず多くの環境で監視対象に含まれます。加えて、GoldenGate 固有の事象は ggserr.log に出力されるため、このファイルを必ず監視対象に追加してください。

初期段階では、Error、WARNING、abnormallyといったメッセージを抽出対象とすることで、主要な障害や注意事項を検知できます。その後は運用状況に応じて、監視条件を段階的にチューニングしていくことが重要です。

タイムラグの監視

データレプリケーションにおけるラグ（Extract/Replicat が最後に処理したレコードの時間と Trail File 内のレコードのタイムスタンプとの差）を監視しましょう。一時的なピーク処理によるラグは通常問題ありませんが、ラグが解消されない場合や、ラグの値が大きくなる場合はチューニングが必要です。

GoldenGate では、ラグの閾値を設定するために以下のパラメータが用意されています：

LAGCRITICALSECONDS：ラグが秒単位で閾値を超えた場合に警告を出力
LAGCRITICALMINUTES：ラグが分単位で閾値を超えた場合に警告を出力
LAGCRITICALHOURS：ラグが時間単位で閾値を超えた場合に警告を出力

いずれかのパラメータに閾値を設定することで、設定した閾値を超えた場合にエラーログに警告メッセージを出力させることができます。これにより、タイムラグの早期検知と適切なチューニングが可能となります。

Trail File 格納用ディスク容量の監視

Trail File を格納しているディスクがいっぱいになると、GoldenGate によるデータレプリケーションが停止する可能性があります。そのため、ディスク容量の監視を導入することは非常に重要です。

Oracle RAC 構成では、共有ストレージ上（例：ACFS）に Trail File を配置することが推奨されます。この場合、ACFS 領域の容量を必ず監視対象に含めるようにしてください。

GoldenGate停止に対する対処

GoldenGateが正常に稼働している場合は大きな問題はありませんが、メンテナンスや障害による停止を想定した設計と対策を検討することが重要です。

ディスク容量設計

GoldenGate停止中はTrail Fileが蓄積されるため、ディスク容量を十分に確保しておく必要があります。

Trail Fileの容量見積り
Trail File disk space = (Source REDO log size per hour) × (Allowed GoldenGate downtime in hours) × 0.4
参考：Estimate Space for the Trails
Trail Fileの保持期間設定
デフォルトでは、処理完了後に自動削除
詳細設定は PURGEOLDEXTRACTS パラメータで制御可能
– USECHECKPOINTS（デフォルト）：すべてのプロセスが処理完了した時に削除
– MINKEEPHOURS：指定時間保持
– MINKEEPDAYS：指定日数保持
– MINKEEPFILES：指定数保持

ディスク容量超過時の対応ケース

ソースノードのExtractにてトラブルが発生した場合

・状況：REDO log から Local Trail File が作成されない。
・復旧：Extract 復旧後に Local Trail File を作成可能ですが、そのためには Archive REDO log が必要です。
・注意点：
– Archive REDO log の保存期間は設計段階で長めに設定してください。
– 必要に応じて、トラブル発生後に保存期間を変更し、自動削除されないよう注意してください。
– Archive redo log を保持するためのディスク容量設計も重要です。
・代替策：
– ディスク容量が不足する場合は、RMAN を用いて Archive redo log を一時退避し、GoldenGate 復旧後に復元することを検討してください。

ソースノードの Datapump / ノード間ネットワーク / リモートノードの Collector にトラブルが発生した場合

・状況：Local Trail File は作成されるが、Remote Trail File が作成されない。
・復旧：トラブル復旧後に Remote Trail File を作成可能。ただし、Local Trail File が残っている必要があります。
・注意点：
– Local Trail File がターゲットノードに送信されないと削除されない設計の場合、Trail File を格納するディスク容量に余裕を持たせてください。
– 時間経過で削除する設計の場合は、保存期間を長めに設定するか、トラブル発生後に変更して、自動削除されないよう注意してください。

リモートノードのReplicatでトラブルが発生した場合

・状況：Remote Trail File は作成されるが、ターゲットデータベースに反映されない。
・影響：Remote Trail File は存在するため、Local Trail File を保持する必要はありません。
・注意点：
– Remote Trail File が削除されない設計の場合、Trail File を格納するディスク容量に余裕を持たせてください。
– 時間経過で削除する設計の場合は、保存期間を長めに設定するか、トラブル発生後に変更して、自動削除されないよう注意してください。