1. Oracle GoldenGate for Distributed Applications and Analytics
  2. データの複製
  3. ターゲット
  4. MongoDB

8.2.23 MongoDB

MongoDBハンドラの使用方法を学習します。このハンドラにより、Oracle GoldenGateからターゲットのMongoDBおよびAutonomous JSONデータベース(AJDおよびATP)にトランザクション・データを複製できます。

親トピック: ターゲット

8.2.23.1 概要

Mongodbハンドラは、MongoDB Wire Protocolを使用して、RDMSおよびMongodbやCassandraなどのドキュメント・ベースのデータベースを次のターゲット・データベースに複製するために使用できます

親トピック: MongoDB

8.2.23.2 MongoDB Wire Protocol

MongoDB Wire Protocolは、単純なソケット・ベースのリクエスト・レスポンス・スタイル・プロトコルです。クライアントは、通常のTCP/IPソケットを介してデータベース・サーバーと通信します。https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/を参照してください。

親トピック: MongoDB

8.2.23.3 サポートされているターゲット・タイプ

  • MongoDBは、高パフォーマンス、高可用性および自動スケーリングを提供するオープン・ソースのドキュメント・データベースです。https://www.mongodb.com/を参照してください。

  • Oracle Autonomous JSON Database (AJD)は、JSON中心のアプリケーションの開発を簡素化するクラウド・ドキュメント・データベース・サービスです。Autonomous JSON Database | Oracleを参照してください。

  • トランザクション処理および混合ワークロード(ATP)用のAutonomous Databaseは、トランザクション、分析およびバッチ・ワークロードを同時に実行するように最適化された、完全に自動化されたデータベース・サービスです。Autonomous Transaction Processing | Oracleを参照してください。

  • MongoDBのデータベースAPIを使用したオンプレミスのOracle Database 21cもサポートされているターゲットです。Oracle DatabaseのためのMongoDBのデータベースAPIのインストールを参照してください。

親トピック: MongoDB

8.2.23.4 詳細な機能

MongoDBハンドラは、ソース証跡ファイルから操作を取得し、対応するドキュメントをターゲットのMongoDBまたはAutonomousデータベース(AJDおよびATP)に作成します。

MongoDBでは、レコードはバイナリJSON (BSON)ドキュメントで、フィールドと値のペアで構成されるデータ構造です。BSONデータ構造は、JSONドキュメントのバイナリ形式です。MongoDBドキュメントはJSONオブジェクトに似ています。フィールドの値には、他のドキュメント、配列、およびドキュメントの配列を含めることができます。

コレクションはMongoDBまたはAJD/ATPドキュメントのグループであり、RDBMSの表に相当します。MongoDBやAJD/ATPのデータベースでは、コレクションがドキュメントの集合を保持します。コレクションはスキーマを強制しません。コレクション内のMongoDBまたはAJD/ATPドキュメントは、異なるフィールドを持つことができます。

親トピック: MongoDB

8.2.23.4.1 ドキュメント・キー列

MongoDBまたはAJD/ATPデータベースでは、すべてのドキュメント(行)に_idという名前の列が必要で、その値はコレクション(表)内で一意である必要があります。これは、RDBMS表の主キーに似ています。挿入時に、ドキュメントに最上位の_id列が含まれていない場合、MongoDBドライバによってこの列が追加されます。

MongoDBハンドラは、証跡レコードの主キー列値に基づいて、すべてのドキュメントのカスタム_idフィールド値を構築します。このカスタム_id は、: (コロン)セパレータで連結されたすべてのキー列値を使用して構築されます。たとえば: 

KeyColValue1:KeyColValue2:KeyColValue3

MongoDBハンドラは、このカスタム_id値に基づいて、一意性を強制します。つまり、証跡のすべてのレコードが、主キー列値に基づいて一意である必要があります。同じ表に一意でないレコードが存在すると、MongoDBハンドラ障害が発生し、Replicatは重複キー・エラーで異常終了します。

_idフィールドの動作は次のとおりです。

  • デフォルトでは、MongoDBは、コレクションの作成時に列の一意の索引を作成します。

  • これは常にドキュメントの最初の列になります。

  • 配列を除く任意のBSONデータ型の値を使用できます。

親トピック: 詳細な機能

8.2.23.4.2 主キーの更新操作

MongoDBまたはAJD/ATPデータベースでは、_id列の変更は許可されていません。つまり、証跡内の主キーの更新操作レコードには、特別な処理が必要です。MongoDBハンドラは、主キーの更新操作をDELETE (古いキー)とINSERT (新しいキー)の組合せに変換します。INSERTを実行するには、証跡内の更新操作の完全な操作前イメージが推奨されます。Oracle GoldenGateのGETUPDATEBEFORESおよびNOCOMPRESSUPDATESパラメータを有効にして、更新操作の完全な操作前イメージを移入する証跡を生成できます。『Oracle GoldenGateリファレンス』を参照してください。

親トピック: 詳細な機能

8.2.23.4.3 MongoDB証跡のデータ型

MongoDBハンドラは、次に示すBSONデータ型への配信をサポートします。

  • 32ビットの整数

  • 64ビットの整数

  • 倍精度

  • 日付

  • 文字列

  • バイナリ・データ

親トピック: 詳細な機能

8.2.23.5 MongoDBハンドラの設定および実行

