Retornar um banco de dados de aplicativo externo ao MongoDB Ops Manager

Você pode retornar um banco de dados de aplicativo externo ao gerenciamento interno pelo recurso do MongoDB Ops Manager. O recurso do MongoDB Ops Manager recupera o StatefulSet do banco de dados de aplicativo existente, e então você exclui o recurso do MongoDB que o gerenciou. O operador Kubernetes não move nem recria seus dados e não reinicia os pods do MongoDB Ops Manager.

Como funciona a migração

O recurso do MongoDB Ops Manager começa com um banco de dados de aplicativo externo: um recurso do MongoDB com spec.role definido como AppDB, chamado <primary-om-name>-db, que possui o StatefulSet do banco de dados de aplicativo. A migração prossegue da seguinte forma:

Você remove spec.externalApplicationDatabaseRef do recurso do MongoDB Ops Manager e adiciona spec.applicationDatabase.
O Kubernetes operador solicita ao recurso MongoDB que libere o StatefulSet. O recurso MongoDB relata a fase Pending enquanto aguarda que o recurso MongoDB Ops Manager o recupere.
O operador Kubernetes recupera o StatefulSet e o gerencia como um banco de dados de aplicativo interno. Como a string de conexão não muda, os pods do Ops Manager não reiniciam.
Você exclui o recurso do MongoDB, que não possui mais nada.

Aviso

Exclua o recurso MongoDB somente depois que o recurso MongoDB Ops Manager gerenciar o banco de dados de aplicativo interno novamente. Se você excluir o recurso MongoDB enquanto ele ainda for proprietário do StatefulSet, o Kubernetes coletará o lixo do banco de dados de aplicativo. Em recuperação desse estado requer a recriação do banco de dados de aplicativo a partir das Persistent Volume Claims retidas, o que causa tempo de inatividade e rotaciona as credenciais do banco de dados de aplicativo.

Pré-requisitos

Antes de começar, conclua as seguintes tarefas:

Instale o operador Kubernetes e kubectl. Para aprender mais, consulte Instalar com Kubernetes.
Confirme se o recurso primário do MongoDB Ops Manager usa um banco de dados de aplicativo externo: ele define spec.externalApplicationDatabaseRef para um recurso MongoDB chamado <primary-om-name>-db, ele não define spec.applicationDatabase, e seu status.applicationDatabase.phase relata Disabled.
Confirme que o recurso MongoDB está na fase Running e possui o StatefulSet do banco de dados de aplicativo.

Considerações

Revisar as seguintes considerações antes de migrar:

Defina spec.applicationDatabase.version para a versão que o banco de dados de aplicativo já executa. Reutilizar a mesma versão mantém os mesmos binários e dados intactos. Uma versão diferente inicia uma atualização do banco de dados de aplicativo ao mesmo tempo que a transferência.
O operador do Kubernetes não exclui o projeto do MongoDB Ops Manager que ele criou para o banco de dados de aplicativo externo. Remover esse projeto torna as métricas históricas do banco de dados de aplicativo ilegíveis, portanto, a limpeza é uma decisão sua.

Procedimento

Defina as variáveis de ambiente para a migração.

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"

Confirme o estado inicial.

Confirme se o recurso do MongoDB Ops Manager faz referência ao banco de dados de aplicativo externo e relata seu banco de dados de aplicativo como Disabled:
```
kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='ref={.spec.externalApplicationDatabaseRef.name} appdb={.status.applicationDatabase.phase}{"\n"}'
```
Confirme que o recurso MongoDB possui o StatefulSet do banco de dados de aplicativo:
```
kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}'
```
O comando retorna MongoDB/${APPDB_NAME}.

Reconfigure o recurso do MongoDB Ops Manager para usar um banco de dados de aplicativo interno.

Este patch remove spec.externalApplicationDatabaseRef e adiciona spec.applicationDatabase.

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

Aguarde até que o recurso do MongoDB Ops Manager recupere o StatefulSet.

Confirme se o recurso MongoDB libera o StatefulSet. O recurso relata a fase Pending com uma mensagem de que está em migração reversa para o recurso MongoDB Ops Manager:
```
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"}'
```
Aguarde o recurso do MongoDB Ops Manager gerenciar o banco de dados de aplicativo interno novamente:
```
kubectl wait --for=jsonpath='{.status.applicationDatabase.phase}'=Running \  om/"${PRIMARY_OM_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
```

