Para fazer a transição de um servidor de configuração incorporado para um servidor de configuração dedicado, você deve garantir que os dados do shard de configuração sejam migrados para os shards restantes no cluster. Este procedimento descreve como migrar dados com segurança e concluir a transição.
Sobre esta tarefa
Criar, fragmentar ou mover coleções durante a execução desse procedimento pode causar interrupções e levar a resultados inesperados.
Não use esse procedimento para migrar um cluster inteiro para um novo hardware. Para migrar, consulte Migrar um cluster fragmentado autogerenciado para hardware diferente.
Quando você remove um fragmento em um cluster com uma distribuição desigual de fragmentos, o balanceador primeiro remove os fragmentos do fragmento de drenagem e, em seguida, equilibra a distribuição desigual de fragmentos restante.
A remoção de um shard pode fazer com que um cursor de fluxo de alteração aberto feche e o cursor de fluxo de alteração fechado pode não ser totalmente retomável.
Você pode reiniciar um cluster com segurança durante um processo de transição. Se você reiniciar um cluster durante um processo contínuo de drenagem , a drenagem continuará automaticamente após a reinicialização dos componentes do cluster. O MongoDB registra o status de transição na
config.shardscoleção.
Antes de começar
Este procedimento utiliza o método para mover as coleções para fora do fragmento de configuração. Antes de iniciar este procedimento, revise
sh.moveCollection()asmoveCollectionconsiderações e requisitos do para entender o comportamento do comando.Para fazer a transição para um servidor de configuração dedicado, primeiro conecte-se a uma das instâncias
mongosdo cluster usandomongosh.
Passos
Certifique-se de que o balanceador esteja habilitado.
Para migrar dados do shard de configuração, o processo do balanceador deve estar habilitado. Para verificar o estado do balanceador , use o sh.getBalancerState() método:
sh.getBalancerState()
Se a operação retornar true, o balanceador estará habilitado.
Se a operação retornar false, consulte Habilitar o Balancer.
Verifique se o servidor de configuração está agindo como um shard.
Execute para confirmar que o fragmento de configuração aparece na lista de listShards fragmentos:
db.adminCommand( { listShards: 1 } )
Na saída, o campo shards._id contém os nomes dos fragmentos. O fragmento de configuração normalmente tem um _id de "config":
{ shards: [ { _id: 'config', ... }, ... ], ok: 1 ... }
Comece a migrar dados fragmentados para fora do shard de configuração.
A partir do admin banco de dados do, execute o transitionToDedicatedConfigServer comando:
use admin db.adminCommand( { transitionToDedicatedConfigServer: 1 } )
O fragmento de configuração entra no estado de drenagem e o balanceador começa a migrar blocos do fragmento de configuração para os fragmentos restantes no cluster. Dependendo da capacidade da rede e da quantidade de dados, essa operação pode levar de minutos a dias para ser concluída.
Mova coleções não fragmentadas para fora do fragmento de configuração.
Use o $listClusterCatalog estágio de agregação para identificar collections não fragmentadas que ainda residem no shard de configuração:
use admin db.aggregate([ { $listClusterCatalog: { shards: true } }, { $match: { sharded: false, shards: "config", type: { $nin: ["timeseries", "view"] }, ns: { $not: { $regex: "^enxcol_\\..*(\\.esc|\\.ecc|\\.ecoc|\\.ecoc\\.compact)$" } }, $or: [ { ns: { $not: { $regex: "\\.system\\." } } }, { ns: { $regex: "\\.system\\.buckets\\." } } ], db: { $nin: ["config", "admin"] } } }, { $project: { _id: 0, ns: 1 } } ])
Para cada namespace na saída, use para mover a collection não fragmentada do shard de configuração para um shard de sh.moveCollection() destinatário:
sh.moveCollection( "<database>.<collection>", "<ID of recipient shard>" )
Repita esta etapa até que nenhuma coleção não fragmentada permaneça no fragmento de configuração.
Altere o fragmento primário para bancos de dados que usam o shard de configuração.
A partir do admin banco de dados do,db.printShardingStatus() execute:
use admin db.printShardingStatus()
Na seção databases da saída, verifique o campo primary de cada banco de dados. Para quaisquer bancos de dados de aplicação (bancos de dados diferentes de config e admin) cujo principal seja o fragmento de configuração, altere o fragmento primário para outro shard.
Para alterar o fragmento primário de um banco de dados,movePrimary execute:
db.adminCommand({ movePrimary: "<dbName>", to: "<recipientShard>" })
As collections que não foram movidas na etapa anterior não estarão disponíveis enquanto movePrimary o estiver em execução.
Verifique o status da transição.
Para verificar o progresso da transição, execute novamente a partir transitionToDedicatedConfigServer do admin banco de dados :
use admin db.adminCommand( { transitionToDedicatedConfigServer: 1 } )
Continue verificando o status até que a transição seja concluída com êxito e a saída seja semelhante ao exemplo a seguir:
{ state: 'completed', msg: 'removeshard completed successfully', shard: 'config', ok: 1 }
Comprometa a transição para um servidor de configuração dedicado .
Depois que o fragmento de configuração relatar um state de 'completed', confirme a transição de um servidor de configuração incorporado para um servidor de configuração dedicado :
use admin db.adminCommand( { commitTransitionToDedicatedConfigServer: 1 } )
Um commit bem-sucedido retorna a seguinte saída:
{ ok: 1, '$clusterTime': { ... }, operationTime: ... }
Quando bem-sucedido, o MongoDB remove o fragmento config dos metadados do cluster e finaliza a transição para um servidor de configuração dedicado. Se o fragmento de configuração não for completamente drenado, o comando falhará e você deverá continuar verificando o status de transição para { state: 'completed' } antes de tentar novamente.
Após a transição ser confirmada, não inclui mais o fragmento de configuração na lista de fragmentos. O cluster agora usa um servidor de configuração dedicado e o servidor de configuração não armazena mais dados do aplicação como umlistShards shard.