Transición de un Embedded servidor de configuración a un Dedicated servidor de configuración

Asegúrate de que el balanceador esté habilitado.

Para migrar datos desde la partición de configuración, el proceso Balanceador debe estar habilitado. Para comprobar el estado del balanceador, utiliza el método sh.getBalancerState():

sh.getBalancerState()

Si la operación devuelve true, el balanceador está habilitado.

Si la operación devuelve false, consulta Activar el balanceador.

Verifica que el servidor de configuración esté actuando como una partición.

Ejecuta listShards para confirmar que la partición de configuración aparece en la lista de particiones:

db.adminCommand( { listShards: 1 } )

En la salida, el campo shards._id contiene los nombres de las particiones. La partición de configuración suele tener un _id de "config":

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

Comienza a migrar los datos particionados fuera de la partición de configuración.

Desde la base de datos admin, ejecute el comando transitionToDedicatedConfigServer:

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

La partición de configuración entra en el estado drenar y el balanceador comienza a migrar fragmentos de la partición de configuración a las particiones restantes en el clúster. Dependiendo de la capacidad de tu red y la cantidad de datos, esta operación puede tardar desde minutos hasta días en completarse.

Mueva las colecciones no particionadas fuera del fragmento de partición.

Utiliza la etapa de agregación $listClusterCatalog para identificar las colecciones que no están particionadas (sharded) y que aún residen en la partición de configuración:

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 } }
])

Para cada namespace en la salida, utiliza sh.moveCollection() para mover la colección no particionada de la partición de configuración a una partición receptora:

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

Repetí este paso hasta que no quede ninguna colección no particionada en la partición de configuración.

Cambia la partición primaria para las bases de datos que usan la partición de configuración.

Desde la base de datos admin, ejecute db.printShardingStatus():

use admin
db.printShardingStatus()

En la sección databases de la salida, verifica el campo primary de cada base de datos. Para cualquier base de datos de aplicación (bases de datos distintas a config y admin) cuya primaria sea la partición de configuración, cambie la partición primaria a otra partición.

Para cambiar la partición primaria de una base de datos, ejecute movePrimary:

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

Cualquier colección que no se haya movido en el paso anterior estará no disponible mientras movePrimary se esté ejecutando.

Verifica el estado de transición.

Para comprobar el progreso de la transición, vuelve a ejecutar transitionToDedicatedConfigServer desde la base de datos admin:

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

Continúe verificando el estado hasta que la transición se complete exitosamente y la salida se asemeje al siguiente ejemplo:

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

Confirmar la transición a un servidor de configuración dedicado.

Después de que la partición de configuración informe un state de 'completed', confirme la transición de un servidor de configuración incrustado a un servidor de configuración dedicado:

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

Una confirmación exitosa devuelve la siguiente salida:

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

Cuando tiene éxito, MongoDB elimina la partición config de los metadatos del clúster y finaliza la transición a un servidor de configuración dedicado. Si la partición de configuración no se vacía por completo, el comando falla y debe continuar verificando el estado de transición de { state: 'completed' } antes de volver a intentarlo.

Después de que la transición se confirme, listShards ya no incluye la partición de configuración en la lista de particiones. El clúster ahora utiliza un servidor de configuración dedicado y el servidor de configuración ya no almacena los datos de la aplicación como una partición.