次の各トピックでは、MongoDBハンドラのコンポーネントの構成およびこのハンドラの実行の手順について説明します。

親トピック: MongoDB

8.2.23.5.1 クラスパス構成

MongoDB Java Driverは、Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)でMongoDBに接続しデータをストリーミングするために必要です。GG for DAAのバージョンが21.7.0.0.0以下である場合は、3.x (MongoDB Java Driver 3.12.8)を使用する必要があります。GG for DAAのバージョンが21.8.0.0.0以上である場合は、MongoDB Java Driver 4.6.0を使用する必要があります。MongoDB Java Driverは、GG for DAA製品に含まれていません。ドライバはmongo java driverからダウンロードする必要があります。

推奨されるドライバJARファイルをダウンロードするには、mongo-java-driverとバージョンを選択します。

実行時にMongoDB Java Driver JARをロードするには、gg.classpath変数を構成する必要があります。たとえば: gg.classpath=/home/mongodb/mongo-java-driver-3.12.8.jar。

GG for DAAでは、MongoDB 3.4に追加されたMongoDB Decimal 128データ型がサポートされています。3.12.8より前のMongoDB Java Driverを使用すると、ClassNotFound例外が発生します。

親トピック: MongoDBハンドラの設定および実行

8.2.23.5.2 MongoDBハンドラ構成

MongoDBハンドラの操作は、プロパティ・ファイルを使用して構成します。これらのプロパティは、Javaアダプタ・プロパティ・ファイルにあります(Replicatプロパティ・ファイルにはありません)

MongoDBハンドラの選択を有効にするには、まずgg.handler.name.type=mongodbを指定してハンドラ・タイプを構成してから、次に示す他のMongoDBプロパティを構成する必要があります。

表8-31 MongoDBハンドラの構成プロパティ

プロパティ 必須/オプション 有効な値 デフォルト 説明

gg.handler.name.type

必須

mongodb

なし

Replicatで使用するMongoDBハンドラを選択します。

gg.handler.name.bulkWrite

オプション

true | false

true

trueに設定すると、コミット・トランザクション・イベントを受信するまで、ハンドラは操作をキャッシュします。トランザクション・イベントのコミット時に、キャッシュされたすべての操作がターゲットのMongoDB、AJDおよびATPデータベースに書き出され、スループットが向上します。

falseに設定すると、ハンドラ内にキャッシュはなく、操作はすぐにMongoDB、AJDおよびATPデータベースに書き込まれます。

gg.handler.name.WriteConcern

オプション

{"w": "value" , "wtimeout": "number" }

なし

MongoDBハンドラで実行されるすべての操作に必要な書込み確認を設定します。

プロパティ値はJSON形式で、wおよびwtimeoutのキーのみを受け入れることができます。https://docs.name.com/manual/reference/write-concern/を参照してください。

gg.handler.name.clientURI

オプション

有効なMongoDBクライアントURI

なし

MongoDBクライアントURIを設定します。クライアントURIは、認証やWriteConcernなど、他のMongoDB接続プロパティの設定にも使用できます。

gg.handler.name.CheckMaxRowSizeLimit

オプション

true | false

false

trueに設定すると、ハンドラは、挿入または変更されるBSONドキュメントのサイズが、MongoDBデータベースで定義された制限内であることを確認します。サイズの計算は、RawBsonDocument,を生成するデフォルト・コーデックの使用を伴い、これによりMongoDBハンドラのスループットが少し低下します。

ドキュメントのサイズがMongoDBの制限を超えると、例外が発生し、Replicatが異常終了します。

gg.handler.name.upsert

オプション

true | false

false

trueに設定します。UPDATE操作の実行時に問合せフィルタに一致するものがない場合は、新しいMongoドキュメントが挿入されます。

gg.handler.name.enableDecimal128

オプション

true | false

true

MongoDBバージョン3.4には、Decimal128という128ビットの10進データ型のサポートが追加されました。このデータ型は、64ビットのLongまたはDoubleに適合しない整数データ型と10進データ型の両方をOracle GoldenGate for Distributed Applications and Analytics (GG for DAA)でサポートするために必要でした。このプロパティをtrueに設定すると、これを必要とするソース・データ型のDouble128データ型へのマッピングが有効になります。falseに設定すると、これらのソース・データ型を64ビットのDoubleとして処理します。

gg.handler.name.enableTransactions

オプション

true | false

false

MongoDB 4.0以上でトランザクション処理を有効にする場合は、trueに設定します。

ノート:

MongoDBは、MongoDBバージョン4.0でトランザクションのサポートが追加されました。また、MongoDBクライアント・ドライバの最低限のバージョンは3.10.1です。

親トピック: MongoDBハンドラの設定および実行

8.2.23.5.3 一括書込みの使用

一括書込みはデフォルトで有効になっています。スループットを向上させるために、一括書込みを使用することをお薦めします。

また、BulkWriteハンドラ・プロパティを使用して、一括書込みを有効にすることもできます。一括書込みを有効または無効にするには、gg.handler.handler.BulkWrite=true | falseを使用します。MongoDBハンドラでは、Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)で使用されるgg.handler.handler.mode=op | txプロパティは使用されません。

一括書込みでは、MongoDBハンドラは、GROUPTRANSOPSパラメータを使用して、バッチ・サイズを取得します。ハンドラは、証跡レコードのバッチをMongoDBドキュメントに変換し、このドキュメントは1つのリクエストでデータベースに書き込まれます。

