Docs Menu
Docs Home
/
MongoDB Atlas
/ / / /

mongomirror

項目一覧

  • 構文
  • オプション

警告

mongomirror を名前空間フィルターとともに使用すると、includeNamespace <database.collection> の範囲外の名前空間を持つソース上のトランザクションは未定義の動作と見なされ、データが失われる可能性があります。

mongomirror は、既存の MongoDB レプリカセットから MongoDB Atlas レプリカセットにデータを手動で移行するためのツールです。

mongomirrorを実行するには、以下を指定する必要があります。

  • ソース レプリカセットとターゲット Atlas レプリカセット。

  • ソース レプリカセットで認証が必要な場合は、適切な権限、対応するパスワード、および適切な権限を持つ Atlas クラスター内のユーザー。

mongomirror --host <sourceReplSet> \
--destination <atlasCluster> \
--destinationUsername <atlasAdminUser> \
--destinationPassword <atlasPassword> \
[Additional options]

コマンドにオプションを含める代わりに、 config fileでオプションを指定できます。

--host <host>

ソース レプリカセットのホスト情報。次のように、レプリカセット名とノードのシードリストを指定します。

<RSname>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>
--username <username>

ソース レプリカセットに認証が必要な場合は、local データベースを含むすべてのデータベースを読み取る権限を持つソース レプリカセット内のユーザーの名前。backup ロールを持つユーザーは適切な権限を提供します。必要な特定の権限の詳細については、「ソース レプリカセットで必要なアクセス権限」を参照してください。

--password <password>

--usernameで指定されたユーザーのパスワード。

--authenticationDatabase <authenticationDatabase>

--usernameで指定されたユーザーが作成されたソース レプリカセット内のデータベース。使用される認証データベースは以下のとおりです。

  • SCRAM 認証ユーザーはadminデータベースです。

  • X.509 認証済みユーザーは $external データベースです。

  • AWS IAM認証ユーザーは$externalデータベースです。

詳細については、「認証データベース」を参照してください。

--authenticationMechanism <authenticationMechanism>

ソース レプリカセットに対してユーザーを認証するために使用する認証メカニズム。

説明

SHA-1 ハッシュ関数を使用する RFC5802 標準の Salted Challenge Response Authentication Mechanismです。

SHA-256 ハッシュ関数を使用する RFC 5802 標準の Salted Challenge Response Authentication Mechanism。

MongoDB TLS/SSL 証明書認証。

GSSAPI(Kerberos)

Kerberos を使用する外部認証。このメカニズムは MongoDB Enterprise でのみ使用できます。

PLAIN(LDAP SASL)

LDAP を使用する外部認証。データベース内のユーザー認証には、PLAIN を使用することもできます。PLAIN はパスワードをプレーン テキストで送信します。このメカニズムは MongoDB Enterprise でのみ使用できます。

MONGODB-IAM

バージョン 0.10.0 の新機能

AWS IAM を使用した外部認証。

AWS IAM 認証情報を使用して認証するには、次のオプションを使用します。

  • --username< AWSアクセスキー ID>

  • --password <secret access key id>

  • --awsSessionToken <AWS session token>

詳細については、「認証メカニズム」を参照してください。

--awsSessionToken

バージョン 0.10.0 の新機能

MONGODB-IAM認証メカニズムで使用する AWS セッション トークン。

--compressors <snappy,...>

バージョン 0.9.0 の新機能

有効にするコンプレッサーのカンマ区切りリスト。無効にするには 'none' を使用します。デフォルト: snappy,zstd,zlib

--config=<file>

mongomirrorのオプションと値を保存するYAMLファイル。相対パスまたは絶対パスを使用してファイルを指定し、ファイルに含まれるオプションで mongomirror を実行します。

設定ファイルは、次のオプションをサポートしています。

option: value構文を使って構成ファイルでオプションを指定します。設定ファイル内のオプションの前に--を含めないでください。構成ファイルでオプションを設定する場合、 mongomirrorコマンド内でそのオプションを指定する必要はありません。

myconfig.yamlというコンフィグ ファイルを作成し、以下の内容を記述します。

password: <passwordForUser>
destinationPassword: <passwordForDestinationUser>

mongomirror--password--destinationPassword フラグを含めずに実行することができます。

