Docs Menu
Docs Home
/
MongoDB Atlas
/ / /

以下を用いた移行: mongomirror

項目一覧

  • 前提条件
  • アップグレード パス
  • ダウンロード mongomirror
  • mongomirror プロセス
  • 実行する mongomirror
  • Atlas への切り替え
  • モニタリング
  • パフォーマンス
  • コマンド構文、オプション、および例
  • トラブルシューティング

mongomirror は、既存の MongoDB レプリカセットから MongoDB Atlas レプリカセットにデータを手動で移行するためのツールです。mongomirror では、既存のレプリカセットまたはアプリケーションをシャットダウンする必要はなく、ユーザーまたはロール データをインポートしたり、 config データベースをコピーしたりしません。

mongomirror を次の場合に使用します:

  • MongoDB Atlas の外部でホストされている MongoDB デプロイから MongoDB Atlas クラスターへのデータセットの 1 回限りの移行の実行。

  • ある Atlas クラスターから別の Atlas クラスターへのデータセットの 1 回限りの移行の実行。

データのインポートおよび移行ツールの選択」も参照してください。

  • ソース MongoDB の配置はレプリカセットである必要があります。ソースがスタンドアロンの MongoDBデプロイである場合は、 mongomirror実行中、 を実行してスタンドアロンをレプリカセットに変換します。

  • ソース レプリカセットでは MongoDB バージョン 2.6 以降を実行する必要があります。

  • ソースMongoDBレプリカセットは、M0 無料クラスターまたは M2/M5共有クラスターにはできません。

  • ソースMongoDBレプリカセットには、時系列コレクション内のデータを含めることはできません。

  • 手順中はいつでも featureCompatibilityVersion フラグを変更しないでください。

  • MongoDB 4.4以前のバージョンから MongoDB 5.0以降のバージョンを実行する Atlas クラスターに移行する場合は、コレクションからgeoHaystack インデックスをすべて削除します。

  • mongomirrorTTL インデックスと互換性がありません。既存の TTL インデックスをすべて削除し、移行プロセスが完了した後に再度ビルドします。既存のインデックスがクエリ パフォーマンスにとって重要で、削除を避けたい場合は、別の方法についてサポートにお問い合わせください

  • 移行プロセスの実行中は、renameCollection コマンドの使用や、$out 集計ステージを含む集計パイプラインの実行など、名前空間の変更を行わないでください。

  • 最初の同期は mongomirror プロセスの一部として実行され、renameCollection コマンドや $out 集約ステージは使用できません。

  • 最初の同期の段階でプライマリを再起動しないでください。

  • お使いの MongoDB 配置に、インデックス キー制限を超えるキーを持つインデックスが含まれている場合は、ライブ移行を開始する前に、インデックスを変更して、大きすぎるキーが含まれないようにします。

mongomirror には、ソース レプリカ セットへのネットワーク アクセス権が必要です。ソース レプリカ セットに認証が必要な場合は、mongomirror を実行するときにユーザー認証情報を含める必要があります。少なくとも次の権限を持つデータベース ユーザーを指定する必要があります。

  • すべてのデータベースとコレクションを読み取ります。admin データベースの readAnyDatabase ロールがこの要件をカバーします。

  • oplog を読みとります。「Oplog アクセス権限」を参照してください。

  • getParameter コマンドを実行します。