親トピック: MongoDBハンドラの設定および実行

8.2.23.5.4 書込み確認の使用

書込み確認は、スタンドアロンMongoDB、レプリカ・セットおよびシャード・クラスタへの書込み操作に関してMongoDBからリクエストされた確認のレベルを説明します。シャード・クラスタを使用して、Mongoインスタンスは書込み確認をシャードに渡します。https://docs.mongodb.com/manual/reference/write-concern/を参照してください。

次の構成を使用します。

w: value
wtimeout: number

親トピック: MongoDBハンドラの設定および実行

8.2.23.5.5 3部構成の表名の使用

Oracle GoldenGate証跡では、Catalog.Schema.Tableなど、3部構成の表名をサポートするソースのデータが存在する場合があります。MongoDBは、DBName.Collectionなど、2部構成の名前のみをサポートします。ソースの3部構成の名前からMongoDBの2部構成の名前へのマッピングをサポートするには、ソースのCatalogとSchemaをアンダースコア区切り文字で連結して、MongoのDBNameを構成します。

たとえば、Catalog.Schema.Tableはcatalog1_schema1.table1になります。

親トピック: MongoDBハンドラの設定および実行

8.2.23.5.6 Undo処理の使用

MongoDB Handlerハンドラは、軽量のundoエンジンを使用して、一括書込みエラーから回復できます。このエンジンは、通常のRDBMSのundoエンジンとは機能が異なり、どちらかといえばエラー・リカバリに役立つよう最善を尽くします。エラー・リカバリが正常に動作するのは、MongoDBデータベースがBulkWriteExceptionによって障害の場所に関する情報を提供する主な違反や他の一括書込みエラーがある場合です。

表8-32では、この機能を最大限に利用するための要件を示します。

表8-32 Undo処理の要件

元に戻す処理 証跡に完全な操作前イメージが必要か。

INSERT

いいえ

DELETE

あり

UPDATE

いいえ(SET句のフィールドの操作前イメージ。)

undo操作中にエラーが発生すると、MongoDBコレクションを一貫性のある状態にすることができない可能性があります。この場合、データを手動で調整する必要があります。

親トピック: MongoDBハンドラの設定および実行

8.2.23.6 セキュリティと認証

MongoDBハンドラは、Oracle GoldenGateの資格証明ストアを使用して、Oracle GoldenGateプロセスがMongoDBデータベースとやり取りするために使用するユーザーIDおよびその暗号化されたパスワード(まとめて資格証明と呼ばれます)を管理します。資格証明ストアを使用すると、Oracle GoldenGateのパラメータ・ファイルにユーザー名およびクリアテキスト・パスワードを指定する必要がなくなります。

ユーザーIDのかわりにパラメータ・ファイルのオプションの別名を使用して、資格証明ストアのユーザーIDとパスワードのペアにマップすることもできます。

Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)では、実際のユーザーIDまたはパスワードではなく、別名およびドメインをプロパティ・ファイル内で指定します。ユーザー資格証明は、セキュアなウォレット・ストレージで管理されます。

CREDENTIAL STOREおよびDBLOGINを追加するには、adminclientで次のコマンドを実行します。 
adminclient> add credentialstore
adminclient> alter credentialstore add user <userid> password <pwd> alias mongo
useridの値の例:
mongodb://myUserAdmin@localhost:27017/admin?replicaSet=rs0
adminclient > dblogin useridalias mongo
DBLOGINをテストするには、次のコマンドを実行します 
adminclient> list tables tcust*

認証を資格証明ストアに正常に追加したら、Extractのパラメータ・ファイルに別名を追加します。

例: 
SOURCEDB USERIDALIAS mongo
MongoDBハンドラは、接続URIを使用してMongoDBデプロイメントに接続します。認証およびセキュリティは、接続URIの一部として問合せ文字列として渡されます。SSLを構成するには、「SSL構成の設定」を参照してください。
アクセス制御を指定するには、useridを使用します。 
mongodb://<user>@<hostname1>:<port>,<hostname2>:<port>,<hostname3>:<port>/?replicaSet=<replicatName>
TLS/SSLを指定するには:
"+srv"の接続文字列接頭辞をmongodb+srvとして使用すると、tlsオプションはtrueに自動的に設定されます。
 mongodb+srv://server.example.com/
TLSを無効にするには、問合せ文字列にtls=falseを追加します。 
mongodb:// >@<hostname1>:<port>/?replicaSet=<replicatName>&tls=false

認証を指定するには:

authSource:
mongodb://<user>@<hostname1>:<port>,<hostname2>:<port>,<hostname3>:<port>/?replicaSet=<replicatName>&authSource=admin
authMechanism:
mongodb://<user>@<hostname1>:<port>,<hostname2>:<port>,<hostname3>:<port>/?replicaSet=<replicatName>&authSource=admin&authMechanism=GSSAPI
接続URLを使用したセキュリティおよび認証の詳細は、Mongo DBドキュメントを参照してください

親トピック: MongoDB

8.2.23.6.1 SSL構成の設定

MongoDBインスタンスとOracle GoldenGate for Distributed Applications and Analytics (GG for DAA)のMongoDBハンドラの間にSSLを構成するには、次の手順を実行します:

認証局(CA)の作成
openssl req -passout pass:password -new -x509 -days 3650 -extensions v3_ca -keyout 
ca_private.pem -out ca.pem -subj 
"/CN=CA/OU=GOLDENGATE/O=ORACLE/L=BANGALORE/ST=KA/C=IN"

クライアントおよびすべてのサーバー・ノードのキーおよび証明書署名リクエスト(CSR)の作成

openssl req -newkey rsa:4096 -nodes -out client.csr -keyout client.key -subj
'/CN=certName/OU=OGGBDCLIENT/O=ORACLE/L=BANGALORE/ST=AP/C=IN'
openssl req -newkey rsa:4096 -nodes -out server.csr -keyout server.key -subj
'/CN=slc13auo.us.oracle.com/OU=GOLDENGATE/O=ORACLE/L=BANGALORE/ST=TN/C=IN'

CAによる証明書署名リクエストの署名

openssl x509 -passin pass:password -sha256 -req -days 365 -in client.csr -CA ca.pem -CAkey
ca_private.pem -CAcreateserial -out client-signed.crtopenssl x509 -passin pass:password -sha256 -req -days 365 -in server.csr -CA ca.pem -CAkey
ca_private.pem -CAcreateserial -out server-signed.crt -extensions v3_req -extfile
 <(cat << EOF[ v3_req ]subjectAltName = @alt_names 
[ alt_names ]
DNS.1 = 127.0.0.1
DNS.2 = localhost
DNS.3 = hostname 
EOF)
mongod用のプライバシ強化メール(PEM)ファイルの作成
cat client-signed.crt client.key > client.pem
cat server-signed.crt server.key > server.pem

トラスト・ストアおよびキーストアの作成

openssl pkcs12 -export -out server.pkcs12 -in server.pem
openssl pkcs12 -export -out client.pkcs12 -in client.pem

bash-4.2$ ls
ca.pem  ca_private.pem     client.csr  client.pem     server-signed.crt  server.key  server.pkcs12
ca.srl  client-signed.crt  client.key  client.pkcs12  server.csr         server.pem

次のオプションを使用して、mongodのインスタンスを起動します。

--tlsMode requireTLS --tlsCertificateKeyFile ../opensslKeys/server.pem --tlsCAFile
        ../opensslKeys/ca.pem

credentialstore connectionString

alter credentialstore add user  
        mongodb://myUserAdmin@localhost:27017/admin?ssl=true&tlsCertificateKeyFile=../mcopensslkeys/client.pem&tlsCertificateKeyFilePassword=password&tlsCAFile=../mcopensslkeys/ca.pem
        password root alias mongo

ノート:

connectionStringの長さは256を超えないでください。

CDC Extractの場合は、JVMオプションの一部としてキー・ストアおよびトラスト・ストアを追加します。

JVMのオプション

-Xms512m -Xmx4024m -Xss32m -Djavax.net.ssl.trustStore=../mcopensslkeys /server.pkcs12
          -Djavax.net.ssl.trustStorePassword=password  
        -Djavax.net.ssl.keyStore =../mcopensslkeys/client.pkcs12
        -Djavax.net.ssl.keyStorePassword=password

親トピック: セキュリティと認証

8.2.23.7 サンプル構成の確認

基本構成

Javaアダプタ・プロパティ・ファイルからのMongoDBハンドラのサンプル構成を次に示します。

gg.handlerlist=mongodb
gg.handler.mongodb.type=mongodb

#The following handler properties are optional.
#Refer to the Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA) documentation
#for details about the configuration.
#gg.handler.mongodb.clientURI=mongodb://localhost:27017/
#gg.handler.mongodb.WriteConcern={w:value, wtimeout: number }
#gg.handler.mongodb.BulkWrite=false
#gg.handler.mongodb.CheckMaxRowSizeLimit=true

goldengate.userexit.timestamp=utc
goldengate.userexit.writers=javawriter
javawriter.stats.display=TRUE
javawriter.stats.full=TRUE
gg.log=log4j
gg.log.level=INFO
gg.report.time=30sec

#Path to MongoDB Java driver.
# maven co-ordinates
# <dependency>
# <groupId>org.mongodb</groupId>
# <artifactId>mongo-java-driver</artifactId>
# <version>3.10.1</version>
# </dependency>
gg.classpath=/path/to/mongodb/java/driver/mongo-java-driver-3.10.1.jar
javawriter.bootoptions=-Xmx512m -Xms32m -Djava.class.path=.:ggjava/ggjava.jar:./dirprm

OracleまたはMongDBデータベース・ソースからMongoDB、AJDおよびATPターゲット

OracleまたはMongDBデータベースの大文字のソース表名を、MongoDBの小文字の表にマップできます。これは表名とスキーマの両方に適用されます。使用できる方法は2つあります。

データ・ポンプの作成

Replicatの前にデータ・ポンプを作成して、名前を小文字に変換できます。次に、ポンプからの出力を使用するようにMongoDB Replicatを構成します。

extract pmp 
exttrail ./dirdat/le 
map RAMOWER.EKKN, target "ram"."ekkn";
複製時の変換

このパラメータをMongoDBプロパティ・ファイルに追加することにより、MongoDB表に複製する場合に表の列名を小文字に変換できます。

gg.schema.normalize=lowercase

親トピック: MongoDB

8.2.23.8 MongoDBからAJD/ATPへの移行

親トピック: MongoDB

8.2.23.8.1 概要