mongomirror --host <sourceReplSet> \
--ssl \
--username <atlasAdminUser> \
--destinationUsername <atlasAdminUser> \
--config=myconfig.yaml \
--destination <atlasCluster> \
[Additional options]
--destination <destination>

ターゲット Atlas レプリカセットのホスト情報。

次のように、レプリカセット名とノードのシードリストを指定します。

<RSname>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>
--destinationAuthenticationDatabase <authentication database>

Atlas クラスター内のデータベースユーザーの認証データベース。SCRAM 認証ユーザーの認証データベースadmin データベースです。

詳細については、 「データベースユーザー認証」を参照してください。

--destinationAuthenticationMechanism <authentication mechanism>

Atlas クラスター内のデータベースユーザーの認証メカニズム。Atlas は、データベースユーザーに対して次の形式の認証を提供します。

説明

SHA-1 ハッシュ関数を使用する RFC 5802 標準の Salted Challenge Response Authentication Mechanism。

SHA-256 ハッシュ関数を使用する RFC 5802 標準の Salted Challenge Response Authentication Mechanism。

PLAIN(LDAP SASL)

LDAP を使用する外部認証。データベース内のユーザー認証には、PLAIN を使用することもできます。PLAIN はパスワードをプレーン テキストで送信します。このメカニズムは MongoDB Enterprise でのみ使用できます。

詳細については、 「データベースユーザー認証」を参照してください。

--destinationUsername <Atlas user name>

Atlasクラスタ内で、任意のデータベースの読み取り、書き込み、および管理を行う権限を持つデータベースユーザーの名前。Atlas 管理者ロールを持つユーザーには適切な権限が付与されます。必要な特定の権限の詳細については、「デスティネーションクラスターに必要なアクセス」を参照してください。

--destinationPassword <password>

--destinationUsernameで指定されているデータベースユーザーのパスワード。

--drop

mongomirror がターゲット クラスター上のすべてのユーザー コレクション(listCollections を使用して各データベースで表示可能)を削除する必要があることを示すフラグ。このオプションは、 local.system*oplog などの内部コレクションは削除しません。

--noIndexRestore

バージョン 0.10.0 の新機能

データの移行時にインデックスを省略します。

--includeNamespace <database.collection>

ターゲット クラスターにミラーリングするソース クラスター上の名前空間を指定します。複数回提供できます。

注意

トランザクションが複数の名前空間にまたがる場合、 --includeNamespaceまたは--includeDBで指定された名前空間に適用された書込み操作のみが宛先クラスターに適用されます。

--includeDB <database>

ターゲット クラスターにミラーリングするソース クラスター上のデータベースを指定します。複数回提供できます。

注意

トランザクションが複数の名前空間にまたがる場合、 --includeNamespaceまたは--includeDBで指定された名前空間に適用された書込み操作のみが宛先クラスターに適用されます。

--ssl

ソー スレプリカセットへの TLS/SSL 暗号化された接続を有効にします。

--sslPEMKeyFile <file>

ソース レプリカセットでクライアントが証明書を提示する必要がある場合の .pem ファイル。.pem ファイルには TLS/SSL 証明書とキーの両方が含まれています。相対パスまたは絶対パスを使用してファイルを指定します。

--sslPEMKeyPassword <value>

--sslPEMKeyFile で指定された証明書キー ファイルを復号化するためのパスワード。--sslPEMKeyFile が暗号化されている場合に使用します。

--sslCAFile <file>

ソース レプリカセットの証明機関(CA)からのルート証明書チェーンを含む .pem ファイル。相対パスまたは絶対パスを使用してファイルを指定します。

--sslCRLFile <filename>

ソース レプリカセットの証明書失効リストを含む .pem ファイル。 相対パスまたは絶対パスを使用してファイルを指定します。

--sslAllowInvalidHostnames

非推奨。使用 tlsInsecure instead.

ソース レプリカセットによって提示された TLS/SSL 証明書の検証を無効にします。証明書内のホスト名が指定されたホスト名と一致しない場合、mongomirror がソース レプリカセットに接続できるようにします。

重要

このオプションはすべての証明書の検証をスキップするため、無効な証明書が受け入れられる可能性があります。

