start
Descrição
Inicia a sincronização entre um cluster de origem e destino.
Requisitos
Estado
Para usar o endpoint start
, mongosync
deve estar no estado IDLE
.
Permissões
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.
mongosync
Várias instâncias de
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.
Solicitar
POST /api/v1/start
Parâmetros do corpo da solicitação
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:
Se você chamar Novidade na versão 1,3,0. | |
documentFilter | documento | Opcional | IMPORTANTE: esse recurso está disponível apenas na A partir do Para saber mais, consulte Filtragem de documentos. Novo na versão 1.8: beta | |
enableUserWriteBlocking | booleano | Opcional | Se definido como Para reverter a sincronização, o campo
O valor padrão é | |
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 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 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 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 Para fazer a sincronização reversa, o campo Esta opção não é suportada para as seguintes configurações:
Para obter mais informações, consulte o endpoint inverso . O valor padrão é | |
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, 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. |
Parâmetros de fragmentação
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 é 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.
Resposta
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 . |
Exemplos
Iniciar um trabalho de sincronização
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}
Iniciar um trabalho de sincronização reversível
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}
Iniciar um trabalho de sincronização filtrado
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
eAPAC
a partir do banco de dados dosales
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}
Iniciar sincronização do conjunto de réplicas para cluster fragmentado
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}
Comece com o Verificador Desativado
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.
Comportamento
Verificador incorporado
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.
Estado
Se a solicitação start
for bem-sucedida, mongosync
entrará no estado RUNNING
.
Fragmentar conjuntos de réplicas
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.
Índices de apoio
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.
Renomear durante a sincronização
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.
Índices exigidos
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. QuandobuildIndexes
está definido comonever
,mongosync
retém esse índice após o commit.
Proteção de endpoint
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.