そのようなユーザーが存在しない場合は、ソース MongoDB レプリカセットにユーザーを作成します。MongoDB サーバーのバージョンによって、組み込みロールが異なります。自分の MongoDB Server バージョンに基づいて組み込みロールを選択し、mongosh で適切なコマンドを実行します。

  • ソースクラスターの場合、ユーザーには readAnyDatabaseclusterMonitor、および backup ロールが必要です。

    ライブ移行プロセスを実行するデータベースユーザーがこれらのロールを持っていることを確認するには、 admin データベースで db.getUser() コマンドを実行します。

    use admin
    db.getUser("admin")
    {
    "_id" : "admin.admin",
    "user" : "admin",
    "db" : "admin",
    "roles" : [
    {
    "role" : "backup",
    "db" : "admin"
    },
    {
    "role" : "clusterMonitor",
    "db" : "admin"
    }
    {
    "role" : "readAnyDatabase",
    "db" : "admin"
    }
    ]
    } ...

    さらに、ソースクラスターのデータベースユーザーには、 admin データベース上の oplog を読み取るロールが必要です。詳細については、「Oplog アクセス」を参照してください。

  • MongoDB 3.4 を実行しているソースクラスターの場合、ユーザーには少なくとも clusterMonitorreadAnyDatabase の両方のロールが必要です。以下に例を挙げます。

    use admin
    db.createUser(
    {
    user: "mySourceUser",
    pwd: "mySourceP@$$word",
    roles: [ "clusterMonitor", "readAnyDatabase" ]
    }
    )
  • MongoDB 3.2 を実行しているソースクラスターの場合、ユーザーには少なくとも clusterManagerreadAnyDatabase の両方のロールと、local データベースに対する読み取りアクセス権が必要です。これには、以下のコマンドで作成できるカスタムロールが必要です。

    use admin
    db.createRole(
    {
    role: "migrate",
    privileges: [
    { resource: { db: "local", collection: "" }, actions: [ "find" ] }
    ],
    roles: ["readAnyDatabase", "clusterManager"]
    }
    )
    db.createUser(
    {
    user: "mySourceUser",
    pwd: "mySourceP@$$word",
    roles: [ "migrate" ]
    }
    )
  • MongoDB 2.6 または 3.0 を実行しているソースクラスターの場合、ユーザーには少なくとも readAnyDatabase ロールが必要です。以下に例を挙げます。

    use admin
    db.createUser(
    {
    user: "mySourceUser",
    pwd: "mySourceP@$$word",
    roles: [ "readAnyDatabase" ]
    }
    )

宛先 Atlas の配置:

  • M0フリー クラスター、M2、または M5 共有クラスターにすることはできません。

  • サーバーレスインスタンスにすることはできません。

  • レプリカセットでなくてはなりません。

  • ソースクラスターの MongoDB のバージョンと同じかそれ以降のバージョンが必要です。アップグレード パスを参照してください。

  • ソース クラスターと重複する名前空間を含めることはできません。mongomirror が宛先クラスター上で重複する名前空間を検出すると、プロセスを開始する前に失敗します。宛先クラスターに重複する名前空間が含まれている場合は、--drop を使用して宛先クラスターからすべてのデータを削除するか、--includeNamespace を使用してソースクラスターからインポートする名前空間を一覧表示します。

  • そのIP アクセス リストには、以下のいずれかを含めなければなりません。

    • mongomirrorが稼働しているサーバーのパブリック IP アドレス、または

    • VPC ピアリング用に設定されている場合は、ピアリングの VPC CIDR ブロック(またはそのサブセット)、あるいはピア VPC のセキュリティ グループのいずれか。

    注意

    クラスター内の任意のノードのパブリック IP アドレスを確認するには、コマンドラインから nslookup ツールを使用します。詳しくは、「Atlas クラスターのパブリック IP の変更」を参照してください。

mongomirror には、宛先クラスターへのネットワーク アクセス権が必要です。

mongomirror を実行するには、Atlas admin ロールを持つデータベースユーザーを指定する必要があります。詳細については、「データベース ユーザーの追加」を参照してください。

重要

mongomirrorは、 MongoDB6.0 + ソースクラスターと6.0 + 宛先クラスター間の移行ではサポートされていません。mongomirror を使用してソースレプリカセット6 から移行することはできません。0 .x6 以降から宛先レプリカセット0 への .x 以降

mongomirrorを使用して、以前のバージョンのソースレプリカセットからMongoDBバージョン6.0 の宛先レプリカセットに移行できます。

または、ソースレプリカセットを 6.0.17+ または7.0.13 + にアップグレードし、このライブ移行手順を使用して、アップグレードされたレプリカセットを Atlas に移行することもできます。

mongomirror は、次の移行パスをサポートします。

Source Replica Set
MongoDB Version
Target Atlas Replica Set
MongoDB Version
5.0
6.0
4.4
6.0
4.2
6.0
4.0
6.0
3.6
6.0
3.4
6.0
3.2
6.0
3.0
6.0
2.6
6.0

