Replicação avançada

É possível aprender sobre conceitos e tarefas de replicação avançada, como os que estão na lista a seguir, e muito mais:

Mantendo seu banco de dados de replicação
Planejando e monitorando replicações
Autenticando durante a replicação

Também pode ser útil revisar os detalhes do protocolo de replicação subjacente e consultar a documentação de referência da API.

Manutenção do banco de dados de replicação

Um banco de dados de replicação deve ser monitorado como qualquer outro banco de dados. Sem manutenção regular do banco de dados, é possível acumular documentos inválidos causados por interrupções no processo de replicação. Ter muitos documentos inválidos pode resultar em um excesso de carga em seu cluster quando o processo do replicador é reiniciado por operações do IBM® Cloudant® for IBM Cloud®.

Para manter um banco de dados de replicação, remova documentos antigos. Será possível remover documentos antigos determinando a idade deles e excluindo-os se eles não forem mais necessários.

O planejador de replicação

O novo Planejador de replicação do IBM Cloudant fornece uma série de melhorias e aprimoramentos quando comparado ao mecanismo de replicação anterior do IBM Cloudant.

Em particular, o uso de rede durante a replicação é mais eficiente. O planejador conta com a carga atual para nós do banco de dados individual dentro de um cluster quando determina a alocação de tarefas de replicação.

Por fim, agora o estado de uma replicação é mais detalhado e consiste em sete estados distintos:

initializing - A replicação foi incluída no planejador, mas ainda não foi inicializada ou planejada para execução. Esse status ocorre quando um documento de replicação novo ou atualizado é armazenado no banco de dados _replicator.
error - A replicação não pode ser transformada em uma tarefa. Esse erro pode ser causado de várias maneiras diferentes. Por exemplo, a replicação deve ser filtrada, mas não foi possível buscar o código do filtro por meio do banco de dados de origem.
pending - A tarefa de replicação está planejada para ser executada, mas ainda não está em execução.
running - A tarefa de replicação está em execução.
crashing - Ocorreu um erro temporário que afeta a tarefa de replicação. A tarefa é repetida automaticamente em outro momento.
completed - A tarefa de replicação foi concluída. Esse estado não se aplica a replicações contínuas.
failed - A tarefa de replicação falhou. A falha é permanente. Esse estado significa que não é feita qualquer tentativa adicional de replicar usando essa tarefa de replicação. A falha poderá ser causada de várias maneiras diferentes, por exemplo, se as URLs de origem ou de destino não forem válidas.

A transição entre esses estados é ilustrada no diagrama a seguir:

A transição entre os estados é , , e . — Estados do Agendador de Replicação

O planejador apresenta dois novos terminais:

É possível gerenciar e determinar o status de replicação de forma mais rápida e fácil usando esses terminais.

Veja o processo típico para usar o planejador de replicação para gerenciar e monitorar replicações:

Crie um documento de replicação que descreva a replicação necessária e armazene o documento no banco de dados do replicador.
Monitore o status da replicação usando o terminal /_scheduler/docs.

Autenticação durante a replicação

Em qualquer aplicativo de produção, a segurança dos bancos de dados de origem e de destino é essencial. Para que a replicação continue, a autenticação é necessária para acessar os bancos de dados. Os pontos de verificação para replicação estão habilitados por padrão, o que significa que a replicação do banco de dados de origem requer acesso de gravação.

Para permitir a autenticação durante a replicação, inclua um nome de usuário e uma senha na URL do banco de dados. O processo de replicação usa os valores fornecidos para a Autenticação básica HTTP.

Veja o exemplo a seguir da especificação dos valores de nome de usuário e senha para acessar bancos de dados de origem e de destino durante a replicação:

