Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.

Migrar um banco de dados de aplicativo para uma implantação externa

Você pode converter um recurso do MongoDB Ops Manager que usa um banco de dados de aplicativo gerenciado internamente para um que usa um banco de dados de aplicativo externo: um recurso personalizado do MongoDB com spec.role definido como AppDB. Isso permite que o Ops Manager faça backup e restaure o banco de dados de aplicativo. Para aprender mais, consulte Fazer backup do banco de dados de aplicativo do MongoDB Ops Manager.

A migração redireciona a propriedade do banco de dados de aplicativo StatefulSet existente e seus Volumes persistentes do recurso Ops Manager para o recurso MongoDB . O Operador Kubernetes não move nem recria seus dados e não reinicia os pods do Ops Manager.

Como funciona a migração

O recurso do MongoDB Ops Manager começa com um banco de dados de aplicativo gerenciado internamente, e o operador do Kubernetes possui um StatefulSet chamado <primary-om-name>-db. A migração prossegue da seguinte forma:

  1. Você cria um recurso do MongoDB com spec.role definido como AppDB e o mesmo nome do StatefulSet, em um projeto que uma instância do MongoDB Ops Manager de gerenciamento gerencia. O recurso MongoDB ainda não pode assumir a propriedade do StatefulSet, portanto, ele permanece na fase Pending com uma mensagem de que não pode assumir a propriedade do StatefulSet do banco de dados de aplicativo.

  2. Você adiciona spec.externalApplicationDatabaseRef ao recurso do MongoDB Ops Manager. O operador Kubernetes desanexa o StatefulSet removendo a referência do proprietário do recurso do MongoDB Ops Manager e marcando o StatefulSet como pronto para migração. O recurso do MongoDB então assume a propriedade dele.

Como o Kubernetes operador calcula a mesma string de conexão de antes, que usa os mesmos nomes de host, os pods do MongoDB Ops Manager não são reiniciados.

Pré-requisitos

Antes de começar, conclua as seguintes tarefas:

Considerações

Revisar as seguintes considerações antes de migrar:

  • A versão do banco de dados de aplicativo que você define no recurso MongoDB deve corresponder à versão que o banco de dados de aplicativo gerenciado internamente executa, e deve ser uma versão do MongoDB que a instância do MongoDB Ops Manager de gerenciamento oferece.

  • O Kubernetes operador não oferece suporte a spec.applicationDatabase.passwordSecretKeyRef durante a migração. O operador Kubernetes gera uma nova senha e gira qualquer senha que você forneceu.

  • O banco de dados de aplicativo pode ficar indisponível por um a dois minutos se a configuração do recurso MongoDB diferir da configuração do banco de dados de aplicativo gerenciado internamente, como um modelo de pod diferente ou um conjunto diferente de contêineres. Se as duas configurações forem semanticamente idênticas, o banco de dados de aplicativo permanecerá disponível.

  • Para migrar um aplicativo de banco de dados de vários clusters, o aplicativo de banco de dados gerenciado internamente deve definir spec.applicationDatabase.topology como MultiCluster, e o aplicativo de banco de dados externo deve ser um recurso MongoDBMultiCluster. O operador Kubernetes rejeita a migração se a topologia do aplicativo de banco de dados atual não corresponder ao tipo do aplicativo de banco de dados externo. Para saber mais, consulte Migrar um banco de dados de aplicativos de vários clusters.

Procedimento

1

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

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"
2

Confirme o estado inicial.

  1. Confirme que o recurso primário do MongoDB Ops Manager e seu banco de dados de aplicativo gerenciado internamente estão na fase Running:

    kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{.status.opsManager.phase} / appdb={.status.applicationDatabase.phase}{"\n"}'

  2. 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}.

3

Crie o ConfigMap do projeto para o banco de dados de aplicativo externo.

O valor orgId é obrigatório. Se você defini-lo como uma string vazia, o Kubernetes operador criará uma organização com o mesmo nome que seu projeto.

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=""
4

Crie o recurso do MongoDB para o banco de dados de aplicativo externo.

Dê ao recurso o mesmo nome do StatefulSet do banco de dados de aplicativo 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
5

Confirme que o recurso MongoDB aguarda a propriedade.

Até que o recurso do MongoDB Ops Manager libere o StatefulSet, o recurso do MongoDB permanece na fase Pending. Isso é esperado e não é um erro.

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"}'