注意

macOS 64ビットでは、 mongomirrorファイルをダウンロードした後、初めて開こうとするとセキュリティ警告が表示されます。 続行するには、「 セキュリティ設定を無効にしてアプリを開く 」を参照してください。

mongomirror を起動すると、次のことを行います。

  1. TLS/SSL 経由で Atlas に接続します。

  2. 最初の同期を実行し、コレクションを既存の MongoDB レプリカセットから MongoDB Atlas の宛先クラスターにコピーします。

  3. 最初の同期後、レプリカセットのoplogで受信変更を継続的に追跡し、Atlas の宛先クラスターで再生します。mongomirror configmongomirror--compressors データベースをコピーしません。ソースまたは宛先クラスターのいずれかで有効にし、 を使用して許可される圧縮ライブラリを指定すると、 はワイヤ圧縮を使用します。

    mongomirrorでは、宛先クラスター上のすべてのインデックスは、ソースクラスターでインデックスがどのようにビルドされたかに関係なくフォアグラウンドで作成されます。フォアグラウンドインデックスをビルドすると、データベース上の他のすべての操作がブロックされます。詳しくは、「 格納済みコレクションでのインデックス ビルド操作 」を参照してください。

一度起動すると、mongomirror はシャットダウンされるまで継続的に次のことを実行します。

  • 最初の同期段階で mongomirror をシャットダウンした場合は、mongomirror を再起動する前に、宛先クラスターが空であることを確認するか、--dropmongomirrorを実行します。

  • oplog のテーリング段階で mongomirror をシャットダウンすると、このプロセスにより oplog のテーリングが停止します。mongomirror を再起動することで、--bookmarkFile を使用して、最後に処理された oplog レコードからテーリングを再開できます。

1

ソース レプリカセットに認証が必要な場合は、実行中の mongomirror にユーザー認証情報を含める必要があります。要件については、「ソース レプリカセットで必要なアクセス権限」を参照してください。

mongomirror を実行するときにこれらの認証情報を指定する必要があるため、このユーザーのユーザー名とパスワードをメモしておきます。

2
  1. まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。

  3. サイドバーで、 Security見出しの下のDatabase Accessをクリックします。

    [データベース アクセス ]ページが表示されます。

3

mongomirror を実行するには、Atlas admin ロールを持つデータベースユーザーを指定する必要があります。データベースユーザーの作成に関するドキュメントについては、「データベースユーザーの追加」を参照してください。

そのようなユーザーが存在しない場合は、ユーザーを作成します。

  1. まだ表示されていない場合は Database Users タブをクリックします。

  2. Add New Database User をクリックします。

  3. Atlas admin ユーザーを追加します。

mongomirror を実行するときにこれらの認証情報を指定する必要があるため、新しいユーザーに選択したユーザー名とパスワードをメモしておきます。

4

mongomirror を実行するホストがクラスターの IPアクセス リストにない場合は、リストをアップデートします。次のいずれかを指定できます。

  • mongomirror が実行するサーバーのパブリック IP アドレス、または

  • VPCピアリング用に設定されている場合、ピアの VPC CIDR ブロック(またはサブネット)、あるいは、ピアVPC のセキュリティー グループのいずれか。

5
  1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. まだ表示されていない場合は、サイドバーの [Clusters] をクリックします。

    [ Clusters (クラスター) ] ページが表示されます。

6

データを移行する Atlas クラスターのConnectをクリックします。

7

Atlas クラスターのホスト名情報は、Atlas ユーザインターフェースから取得できます。

注意

mongomirror を使用してデータを移行する場合、ドライバーを使用する必要はありません。

  1. Connect ダイアログボックスから [Shell] をクリックします。

  2. ドロップダウンリストから、[3.4 or earlier] を選択します。接続文字列は次の例のようになります。この例は、読みやすくするために複数行に分割されています。

    mongodb://<db_username>:<db_password>@
    00.foo.mongodb.net:27017,
    01.foo.mongodb.net:27017,
    02.foo.mongodb.net:27017/test?
    ssl=true&replicaSet=myAtlasRS&authSource=admin
  3. テキスト エディターで、replicaSet の値を貼り付け、フォワードスラッシュ(/)を追加し、次の例のようにホスト リストをカンマで区切った値として追加します。

    myAtlasRS/00.foo.mongodb.net:27017,01.foo.mongodb.net:27017,02.foo.mongodb.net:27017