トランザクション処理用のOracle Autonomous JSON Database (AJD)およびAutonomous Databaseも、ワイヤ・プロトコルを使用して接続します。ワイヤ・プロトコルには同じMongoDB CRUD APIがあります。

親トピック: MongoDBからAJD/ATPへの移行

8.2.23.8.2 AJD/ATPに書き込むためのMongoDBハンドラの構成

基本構成は、この章で説明するオプションのプロパティを含めて同じままです。

ハンドラは、レプリケーションを実行するためのすべての操作をターゲットに依存しない方法で実行するために、mongodbと同じプロトコル(mongodb wire protocol)およびAutonomousデータベース用の同じドライバjarを使用します。プロパティは、サポートされている任意のターゲットにも使用できます。

Javaアダプタ・プロパティ・ファイルからのAJD/ATP用のMongoDBハンドラのサンプル構成を次に示します。
gg.handlerlist=mongodb
gg.handler.mongodb.type=mongodb
#URL mentioned below should be an AJD instance URL
gg.handler.mongodb.clientURI=mongodb://[username]:[password]@[url]?authSource=$external&authMechanism=PLAIN&ssl=true
#Path to MongoDB Java driver. Maven co-ordinates
# <dependency>
# <groupId>org.mongodb</groupId>
# <artifactId>mongo-java-driver</artifactId>
# <version>3.10.1</version>
# </dependency>
gg.classpath=/path/to/mongodb/java/driver/mongo-java-driver-3.10.1.jar
javawriter.bootoptions=-Xmx512m -Xms32m -Djava.class.path=.:ggjava/ggjava.jar:./dirprm

親トピック: MongoDBからAJD/ATPへの移行

8.2.23.8.3 移行のステップ

MongoDBからAJDに移行するには、最初に初期ロードを実行する必要があります。初期ロードは、挿入操作のみで構成されます。初期ロードの実行後、ソース・データベースとターゲット・データベースの同期を維持するCDCを起動します。

  1. CDC Extractを開始し、証跡を生成します。これらの証跡ファイルを消費するために、Replicatを起動しないでください。
  2. 初期ロードExtractを起動し、初期ロードが完了するまで待機します。
  3. ステップ2で生成された初期ロード証跡を消費する新しいReplicatを作成します。完了を待ってから、Replicatを停止します。
  4. CDC証跡を消費する新しいレプリケートを作成します。HANDLECOLLISIONSを使用するようにこのReplicatを構成してから、Replicatを起動します。
  5. CDC Replicat (ステップ4)がすべての証跡を消費し、replicat lagおよびreplicat RBAをチェックして、CDC Replicatが追い付いたことを確認します。この時点で、ソース・データベースとターゲット・データベースが同期しています。
  6. CDC Replicatを停止し、HANDLECOLLISIONSパラメータを削除してから、CDC Replicatを再起動します。

親トピック: MongoDBからAJD/ATPへの移行

8.2.23.8.4 ベスト・プラクティス

mongoDBからOracle Autonomous Database (AJD/ATP)に移行する場合、ベスト・プラクティスは次のとおりです。
  1. CDCを実行する前に、挿入操作を使用して初期データをロードする初期ロードを実行してください。
  2. スループットを向上させるために、mongoDBハンドラの実行にバルク・モードを使用します。
  3. 移行中にハンドル衝突を有効にして、Replicatが衝突エラーを自動的に処理できるようにします。
  4. 欠落している更新を挿入するために、INSERTMISSINGUPDATESプロパティを.prmファイルに追加してください。

親トピック: MongoDBからAJD/ATPへの移行

8.2.23.9 正確なインスタンス化を使用したMongoDBソース・データベースのExtractの初期同期の構成

ソースMongoDBデータベースからターゲットMongoDBデータベースへのデータ同期は、正確なインスタンス化の方法を介してMongoDBダンプ・ユーティリティを使用して効果的に実現できます。

正確なインスタンス化の方法により、ターゲットReplicatでの衝突処理が不要になります。これは、パフォーマンスを維持するために重要です。衝突処理は、パフォーマンスに悪影響を与える可能性があります。競合を防止して、一貫性を確保するために、レコードを適切な操作に変換する必要があるためです。

この正確なインスタンス化の方法では、MongoDBダンプ・ユーティリティを使用してデータベース・スナップショットを作成して、ソースから現在のデータ状態を取得し、MongoDBリストア・ユーティリティを使用してターゲットに転送します。oplogダンプの最初の操作は、チェンジ・データ・キャプチャ(CDC)プロセスの開始点として、Extract側の初期操作と位置合わせされます。この位置合わせにより、最初にダンプされたデータと抽出によって生成されるCDC証跡の間に操作の損失や重複がないことが保証されます。

親トピック: MongoDB

8.2.23.9.1 MongoDBダンプとチェンジ・データ・キャプチャ(CDC)のExtractの同期

MongoDBダンプ・ユーティリティを使用すると、指定されたデータベース内の指定されたコレクションからドキュメント、メタデータおよび索引定義を抽出して、選択したディレクトリにバイナリ・アーカイブ・ファイルとして保存できます。--oplogオプションを使用すると、ダンプの開始時にnoopエントリが追加されます。ダンプの実行中に行われる操作は、ダンプ・フォルダにあるoplog.bsonファイルに直接記録されます。これには、noopなどのすべての操作、およびダンプ中に発生する受信アクションが含まれ、それぞれにタイムスタンプと追加の詳細があります。oplog.bsonファイルを分析することで、少なくとも1つの操作が発生した場合、ダンプ・プロセス中に行われた最初の操作とそのタイムスタンプを判別できます。操作が記録されなかった場合、分析は最初のnoopエントリとそれに対応するタイムスタンプを表示します。

