Menu Docs
Página inicial do Docs
/
Sincronização de Cluster-to-Cluster do MongoDB
/ /

start

Nesta página

  • Descrição
  • Requisitos
  • Solicitar
  • Resposta
  • Exemplos
  • Comportamento

Inicia a sincronização entre um cluster de origem e destino.

Para usar o endpoint start , mongosync deve estar no estado IDLE .

O usuário especificado na string de conexão mongosync deve ter as permissões necessárias nos clusters de origem e destino. Consulte Permissões do usuário para garantir que o usuário tenha as permissões corretas para iniciar a sincronização.

Certifique-se de usar o usuário mongosync configurado nas connection strings para as configurações cluster0 ou cluster1 ao iniciar mongosync.

Observação

Ao configurar várias instâncias mongosync para sincronizar entre clusters fragmentados, você deve enviar comandos de ponto de conexão da API idênticos para cada instância mongosync .

Para obter mais informações, consulte Iniciar vários Mongosyncs.

POST /api/v1/start
Parâmetro
Tipo
necessidade
Descrição
source
string
Obrigatório
Nome do cluster de origem.
destination
string
Obrigatório
Nome do cluster de destino.
buildIndexes
string
Opcional

Configura compilações de índice durante a sincronização.

Opções suportadas:

  • beforeDataCopy (o padrão) faz com que mongosync crie índices no cluster de destino. Isso inclui os índices existentes e quaisquer índices criados durante a migração no cluster de origem.

  • never faz com que mongosync pule a criação de índices desnecessários durante a sincronização. Isso pode melhorar o desempenho da migração, especialmente com volumes de trabalho pesados de índice.

    Se você iniciar a sincronização com a verificação ativada e buildIndexes definido como never, a migração falhará se mongosync encontrar uma coleção TTL no cluster de origem. Isso pode acontecer depois de chamar o endpoint /start ou muito mais tarde, como quando um usuário cria um índice TTL no cluster de origem enquanto uma migração está em andamento.

    Para sincronizar coleções TTL sem construir índices no agrupamento de destino, você deve iniciar a sincronização com o verificador desabilitado.

    AVISO: não construa índices manualmente enquanto mongosync estiver executando uma migração. Aguarde até que a migração esteja totalmente confirmada.

    Para obter mais informações sobre os índices que ele cria, consulte Índices necessários.

/start retorna um erro quando buildIndexes está definido como never e reversible está definido como true.

Se você chamar /start sem especificar a opção buildIndexes , o mongosync construirá índices no agrupamento de destino.

Novidade na versão 1,3,0.

documentFilter
documento
Opcional

IMPORTANTE: esse recurso está disponível apenas na mongosync versão beta. Para saber mais, consulte o Programa beta do Cluster-to-Cluster Sync .beta

A partir do mongosync beta 1.8, você pode migrar seletivamente documentos com base em condições específicas. Para limitar ainda mais quais documentos migram para o cluster de destino, você pode combinar a filtragem de documento e a filtragem de namespace .

Para saber mais, consulte Filtragem de documentos.

Novo na versão 1.8: beta

enableUserWriteBlocking
booleano
Opcional

Se definido como true, bloqueia as gravações no cluster de destino enquanto a sincronização está em andamento. Depois que a sincronização é confirmada no cluster de destino, o cluster de origem original bloqueia as gravações e o cluster de destino aceita as gravações.

Para reverter a sincronização, o campo enableUserWriteBlocking deve ser configurado para true. Para permitir que o cluster de origem aceite gravações novamente, por exemplo , depois de executar testes de migração, execute o seguinte comando:

db.adminCommand( { setUserWriteBlockMode: 1, global: false } )

O valor padrão é false.

includeNamespaces
array
Opcional

Filtra o reconhecimento de data center ou as collection para incluir na sincronização.

Se você configurar um filtro em um cluster de origem que tenha vários reconhecimento de data center, o mongosync sincronizará somente os reconhecimento de data center especificados na definição de filtro. mongosync não sincronizará os outros reconhecimento de data center existentes.

Se você quiser modificar o filtro para adicionar um reconhecimento de data center recém-criado, será necessário reiniciar a sincronização filtrada desde o início.

