Migrar una base de datos de la aplicación a una implementación externa

Puede convertir un recurso de MongoDB Ops Manager que utiliza una base de datos de la aplicación gestionada internamente en uno que utiliza una base de datos de la aplicación externa: un recurso personalizado de MongoDB con spec.role establecido en AppDB. Esto permite a MongoDB Ops Manager realizar copias de seguridad y restaurar la base de datos de la aplicación. Para obtener más información, consulte Realizar copias de seguridad de la base de datos de la aplicación de MongoDB Ops Manager.

La migración reasigna la propiedad del StatefulSet de la base de datos de la aplicación existente y sus Persistent Volumes del recurso de MongoDB Ops Manager al recurso de MongoDB. El Operador de Kubernetes no mueve ni vuelve a crear sus datos, y no reinicia los pods de Ops Manager.

Cómo funciona la migración

El recurso de MongoDB Ops Manager comienza con una base de datos de la aplicación gestionada internamente, y el operador de Kubernetes posee un StatefulSet llamado <primary-om-name>-db. La migración procede de la siguiente manera:

Crea un recurso de MongoDB con spec.role establecido en AppDB y el mismo nombre que el StatefulSet, en un proyecto que gestiona una instancia de MongoDB Ops Manager de **gestión**. El recurso de MongoDB no puede asumir la propiedad del StatefulSet todavía, por lo tanto, permanece en la fase Pending con un mensaje que indica que no puede asumir la propiedad del StatefulSet de la base de datos de la aplicación.
Añade spec.externalApplicationDatabaseRef al recurso de MongoDB Ops Manager. El operador de Kubernetes desvincula el StatefulSet al remover la referencia del propietario del recurso de MongoDB Ops Manager y marcar el StatefulSet como listo para la migración. El recurso de MongoDB entonces se hace cargo de ello.

Dado que el operador de Kubernetes calcula la misma cadena de conexión que antes, que utiliza los mismos nombres de host, los pods de MongoDB Ops Manager no se reinician.

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.
Implemente un recurso primario de MongoDB Ops Manager que utilice una base de datos de la aplicación gestionada internamente. Este recurso establece spec.applicationDatabase, y el operador de Kubernetes posee un StatefulSet llamado <primary-om-name>-db. Para obtener más información, consulta Implementar un recurso de MongoDB Ops Manager.
Implemente un recurso de gestión de MongoDB Ops Manager que se encuentra en la fase Running y que es propietario del Proyecto para la base de datos de la aplicación externa. Para obtener más información, consulte Implementar Ops Manager con una base de datos de la aplicación externa.
Cree credenciales para el operador de Kubernetes. El secreto contiene el par de claves de API programáticas que el operador de Kubernetes utiliza para autenticarse en la API de gestión de MongoDB Ops Manager en su nombre. Puedes darle al secreto cualquier nombre. Para aprender más, consulte Crear credenciales para el operador de Kubernetes.

Considerations

Revise las siguientes consideraciones antes de migrar:

La versión de la base de datos de la aplicación que establezca en el recurso de MongoDB debe coincidir con la versión que ejecuta la base de datos de la aplicación gestionada internamente, y debe ser una versión de MongoDB que ofrezca la instancia de MongoDB Ops Manager de gestión.
El Kubernetes operador no es compatible con spec.applicationDatabase.passwordSecretKeyRef durante la migración. El Kubernetes operador genera una nueva contraseña y rota cualquier contraseña que haya proporcionado.
La base de datos de la aplicación puede no estar disponible durante uno o dos minutos si la configuración de recursos de MongoDB difiere de la configuración de la base de datos de la aplicación gestionada internamente, como una plantilla de pod diferente o un conjunto de contenedores diferente. Si las dos configuraciones son semánticamente idénticas, la base de datos de la aplicación permanece disponible.
Para migrar una base de datos de aplicaciones multiclúster, la base de datos de aplicaciones administrada internamente debe establecer spec.applicationDatabase.topology en MultiCluster, y la base de datos de aplicaciones externa debe ser un recurso MongoDBMultiCluster. El operador de Kubernetes rechaza la migración si la topología de la base de datos de aplicaciones actual no coincide con el tipo de la base de datos de aplicaciones externa. Para obtener más información, consulte Migrar una base de datos de aplicaciones multiclúster.

Procedimiento

Establezca las variables de entorno para la migración.