--sslAllowInvalidCertificates

非推奨。使用 tlsInsecure instead.

ソース レプリカセットによって提示される証明書の検証チェックをバイパスします。--allowInvalidCertificates 設定を使用すると、MongoDB は無効な証明書の使用を警告としてログを記録します。

重要

このオプションはすべての証明書の検証をスキップするため、無効な証明書が受け入れられる可能性があります。

--tlsInsecure

サーバーの証明書チェーンとホスト名の検証チェックをバイパスします。これにより、無効な証明書とホスト名を使用できるようになります。

これは、非推奨の sslAllowInvalidHostnamessslAllowInvalidCertificates オプションに取って代わるものです。

--gssapiServiceName <name>

ソース レプリカセットが Kerberos 認証を使用する場合、GSSAPI/Kerberos を使用するサービスの名前。サービスがデフォルト名 mongodb を使用しない場合のみ必要となります。

このオプションは MongoDB Enterprise でのみ使用できます。

--gssapiHostName <host>

ソース レプリカセットが Kerberos 認証を使用する場合、GSSAPI/Kerberos を使用するサービスのホスト名。マシンのホスト名が DNS によって解決されたホスト名と一致しない場合にのみ必要となります。

このオプションは MongoDB Enterprise でのみ使用できます。

--readPreference <read preference>

バージョン 0.9.0 以降では非推奨

mongomirror ソースがレプリカセット名を持たない単一のホストでない限り、常にプライマリから読み取ります。この場合、そのホストにのみ直接接続します。

--writeConcern <write concern>

バージョン 0.2.3 以降では非推奨: mongomirror は常に過半数の書込み保証 (write concern)を使用します。

--numParallelCollections <num>, -j <num>

デフォルト: 4

並行してコピーおよび復元するコレクションの数。

--bypassDocumentValidation

バージョン 0.2.3 以降では非推奨: mongomirror は常にドキュメント検証をバイパスします。

--bookmarkFile <file>

デフォルト: mongomirror.bookmark

oplog タイムスタンプ ブックマーク ファイルの名前。

--forceDump

空でないお気に入りのファイルが存在する場合でも、 mongomirrorがすべてのソース コレクションを再同期することを示すフラグ。

--oplogPath <path>

バージョン 0.5.0 の新機能

mongomirror による最初の同期の oplog window をディスクにバッファリングすることを可能にします。このオプションに値を指定すると、mongomirror は、ソース oplog エントリを単一ファイル(<oplogPath>/oplog-mongomirror.bson.sz)内で指定されたディレクトリにストリーミングします。oplog ファイル全体が宛先クラスターにリプレイされた後、mongomirror ファイルを削除し、バッファリングせずにソース oplog のテーリングを開始します。

デフォルトでは、mongomirror はソースから oplog エントリをストリーミングし、それを宛先クラスターに適用します。ただし、ソースの oplog が最初の同期の oplog window 全体を保持するのに十分な大きさでない場合、移行が失敗する可能性があります。このエラーを回避するには、ソース oplog のサイズを増やすか、このオプションを指定して、移行プロセス中にソース oplog のスペースが不足しないようにします。

重要

最初の mongomirror 同期中に発生するすべてのソース oplog エントリに十分対応できるディスク領域が必要です。

たとえば、ソース oplog が10 GB で、 24時間の変更をカバーし、 mongomirrorの同期に48時間かかると推定される場合、少なくとも20 GB の空きディスク容量が必要です指定されたディレクトリ内にあります。

--oplogBatchSize <num>

デフォルト: 10,000

バッチとして送信する oplog エントリの数を指定します。mongomirrorでは、データ ボリューム サイズが最大 16 MBまでのドキュメントをバッチとして送信できます。

--httpStatusPort <num>

指定されたポートで HTTP サーバーを起動するように mongomirror に指示します。http://localhost:<num> に HTTP GET リクエストを発行して、mongomirror の現在のステータスを取得できます。

--httpStatusPort で実行している場合、エラーが発生しても mongomirror は終了しません。その代わり、通常通りエラーをログに記録し、指定されたポートにHTTP経由でエラーを報告します。