Para obter mais detalhes, consulte Sincronização filtrada.

Para limitações atuais, consulte Sincronização filtrada.

Novidade na versão 1.1.

excludeNamespaces
array
Opcional

Filtra o reconhecimento de data center ou as collection a serem excluídas da sincronização.

Se você configurar um filtro em um cluster de origem que tenha vários reconhecimento de data center, o mongosync sincronizará somente os reconhecimento de data center especificados na definição de filtro. mongosync não sincronizará os outros reconhecimento de data center existentes.

Se você quiser modificar o filtro para adicionar um reconhecimento de data center recém-criado, será necessário reiniciar a sincronização filtrada desde o início.

Para obter mais detalhes, consulte Sincronização filtrada.

Para limitações atuais, consulte Sincronização filtrada.

Novidade na versão 1.6.

namespaceRemap
array
Opcional

IMPORTANTE: esse recurso está disponível apenas na mongosync versão beta. Para saber mais, consulte o Programa beta do Cluster-to-Cluster Sync .beta

Array de documentos que especificam as alterações de namespace a serem feitas durante a sincronização.

Para obter mais informações, consulte Remapeamento de namespace.

Novo na versão 1.8: beta

reversible
booleano
Opcional

Se definido para true, permite que a operação de sincronização seja revertida.

Para fazer a sincronização reversa, o campo enableUserWriteBlocking deve ser definido como true.

Esta opção não é suportada para as seguintes configurações:

  • Sincronizar de um conjunto de réplicas para um cluster fragmentado

  • Sincronizar clusters fragmentados que têm números diferentes de shards

  • Sincronização reversível quando buildIndexes está definido como never.

  • Sincronização reversível com o verificador incorporado. O verificador suporta a direção direta inicial da sincronização reversível. Quando você chama o endpoint /reverse, ele desabilita o verificador.

Para obter mais informações, consulte o endpoint inverso .

O valor padrão é false.

sharding
documento
Opcional

Configura a sincronização entre um conjunto de réplicas e um cluster fragmentado. A sincronização de um conjunto de réplicas para um cluster fragmentado requer esta opção.

Para obter mais informações, consulte Parâmetros de fragmentação.

Novidade na versão 1.1.

verification
Documento
Opcional

Configura o verificador incorporado.

Para obter mais informações, consulte Verificador incorporado.

Novidades na versão 1.9.

verification.enabled
Bool
Opcional

Habilita o verificador incorporado. O verificador executa uma série de verificações nas collections suportadas no cluster de destino para confirmar que a migração foi bem-sucedida.

Se o verificador não encontrar erros, mongosync fará a transição para o estado COMMITTED. Se encontrar erros, haverá falha na migração.

O verificador é habilitado por padrão para migrações de conjunto para conjunto de réplicas. Se a migração incluir um cluster fragmentado, o verificador será desabilitado.

AVISO: o verificador não verifica todas as collections ou dados. Para obter detalhes, consulte Verificador incorporado.

Novidades na versão 1.9.

Novidade na versão 1.1.

Para sincronizar de um conjunto de réplicas para um cluster fragmentado, defina a opção sharding para fragmentar coleções no cluster de destino.

A opção sharding tem os seguintes parâmetros:

Parâmetro
Tipo
Descrição
createSupportingIndexes
booleano

Opcional. Define se a sincronização cria um índice de suporte para a chave de shard, se não existir nenhum. O padrão é false.

Para obter mais informações e limitações,consulte Índices de suporte.

shardingEntries
matriz de documentos

Obrigatório. Define o namespace e a chave das collection para fragmentar durante a sincronização.

As coleções não incluídas nesta array são sincronizadas com coleções não fragmentadas no cluster de destino. Se definido com uma array vazia, nenhuma collection será fragmentada.

shardingEntries
.collection
string
Define a collection como shard.
shardingEntries
.database
string
Define o reconhecimento de data center da collection como shard.
shardingEntries
.shardCollection
documento
Define a chave de shard para gerar no cluster de destino.
shardingEntries
.shardCollection
.key
array