A mensagem de status informa que o recurso não pode assumir a propriedade do StatefulSet do banco de dados de aplicativo.

6

Adicione a referência do banco de dados de aplicativo externo ao recurso do 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\"}}}"

Você pode remover spec.applicationDatabase no mesmo patch. Deixá-lo no lugar não tem efeito: depois de definir spec.externalApplicationDatabaseRef, o operador do Kubernetes para de gerenciar um banco de dados de aplicativo interno para este recurso.

7

Aguarde a migração terminar.

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
8

Verifique a migração.

  1. 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}.

  2. Confirme se o recurso do MongoDB Ops Manager relata seu banco de dados de aplicativo como Disabled, o que significa que o operador do Kubernetes não gerencia mais um banco de dados de aplicativo interno para ele:

    kubectl get om "${PRIMARY_OM_NAME}" --context "${K8S_CTX}" -n "${MDB_NS}" \  -o jsonpath='{.status.applicationDatabase.phase}{"\n"}'

  3. 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}"

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

Se o recurso principal do Ops Manager usar um banco de dados de aplicativos de vários clusters gerenciado internamente, você poderá migrá-lo para um recurso externo do MongoDBMultiCluster. O Operador Kubernetes desvincula o Banco de Dados de Aplicativo StatefulSet em cada cluster de membros, e o recurso MongoDBMultiCluster adota cada um deles. 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:

  • O aplicativo de banco de dados gerenciado internamente deve definir spec.applicationDatabase.topology como MultiCluster.

  • O banco de dados de aplicativo externo deve ser um recurso MongoDBMultiCluster com spec.role definido como AppDB, com o mesmo nome, layout de membro e configuração TLS que o banco de dados de aplicativos gerenciado internamente. Um banco de dados de aplicativos externo de vários clusters requer criptografia TLS e rede entre clusters entre os clusters de membros, com ou sem uma interface de serviço. Para saber mais, consulte Implantar um banco de dados de aplicativos externos multicluster.

  • Defina kind como MongoDBMultiCluster ao adicionar spec.externalApplicationDatabaseRef:

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

  • O Operador Kubernetes realiza a transferência de propriedade em cada cluster de membros. 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>:

    kubectl get statefulset "${APPDB_NAME}-0" --context "${K8S_CTX_MEMBER}" -n "${MDB_NS}" \  -o jsonpath='{.metadata.labels.mongodbmulticluster}{"\n"}'

    O comando retorna <namespace>-<appdb-name> e a anotação mongodb.com/appdb-migration-ready é limpa. Para saber mais sobre o rastreamento de propriedade em sistemas de vários clusters, consulte Anotações de migração.

Problemas Comuns de Migração

O recurso MongoDB relata um erro de versão

Se o recurso do MongoDB relatar Failed com uma mensagem de que a versão do MongoDB não está disponível, defina spec.version para uma versão que a instância do MongoDB Ops Manager de gerenciamento oferece e mantenha a versão do MongoDB Ops Manager e a versão do banco de dados de aplicativo na mesma versão principal.

O recurso MongoDB permanece pendente após o patch

O operador Kubernetes deve desanexar o StatefulSet antes que o recurso MongoDB possa assumir a propriedade dele. Confirme se você aplicou spec.externalApplicationDatabaseRef ao recurso primário do MongoDB Ops Manager, e que o valor de spec.externalApplicationDatabaseRef.name é exatamente <primary-om-name>-db.

O recurso MongoDB relata um erro de projeto

Se o recurso MongoDB permanecer na fase Pending com um erro de projeto ou registro, a API pública de gerenciamento do MongoDB Ops Manager API pode não ter estado pronta quando você criou o recurso. Confirme se o recurso de gerenciamento do MongoDB Ops Manager está na fase Running e que sua API responde às solicitações, então reconcilie o recurso novamente.

Os pods do Ops Manager reiniciam durante a migração

Se os pods do MongoDB Ops Manager forem reiniciados, a string de conexão calculada será alterada. Para um conjunto de réplicas que usa a porta padrão, a string de conexão é idêntica antes e depois da migração. O Kubernetes operador não oferece suporte a portas não padrão para essa migração.

Próximos passos

Voltar
Implantar com um banco de dados de aplicativo externo
Próximo
Retornar para um banco de dados de aplicativo interno
Avalie esta página

Nesta página