ダンプが完了したら、MongoDBリストア・ユーティリティを使用して、ダンプされたレコード、メタデータおよび索引情報をターゲットMongoDBインスタンスに適用できます。これにより、ダンプ・プロセス中にダンプされたすべてのデータが適用されます。

チェンジ・データ・キャプチャ(CDC)のExtractを開始するときに、前述のように、oplog.bsonファイルに記録されたタイムスタンプを使用します。このプロセスは、ダンプ・プロセスの完了後に発生した最初のイベントから操作の取得を開始します。指定されたタイムスタンプは、ダンプ中に記録された最初の操作に対応するか、操作が実行されなかった場合は操作なし(noop)を示します。この方法では、ダンプされたデータとCDC証跡ファイルの間に欠落した操作または重複がないことが保証されます。

親トピック: 正確なインスタンス化を使用したMongoDBソース・データベースのExtractの初期同期の構成

8.2.23.9.2 手順と例

  1. 次のようにMongoDBツールのbinフォルダから---oplogオプションを指定してmongodump実行可能ファイルを実行し、MongoDBダンプ・ユーティリティを実行します: 
    $ ./mongodump --uri="mongodb://localhost:27021" --oplog -v
    出力例:
    ./bin/mongodump --uri="mongodb://localhost:27021" --oplog -v
2024-12-12T15:10:50.666+0000	getting most recent oplog timestamp
2024-12-12T15:10:50.694+0000	writing admin.system.version to dump/admin/system.version.bson
2024-12-12T15:10:50.697+0000	done dumping admin.system.version (1 document)
2024-12-12T15:10:50.697+0000	dumping up to 4 collections in parallel
2024-12-12T15:10:50.698+0000	writing mydb.myColl2 to dump/mydb/myColl2.bson
2024-12-12T15:10:50.699+0000	writing mydb.myColl3 to dump/mydb/myColl3.bson
2024-12-12T15:10:50.699+0000	writing mydb.myColl0 to dump/mydb/myColl0.bson
2024-12-12T15:10:50.699+0000	writing mydb.myColl4 to dump/mydb/myColl4.bson
2024-12-12T15:10:50.739+0000	done dumping mydb.myColl3 (10000 documents)
2024-12-12T15:10:50.740+0000	done dumping mydb.myColl2 (10000 documents)
2024-12-12T15:10:50.741+0000	writing mydb.myColl6 to dump/mydb/myColl6.bson
2024-12-12T15:10:50.742+0000	writing mydb.myColl1 to dump/mydb/myColl1.bson
2024-12-12T15:10:50.748+0000	done dumping mydb.myColl0 (10000 documents)
2024-12-12T15:10:50.748+0000	done dumping mydb.myColl4 (10000 documents)
2024-12-12T15:10:50.748+0000	writing mydb.myColl8 to dump/mydb/myColl8.bson
2024-12-12T15:10:50.748+0000	writing mydb.myColl5 to dump/mydb/myColl5.bson
2024-12-12T15:10:50.770+0000	done dumping mydb.myColl1 (10000 documents)
2024-12-12T15:10:50.773+0000	writing mydb.myColl9 to dump/mydb/myColl9.bson
2024-12-12T15:10:50.786+0000	done dumping mydb.myColl6 (10000 documents)
2024-12-12T15:10:50.786+0000	writing mydb.myColl7 to dump/mydb/myColl7.bson
2024-12-12T15:10:50.793+0000	done dumping mydb.myColl8 (10000 documents)
2024-12-12T15:10:50.801+0000	done dumping mydb.myColl5 (10000 documents)
2024-12-12T15:10:50.806+0000	done dumping mydb.myColl9 (10000 documents)
2024-12-12T15:10:50.810+0000	done dumping mydb.myColl7 (10000 documents)
2024-12-12T15:10:50.811+0000	writing captured oplog to 
2024-12-12T15:10:50.812+0000		dumped 1 oplog entry
    これにより、すべてのデータベースおよびコレクションのバイナリ・アーカイブ・データ・ファイルおよびoplog.bsonファイルを含むダンプ・ディレクトリが作成されます。特定のデータベースおよびコレクションが必要な場合は、データベースおよびコレクション名を指定できます。詳細は、https://www.mongodb.com/docs/database-tools/mongodump/を参照してください

    ノート:

    オプション--numParallelCollectionsを使用して、並列でバックアップするコレクションの数を指定できます。デフォルト値は4です。
    たとえば: 
    $  ./mongodump --uri="mongodb://localhost:27021" --oplog -v
