埋め込みから専用コンフィギュレーションサーバーへの移行

バランサーが有効になっていることを確認します。

コンフィギュレーションシャードからデータを移行するには、バランサープロセスを有効にする必要があります。バランサーの状態を確認するには、 メソッドを使用します。sh.getBalancerState()

sh.getBalancerState()

操作がtrueを返す場合、バランサーは有効になっています。

この操作でfalseが返される場合は、 「 バランサーを有効にする 」を参照してください。

コンフィギュレーションサーバーがシャードとして機能していることを確認します。

listShardsを実行して、構成シャードがシャード リストに表示されることを確認します。

db.adminCommand( { listShards: 1 } )

出力の shards._idフィールドにはシャード名が含まれます。コンフィギュレーションシャードには通常、_id の "config" があります。

{
  shards: [
    {
      _id: 'config',
      ...
    },
    ...
  ],
  ok: 1
  ...
}

コンフィギュレーションシャードからシャーディングされたデータの移行を開始します。

adminデータベースから コマンドを実行します。transitionToDedicatedConfigServer

use admin
db.adminCommand( { transitionToDedicatedConfigServer: 1 } )

コンフィギュレーションシャードはドレイン状態になり、バランサーはコンフィギュレーションシャードからクラスター内の残りのシャードへのチャンクの移行を開始します。ネットワークキャパシティーとデータ量に応じて、この操作が完了するまでに 分から 日までかかる場合があります。

シャーディングされていないコレクションをコンフィギュレーションシャードから移動します。

$listClusterCatalog集計ステージを使用して、コンフィギュレーションシャード上に残っているシャーディングされていないコレクションを識別します。

use admin
db.aggregate([
  { $listClusterCatalog: { shards: true } },
  {
    $match: {
      sharded: false,
      shards: "config",
      type: { $nin: ["timeseries", "view"] },
      ns: { $not: { $regex: "^enxcol_\\..*(\\.esc|\\.ecc|\\.ecoc|\\.ecoc\\.compact)$" } },
      $or: [
        { ns: { $not: { $regex: "\\.system\\." } } },
        { ns: { $regex: "\\.system\\.buckets\\." } }
      ],
      db: { $nin: ["config", "admin"] }
    }
  },
  { $project: { _id: 0, ns: 1 } }
])

出力内の各名前空間について、sh.moveCollection() を使用してシャーディングされていないコレクションを構成シャードから受信者シャードに移動します。

sh.moveCollection(
  "<database>.<collection>",
  "<ID of recipient shard>"
)

コンフィギュレーションシャードにシャーディングされていないコレクションがなくなるまで、この手順を繰り返します。

コンフィギュレーションシャード を使用するデータベースのプライマリシャードを変更します。

adminデータベースからdb.printShardingStatus() を実行します。

use admin
db.printShardingStatus()

出力の databases セクションで、各データベースの primaryフィールドを確認します。コンフィギュレーションシャードがプライマリであるアプリケーションデータベース（configと admin 以外のデータベース）は、プライマリシャードを別のシャードに変更します。

データベースのプライマリシャードを変更するには、movePrimary を実行します。

db.adminCommand({
  movePrimary: "<dbName>",
  to: "<recipientShard>"
})

movePrimaryの実行中は、前のステップで移動されなかったコレクションは利用できません。

移行ステータスを確認します。

移行の進行状況を確認するには、transitionToDedicatedConfigServer adminデータベースから を再実行します。

use admin
db.adminCommand( { transitionToDedicatedConfigServer: 1 } )

移行が正常に完了し、出力が次の例のようになるまで、ステータスをチェックし続けます。

{
  state: 'completed',
  msg: 'removeshard completed successfully',
  shard: 'config',
  ok: 1
}

専用のコンフィギュレーションサーバーへの移行をコミットします。

コンフィギュレーションシャードが 'completed' の state を報告したら、埋め込みコンフィギュレーションサーバーから専用コンフィギュレーションサーバーへの移行をコミットします。

use admin
db.adminCommand( { commitTransitionToDedicatedConfigServer: 1 } )

コミットが成功すると、次の出力が返されます。

{
   ok: 1,
   '$clusterTime': {
      ...
   },
   operationTime: ...
}

成功すると、 MongoDB はクラスターメタデータから config シャードを削除し、専用のコンフィギュレーションサーバーへの移行を終了します。コンフィギュレーションシャードが完全にドレインされていない場合、コマンドは失敗します。再試行する前に、{ state: 'completed' } の移行ステータスを引き続き確認する必要があります。

移行がコミットされると、 はシャードlistShards リストに構成シャードを含めなくなります。クラスターは専用のコンフィギュレーションサーバーを使用するようになり、コンフィギュレーションサーバーはアプリケーションデータをシャードとして保存しなくなりました。