export K8S_CTX="<your-kube-context>"export MDB_NS="mongodb"
export MANAGEMENT_OM_NAME="management-om"export PRIMARY_OM_NAME="primary-om"
export APPDB_NAME="${PRIMARY_OM_NAME}-db"export APPDB_VERSION="8.0.5-ent"
export MANAGEMENT_OM_URL="http://${MANAGEMENT_OM_NAME}-svc.${MDB_NS}.svc.cluster.local:8080"export MANAGEMENT_OM_ADMIN_KEY_SECRET="<your-operator-credentials-secret>"
export APPDB_PROJECT_CONFIGMAP="${APPDB_NAME}-config"export APPDB_PROJECT_NAME="external-appdb"

Confirme el estado inicial.

Confirme que el recurso primario de MongoDB Ops Manager y su base de datos de la aplicación gestionada internamente están en la fase Running:
```
kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{.status.opsManager.phase} / appdb={.status.applicationDatabase.phase}{"\n"}'
```
Confirme que el recurso de MongoDB Ops Manager es propietario del StatefulSet de la base de datos de la aplicación:
```
kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}'
```
El comando devuelve MongoDBOpsManager/${PRIMARY_OM_NAME}.

Crear el ConfigMap del Proyecto para la base de datos de la aplicación externa.

El valor orgId es obligatorio. Si lo establece en una string vacía, el operador de Kubernetes crea una organización con el mismo nombre que su Proyecto.

kubectl create configmap "${APPDB_PROJECT_CONFIGMAP}" \  --context "${K8S_CTX}" -n "${MDB_NS}" \  --from-literal=baseUrl="${MANAGEMENT_OM_URL}" \  --from-literal=projectName="${APPDB_PROJECT_NAME}" \  --from-literal=orgId=""

Crear el recurso de MongoDB para la base de datos de la aplicación externa.

Asigne al recurso el mismo nombre que el StatefulSet de la base de datos de la aplicación existente.

kubectl apply --context "${K8S_CTX}" -n "${MDB_NS}" -f - <<EOFapiVersion: mongodb.com/v1kind: MongoDBmetadata:  name: ${APPDB_NAME}spec:  members: 3  version: ${APPDB_VERSION}  type: ReplicaSet  role: AppDB  opsManager:    configMapRef:      name: ${APPDB_PROJECT_CONFIGMAP}  credentials: ${MANAGEMENT_OM_ADMIN_KEY_SECRET}  persistent: true  security:    authentication:      enabled: true      modes: ["SCRAM"]      ignoreUnknownUsers: trueEOF

Confirme que el recurso de MongoDB espera la propiedad.

Hasta que el recurso de MongoDB Ops Manager libere el StatefulSet, el recurso de MongoDB permanece en la fase Pending. Esto es lo esperado y no es un error.

kubectl wait --for=jsonpath='{.status.phase}'=Pending \  mdb/"${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=300s
kubectl get mdb "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{.status.message}{"\n"}'

El mensaje de estado indica que el recurso no puede asumir la propiedad del StatefulSet de la base de datos de la aplicación.

Agregue la referencia externa de la base de datos de la aplicación al recurso de MongoDB Ops Manager.

kubectl patch om "${PRIMARY_OM_NAME}" \  --context "${K8S_CTX}" -n "${MDB_NS}" \  --type merge \  -p "{\"spec\":{\"externalApplicationDatabaseRef\":{\"name\":\"${APPDB_NAME}\",\"kind\":\"MongoDB\"}}}"

Puede remover spec.applicationDatabase en el mismo parche. Dejarlo en su lugar no tiene ningún efecto: una vez que configure spec.externalApplicationDatabaseRef, el operador de Kubernetes deja de administrar una base de datos de la aplicación interna para este recurso.

Espere a que la migración termine.

kubectl wait --for=jsonpath='{.status.phase}'=Running \  mdb/"${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1200s
kubectl wait --for=jsonpath='{.status.opsManager.phase}'=Running \  om/"${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" --timeout=1800s

Verifique la migración.

Confirme que el recurso de MongoDB es propietario del StatefulSet de la base de datos de la aplicación:
```
kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}'
```
El comando devuelve MongoDB/${APPDB_NAME}.
Confirme que el recurso de MongoDB Ops Manager informa su base de datos de la aplicación como Disabled, lo que significa que el operador de Kubernetes ya no gestiona una base de datos de la aplicación interna para él:
```
kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{.status.applicationDatabase.phase}{"\n"}'
```
Confirme que los pods de MongoDB Ops Manager no se reiniciaron comprobando su antigüedad y el número de reinicios:
```
kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}"
```