Exclua o recurso do MongoDB.

Conclua esta etapa somente após a etapa anterior relatar applicationDatabase.phase=Running.

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

Verifique a migração.

Confirme que o recurso do MongoDB Ops Manager possui o StatefulSet do banco de dados de aplicativo:
```
kubectl get statefulset "${APPDB_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}/{.name}{"\n"}{end}'
```
O comando retorna MongoDBOpsManager/${PRIMARY_OM_NAME}.
Confirme se o recurso do MongoDB Ops Manager relata seu banco de dados de aplicativo como Running e que o recurso do MongoDB não existe mais:
```
kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{.status.applicationDatabase.phase}{"\n"}'
kubectl get mdb --context "${K8S_CTX}" -n "${MDB_NS}"
```
Confirme que os pods do MongoDB Ops Manager não foram reiniciados verificando sua idade e contagens de reinicialização:
```
kubectl get pods --context "${K8S_CTX}" -n "${MDB_NS}"
```

Retornar um banco de dados de aplicativos de vários clusters

Se o recurso principal do Ops Manager fizer referência a um aplicativo de banco de dados MongoDBMultiCluster externo, você poderá retorná-lo a um aplicativo de banco de dados de vários clusters gerenciado internamente. O Operador Kubernetes solicita ao recurso MongoDBMultiCluster para liberar o Banco de Dados do Aplicativo StatefulSet em cada cluster de membros. O recurso do Ops Manager então readota cada StatefulSet como um aplicativo de banco de dados interno. Os pods do Ops Manager não são reiniciados porque a string de conexão não muda.

O procedimento corresponde ao procedimento de cluster único nesta página, com as seguintes diferenças:

Defina as seguintes variáveis de ambiente adicionais para os clusters de membros e a configuração do TLS do aplicativo de banco de dados. Use os mesmos valores que o banco de dados do aplicativo externo usa:
```
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"
```
O spec.applicationDatabase restaurado deve definir topology como MultiCluster e deve usar o mesmo layout de membro e a mesma configuração de TLS que o banco de dados de aplicativos externo, para que o recurso do Ops Manager possa readotar os 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}]}}}"
```
O recurso MongoDBMultiCluster informa a fase Pending enquanto o recurso Ops Manager recupera os StatefulSets. Exclua o recurso MongoDBMultiCluster somente após status.applicationDatabase.phase reportar Running.
Para verificar a migração, inspecione o StatefulSet do aplicativo de banco de dados em cada cluster de membros, denominado <primary-om-name>-db-<cluster-index>. Após a transferência, o StatefulSet sobrevive com ownerReferences vazio e o recurso Ops Manager o gerencia como um aplicativo de banco de dados interno.

Problemas Comuns de Migração

O recurso MongoDB não libera o StatefulSet

Se o recurso do MongoDB permanecer na fase Running e ainda possuir o StatefulSet, o recurso do MongoDB Ops Manager não solicitou a liberação. Confirme se o seu conjunto de patches spec.externalApplicationDatabaseRef para null e adicionou spec.applicationDatabase.

A versão do banco de dados de aplicativo não corresponde

Defina spec.applicationDatabase.version para a versão que o banco de dados de aplicativo já executa para que o StatefulSet recuperado mantenha os mesmos binários.

Você excluiu o recurso do MongoDB cedo demais

Se você excluir o recurso MongoDB enquanto ele ainda possui o StatefulSet, o Kubernetes coleta o lixo do StatefulSet e os segredos que ele compartilha com o recurso MongoDB Ops Manager. Para recuperar, recrie o banco de dados de aplicativo a partir das Reivindicações de Volume Persistente retidas. Esse caminho causa tempo de inatividade e rotaciona as credenciais do banco de dados de aplicativo. Para saber mais, consulte Recuperação de desastres para o MongoDB Ops Manager e Recursos do AppDB.

Próximos passos

Para usar um banco de dados de aplicativo externo novamente, consulte Migrar um banco de dados de aplicativo para uma implantação externa.

Voltar

Migrar para um banco de dados de aplicativo externo

atualização