Devolver una base de datos de la aplicación externa a MongoDB Ops Manager

Cómo funciona la migración

El recurso de MongoDB Ops Manager comienza con una base de datos de la aplicación externa: un recurso de MongoDB con spec.role establecido en AppDB, denominado <primary-om-name>-db, que posee el StatefulSet de la base de datos de la aplicación. La migración procede de la siguiente manera:

1. Usted remueve spec.externalApplicationDatabaseRef del recurso de MongoDB Ops Manager y añade spec.applicationDatabase.

2. El operador de Kubernetes solicita al recurso de MongoDB que libere el StatefulSet. El recurso de MongoDB informa de la fase Pending mientras espera a que el recurso de MongoDB Ops Manager lo reclame.

3. El operador de Kubernetes recupera el StatefulSet y lo gestiona como una base de datos de la aplicación interna. Debido a que la cadena de conexión no cambia, los pods de MongoDB Ops Manager no se reinician.

4. Borra el recurso de MongoDB, que ya no posee nada.

Requisitos previos

Antes de comenzar, cumpla con las siguientes tareas:

• Instala el operador de Kubernetes y kubectl. Para aprender más, consulta Instala con Kubernetes.

• Confirme que el recurso primario de MongoDB Ops Manager utiliza una base de datos de la aplicación externa: establece spec.externalApplicationDatabaseRef en un recurso de MongoDB denominado <primary-om-name>-db, no establece spec.applicationDatabase, y su status.applicationDatabase.phase informa Disabled.

• Confirme que el recurso de MongoDB está en la fase Running y es propietario del StatefulSet de la base de datos de la aplicación.

Considerations

Revise las siguientes consideraciones antes de migrar:

• Establezca spec.applicationDatabase.version en la versión que la base de datos de la aplicación ya ejecuta. La reutilización de la misma versión mantiene los mismos archivos binarios y datos en su lugar. Otra versión inicia una actualización de la base de datos de la aplicación al mismo tiempo que el traspaso.

• El operador de Kubernetes no borra el Proyecto de MongoDB Ops Manager que creó para la base de datos de la aplicación externa. Remover ese Proyecto hace que las métricas históricas de la base de datos de la aplicación sean ilegibles, por lo tanto, limpiarlo es su decisión.

Procedimiento

export K8S_CTX="<your-kube-context>"export MDB_NS="mongodb"
export PRIMARY_OM_NAME="primary-om"export APPDB_NAME="${PRIMARY_OM_NAME}-db"export APPDB_VERSION="8.0.5-ent"

kubectl patch om "${PRIMARY_OM_NAME}" \  --context "${K8S_CTX}" -n "${MDB_NS}" \  --type merge \  -p "{\"spec\":{\"externalApplicationDatabaseRef\":null,\"applicationDatabase\":{\"members\":3,\"version\":\"${APPDB_VERSION}\"}}}"

kubectl delete mdb "${APPDB_NAME}" \  --context "${K8S_CTX}" -n "${MDB_NS}" --wait=true --timeout=300s

Devuelve una base de datos de aplicación multiclúster.

Si el recurso principal de Ops Manager hace referencia a una base de datos de aplicación MongoDBMultiCluster externa, puede devolverla a una base de datos de aplicación multiclúster gestionada internamente. El operador de Kubernetes solicita al recurso MongoDBMultiCluster que libere el StatefulSet de la base de datos de aplicación en cada clúster miembro. A continuación, el recurso Ops Manager vuelve a adoptar cada StatefulSet como una base de datos de aplicación interna. Los pods de Ops Manager no se reinician, ya que la cadena de conexión no cambia.

El procedimiento coincide con el procedimiento de clúster único que se describe en esta página, con las siguientes diferencias:

• Configure las siguientes variables de entorno adicionales para los clústeres miembros y la configuración TLS de la base de datos de la aplicación. Utilice los mismos valores que utiliza la base de datos de la aplicación externa:

  export K8S_CTX_MEMBER_1="<member-cluster-1-context>"export K8S_CTX_MEMBER_2="<member-cluster-2-context>"export APPDB_CERT_PREFIX="appdb"export APPDB_CA_CONFIGMAP="${APPDB_NAME}-ca"

• El spec.applicationDatabase restaurado debe establecer topology en MultiCluster y debe usar el mismo diseño de miembro y configuración TLS que la base de datos de la aplicación externa, para que el recurso del administrador de operaciones pueda volver a adoptar los StatefulSets existentes:

  kubectl patch om "${PRIMARY_OM_NAME}" \  --context "${K8S_CTX}" -n "${MDB_NS}" \  --type merge \  -p "{\"spec\":{\"externalApplicationDatabaseRef\":null,\"applicationDatabase\":{\"topology\":\"MultiCluster\",\"version\":\"${APPDB_VERSION}\",\"security\":{\"certsSecretPrefix\":\"${APPDB_CERT_PREFIX}\",\"tls\":{\"ca\":\"${APPDB_CA_CONFIGMAP}\"}},\"clusterSpecList\":[{\"clusterName\":\"${K8S_CTX_MEMBER_1}\",\"members\":2},{\"clusterName\":\"${K8S_CTX_MEMBER_2}\",\"members\":2}]}}}"

• El recurso MongoDBMultiCluster informa la fase Pending mientras que el recurso Ops Manager recupera los StatefulSets. Elimine el recurso MongoDBMultiCluster solo después de que status.applicationDatabase.phase informe Running.

• Para verificar la migración, inspeccione el StatefulSet de la base de datos de la aplicación en cada clúster miembro, denominado <primary-om-name>-db-<cluster-index>. Tras la transferencia, el StatefulSet permanece con un ownerReferences vacío, y el recurso del Administrador de operaciones lo gestiona como una base de datos de aplicación interna.

Problemas comunes de migración

Próximos pasos

Para usar una base de datos de la aplicación externa de nuevo, consulte Migrar una base de datos de la aplicación a una implementación externa.