Migrar una base de datos de aplicación multiclúster

Si el recurso principal de Ops Manager utiliza una base de datos de aplicaciones multiclúster gestionada internamente, puede migrarla a un recurso MongoDBMultiCluster externo. El operador de Kubernetes desvincula el StatefulSet de la base de datos de aplicaciones en cada clúster miembro, y el recurso MongoDBMultiCluster adopta cada uno de ellos. 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:

La base de datos de la aplicación gestionada internamente debe establecer spec.applicationDatabase.topology en MultiCluster.
La base de datos de aplicación externa debe ser un recurso MongoDBMultiCluster con spec.role configurado como AppDB, con el mismo nombre, diseño de miembros y configuración TLS que la base de datos de aplicación administrada internamente. Una base de datos de aplicación externa multiclúster requiere cifrado TLS y comunicación en red entre clústeres, con o sin malla de servicios. Para obtener más información, consulte Implementar una base de datos de aplicación externa multiclúster.
Establece kind en MongoDBMultiCluster cuando añadas spec.externalApplicationDatabaseRef:
```
kubectl patch om "${PRIMARY_OM_NAME}" \  --context "${K8S_CTX}" -n "${MDB_NS}" \  --type merge \  -p "{\"spec\":{\"externalApplicationDatabaseRef\":{\"name\":\"${APPDB_NAME}\",\"kind\":\"MongoDBMultiCluster\"}}}"
```
El operador de Kubernetes realiza la transferencia de propiedad en cada clúster miembro. 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>:
```
kubectl get statefulset "${APPDB_NAME}-0" --context "${K8S_CTX_MEMBER}" -n "${MDB_NS}" \  -o jsonpath='{.metadata.labels.mongodbmulticluster}{"\n"}'
```
El comando devuelve <namespace>-<appdb-name> y se borra la anotación mongodb.com/appdb-migration-ready. Para obtener más información sobre el seguimiento de la propiedad en implementaciones de clústeres múltiples, consulte Anotaciones de migración.

Problemas comunes de migración

El recurso de MongoDB informa de un error de versión

Si el recurso de MongoDB informa Failed con un mensaje de que la versión de MongoDB no está disponible, establezca spec.version a una versión que ofrezca la instancia de MongoDB Ops Manager de gestión, y mantenga la versión de MongoDB Ops Manager y la versión de la base de datos de la aplicación en la misma versión principal.

El recurso de MongoDB permanece pendiente después del parche

El operador de Kubernetes debe desvincular el StatefulSet antes de que el recurso de MongoDB pueda tomar posesión de él. Confirme que ha aplicado spec.externalApplicationDatabaseRef al recurso primario de MongoDB Ops Manager y que el valor de spec.externalApplicationDatabaseRef.name es exactamente <primary-om-name>-db.

El recurso de MongoDB informa de un error de proyecto

Si el recurso de MongoDB permanece en la Pending fase con un error de proyecto o de registro, la API pública de gestión de MongoDB Ops Manager podría no haber estado lista cuando creó el recurso. Confirme que el recurso de gestión de MongoDB Ops Manager está en la fase Running y que su API responde a las solicitudes; a continuación, vuelva a conciliar el recurso.

Los pods de MongoDB Ops Manager se reinician durante la migración

Si se reinician los pods de MongoDB Ops Manager, la cadena de conexión calculada cambió. Para un set de réplicas que utiliza el puerto por defecto, la cadena de conexión es idéntica antes y después de la migración. El operador de Kubernetes no es compatible con puertos que no son por defecto para esta migración.

Próximos pasos

Para hacer una copia de seguridad de la base de datos de la aplicación externa, habilite la copia de seguridad en el recurso de MongoDB en el Proyecto que gestiona la instancia de MongoDB Ops Manager de gestión. Para aprender más, consulte Configurar las copias de seguridad de la base de datos de MongoDB.
Para revertir esta migración, consulte Devolver una base de datos de la aplicación externa a Ops Manager.

Volver

Implementar con una base de datos de la aplicación externa

Volver a una base de datos de la aplicación interna