警告
 mongomirror を名前空間フィルターとともに使用すると、includeNamespace <database.collection> の範囲外の名前空間を持つソース上のトランザクションは未定義の動作と見なされ、データが失われる可能性があります。
mongomirror は、既存の MongoDB レプリカセットから MongoDB Atlas レプリカセットにデータを手動で移行するためのツールです。「mongomirror をダウンロードする」もご覧ください。
構文
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ロールを持つユーザーは適切な権限を提供します。必要な特定の権限の詳細については、「ソース レプリカセットで必要なアクセス権限」を参照してください。
- --authenticationDatabase <authenticationDatabase>
- --usernameで指定されたユーザーが作成されたソース レプリカセット内のデータベース。使用される認証データベースは以下のとおりです。- SCRAM 認証ユーザーは - adminデータベースです。
- X.509 認証済みユーザーは - $externalデータベースです。
- AWS IAM認証ユーザーは - $externalデータベースです。
 - 詳細については、「認証データベース」を参照してください。 
- --authenticationMechanism <authenticationMechanism>
- ソース レプリカセットに対してユーザーを認証するために使用する認証メカニズム。 値説明- RFC 5802 標準の Salted Challenge Response Authentication Mechanism(SHA-1 ハッシュ関数を使用)。 - RFC5802 標準の Salted Challenge Response Authentication Mechanism。256 - MongoDB TLS/SSL 証明書認証。 - GSSAPI(Kerberos) - Kerberos を使用する外部認証。このメカニズムは MongoDB Enterprise でのみ使用できます。 - PLAIN(LDAP SASL) - LDAP を使用する外部認証。データベース内のユーザー認証には、 - PLAINを使用することもできます。- PLAINはパスワードをプレーン テキストで送信します。このメカニズムは MongoDB Enterprise でのみ使用できます。- MONGODB-IAM - バージョン 0.10.0 の新機能 - Amazon Web Services IAM を使用した外部認証。 - AWS IAM 認証情報を使用して認証するには、次のオプションを使用します。 - --username< Amazon Web ServicesアクセスキーID>
- --password<secret access key id>
- --awsSessionToken<AWS session token>
 - 詳細については、「認証メカニズム」を参照してください。 
- --compressors <snappy,...>
- バージョン 0.9.0 の新機能 - 有効にするコンプレッサーのカンマ区切りリスト。無効にするには 'none' を使用します。デフォルト: - snappy,zstd,zlib
- --config=<file>
- mongomirrorのオプションと値を保存するYAMLファイル。相対パスまたは絶対パスを使用してファイルを指定し、ファイルに含まれるオプションで- mongomirrorを実行します。- 設定ファイルは、次のオプションをサポートしています。 - password<password>
- sslPEMKeyPassword<password>
- destinationPassword<password>
- uri<ソース クラスター URI 接続文字列>
 - 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 は、データベースユーザーに対して次の形式の認証を提供します。 値説明- RFC5802 標準の Salted Challenge Response Authentication Mechanism。1 - RFC5802 標準の Salted Challenge Response Authentication Mechanism。256 - PLAIN(LDAP SASL) - LDAP を使用する外部認証。データベース内のユーザー認証には、 - PLAINを使用することもできます。- PLAINはパスワードをプレーン テキストで送信します。このメカニズムは MongoDB Enterprise でのみ使用できます。- 詳細については、 「データベースユーザー認証」を参照してください。 