{
  "source": {
    "url": "https://example.com/db",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/db",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  }
}

Para credenciais do IAM, use o exemplo abaixo para autenticar com uma chave de API do IAM:

{
  "source": {
    "url": "https://example.com/db",
    "auth": {
      "iam": {
        "apikey": "$APIKEY"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/db",
    "auth": {
      "iam": {
        "apikey": "$APIKEY"
      }
    }
  }
}

Replicação filtrada

Às vezes você não quer transferir todos os documentos da origem para o destino. Para escolher quais documentos transferir, inclua uma ou mais funções de filtro em um documento de design na origem. Em seguida, é possível dizer ao replicador para usar essas funções de filtro.

A filtragem de documentos durante a replicação é semelhante ao processo de filtragem do feed _changes.

Uma função de filtro usa dois argumentos:

O documento a ser replicado.
A solicitação de replicação.

Uma função de filtro retorna um valor true ou false. Se o resultado for verdadeiro, o documento será replicado.

Para configurar a filtragem, use o campo selector sempre que possível. Quando você usa o campo selector, é possível especificar um filtro sem precisar replicar o banco de dados inteiro. Esse método torna a filtragem mais rápida e causa menos carga no IBM Cloudant. Para obter mais informações, consulte a documentação do campo “ selector ”.

Consulte o exemplo a seguir de uma função de filtro:

function(doc, req) {
	return !!(doc.type && doc.type == "foo");
}

Os filtros são armazenados na chave superior filters do documento de design.

Veja o exemplo a seguir de armazenamento de uma função de filtro em um documento de design:

{
	"_id": "_design/myddoc",
	"filters": {
		"myfilter": "function goes here"
	}
}

Uma replicação filtrada é iniciada usando uma instrução JSON que identifica os itens a seguir:

Banco de dados de origem.
O banco de dados de destino.
O nome do filtro armazenado na chave filters do documento de design.

Veja exemplo de JSON para iniciar uma replicação filtrada:

{
  "source": {
    "url": "https://example.org/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "filter": "myddoc/myfilter"
}

Os argumentos podem ser fornecidos para a função de filtro incluindo pares de chave e valor no campo query_params da chamada.

Veja exemplo de JSON para iniciar uma replicação filtrada com parâmetros fornecidos:

{
  "source": {
    "url": "https://example.org/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "target": {
    "url": "https://$ACCOUNT.cloudant.com/example-database",
    "auth": {
      "basic": {
        "username": "$USERNAME",
        "password": "$PASSWORD"
      }
    }
  },
  "filter": "myddoc/myfilter",
  "query_params": {
    "key": "value"
  }
}

A opção selector fornece benefícios de desempenho quando comparada com o uso da opção filter. Use a opção selector sempre que possível. Para obter mais informações, consulte a selector documentação.

Eliminando conflitos que usam replicação

Use a opção winning_revs_only: true para replicar as revisões de documentos vencedoras apenas. Essas revisões são as revisões que seriam retornadas pelo terminal da API do GET $ACCOUNT/$DATABASE/$DOCID por padrão ou aparecerão no _changes alimentação com os parâmetros padrão.

{
	"source": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://$ACCOUNT.cloudant.com/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"winning_revs_only": true
}

A replicação com este modo descarta revisões conflitantes, portanto, pode ser uma maneira de remover conflitos através da replicação.

IDs de replicação e IDs de ponto de verificação, gerados por winning_revs_only: true Essas replicações são diferentes das geradas por padrão; portanto, é possível primeiro replicar as revisões vencedoras e, posteriormente, preencher o restante das revisões com uma tarefa de replicação regular.

A opção winning_revs_only: true pode ser combinada com filtros ou outras opções como continuous: true ou create_target: true.

Replicação de documento nomeado

Às vezes você não quer replicar documentos. Para replicações simples, não é necessário gravar uma função de filtro. Em vez disso, para replicar documentos específicos, inclua a lista de chaves como uma matriz no campo doc_ids.

Veja o exemplo a seguir de replicação de documentos específicos:

{
	"source": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://127.0.0.1:5984/example-database",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"doc_ids": ["foo", "bar", "baz"]
}

A propriedade `user_ctx` e delegações

Os documentos de replicação podem ter uma propriedade user_ctx customizada. Essa propriedade define o contexto do usuário sob o qual uma replicação é executada.

Uma maneira mais antiga de acionar replicações, executando um POST para o terminal /_replicate/, não precisava da propriedade user_ctx. A razão é que, no momento de acionar a replicação, todas as informações necessárias sobre o usuário autenticado estão disponíveis.

Em contraste, o banco de dados replicador é um banco de dados regular. As informações sobre o usuário autenticado só estão disponíveis no momento em que o documento de replicação é gravado no banco de dados. Em outras palavras, a implementação do banco de dados do replicador é semelhante a um aplicativo de consumo de feed _changes com ?include_docs=true configurado.

Para fins de replicação, essa diferença de implementação significa que, para usuários que não sejam administradores, uma propriedade user_ctx que inclua o nome do usuário e um subconjunto de suas funções deve ser definida no documento de replicação. Esse requisito é abordado por uma função de validação presente no documento de design padrão do banco de dados replicador. A função valida cada atualização de documento. Essa função de validação também garante que um usuário sem privilégios de administrador não possa definir uma propriedade de nome de usuário na propriedade user_ctx que não corresponda ao nome de usuário correto. O mesmo princípio também se aplica para funções.

Veja o exemplo de documento de replicação delegada a seguir:

{
	"_id": "my_rep",
	"source": {
	  "url": "https://$SERVER.com:5984/foo",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://$ACCOUNT.cloudant.com/bar",
	  "auth": {
	    "basic": {
	      "username": "$USERNAME",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"continuous":  true,
	"user_ctx": {
		"name": "joe",
		"roles": ["erlanger", "researcher"]
	}
}

Para administradores, a propriedade user_ctx é opcional. Se a propriedade estiver ausente, o valor será padronizado para um contexto de usuário com o nome null e uma lista vazia de funções.

A lista vazia de funções significa que os documentos de design não são gravados em destinos locais durante a replicação. Para gravar documentos de design em destinos locais, um contexto de usuário com a função _admin deve ser configurado explicitamente.

Além disso, para administradores, a propriedade user_ctx pode ser usada a fim de acionar uma replicação para outro usuário. Esse contexto de usuário é transmitido para funções de validação de documentos de banco de dados de destino local.

A propriedade user_ctx se aplica somente aos terminais locais.

Em resumo, para os administradores, a propriedade user_ctx é opcional. Enquanto para usuários regulares (não administradores), é obrigatório. Quando a propriedade de funções de user_ctx está ausente, ela é padronizada para a lista vazia [ ].

Várias opções relacionadas ao desempenho podem ser configuradas para uma replicação incluindo-as no documento de replicação.

use_bulk_get: Configure como true para melhorar o desempenho do trabalho de replicação. Uma replicação busca documentos em lotes da fonte. O aumento da taxa de replicação pode consumir a capacidade da conta de origem e de destino mais rapidamente e resultar em mais solicitações simultâneas de não replicação nessas contas 429 HTTP erros.
connection_timeout: O período máximo de inatividade para uma conexão em milissegundos. Se uma conexão ficar inativa durante esse período, sua solicitação atual será repetida. O valor padrão é de 30000 milissegundos (30 segundos).
http_connections: O número máximo de conexões HTTP por replicação. Para replicações push, o número efetivo de conexões HTTP que são usadas é min(worker_processes + 1, http_connections). Para replicações pull, o número efetivo de conexões que são usadas corresponde ao valor desse parâmetro. O valor padrão é 20.
retries_per_request: O número máximo de novas tentativas por solicitação. Antes de uma nova tentativa, o replicador aguarda um curto período antes de repetir a solicitação. Esse período dobra entre cada nova tentativa consecutiva e nunca ultrapassa 5 minutos. O valor mínimo antes da primeira nova tentativa é de 0,25 segundos. O valor padrão é de 10 novas tentativas.
socket_options: Uma lista de opções para passar aos soquetes de conexão. As opções disponíveis podem ser encontradas na documentação da função Erlang setopts do módulo inet . O valor padrão é [{keepalive, true},{nodelay, false}].
worker_batch_size: Os processos do trabalhador executam lotes de tarefas de replicação, onde o tamanho do lote é definido por este parâmetro. O tamanho corresponde ao número de linhas de feed _changes. Valores maiores para o tamanho do lote podem resultar em melhor desempenho. Valores menores significam que o ponto de verificação é feito com mais frequência. O valor padrão é 500.
worker_processes: O número de processos que o replicador utiliza em cada tarefa de replicação para transferir documentos da origem para o banco de dados de destino. Valores mais altos podem produzir melhor rendimento por causa de um maior paralelismo nas atividades de E/S de disco e de rede, mas essa melhoria exige mais memória e potencialmente mais tempo de CPU. O valor padrão é 4.

Veja o exemplo a seguir que inclui opções de desempenho em um documento de replicação:

{
	"source": {
	  "url": "https://example.com/example-database",
	  "auth": {
	    "basic": {
	      "username": "$ACCOUNT1",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"target": {
	  "url": "https://example.org/example-database",
	  "auth": {
	    "basic": {
	      "username": "$ACCOUNT2",
	      "password": "$PASSWORD"
	    }
	  }
	},
	"connection_timeout": 60000,
	"retries_per_request": 20,
	"http_connections": 30
}

O efeito de anexos grandes

Ter grandes números de anexos em documentos pode causar um efeito adverso no desempenho da replicação.

Para obter mais informações sobre o efeito dos anexos no desempenho da replicação, consulte Considerações de desempenho.

Evitando o terminal `/_replicate`

Use o planejador _replicator no lugar do terminal /_replicate.

Se ocorrer um problema durante a replicação, como uma paralisação, um tempo limite ou um travamento do aplicativo, a replicação definida dentro do banco de dados _replicator será reiniciada automaticamente pelo sistema. No entanto, se você definir uma replicação enviando uma solicitação para o terminal /_replicate, ela não poderá ser reiniciada pelo sistema se ocorrer um problema, pois a solicitação de replicação não persistirá. As replicações que são definidas no banco de dados _replicator são mais fáceis de monitorar.

Replicação avançada

Replicação avançada

Manutenção do banco de dados de replicação

O planejador de replicação

Autenticação durante a replicação

Replicação filtrada

Eliminando conflitos que usam replicação

Replicação de documento nomeado

A propriedade user_ctx e delegações

Opções relacionadas ao desempenho

O efeito de anexos grandes

Evitando o terminal /_replicate

A propriedade `user_ctx` e delegações

Evitando o terminal `/_replicate`