A partir do Kubernetes Operator 1.15, as implantações autônomo são preteridas e perdem o suporte na próxima versão principal. Migre suas implementações autônomo para conjuntos de réplicas de um membro. Um conjunto de réplicas de um membro fornece a mesma topologia de nó único que uma instância autônomo e permite adicionar membros posteriormente sem migrar novamente.
Sobre esta tarefa
Esta migração não é uma atualização no local. Você implementa um novo conjunto de réplicas de um membro, copia seus dados com mongodump e mongorestore e, em seguida, direciona seus aplicativos para o conjunto de réplicas.
Um projeto do Ops Manager mantém um sistema, portanto, o conjunto de réplicas exige um novo projeto. Você não pode reutilizar o projeto que o sistema autônomo usa.
mongodumpemongorestorenão copiam usuários de banco de dados . Após a restauração, recrie seus usuários como recursosMongoDBUser.A implantação autônomo permanece intacta até você excluí-la. Se a migração falhar, você poderá direcionar seus aplicativos de volta para o sistema autônomo .
Antes de começar
Implemente um recurso autônomo que o Operador Kubernetes gerencia. Para saber mais, consulte Implementar uma instância standalone do MongoDB .
Configure o
kubectlpara acessar o cluster Kubernetes que hospeda o sistema autônomo .Observe o valor de
spec.versionno recurso autônomo . O conjunto de réplicas de um membro deve executar a mesma versão MongoDB .
Procedimento
Crie um ConfigMap para um novo projeto.
Um projeto do Ops Manager contém um sistema, portanto, você não pode reutilizar o projeto que o sistema autônomo usa. Copie o ConfigMap referenciado pelo sistema autônomo , mantenha os valores baseUrl e orgId e defina um novo e exclusivo projectName. Aplique o ConfigMap ao mesmo namespace do Kubernetes que o sistema autônomo .
Para saber mais,consulte Criar um projeto por sistema MongoDB usando um ConfigMap.
Implemente um conjunto de réplicas de um membro.
Crie um recurso MongoDB com spec.type definido como ReplicaSet e spec.members definido como 1. Configure o spec.version para a mesma versão MongoDB que a implantação autônomo executa e faça referência ao ConfigMap que você criou na etapa anterior. Você pode reutilizar o segredo de credenciais que o sistema autônomo usa. Copie quaisquer configurações spec adicionais do recurso autônomo .
apiVersion: mongodb.com/v1kind: MongoDBmetadata: name: <my-replica-set> namespace: <my-namespace>spec: members: 1 # Must match the MongoDB version of the standalone deployment version: "<mongodb-version>" opsManager: configMapRef: # Must match metadata.name in the new project ConfigMap file name: <configMap.metadata.name> # Can match the credentials Secret that the standalone deployment uses credentials: <mycredentials> type: ReplicaSet persistent: trueAplique o recurso:
kubectl apply -f <replica-set-yaml> --namespace <my-namespace>Para verificar o status do seu recurso MongoDB, utilize o seguinte comando:
kubectl get mdb <resource-name> -o yaml -wCom o sinalizador -w (inspeção) definido, quando a configuração muda, o resultado é atualizado imediatamente até que a fase de status atinja o estado Running . Para saber mais sobre os status de distribuição de recursos, consulte Solucionar problemas do operador Kubernetes.
Implemente um pod de ferramentas.
As imagens de container que executam os pods de banco de dados não incluem as Database Tools MongoDB . Para executar mongodump e mongorestore, implemente um pod de ferramentas dedicado com base na imagem mongodb-enterprise-server. Defina a marcação de imagem para a mesma versão do MongoDB que a implementação autônomo executa.
apiVersion: v1kind: Podmetadata: name: mongodb-tools namespace: <my-namespace>spec: containers: - name: mongodb-tools # Use the standalone's MongoDB version without the -ent # suffix, for example 8.0.4 image: quay.io/mongodb/mongodb-enterprise-server:<mongodb-version>-ubi9 command: ["sleep", "infinity"]Aplique o pod:
kubectl apply -f <tools-pod-yaml> --namespace <my-namespace>Registre as contagens de documento e um hash de banco de dados .
Registre a contagem de documento de cada collection e o dbHash de cada banco de dados no sistema autônomo , exceto os bancos de dados admin, config e local. A restauração exclui os bancos de dados admin e config, e a replicação grava no banco de dadoslocal, portanto, esses valores nunca correspondem. Após a restauração, repita essas medições em relação ao conjunto de réplicas para verificar a migração.
Descarte os dados autônomo .
Execute mongodump do pod de ferramentas no serviço do sistema autônomo :
kubectl exec mongodb-tools --namespace <my-namespace> -- \ mongodump \ --host "<my-standalone>-svc.<my-namespace>.svc.cluster.local:27017" \ --out /tmp/dumpSe a implementação autônomo exigir autenticação, conecte-se como um usuário que tenha as funções backup e readAnyDatabase. Se a implantação exigir TLS, adicione as opções de conexão mongodump correspondentes. Para saber mais, consulte mongodump.
Restaure os dados no conjunto de réplicas.
Execute mongorestore do pod de ferramentas no serviço do conjunto de réplicas:
kubectl exec mongodb-tools --namespace <my-namespace> -- \ mongorestore \ --host "<my-replica-set>-svc.<my-namespace>.svc.cluster.local:27017" \ --nsExclude="admin.*" \ --nsExclude="config.*" \ /tmp/dumpAs opções --nsExclude excluem os bancos de dados admin e config da restauração. Uma saída mongodump completa inclui admin.system.users e admin.system.version. Restaurá-los gravaria os usuários do banco de dados e o esquema de autenticação no conjunto de réplicas fora da configuração de automação, de modo que a lista de usuários do projeto no Ops Manager não corresponderia mais ao banco de dados.
Se o conjunto de réplicas exigir autenticação, ele ainda não tem usuários porque você recria os usuários do banco de dados em uma etapa posterior. Crie um recurso MongoDBUser temporário no novo projeto com as funções restore, readWriteAnyDatabase e dbAdminAnyDatabase e conecte-se como esse usuário. Para saber mais sobre como criar usuários, consulte Gerenciar usuários do banco de dados.
Se o conjunto de réplicas exigir TLS, adicione as opções de conexão mongorestore correspondentes. Para saber mais, consulte mongorestore.
Recrie os usuários do banco de dados .
O despejo não carrega usuários de banco de dados . Recrie cada usuário como um recurso MongoDBUser no novo projeto. Se você criou um usuário temporário para a restauração, exclua-o depois de recriar seus usuários. Para saber mais, consulte Gerenciar usuários do banco de dados e Especificação de recursos do usuário do MongoDB .
Exclua o sistema autônomo .
Após verificar a migração, exclua o recurso autônomo MongoDB. O Operador Kubernetes não exclui a declaração de volume persistente usada pelo sistema autônomo , portanto, exclua a declaração manualmente. Para saber mais, consulte Remover um recurso MongoDB.
Rollback
A implantação autônomo permanece intacta até você excluí-la. Para reverter a migração, direcione seus aplicativos de volta para o sistema autônomo . A implantação autônomo não contém gravações que o conjunto de réplicas tenha recebido após a transição.