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>

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

値	説明
SCRAM-SHA-1	SHA-1 ハッシュ関数を使用する RFC5802 標準の Salted Challenge Response Authentication Mechanismです。
SCRAM-SHA-256	SHA-256 ハッシュ関数を使用する RFC 5802 標準の Salted Challenge Response Authentication Mechanism。
MONGODB-X509	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 を実行します。

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

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 は、データベースユーザーに対して次の形式の認証を提供します。

値	説明
SCRAM-SHA-1	SHA-1 ハッシュ関数を使用する RFC 5802 標準の Salted Challenge Response Authentication Mechanism。
SCRAM-SHA-256	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

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

これは、非推奨の 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)を使用します。

--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`	`mongomirror` がコレクションからターゲット Atlas クラスターにすべてのドキュメントまたはインデックスをコピーしたかどうかに応じて、`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`	`mongomirror` で発生したエラーを説明する文字列。

--collStatsThreshold <num>

バージョン 0.9.0 の新機能

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

--removeAutoIndexId

バージョン 0.12.0 の新機能

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

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

例

レプリカセットを 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'
--ssl
--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

戻る

手動で移行する

mongomirror Changelog

警告

構文

オプション

例

注意

注意

重要

重要

重要

例

レプリカセットを Atlas に移行する：ソースに認証なし

レプリカセットの移行: ソース レプリカセットは SCRAM-SHA1 認証を使用します。

レプリカセットの移行: ソース レプリカセットには X.509 クライアント認証が必要です。

レプリカセットの移行: ソース レプリカセットには Kerberos/GSSAPI 認証が必要です。

mongomirrorファイルへの 出力の保存

レプリカセットの移行: ソースレプリカセットは SCRAM-SHA1 認証を使用します。

レプリカセットの移行: ソースレプリカセットには X.509 クライアント認証が必要です。

レプリカセットの移行: ソースレプリカセットには Kerberos/GSSAPI 認証が必要です。

`mongomirror`ファイルへの出力の保存