この値を次のステップの --destination に使用します。

8

移行プロセスを完了するには、 Atlas に切り替えます。

mongomirror が最初の同期を完了し、レプリカセットの oplog を追跡したら、宛先 Atlas クラスターに切り替えられます。

1

これにより、ソースクラスター上で追加の書込み (write) が発生しなくなります。

2

これは、ソース クラスターと宛先クラスターがコンシステントな状態にあるということです。

3

Atlas クラスターが最新になったら、 mongomirror を停止します。

4

クラスター パネルの [Connect] ボタンから提供される Atlas 接続文字列を使用して、クライアント アプリケーションを更新します。

Atlas への接続の詳細については、「ドライバー経由で接続」を参照してください。

mongomirror は進行状況をターミナルの標準出力にログします。最初の同期中、mongomirror はコピーしたコレクションごとにプログレス バーをログします。以下に例を挙げます。

2021-08-09T16:35:50.227-0000 [#....................] park.events 2179/34184 (6.4%)
2021-08-09T16:35:50.227-0000 [#############........] zoo.animals 29000/49778 (58.3%)

oplog を追跡する場合、mongomirror はソース クラスターの最新の oplog エントリーとデスティネーション クラスターで最後に処理された oplog エントリーとの間の遅延時間を秒単位で記録します。以下に例を挙げます。

2016-12-12T16:22:17.027-0800 Current lag from source: 6s

6 秒の遅延時間は、処理された最後の oplog エントリー mongomirror は、ソースクラスターで使用可能な最新エントリーより 6 秒前に発生したということを示します。

注意

mongomirror が追いつくのにかかる時間は、1 秒あたりに到着するエントリー数に応じて、6 秒より長くなるか短くなる場合があります。

遅延時間が 0 秒であれば、mongomirror は、最新の oplog エントリーの 1 秒未満前に到着したエントリーを処理しているということになります。

ソースクラスターにインデックスがある場合、mongomirror はデスティネーションクラスターに同じインデックスを構築します。進行ログは、インデックス構築プロセスの開始時刻と終了時刻を示します。インデックス構築の進捗状況を見るには、次の方法があります。

  • 宛先クラスターのプライマリ ノードで currentOp コマンドを使用します。command フィールドには実行中の操作に関する情報が表示されます。インデックス構築エントリーは、次のようになります。

    "command" : {
    "createIndexes" : "perfs",
    "indexes" : [
    {
    "key" : {
    "animal" : "text"
    },
    "name" : "animal_text"
    }
    ]...
  • 宛先クラスターの mongodb ログ をダウンロードし、インデックス関連の行の最近のエントリーを検索します。インデックスの構築に関連するログ メッセージは次のようになります。

    {"t":{"$date":"2021-08-09T16:35:50.227+00:00"},"s":"I", "c":"INDEX", "id":20447, "ctx":"conn1080","msg":"Index build: completed","attr":{"buildUUID":{"uuid":{"$uuid":"c4a62739-bf19-456d-bbd6-7baa29f1063b"}}}}

ネットワークと CPU リソースの競合を回避するには、レプリカセットの mongod インスタンスが実行されているホスト以外のホストで mongomirror を実行します。

  • mongomirror は、セカンダリがある場合と同様に、ソース レプリカセットのパフォーマンスに影響します。

    • 最初の同期段階では、負荷はデータセットのサイズに応じて増加します。

    • 最初の同期が完了すると、負荷は 1 時間あたりに使用される oplog ギガバイトに応じて増えます。

mongomirror のシンタックス、オプション、および例については、mongomirror リファレンス ページをご覧ください。

mongomirrorトラブルシューティングについては、「ライブ移行(プル)の一般的な検証後エラー」を参照してください。

戻る

自己管理型ツール