--numParallelCollections 8
  2. 生成されたoplog.bsonファイルを分析するには、MongoDB bsondumpユーティリティを使用して次のコマンドを実行し、判読可能なJSON形式に変換します。 
    $ ./bsondump --pretty --outFile path/to/oplog.json path/to/oplog.bson
    変換後、oplog.jsonファイルを確認して次のステップを実行します。
  3. ダンプ・プロセス中に受信操作が発生しなかった場合、oplog.jsonファイルにはタイムスタンプ付きのnoopエントリのみが含まれています。MongoDB CDC Extractの開始点として使用できるno-opエントリのタイムスタンプを書き留めます。
    {
	"op": "n",
	"ns": "",
	"o": {
		"msg": "periodic noop"
	},
	"ts": {
		"$timestamp": {
			"t": 1726486546,
			"i": 1
		}
	},
	"t": {
		"$numberLong": "1"
	},
	"v": {
		"$numberLong": "2"
	},
	"wall": {
		"$date": {
			"$numberLong": "1726486546549"
		}
	}
}
  4. ダンプ・プロセス中に1つ以上の受信操作が存在する場合、oplog.jsonファイルには、これらのすべての受信操作のエントリ(タイムスタンプ付き)とno-opが含められます。MongoDB CDC Extractの開始位置として使用される、oplog.jsonファイルに記録された最初の受信操作のタイムスタンプを次のように書き留めます:
    {
	"lsid": {
		"id": {
			"$binary": {
				"base64": "teT9VByFTI2COKwsVbp8/g==",
				"subType": "04"
			}
		},
		"uid": {
			"$binary": {
				"base64": "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=",
				"subType": "00"
			}
		}
	},
	"txnNumber": {
		"$numberLong": "1"
	},
	"op": "i",
	"ns": "mydb.myColl",
	"ui": {
		"$binary": {
			"base64": "BFAoef89RNC1kObCDV+8SA==",
			"subType": "04"
		}
	},
	"o": {
		"_id": {
			"$numberInt": "10000006"
		},
		"Name": "TEST DATA 006",
		"EmployeeID": {
			"$numberInt": "1006"
		},
		"Designation": "Sr. Software Engineer",
		"Level": "MGR",
		"Age": {
			"$numberInt": "75"
		},
		"Qualification": "Masters",
		"Address": {
			"Street": "Street_65",
			"City": "City_35",
			"Nationality": "German"
		}
	},
	"ts": {
		"$timestamp": {
			"t": 1726486553,
			"i": 2
		}
	},
	"t": {
		"$numberLong": "1"
	},
	"v": {
		"$numberLong": "2"
	},
	"wall": {
		"$date": {
			"$numberLong": "1726486553788"
		}
	},
	"stmtId": {
		"$numberInt": "1"
	},
	"prevOpTime": {
		"ts": {
			"$timestamp": {
				"t": 1726486553,
				"i": 1
			}
		},
		"t": {
			"$numberLong": "1"
		}
	}
}
  5. MongoDBリストア・ユーティリティを使用して、mongodumpで作成されたバックアップからデータをリストアします。mongoツールのbinフォルダにあるMongoDBリストア・ユーティリティを実行します: ($ ./mongorestore --uri="mongodb://localhost:27021")。これにより、次のようにメタデータおよび索引定義とともにすべてのデータがターゲットMongoDBインスタンスにダンプされます:
    $ ./mongorestore --uri="mongodb://localhost:27021"  