mongomirror HTTP リクエストに応答してドキュメントを返します。次の例の構文は、使用可能なすべてのフィールドを表していますが、実際の応答では、これらのフィールドのサブセットのみが返される場合があります。フィールドの説明と、それらをいつ期待するかについては、次の表を参照してください。

{
"stage" : "<stage Name>",
"phase" : "<phase Name>",
"details" : {
"currentTimestamp" : "<BSON timestamp>",
"latestTimestamp" : "<BSON timestamp>",
"lastWriteOnSourceTimestamp" : "<BSON timestamp>",
"<namespace>" : {
"complete" : <boolean>,
"copiedBytes" : <integer>,
"totalBytes" : <integer>,
"createIndexes" : <integer>
},
...
},
"errorMessage" : "<error message>"
}

以下の表は、各フィールドとその取り得る値について説明したものです。

フィールド
説明

stage

進行中のステージの名前。可能な値は次のとおりです。

  • initializing

    mongomirror は開始されましたが、まだデータをコピーしていません。

  • initial sync

    mongomirrorは、復元元にすでに存在するドキュメントとインデックスをコピーしています。mongomirror もoplogのエントリを追跡して適用します

  • oplog sync

    mongomirror は oplog のエントリーをテーリングして適用しています。

phase

フェーズの名前。stage のどの部分が進行中であるか、より具体的な詳細を提供します。

details

現在のフェーズの進捗状況を詳細に説明したドキュメント。

initial syncステージの間、 内の各サブドキュメントは、details mongomirrorによってコピーされる単一のコレクションを表します。

stageまたはphase に応じて、mongomirror は応答にこのフィールドを含めない場合があります。

details.<namespace>

コピーされるコレクションの完全な名前空間が <database>.<collection>として表示されます。

ドキュメントまたはインデックスをコピーする場合の initial sync フェーズでのみ表示されます。

details.<namespace>.complete

がコレクションからターゲット Atlas クラスターにすべてのドキュメントまたはインデックスをコピーしたかどうかに応じて、 mongomirrorまたは が表示されます。truefalse

ドキュメントまたはインデックスをコピーする場合の initial sync フェーズでのみ表示されます。

details.<namespace>.copiedBytes

これまでにコピーされたバイト数。これは、コピーされたドキュメントの現在の数や合計数を報告するmongomirror ログとは異なる測定値であることに注意してください。

インデックス以外のデータをコピーする場合の initial sync フェーズでのみ表示されます。

details.<namespace>.totalBytes

コレクションの合計サイズ(バイト単位)。

インデックス以外のデータをコピーする場合の initial sync フェーズでのみ表示されます。

details.<namespace>.createIndexes

作成済みまたはこれから作成されるインデックスの数。

インデックスをコピーする場合の initial sync ステージでのみ表示されます。

details.currentTimestamp

最近処理されたoplogエントリーのBSONタイムスタンプ値。mongomirror はこのデータ点を10 秒ごとにのみ更新するため、mongomirror は報告された時間よりわずかに進んでいる可能性があります。

oplog エントリーを手―リングまたは適用するときに、 initial sync または oplog sync ステージでのみ表示されます。

details.latestTimestamp

initial sync ステージの間、これは最初の同期中に初期データがコピーされた後に利用可能な最新の oplog エントリの BSON タイムスタンプ値を表します。

oplog sync ステージでは、これはソース配置で使用可能な最新の oplog エントリーの BSON タイムスタンプ値を表します。

oplog エントリーを手―リングまたは適用するときに、 initial sync または oplog sync ステージでのみ表示されます。

details
.lastWriteOnSourceTimestamp

何も操作されていない最新のoplogエントリーのBSONタイムスタンプ値。操作なし エントリは、通常、データベースのデータを書込みまたは編集しないハートビートなどのシステムレベルの操作です。mongomirror は10 秒ごとにこの値を更新します。データベース内のデータを書込み (write) または編集する操作は、次回の更新まで報告されない可能性があります。

lastWriteOnSourceTimestamp フィールドは、移行中に切り替えを行う前に、ソース配置で新しい書込み (write) が行われていないことを確認するのに役立ちます。

errorMessage

--collStatsThreshold <num>

バージョン 0.9.0 の新機能

collStats が無効になる前に存在可能なコレクションの最大数。常に collStats を実行するには -1 使用し、collStats を実行しない場合は 0 使用します。デフォルト: -1

