mongosync
Comportamento
Nesta página
- Isenção de responsabilidade do verificador incorporado
- Configurações
- Independência do Cluster
- Arquivo de configuração
- Tipos de cluster e coleção
- Clusters fragmentados
- Vários clusters
- Capped collections
- Leituras e escritas
- Bloqueio de gravação
- Preocupação de leitura e gravação
- readPreference
- Tratamento de índice legado
- Considerações para sincronização contínua
- Alterações temporárias nas características da coleção
- Construção contínua de índices
- Clusters de Destino
- Consistência
- Criação de perfil
- Visualizações
- Coleções do sistema
- UUIDs
- Classificação
- Desempenho
- Resiliência
- Operações em Linguagem de definição de dados (Data Definition Language ou DDL em inglês)
- Saiba mais
O binário mongosync
é o processo primário usado no Cluster-to-Cluster Sync. mongosync
migra dados de um cluster para outro e pode manter os clusters em sincronização contínua.
Para uma visão geral do processo do mongosync
, consulte Sobre o mongosync
.
Para começar a utilizar o mongosync
, consulte o Guia de Início Rápido.
Para obter informações mais detalhadas, consulte a página Instalação ou Conexão mongosync
que melhor se adequa à sua situação.
Isenção de responsabilidade do verificador incorporado
A partir de 1.9, mongosync
inclui um verificador incorporado para realizar uma série de verificações em todas as collections suportadas no cluster de destino para confirmar que foi bem-sucedido na transferência de documentos do cluster de origem para o de destino.
Quando você inicia o processo do mongosync
, ele fornece um termo de responsabilidade avisando o usuário de que o verificador está ativado por padrão.
Embedded verification is enabled by default for replica set to replica set migrations. Verification checks for data consistency between the source and destination clusters. Verification will cause mongosync to fail if any inconsistencies are detected, but it does not check for all possible data inconsistencies. Please see the documentation at https://www.mongodb.com/pt-br/docs/cluster-to-cluster-sync/current/reference/verification/embedded for more details. Verification requires approximately 0.5 GB of memory per 1 million documents on the source cluster and will fail if insufficient memory is available. Accepting this disclaimer indicates that you understand the limitations and memory requirements for this tool. To skip this disclaimer prompt, use –-acceptDisclaimer. To disable the embedded verifier, specify 'verification: false' when starting mongosync. Please see https://www.mongodb.com/pt-br/docs/cluster-to-cluster-sync/current/reference/verification/ for alternative verification methods. Do you want to continue? (y/n):
Se você já leu e aceitou o aviso de exclusão, você pode iniciar mongosync
com a opção para ignorar esta --acceptDisclaimer
notificação.
Configurações
Independência do Cluster
mongosync
sincroniza dados de coleta entre um cluster de cluster de origem de destino. mongosync
não sincronizausuários ou funções . Como resultado, você pode criar usuários com permissões de acesso diferentes em cada cluster.
Arquivo de configuração
As opções para mongosync
podem ser definidas em um arquivo de configuração YAML. Use a opção --config
. Por exemplo:
$ mongosync --config /etc/mongosync.conf
Para obter informações sobre as configurações disponíveis, consulte Configuração.
Tipos de cluster e coleção
Clusters fragmentados
Cluster-to-Cluster Sync oferece suporte à replicação entre clusters fragmentados. mongosync
replica shards individuais em paralelo do cluster de cluster de origem para o cluster de destino. No entanto, o mongosync
não preserva a configuração de fragmentação do cluster de origem.
Importante
Quando o cluster de origem ou destino for um cluster fragmentado, você deve parar o balanceador em ambos os clusters e não executar os moveChunk
comandos ou durante a migração. Para parar o balanceador,moveRange
balancerStop
execute o comando e aguarde a conclusão do comando.
Parte pré-divisão
Quando o mongosync
sincroniza com um cluster de destino fragmentado, ele pré-divide os blocos para coleções fragmentadas no cluster de destino. Para cada coleção fragmentada, o mongosync
cria o dobro de blocos enquanto há fragmentos no cluster de destino.
Distribuição de chunks
mongosync
não preserva a distribuição de chunks da origem para o destino, mesmo com várias instâncias mongosync
. Não é possível reproduzir uma pré-divisão específica de blocos de um cluster de cluster de origem de destino.
A única configuração de fragmentação que o mongosync
preserva do cluster de cluster de origem para o cluster de destino é a chave de fragmentação. Quando a migração for concluída, você poderá ativar o balanceador do cluster de destino que distribui documentos independentemente da distribuição do cluster de origem.
Primary shards
Quando você sincroniza com um cluster de destino fragmentado, o mongosync
atribui um fragmento primário para cada banco de dados de dados por meio de um round-robin.
Aviso
A execução de no cluster de origem ou destino durante a migração pode resultar em um erro fatal ou exigir que você reinicie a migração desde o início.movePrimary
Para mais informações, consulte Clusters fragmentados.
Vários clusters
Para sincronizar um cluster de origem com vários clusters de destino, use uma instância mongosync
para cada cluster de destino. Para obter mais informações, consulte Limitações de clusters múltiplos.
Capped collections
A partir de 1.3.0, O Cluster-to-Cluster Sync oferece suporte a coleções limitadas com algumas limitações.
convertToCapped
não é compatível. Se você executarconvertToCapped
,mongosync
será encerrado com um erro.cloneCollectionAsCapped
não é suportado.
As coleções limitadas no cluster de origem funcionam normalmente durante a sincronização.
As coleções limitadas no cluster de destino apresentam alterações temporárias durante a sincronização:
Não há nenhum número máximo de documentos.
O tamanho máximo da coleção é 1PB.
mongosync
restaura os valores originais para o número máximo de documentos e o tamanho máximo do documento durante o commit.
Leituras e escritas
Bloqueio de gravação
mongosync
não habilita o bloqueio de gravação por padrão. Se você habilitar o bloqueio de gravação, mongosync
bloqueará as gravações:
No cluster de destino durante a sincronização.
No cluster de origem quando
commit
é recebido.
Para ativar o bloqueio de gravação, use a API inicial para definir enableUserWriteBlocking
como true
. Você não pode ativar o bloqueio de gravação após o início da sincronização.
Você deve ativar o bloqueio de gravação ao iniciar o mongosync
se quiser usar a sincronização reversa posteriormente.
Permissões de usuário
Para definir enableUserWriteBlocking
, o usuário mongosync
deve ter uma função que inclua os ActionTypes setUserWriteBlockMode
e bypassWriteBlockingMode
.
Observação
Ao usar enableUserWriteBlocking
, as gravações são bloqueadas apenas para os usuários que não possuam o ActionType bypassWriteBlockingMode
. Os usuários que possuam esse ActionType poderão realizar gravações.
Leituras permitidas
As operações de leitura no cluster de origem são sempre permitidas.
Quando os relatórios de endpoint /progress canWrite
são true
, os dados nos clusters de origem e destino são consistentes.
Gravações permitidas
Para ver em que estado mongosync
está, chame o endpoint da API /progress. A saída /progress
inclui um valor booleano, canWrite
.
Quando
canWrite
étrue
, é seguro escrever no cluster de destino.Quando
canWrite
forfalse
, não escreva no cluster de destino.
Você pode gravar com segurança no cluster de origem enquanto mongosync
estiver sincronizando. Não grave no cluster de destino a menos que canWrite
seja true
.
Preocupação de leitura e gravação
Por padrão, mongosync
define o nível de preocupação de leitura como "majority"
para leituras no cluster de origem. Para gravações no cluster de destino, mongosync
define o nível de preocupação de gravação como "majority"
com j: true.
Para obter mais informações sobre a configuração e o comportamento da preocupação de leitura e gravação, consulte preocupação de leitura e preocupação de gravação.
readPreference
mongosync
requer a preferência de leitura primary
ao se conectar aos clusters de origem e destino. Para obter mais informações, consulte Opções de preferência de leitura.
Tratamento de índice legado
mongosync
reescreve valores de índice legado , como 0
ou uma string vazia, para 1
no destino. mongosync
também remove todas as opções de índice inválidas no destino.
Considerações para sincronização contínua
Para qualquer caso de uso de sincronização contínua com mongosync
, certifique-se de que mongosync
confirme antes de cortar da origem para o destino.
Se o cluster de origem for desligado antes que mongosync
possa confirmar, como em um cenário de desastre, o cluster de destino poderá não ter um snapshot consistente dos dados de origem. Para saber mais, consulte Consistência.
Observação
Após a confirmação, você não pode retomar a sincronização contínua entre dois clusters, pois mongosync
só pode sincronizar em clusters de destino vazios. Se você precisar usar os mesmos dois clusters após o cutover, poderá chamar o endpoint reverse
para manter os clusters sincronizados. Caso contrário, inicie uma nova operação de sincronização contínua usando um novo cluster de destino vazio.
Alterações temporárias nas características da coleção
mongosync
altera temporariamente as seguintes características da coleção durante a sincronização. Os valores originais são restaurados durante o processo de confirmação.
Mudar | Descrição |
---|---|
Unique Indexes | Os índices únicos no cluster de origem são sincronizados como índices não exclusivos no cluster de destino. |
TTL Indexes | A sincronização define |
Hidden Indexes | A sincronização replica índices ocultos como não ocultos. |
Bloqueio de gravação | Se você habilitar o bloqueio de gravação,
Para saber mais,consulte Bloqueio de escrita. |
Capped collections | A sincronização define capped collections para o tamanho máximo permitido. |
Índices fictícios | Em alguns casos, a sincronização pode criar índices fictícios no destino para dar suporte a gravações em coleções fragmentadas ou coletadas. |
Construção contínua de índices
mongosync
não oferece suporte a compilações de índice contínuo durante a migração. Para evitar a criação de índices de forma contínua durante a migração, use um dos métodos a seguir para garantir que seus índices de destino correspondam aos índices de origem:
Construa o índice na origem antes da migração.
Construa o índice na origem durante a migração com uma construção de índice padrão.
Construa o índice no destino após a migração.
Clusters de Destino
Consistência
mongosync
oferece suporte à consistência eventual no cluster de destino. A consistência de leitura não é garantida no cluster de destino até a confirmação. Antes de confirmar, os clusters de origem e destino podem ser diferentes em um determinado ponto . Para saber mais, consulte Considerações sobre sincronização contínua.
Enquanto mongosync
estiver sincronizando, mongosync
pode reordenar ou combinar gravações à medida que as transmite da origem para o destino. Para um determinado documento, o número total de gravações pode ser diferente entre a origem e o destino.
As transações podem não aparecer atomicamente no cluster de destino. As retryable Writes podem não ser repetíveis no cluster de destino.
Criação de perfil
Se o perfil estiver habilitado em um banco de dados de origem, o MongoDB criará uma coleção especial denominada <db>.system.profile
. Depois que a sincronização for concluída, o Cluster-to-Cluster Sync não eliminará a coleção <db>.system.profile
do destino, mesmo que o banco de dados de origem seja eliminado posteriormente. A coleção <db>.system.profile
não alterará a precisão dos dados do usuário no destino.
Visualizações
Se um banco de dados com visualizações for descartado na origem, o destino poderá mostrar uma coleção system.views
vazia nesse banco de dados. A coleção vazia system.views
não alterará a precisão dos dados do usuário no destino.
Coleções do sistema
O Cluster-to-Cluster Sync não replica coleções de sistemas para o cluster de destino.
Se você emitir um comando dropDatabase
no cluster de origem, essa alteração não será diretamente aplicada no cluster de destino. Em vez disso, o Cluster-to-Cluster Sync descarta coleções e visualizações de usuários no banco de dados no cluster de destino, mas não descarta as coleções do sistema nesse banco de dados.
Por exemplo, no cluster de destino:
A operação de descarte não afeta uma coleção do
system.js
criada pelo usuário.Se você habilitar o perfil, a coleção
system.profile
permanecerá.Se você criar exibições no cluster de origem e depois descartar o banco de dados, a replicação do descarte removerá as exibições, mas descartará uma coleção
system.views
vazia.
Nesses casos, a replicação do dropDatabase
remove todas as coleções criadas pelo usuário do banco de dados, mas deixa suas coleções do sistema no cluster de destino.
UUIDs
mongosync
cria collections com novos UUIDs no cluster de destino. Não há relacionamento entre UUIDs no cluster de origem e no cluster de destino. Se os aplicativos contiverem UUIDs codificados (o que o MongoDB não recomenda), pode ser necessário atualizar esses aplicativos antes que funcionem corretamente com o cluster migrado.
Classificação
mongosync
insere documentos no cluster de destino em uma ordem indefinida que não preserva a ordem de classificação natural do cluster de origem. Se os aplicativos dependerem da ordem dos documentos, mas não tiverem um método de classificação definido, talvez seja necessário atualizar esses aplicativos para especificar a ordem de classificação esperada antes que os aplicativos funcionem corretamente com o cluster migrado.
Desempenho
Resiliência
mongosync
é resiliente e consegue lidar com erros não fatais. Os logs que contêm a palavra "erro" ou "falha" não indicam que mongosync
está falhando ou corrompendo os dados. Por exemplo, se ocorrer um erro de rede, o log mongosync
poderá conter a palavra "erro", mas
mongosync
ainda poderá concluir a sincronização. Caso uma sincronização não seja concluída, mongosync
grava uma entrada de log fatal.
Operações em Linguagem de definição de dados (Data Definition Language ou DDL em inglês)
O uso de operações DDL (operações que atuam em coleções ou bancos de dados, como db.createCollection()
e db.dropDatabase()
) durante a sincronização aumenta o risco de falha na migração e pode afetar negativamente o desempenho do mongosync
. Para obter melhor desempenho, evite executar operações DDL no cluster de origem enquanto a sincronização estiver em andamento.
Para obter mais informações sobre operações DDL, consulte Operações e transações DDL pendentes.