Define os campos a serem usados para a chave de shard.

Para obter mais informações, consulte Chaves de fragmento.

mongosync exibe um erro se a opção sharding não estiver definida ao sincronizar de um conjunto de réplicas para um cluster fragmentado. mongosync também apresenta um erro se a opção sharding estiver definida com qualquer outra configuração.

Campo
Tipo
Descrição
success
booleano
Quando a solicitação é bem-sucedida, esse valor é true.
error
string
Se ocorreu um erro, indica o nome do erro. Este campo é omitido da resposta quando success é true.
errorDescription
string
Descrição detalhada do erro que ocorreu. Este campo é omitido da resposta quando success é true.

O exemplo a seguir inicia uma tarefa de sincronização entre cluster0 e cluster1. O cluster de origem é cluster0 e o cluster de destino é cluster1.

Solicitação:

curl localhost:27182/api/v1/start -XPOST \
--data '
{
"source": "cluster0",
"destination": "cluster1"
} '

Resposta:

{"success":true}

O exemplo a seguir inicia uma tarefa de sincronização entre cluster0 e cluster1. O cluster de origem é cluster0 e o cluster de destino é cluster1.

Os campos reversible e enableUserWriteBlocking permitem que a sincronização seja revertida. Para reverter a direção de sincronização, consulte: reverter.

Solicitação:

curl localhost:27182/api/v1/start -XPOST \
--data '
{
"source": "cluster0",
"destination": "cluster1",
"reversible": true,
"enableUserWriteBlocking": true
} '

Resposta:

{"success":true}

O exemplo a seguir inicia uma tarefa de sincronização entre cluster0 e cluster1. O cluster de origem é cluster0 e o cluster de destino é cluster1.

cluster0 contém o reconhecimento de data center sales, marketing e engineering.

O banco de dados sales contém as coleções EMEA, APAC e AMER.

O array includeNamespaces neste exemplo define um filtro em dois dos bancos de dados: sales e marketing.

O banco de dados sales também filtra as coleções EMEA e APAC.

"includeNamespaces" : [
{
"database" : "sales",
"collections": [ "EMEA", "APAC" ]
},
{
"database" : "marketing"
}
]

Depois de chamar a API /start com este filtro em vigor, mongosync:

  • Sincroniza todas as coleções no banco de dados do marketing

  • Filtra o banco de dados engineering

  • Sincroniza as coleções EMEA e APAC a partir do banco de dados do sales

  • Filtra a coleção AMER

A opção includeNamespaces cria um filtro. Para filtrar a sincronização, consulte: Sincronização filtrada

Solicitação:

curl -X POST "http://localhost:27182/api/v1/start" --data '
{
"source": "cluster0",
"destination": "cluster1",
"includeNamespaces": [
{
"database": "sales",
"collectionsRegex": {
"pattern": "^accounts_.+$",
"options": "i"
}
}, {
"database": "marketing"
}
]
} '

Resposta:

{"success":true}

Solicitação:

curl localhost:27182/api/v1/start -XPOST \
--data '
{
"source": "cluster0",
"destination": "cluster1",
"sharding": {
"createSupportingIndexes": true,
"shardingEntries": [
{
"database": "accounts",
"collection": "us_east",
"shardCollection": {
"key": [
{ "location": 1 },
{ "region": 1 },
]
}
}
]
}
} '

Resposta:

{"success":true}

A partir de 1.9, o verificador embarcado é executado por padrão quando você inicia uma migração. Se precisar desativá-lo, defina verification.enabled como false.

Solicitação:

curl localhost:27182/api/v1/start -XPOST \
--data '
{
"source": "cluster0",
"destination": "cluster1",
"verification": {
"enabled": false
}
} '

Resposta:

{"success":true}

Você deve verificar se uma migração foi bem-sucedida antes de transferir a carga do aplicação para o cluster de destino. Se você precisar desativar o verificador por qualquer motivo, use um método alternativo para verificar a sincronização.

A partir de 1.9, mongosync fornece um verificador incorporado para determinar se a transferência de dados do cluster de origem para o destino foi bem-sucedida.