--removeAutoIndexId

バージョン 0.12.0 の新機能

ターゲット クラスターへの初期同期中にコレクションから autoIndexIdオプションを削除します。また、移行中に mongomirror が作成するコレクションから autoIndexId オプションも削除されます。

--preserveUUIDs

Atlas がライブ移行中に UUID を保持できるようにします。このオプションは、Atlas が実行するライブ移行プロセスでのみ機能します。コマンドラインで --preserveUUIDs オプションを使用しても、権限エラーで失敗します。このオプションは mongomirror を実行する自己管理型移行プロセスのコマンドラインでの使用を目的としていないため、こうしたエラーが予想されます。

次の例では、認証を必要としないソース レプリカセットから移行します。

mongomirror --host sourceRS/source-host1:27017,source-host2:27017 \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \
--destinationUsername myAtlasUser \
--destinationPassword myAtlasPwd

認証を必要としないソース レプリカセットから移行するには、次のオプションを指定して mongomirror を実行します。

ターゲットには、レプリカセット名に続いてノードのシードリストを次の形式で指定します。

<replicaSetName>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>,...

指定されたユーザーには、Atlas での Atlas admin ロールが必要です。

次の例では、SCRAM-SHA1 認証を使用するソース レプリカセットを Atlas に移行します。

mongomirror --host sourceRS/source-host1:27017,source-host2:27017,source-host3:27017 \
--username mySourceUser \
--password mySourcePassword \
--authenticationDatabase admin \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \
--destinationUsername myAtlasUser \
--destinationPassword atlasPassw0Rd

SCRAM-SHA 1認証を使用するソース レプリカセットから移行するには、次のオプションを指定してmongomirrorを実行します。

ソース レプリカセット ユーザーには、ソース クラスターでのアクセス権が必要です。backup ロールにより、適切な権限が付与されます。

ターゲットには、レプリカセット名に続いてノードのシードリストを次の形式で指定します。

<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,...

指定されたユーザーは Atlas の Atlas admin を持っている必要があります。

次の例では、X.509 認証を使用するソース レプリカセットから移行します。

mongomirror --host sourceRS/source-host1:27017,source-host2:27017,source-host3:27017 \
--username "CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry" \
--authenticationDatabase '$external' \
--authenticationMechanism MONGODB-X509 \
--ssl \
--sslPEMKeyFile <path-to-my-client-certificate.pem> \
--sslCAFile <path-to-my-certificate-authority-certificate.pem> \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \
--destinationUsername myAtlasUser \
--destinationPassword atlasPassw0Rd

X. 509認証を使用するソース レプリカセットから移行するには、次のオプションを指定してmongomirrorを実行します。

ソース レプリカセット ユーザーには、ソース クラスターでのアクセス権が必要です。backup ロールにより、適切な権限が付与されます。

ターゲットには、レプリカセット名に続いてノードのシードリストを次の形式で指定します。

<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,...

指定されたユーザーは Atlas の Atlas admin を持っている必要があります。

次の例では、Kerberos 認証を使用するソースレプリカ セットから移行します。

mongomirror --host sourceRS/source-host1:27017,source-host2:27017,source-host3:27017 \
--username sourceUser/administrator@MYREALM.COM \
--authenticationDatabase '$external' \
--authenticationMechanism GSSAPI \
--destination myAtlasRS/atlas-host1:27017,atlas-host2:27017,atlas-host3:27017 \
--destinationUsername atlasUser \
--destinationPassword atlasPass

Kerberos 認証を使用するソース レプリカセットから移行するには、次のオプションを指定して mongomirror を実行します。

ソース レプリカセット ユーザーには、ソース クラスターでのアクセス権が必要です。backup ロールにより、適切な権限が付与されます。

ターゲットには、レプリカセット名に続いてノードのシードリストを次の形式で指定します。

<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,...

指定されたユーザーは Atlas の Atlas admin を持っている必要があります。

mongomirror 手順からの出力ログをファイルに保存して、後で調査やデバッグに使えます。出力を mongomirror.log ファイルに保存するには、以下の書式を使用します。

mongomirror <args> 2>&1 | tee -a mongomirror.log

戻る

手動で移行する