Sample outcome:
2024-12-12T15:17:56.593+0000	using write concern: &{majority <nil> 0s}
2024-12-12T15:17:56.598+0000	using default 'dump' directory
2024-12-12T15:17:56.598+0000	preparing collections to restore from
2024-12-12T15:17:56.598+0000	found collection admin.system.version bson to restore to admin.system.version
2024-12-12T15:17:56.598+0000	found collection metadata from admin.system.version to restore to admin.system.version
2024-12-12T15:17:56.598+0000	found collection mydb.myColl0 bson to restore to mydb.myColl0
2024-12-12T15:17:56.598+0000	found collection metadata from mydb.myColl0 to restore to mydb.myColl0
2024-12-12T15:17:56.598+0000	found collection mydb.myColl1 bson to restore to mydb.myColl1
2024-12-12T15:17:56.598+0000	found collection metadata from mydb.myColl1 to restore to mydb.myColl1
2024-12-12T15:17:56.598+0000	found collection mydb.myColl2 bson to restore to mydb.myColl2
2024-12-12T15:17:56.598+0000	found collection metadata from mydb.myColl2 to restore to mydb.myColl2
2024-12-12T15:17:56.598+0000	found collection mydb.myColl3 bson to restore to mydb.myColl3
2024-12-12T15:17:56.598+0000	found collection metadata from mydb.myColl3 to restore to mydb.myColl3
2024-12-12T15:17:56.598+0000	found collection mydb.myColl4 bson to restore to mydb.myColl4
2024-12-12T15:17:56.598+0000	found collection metadata from mydb.myColl4 to restore to mydb.myColl4
2024-12-12T15:17:56.598+0000	found collection mydb.myColl5 bson to restore to mydb.myColl5
2024-12-12T15:17:56.598+0000	found collection metadata from mydb.myColl5 to restore to mydb.myColl5
2024-12-12T15:17:56.598+0000	reading metadata for mydb.myColl0 from dump/mydb/myColl0.metadata.json
2024-12-12T15:17:56.598+0000	reading metadata for mydb.myColl4 from dump/mydb/myColl4.metadata.json
2024-12-12T15:17:56.598+0000	reading metadata for mydb.myColl3 from dump/mydb/myColl3.metadata.json
2024-12-12T15:17:56.599+0000	reading metadata for mydb.myColl5 from 
dump/mydb/myColl9.metadata.json
2024-12-12T15:17:56.599+0000	reading metadata for mydb.myColl1 from dump/mydb/myColl1.metadata.json
2024-12-12T15:17:56.599+0000	reading metadata for mydb.myColl2 from dump/mydb/myColl2.metadata.json
2024-12-12T15:17:56.605+0000	creating collection mydb.myColl3 with no metadata
2024-12-12T15:17:56.608+0000	creating collection mydb.myColl0 with no metadata
2024-12-12T15:17:56.656+0000	restoring mydb.myColl3 from dump/mydb/myColl3.bson
2024-12-12T15:17:56.667+0000	restoring mydb.myColl0 from dump/mydb/myColl0.bson
2024-12-12T15:17:56.885+0000	creating collection mydb.myColl2 with no metadata
2024-12-12T15:17:56.913+0000	restoring mydb.myColl2 from dump/mydb/myColl2.bson
2024-12-12T15:17:56.947+0000	finished restoring mydb.myColl0 (10000 documents, 0 failures)
2024-12-12T15:17:56.947+0000	creating collection mydb.myColl1 with no metadata
2024-12-12T15:17:56.949+0000	finished restoring mydb.myColl3 (10000 documents, 0 failures)
2024-12-12T15:17:56.949+0000	creating collection mydb.myColl4 with no metadata
2024-12-12T15:17:56.976+0000	restoring mydb.myColl1 from dump/mydb/myColl1.bson
2024-12-12T15:17:56.980+0000	restoring mydb.myColl4 from dump/mydb/myColl4.bson
2024-12-12T15:17:57.214+0000	creating collection mydb.myColl5 with no metadata
2024-12-12T15:17:57.229+0000	finished restoring mydb.myColl2 (10000 documents, 0 failures)
2024-12-12T15:17:57.230+0000	restoring mydb.myColl5 from dump/mydb/myColl5.bson
2024-12-12T15:17:57.269+0000	finished restoring mydb.myColl4 (10000 documents, 0 failures)
2024-12-12T15:17:57.269+0000	finished restoring mydb.myColl1 (10000 documents, 0 failures)
2024-12-12T15:17:57.445+0000	finished restoring mydb.myColl5 (10000 documents, 0 failures)
2024-12-12T15:17:57.474+0000	100000 document(s) restored successfully. 0 document(s) failed to restore.
  6. MongoDBがリストアされると、初期ロードが完了します。初期ロードが完了したら、ログ内のログ順序番号(LSN) (ステップ3またはステップ4で取得したタイムスタンプ)の位置から開始するようにMongoDB CDC Extractを構成します。たとえば、oplog.jsonファイルから取得された最初のタイムスタンプは$timestamp:{ “t”:1726173148, “i”:1}で、提供される形式はt.iで1726173148.1のようになります。これにより、ドキュメントが重複したり欠落したりしないように、正確な開始が構成されます。

親トピック: 正確なインスタンス化を使用したMongoDBソース・データベースのExtractの初期同期の構成

8.2.23.10 MongoDBハンドラ・クライアント依存性

MongoDBデータベースに接続するためのMongoDBハンドラの依存性とはどのようなものでしょう。

Oracle GoldenGateでは、MongoDBとの統合にバージョン4.6.0 MongoDBのリアクティブ・ストリームが必要です。このドライバは、https://search.maven.org/artifact/org.mongodb/mongodb-driver-reactivestreamsからダウンロードできます

ノート:

Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)のバージョンが21.7.0.0.0以下の場合、このドライバのバージョンはMongoDB Java Driver 3.12.8です。Oracle GoldenGate for Distributed Applications and Analytics (GG for DAA)バージョン21.8.0.0.0以上の場合、このドライバのバージョンはMongoDB Java Driver 4.6.0です。

親トピック: MongoDB

8.2.23.10.1 MongoDB Java Driver 4.6.0

必要な依存クライアント・ライブラリは次のとおりです:

  • bson-4.6.0.jar
  • bson-record-codec-4.6.0.jar
  • mongodb-driver-core-4.6.0.jar
  • mongodb-driver-legacy-4.6.0.jar
  • mongodb-driver-legacy-4.6.0.jar
  • mongodb-driver-sync-4.6.0.jar

MongoDB Replicatの実行に必要なサード・パーティ・ライブラリのMaven座標は次のとおりです: 

<dependency>

    <groupId>org.mongodb</groupId>
    <artifactId>mongodb-driver-legacy</artifactId>
    <version>4.6.0</version>
    </dependency>

 <dependency>
    <groupId>org.mongodb</groupId>
    <artifactId>mongodb-driver-sync</artifactId>
    <version>4.6.0</version>
</dependency>

例

Maven Central (https://central.sonatype.com/artifact/org.mongodb/mongodb-driver-reactivestreams/4.6.0)から最新バージョンをダウンロードします。

親トピック: MongoDBハンドラ・クライアント依存性

8.2.23.10.2 MongoDB Java Driver 3.12.8

gg.classpathプロパティにMongoDB Java Driverへのパスを含める必要があります。Maven Central RepositoryからJavaドライバが自動的にダウンロードされるようにするには、pom.xmlファイルに次の行を追加して、正しい情報で置換します。
<!-- https://mvnrepository.com/artifact/org.mongodb/mongo-java-driver -->
<dependency>
    <groupId>org.mongodb</groupId>
    <artifactId>mongo-java-driver</artifactId>
    <version>3.12.8</version>
</dependency>

親トピック: MongoDBハンドラ・クライアント依存性