- --destinationUsername <Atlas user name>
- Atlasクラスタ内で、任意のデータベースの読み取り、書き込み、および管理を行う権限を持つデータベースユーザーの名前。Atlas 管理者ロールを持つユーザーには適切な権限が付与されます。必要な特定の権限の詳細については、「デスティネーションクラスターに必要なアクセス」を参照してください。 
- --drop
- mongomirrorがターゲット クラスター上のすべてのユーザー コレクション(- listCollectionsを使用して各データベースで表示可能)を削除する必要があることを示すフラグ。このオプションは、- local.system*や oplog などの内部コレクションは削除しません。
- --includeNamespace <database.collection>
- ターゲット クラスターにミラーリングするソース クラスター上の名前空間を指定します。複数回提供できます。 - 注意- トランザクションが複数の名前空間にまたがる場合、 - --includeNamespaceまたは- --includeDBで指定された名前空間に適用された書込み操作のみが宛先クラスターに適用されます。
- --includeDB <database>
- ターゲット クラスターにミラーリングするソース クラスター上のデータベースを指定します。複数回提供できます。 - 注意- トランザクションが複数の名前空間にまたがる場合、 - --includeNamespaceまたは- --includeDBで指定された名前空間に適用された書込み操作のみが宛先クラスターに適用されます。
- --sslPEMKeyFile <file>
- ソース レプリカセットでクライアントが証明書を提示する必要がある場合の .pem ファイル。.pem ファイルには TLS/SSL 証明書とキーの両方が含まれています。相対パスまたは絶対パスを使用してファイルを指定します。 
- --sslPEMKeyPassword <value>
- --sslPEMKeyFileで指定された証明書キー ファイルを復号化するためのパスワード。- --sslPEMKeyFileが暗号化されている場合に使用します。
- --sslAllowInvalidHostnames
- 非推奨。使用 - tlsInsecureinstead.- ソース レプリカセットによって提示された TLS/SSL 証明書の検証を無効にします。証明書内のホスト名が指定されたホスト名と一致しない場合、 - mongomirrorがソース レプリカセットに接続できるようにします。- 重要- このオプションはすべての証明書の検証をスキップするため、無効な証明書が受け入れられる可能性があります。 
- --sslAllowInvalidCertificates
- 非推奨。使用 - tlsInsecureinstead.- ソース レプリカセットによって提示される証明書の検証チェックをバイパスします。 - --allowInvalidCertificates設定を使用すると、MongoDB は無効な証明書の使用を警告としてログを記録します。- 重要- このオプションはすべての証明書の検証をスキップするため、無効な証明書が受け入れられる可能性があります。 
- --tlsInsecure
- サーバーの証明書チェーンとホスト名の検証チェックをバイパスします。これにより、無効な証明書とホスト名を使用できるようになります。 - これは、非推奨の - sslAllowInvalidHostnamesと- sslAllowInvalidCertificatesオプションに取って代わるものです。
- --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)を使用します。
- --bypassDocumentValidation
- バージョン 0.2.3 以降では非推奨: - mongomirrorは常にドキュメント検証をバイパスします。
- --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経由でエラーを報告します。- mongomirrorHTTP リクエストに応答してドキュメントを返します。次の例の構文は、使用可能なすべてのフィールドを表していますが、実際の応答では、これらのフィールドのサブセットのみが返される場合があります。フィールドの説明と、それらをいつ期待するかについては、次の表を参照してください。- { - "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または が表示されます。- true- false- ドキュメントまたはインデックスをコピーする場合の - 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
例
レプリカセットを Atlas に移行する:ソースに認証なし
次の例では、認証を必要としないソース レプリカセットから移行します。
mongomirror --host  sourceRS/source-host1:27017,source-host2:27017 \          --destination myAtlasRS/atlas-host1:27017,atlas-host2:27017 \          --destinationUsername myAtlasUser \          --destinationPassword myAtlasPwd 
認証を必要としないソース レプリカセットから移行するには、次のオプションを指定して mongomirror を実行します。
- --host<sourceReplSet/seed list of members>
- --destination<Atlas Cluster>
- --destinationUsername<atlasUser>
- --destinationPassword<atlasPassword>
ターゲットには、レプリカセット名に続いてノードのシードリストを次の形式で指定します。
<replicaSetName>/<host1>:<port1>,<host2>:<port2>,<host3>:<port3>,... 
指定されたユーザーには、Atlas での Atlas admin ロールが必要です。
レプリカセットの移行: ソース レプリカセットは SCRAM-SHA1 認証を使用します。
次の例では、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を実行します。
- --host<sourceReplSet/seed list of members>
- --username<sourceUser>
- --password<sourcePassword>
- --authenticationDatabase<sourceDatabase>
- --destination<Atlas Cluster>
- --destinationUsername<atlasUser>
- --destinationPassword<atlasPassword>
ソース レプリカセット ユーザーには、ソース クラスターでのアクセス権が必要です。backup ロールにより、適切な権限が付与されます。
ターゲットには、レプリカセット名に続いてノードのシードリストを次の形式で指定します。
<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,... 
指定されたユーザーは Atlas の Atlas admin を持っている必要があります。
レプリカセットの移行: ソース レプリカセットには X.509 クライアント認証が必要です。
次の例では、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を実行します。
- --host<sourceReplSet/seed list of members>
- --username<subject from the client certificate>
- --authenticationMechanism- MONGODB-X509
- --authenticationDatabase- '$external'
- --sslPEMKeyFile<path-to-my-client-certificate.pem>
- --sslCAFile<path to root CA PEM file>
- --destination<Atlas Cluster>
- --destinationUsername<atlasUser>
- --destinationPassword<atlasPassword>
ソース レプリカセット ユーザーには、ソース クラスターでのアクセス権が必要です。backup ロールにより、適切な権限が付与されます。
ターゲットには、レプリカセット名に続いてノードのシードリストを次の形式で指定します。
<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,... 
指定されたユーザーは Atlas の Atlas admin を持っている必要があります。
レプリカセットの移行: ソース レプリカセットには Kerberos/GSSAPI 認証が必要です。
次の例では、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 を実行します。
- --host<sourceReplSet/seed list of members>
- --username<Kerberos user principal>
- --authenticationDatabase- '$external'
- --authenticationMechanism- GSSAPI
- --destination<Atlas Cluster>
- --destinationUsername<atlasUser>
- --destinationPassword<atlasPassword>
ソース レプリカセット ユーザーには、ソース クラスターでのアクセス権が必要です。backup ロールにより、適切な権限が付与されます。
ターゲットには、レプリカセット名に続いてノードのシードリストを次の形式で指定します。
<replicaSetName>/<replicaMember>,<replicaMember>,<replicaMember>,... 
指定されたユーザーは Atlas の Atlas admin を持っている必要があります。
mongomirrorファイルへの 出力の保存
mongomirror 手順からの出力ログをファイルに保存して、後で調査やデバッグに使えます。出力を mongomirror.log ファイルに保存するには、以下の書式を使用します。
mongomirror <args> 2>&1 | tee -a mongomirror.log