1. はじめに
Oracle GoldenGateの適用を検討している方、すでに運用している方向けに、Oracle GoldenGateの概要、設計や運用する際のノウハウをご紹介します。Oracle GoldenGateによるデータレプリケーションは、他のデータベース製品と比較すると優れている機能だと思いますので、ぜひ理解を深めて活用してみてください。
2. Oracle GoldenGateとは
Oracle GoldenGateとはリアルアイムデータレプリケーションを実現するソフトウェアパッケージとなります。主な用途は下記となります。
・遠隔地へのデータレプリケーション
商用環境で運用している重要なデータを、遠隔地にリアルタイムでバックアップする際に有効になります。災害対策環境にリアルタイムでレプリケーションしておくことで、商用環境のデータベースが何らかの原因で壊れた場合でもすぐに復旧することが可能です。あるいは、たとえば分析用のデータベースを切り出すことで、商用環境のデータベースにアクセスすることなくデータ分析を行うこともできます。
・データ移行
ハードリプレースなどの要件で、旧データベースから新データベースサーバに対してデータ移行する際にも有効な手段となります。異なるバージョン間の移行であったり、異なるデータベース製品への移行（OracleからPostgreSQL）を実現することができます。
3. Oracle GoldenGateのアーキテクチャ
3.1 Oracle GoldenGateのアーキテクチャ
Oracle GoldenGateによるレプリケーションを実現するためのコンポーネントをご紹介します。
Oracle GoldenGateによるデータレプリケーションの流れを記載します。双方向レプリケーションも実現可能ですが、理解しやすいように片方向のレプリケーションの仕組みをご説明します。
3.2 Oracle Real Application Clusters（RAC）におけるアーキテクチャ
Oracle GoldenGateをOracle RAC環境に導入する際のアーキテクチャを記載します。GoldenGateのリソースはActive-Active構成をとることはできないので、Active-Standby構成にする必要があります。2台構成のNode 1側にGoldenGateを配置する構成例を記載しています。VIPを設定することで、片方のノードで異常が発生してフェイルオーバしたとしてもソース側は意識せずにターゲット側と通信するようにしています。仮にソースNode 1で障害が起きた場合、ソースNode2側にGoldenGate関連のリソースがフェイルオーバし、ソースNode2とターゲットNode1間でデータのやり取りが行われます。ターゲットNode側で障害が起きた場合も同じ挙動となります。また、GoldenGateのリソースをフェイルオーバさせる際の挙動はアクションスクリプトと呼ばれるスクリプトを作成することで制御するのが一般的かと思います。
4. Oracle GoldenGate導入にあたり考慮すべき点
4.1 GoldenGate監視設計の考慮
□各種プロセスの死活監視
Manager、Extract、Replicat、Collectorの各種プロセスを監視する仕組みを導入しましょう。Zabbixなどによる監視ソフトによるプロセス監視、あるいはアクションスクリプトによる監視を検討してみて下さい。
※アクションスクリプト
Oracle GoldenGateのアクションスクリプトとは、指定した条件に応じて自動的に実行されるスクリプトであり、GoldenGate関連プロセスの監視や、状態に応じた自動処理を実装することができます。指定したタイミングで状態を確認して、停止状態になっていたら自動起動するような処理を実行させるといった用途が一般的かと思います。プロセス異常終了などのエラー、処理遅延などをトリガーとして実行する方法や、cron設定でOSから起動させる方法などがありますので、要件に応じた起動トリガーを検討いただければと思います。
□ログ監視
OracleのtraceログやalertログについてはGoldenGate導入にかかわらず監視対象にしていることが多いかと思いますが、GoldenGateに特化した事象はggserr.logというログに出力されますので、こちらを監視対象に追加しましょう。一旦は、WARNINGの文言を抽出対象にすればよいかと思いますが、運用していく中で実態に合わせてチューニングしていってください。
□タイムラグの監視
データレプリケーションのラグ(Extract/Replicatが最後のレコードを処理した時間とTrail File内のレコードのタイムスタンプとの時間差)を監視しましょう。一時的なピーク処理によるラグ発生であれば問題ありませんが、ラグが解消されない、あるいはラグの値が大きくなるようであればチューニングが必要です。LAGCRITICALSECONDS、LAGCRITICALMINUTES、LAGCRITICALHOURSのいずれかの閾値を設定すると、閾値を超えた際にエラーログに警告メッセージを出力させることができます。
□Trail File格納用のディスク容量監視
Trail Fileを格納しているディスクがいっぱいになってしまうと、GoldenGateによるデータレプリケーションができなくなりますので、容量監視を導入することは非常に重要です。Oracle RAC構成であれば、共有領域である/acfs領域に格納するのが一般的かと思いますので、本領域を監視するようにしてください。
4.3 GoldenGate停止期間の考慮
GoldenGateが正常に動作している状況ではあまり気にすることはないですが、メンテナンスやトラブルによりGoldenGateが停止する期間が発生することを考慮した設計をすることが重要です。まずは、Archive REDOログあるいはTrail Fileを格納するディスク領域の容量設計を適切に行いましょう。Archive REDOログよりもTrail Fileの方が容量が小さいので、個人的にはTrail Fileを長期間保存できるような容量設計をしておく方が良いかと考えております。
※Trail Fileのディスク領域の見積り方法
Trail Fileディスク領域容量 = ソース側のREDOログ容量/時間 × 許容するGoldenGate停止期間 × 0.4
https://docs.oracle.com/cd/G13662_01/coredoc/extract-estimate-space-trails.html
※Archive REDOログの保持期間設定
下記のRMANコマンドを実行することで、アーカイブREDOログの保存期間を設定することができます。データベース稼働中に実行することが可能です。
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
※Trail Fileの保持期間設定
デフォルトでは、対象のTrail Fileに対する処理が完了したら自動削除される設定になっておりますが、保持の条件を細かく指定することも可能です。PURGEOLDEXTRACTSパラメータにて設定することが可能です。たとえば下記のような設定項目があります。
USECHECKPOINTS（デフォルト）：すべてのプロセスがファイルの処理を完了したことがチェックポイントによって示されたときにパージをトリガーします。
MINKEEPHOURS：設定した時間はデータを保持する。
MINKEEDAYS：設定した日数はデータを保持する
MINIKEEPFILES：設定した数のTrail Fileを保持する。
続いて、ディスク容量設計を超えるほどのGoldenGate停止が発生する場合の対処としては、いくつか考えられるケースがありますのでケースごとに説明をさせていただきます。
ソースノードのExtractにてトラブルが発生した場合
REDO LogからLocal Trail Fileが作成されない状況になります。Extract復旧後にLocal Trail Fileを作成することは可能ですが、そのためにはREDO LogおよびArchive REDO Logが必要となります。Archive REDO Logの保存期間を設計段階である程度長く設定しておく、あるいはトラブル起きてから保存期間を変更することで、自動削除されてしまわないように気を付けましょう。また、Archive REDO Logを保存しておくために適切なディスク容量設計をしておくことも重要です。どうしてもディスク容量がいっぱいになってしまう場合は、RMANを用いてArchive REDOログを一時的に退避しておいて、GoldenGate復旧後に復元するという方法もありますので、検討してみると良いかと思います。
ソースノードのDatapump/ノード間のネットワーク/リモートノードのCollectorのいずれかでトラブルが発生した場合
Local Trail Fileは作成されるが、Remote Trail Fileが作成されない状態になります。トラブル復旧後にRemote Trail Fileを作成することは可能ですが、そのためにはLocal Trail Fileが残っている必要があります。Local Trail Fileがターゲットノード側に送信されないと削除されない設計としている場合は、Trail Fileを格納している領域が溢れないようなディスク容量設計が必要です。Trail Fileを時間経過によって削除する設計にしている場合は、保存期間を設計段階である程度長く設定しておく、あるいはトラブル起きてから保存期間を変更することで、自動削除されてしまわないように気を付けましょう。
リモートノードのReplicatでトラブルが発生した場合
Remote Trail Fileは作成されるが、ターゲットデータベースに反映されない状況を想定しています。Remote Trail Fileが作成できているので、Local Trail Fileを保持しておく必要はありませんが、Remote Trail Fileが消失しないようにする必要があります。Remote Trail Fileがターゲットデータベースに反映されないと削除されない設計としている場合は、Trail Fileを格納している領域が溢れないようなディスク容量設計が必要です。Trail Fileを時間経過によって削除する設計にしている場合は、保存期間を設計段階である程度長く設定しておく、あるいはトラブル起きてから保存期間を変更することで、自動削除されてしまわないように気を付けましょう。
6. まとめ
Oracle GoldenGateに関する基礎知識のご紹介は以上となります。商用運転している状況においては、GoldenGate関連のトラブルが起きることは少ないかもしれないですが、試験実施中はソースデータベースとターゲットデータベース間の不整合などが原因でかなりトラブル起きる印象があります。アーキテクチャの基本を抑えて適切なトラブル対処が迅速にできるようになるべく、私もさらに理解を深めていきたいと思います。ここまで読んでいただきありがとうございました。
Oracle関連の記事は他にもいくつか記載をしてますので、興味がある方は覗いて行ってもらえると嬉しいです。
Oracle RACの仕組みを理解しよう ～キャッシュフュージョンによるブロック転送～
Oracle RACの仕組み解説 ～データベース接続・負荷分散～
【Oracle】AWRレポートの見方および解析観点のご紹介
【Oracle19c】目指せOracle Master ～学習環境の構築方法～
コメント