Quando ativado, o verificador realiza uma série de verificações no cluster de destino. Se alguma dessas verificações retornar um erro, o verificador falhará na migração. Se todas as verificações forem bem-sucedidas, mongosync fará a transição para o estado COMMITTED.

Para desabilitar o verificador, consulte Iniciar com o verificador desabilitado.

O endpoint /start retorna um erro se você habilitar verificações de verificação que não são suportadas pelo cluster de origem ou destino ou se não houver memória suficiente.

Se a solicitação start for bem-sucedida, mongosync entrará no estado RUNNING .

A sincronização de um conjunto de réplicas para um cluster fragmentado requer a opção sharding . Esta opção configura como mongosync fragmenta a collection.

A matriz sharding.shardingEntries especifica as coleções a serem fragmentadas. As collection que não estão listadas nesta matriz replicam como não fragmentadas.

Para obter mais informações, consulte Comportamento de cluster fragmentado.

mongosync sincroniza índices do cluster de cluster de origem para o cluster de destino. Ao sincronizar de um conjunto de réplicas para um cluster fragmentado, mongosync pode exigir um índice adicional para suportar a chave de shard, que pode não existir no cluster de origem.

mongosync pode criar índices de suporte para collection fragmentadas durante a sincronização. Isso é feito definindo a opção sharding.createSupportingIndexes .

Quando sharding.createSupportingIndexes é false (o padrão):

  • Cada chave de shard fornecida para a opção sharding.shardingEntries deve ter um índice existente no cluster de origem.

  • Um dos índices usados para a chave de shard deve ter agrupamento simples se a collection usar qualquer outro agrupamento.

  • Para usar um índice único na chave de fragmento, você deve especificar sua exclusividade ao criar o índice no cluster de origem.

  • Índice único no cluster de origem que são incompatíveis com a chave de shard solicitada no cluster de destino, como um índice único na origem que não contém a chave de shard solicitada como prefixo no destino, podem fazer com que mongosync falhe.

Quando sharding.createSupportingIndexes é true:

  • Se os índices de suporte existirem no cluster de origem, o mongosync sincronizará os índices com o cluster de destino e os utilizará como chaves de shard.

  • Se os índices de suporte não existirem, o mongosync os criará no cluster de destino.

A opção sharding.createSupportingIndexes afeta todas as collection fragmentadas.

As collection listadas na matriz sharding.shardingEntries , quando sincronizadas de um conjunto de réplicas para um cluster fragmentado, tornam-se collection no cluster de destino.

Renomear uma coleção (como com o comando renameCollection ) no cluster de origem depois de chamar start , mas antes mongosync começar a copiar a coleção pode bloquear a fragmentação da coleção no destino.

Observação

Não é permitido renomear collection para usar um reconhecimento de data center diferente durante a sincronização de um conjunto de réplicas para um cluster fragmentado.

Para verificar se é seguro renomear as coleções, chame o endpoint progress e verifique o valor do campo collectionCopy.estimatedCopiedBytes no documento de retorno.

  • Um valor de 0 indica que mongosync não começou a copiar a collection.

    Renomear uma coleção nesse ponto pode resultar em uma coleção não fragmentada no cluster de destino, pois a transição para a cópia pode acontecer antes que a renomeação entre em vigor na origem.

  • Um valor maior que 0 indica que mongosync iniciou a cópia. Renomear a collection a partir desse ponto não bloqueia sua fragmentação no cluster de destino, mesmo em caso de falha.

Quando você chama /start com a opção buildIndexes definida como never, mongosync ignora a criação de índices desnecessários.

Os índices que são sempre construídos incluem:

  • mongosync constrói um índice no campo _id de cada collection que copia.

  • mongosync cria índices fictícios para cada coleção fragmentada que não tem um índice para dar suporte à chave de shard no cluster de destino. Quando buildIndexes está definido como never, mongosync retém esse índice após o commit.

mongosync não protege o endpoint start . No entanto, por padrão, a API é vinculada apenas ao host local e não aceita chamadas de outras fontes. Além disso, a chamada start não expõe credenciais de conexão ou dados de usuário.

Voltar

Pontos de conexão da API do mongosync