Descrição
Inverte a direção de uma operação de sincronização confirmada.
Por exemplo:
Você tem uma operação de sincronização
COMMITTED.cluster0é a origem ecluster1é o destino.Após a operação de sincronização ser
COMMITTED, novas gravações ocorrerão somente no cluster de destino. O cluster de origem não aceitará novas gravações.
Nesse cenário, você pode usar o endpoint reverse para sincronizar gravações de cluster1 para cluster0, incluindo quaisquer gravações que tenham ocorrido em cluster1 depois que mongosync atingiu canWrite=true. Para verificar o status do canWrite durante a sincronização, use o endpoint /progress .
Para obter mais informações e um tutorial sobre como usar o reverse endpoint, consulte Direção de sincronização inversa.
Requisitos
Para usar o ponto de extremidade reverse :
mongosyncdeve ser configurado quando a sincronização inicial começar. A chamada para o ponto de extremidade da API /start deve definir a opçãoreversiblecomotrue.
Você não pode atualizar esta opção após o início da sincronização.
mongosyncdeve estar no estadoCOMMITTED.O oplog do cluster de destino não deve ser acumulado entre
mongosync, alcançarcanWrite=truee receber a solicitação/reverse.
Aviso
Os índices únicos no cluster de origem não devem usar o formato legado.
Para validar se os índices de collection no cluster de origem usam a formatação adequada, consulte Validar índices únicos.
Os clusters de origem e destino devem ter o mesmo número de fragmentos. Não é possível fazer a sincronização reversa quando os clusters têm topologias diferentes.
Os clusters de origem e destino devem executar a mesma versão principal do MongoDB .
- O usuário especificado na string de conexão
mongosyncdeve ter as permissões necessárias nos clusters de origem e destino. As permissões variam dependendo do seu ambiente e se você deseja usar a sincronização reversa.
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 Reverter vários Mongosyncs.
Validar índices únicos
In order to reverse direction, mongosync requires that all unique indexes on the source cluster (except for _id) do not have legacy unique index keys.
Antes de começar
You can ensure that non-_id unique indexes use the correct formatting on the source cluster with the $collStats aggregation stage. To run this aggregation pipeline on your collection, copy and paste the example code, replacing <collection> with the collection name and <field_name> with the name of the indexed field. You must run this on all nodes, for all collections that have unique indexes. Note that only the non-_id unique indexes need to have formatVersion 13 or 14.
db.<collection>.aggregate( [ { $collStats: { storageStats: { } } }, { $project: { "storageStats.indexDetails.<index_name>.metadata.formatVersion": 1 } } ] )
[ { storageStats: { indexDetails: { <field_name>: { metadata: { formatVersion: 14 } } } } } ]
É garantido que índices únicos com formatVersion 13 ou 14 não tenham chaves legado .
If you have unique indexes of a different formatVersion, you can also use the db.collection.validate() method with full = false to confirm if there are legacy index keys. You must run this on all nodes for all collections with unique indexes. validate() returns a warning if legacy format index keys are detected.
Passos
Para atualizar a versão de formato dos índices para compatibilidade com mongosync, você deve ressincronizar todos os nós no cluster de origem original. Para sincronizar todos os nós novamente:
Sincronize todos os secundários, um por um.
Para obter um tutorial sobre a ressincronização de nós, consulte Sincronizar novamente um membro de um conjunto de réplicas.
Solicitar
POST /api/v1/reverse
Parâmetros do corpo da solicitação
Este endpoint não usa parâmetros do corpo da solicitação HTTP. No entanto, você deve especificar a opção --data com um objeto vazio { }.
Resposta
Campo | Tipo | Descrição |
|---|---|---|
| booleano | Quando a solicitação é bem-sucedida, esse valor é |
| string | Se ocorreu um erro, indica o nome do erro. Este campo é omitido da resposta quando |
| string | Descrição detalhada do erro que ocorreu. Este campo é omitido da resposta quando |
Exemplo
O exemplo a seguir reverte a direção de uma operação de sincronização confirmada.
Solicitar
curl localhost:27182/api/v1/reverse -XPOST --data '{ }'
Resposta
{"success":true}
Comportamento
O endpoint reverse inicia o estado REVERSING . mongosync troca os clusters de origem e destino e retoma a aplicação de eventos de alteração.
Se a sincronização reverse for bem-sucedida, mongosync entrará no estado RUNNING . A sincronização continua na direção inversa do tarefa de sincronização original. Você não precisa reiniciar todo o processo de sincronização para copiar os dados originais.
Para visualizar a direção de mapeamento para a sincronização dos clusters de origem e destino, use o endpoint de progresso e verifique o objeto directionMapping .
Observação
mongosync não retém documentos quentes especificados com a opção --hotDocIDs ou a configuração hotDocIDs em uma sincronização reverse. Se o atraso de replicação ocorrer devido a documentos quentes durante uma sincronização reverse, reinicie o processo mongosync e especifique os identificadores de documentos quentes para a direção inversa. Os identificadores de documentos quentes especificados só entram em vigor depois que você interrompe e reinicia mongosync. Não reinicie a migração do zero.
Verificador incorporado
O verificador embarcado é habilitado por padrão para migrações de conjunto de réplicas.
Proteção de endpoint
mongosync não protege o endpoint reverse . 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 reverse não expõe credenciais de conexão ou dados de usuário.
Limitações
O endpoint reverse não suporta:
migrações de 6.0 clusters de origem pré-.