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
ロールを持つユーザーは適切な権限を提供します。必要な特定の権限の詳細については、「ソース レプリカセットで必要なアクセス権限」を参照してください。
--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>
詳細については、「認証メカニズム」を参照してください。
--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 は、データベースユーザーに対して次の形式の認証を提供します。
値説明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 管理者ロールを持つユーザーには適切な権限が付与されます。必要な特定の権限の詳細については、「デスティネーションクラスターに必要なアクセス」を参照してください。
--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
非推奨。使用
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)を使用します。
--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>
に HTTPGET
リクエストを発行して、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
例
レプリカセットを 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