Implementar um conjunto de réplicas autogerenciado geograficamente redundante
Visão geral
Este tutorial descreve o processo de distribuição de um conjunto de réplicas com nós em vários locais. O tutorial descreve conjuntos de réplicas de três nós e de cinco nós. Se você tiver um número par de nós de conjuntos de réplicas, adicione outro nó portador de dados, se possível, para distribuir um número ímpar de nós votantes. [1]
Para obter mais informações sobre conjuntos de réplicas distribuídos, consulte Conjuntos de réplicas distribuídos em dois ou mais data centers. Consulte também Arquiteturas de implantação de conjuntos de réplicas e Referência de replicação autogerenciada.
[1] | (1, 2) Se as circunstâncias proibirem outro nó portador de dados e você tiver um número par de nós votantes, você poderá adicionar um arbiter. Para saber como usar um arbiter, consulte Conjunto de réplicas de arbiter. |
Considerações
Arquitetura
Na produção, implemente cada membro da réplica definida em sua própria máquina. Se possível, certifique-se de que o MongoDB escuta na porta padrão do 27017
.
Observação
Fora de uma atualização contínua, todos os membros mongod
de um conjunto de réplicas devem usar a mesma versão principal do MongoDB.
Para obter mais informações, consulte Arquiteturas de sistema de conjunto de réplicas.
Nomes do host
Importante
Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.
Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.
Vinculação IP
Use a opção --bind_ip
para garantir que o MongoDB escute as conexões dos aplicativos nos endereços configurados.
Aviso
Antes de vincular a um não localhost (por exemplo, acessível IP ), certifique-se de ter protegido seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte a Lista de verificação de segurança para implementações autogerenciadas. No mínimo, procure habilitar a autenticação e fortalecer a infraestrutura de rede.
Os binários do MongoDB, mongod
e mongos
, são vinculados ao host local por padrão. Se a configuração do arquivo de configuração net.ipv6
ou a opção de linha de comando --ipv6
estiver definida para o binário, o binário também será vinculado ao endereço IPv6 do host local.
Por padrão, mongod
e mongos
que estão vinculados a localhost só aceitam conexões de clientes executados no mesmo computador. Este comportamento vinculativo inclui mongosh
e outros membros do seu conjunto de réplica ou cluster fragmentado. Clientes remotos não podem se conectar a binários vinculados apenas ao localhost.
Para substituir a associação padrão e vincular a outros endereços IP, use a net.bindIp
configuração do arquivo de configuração ou a --bind_ip
opção de linha de comando para especificar uma lista de nomes de host ou endereços IP.
Aviso
A partir do MongDB 5.0, DNS de horizonte dividido nós que são configurados apenas com um endereço IP falham na validação de inicialização e relatam um erro. Consulte disableSplitHorizonIPCheck
.
Por exemplo, a instância mongod
a seguir é vinculada ao host local e ao nome de host My-Example-Associated-Hostname
, que está associado ao endereço IP 198.51.100.1
:
mongod --bind_ip localhost,My-Example-Associated-Hostname
Para se conectar a esta instância, os clientes remotos devem especificar o nome do host ou seu endereço IP associado 198.51.100.1
:
mongosh --host My-Example-Associated-Hostname mongosh --host 198.51.100.1
Conectividade
Certifique-se de que o tráfego de rede possa passar com segurança entre todos os membros do conjunto e todos os clientes da rede.
Considere o seguinte:
Estabeleça uma rede virtual privada. Certifique-se de que sua topologia de rede roteie todo o tráfego entre membros em um único site pela rede local.
Configure o controle de acesso para evitar conexões de clientes desconhecidos ao conjunto de réplicas.
Configure as regras de rede e de firewall para que os pacotes de entrada e saída sejam permitidos somente na porta padrão do MongoDB e somente a partir da sua implantação. Consulte as considerações de ligação de IP.
Certifique-se de que cada membro de um conjunto de réplicas esteja acessível por meio de DNS ou nomes de host resolvíveis. Você deve configurar seus nomes de DNS adequadamente ou configurar o arquivo /etc/hosts
de seus sistemas para refletir essa configuração.
Cada membro deve ser capaz de se conectar a todos os outros membros. Para obter instruções sobre como verificar sua conexão, consulte Testar conexões entre todos os membros.
Configuração
Crie o diretório onde o MongoDB armazena arquivos de dados antes de implantar o MongoDB.
Especifique a configuração do mongod
em um arquivo de configuração armazenado no /etc/mongod.conf
ou em um local relacionado.
Para obter mais informações sobre opções de configuração, consulte Opções de arquivo de configuração autogerenciado.
Distribuição dos membros
Se possível, use um número ímpar de centros de dados e escolha uma distribuição de membros que maximize a probabilidade de que, mesmo com a perda de um centro de dados, os membros restantes do conjunto de réplicas possam formar uma maioria ou, no mínimo, fornecer uma cópia de seus dados.
Membros votantes
Nunca implemente mais de sete membros votantes.
Pré-requisitos
Para todas as configurações neste tutorial, implemente cada membro do conjunto de réplicas em um sistema separado. Embora você possa implantar mais de um membro do conjunto de réplicas em um único sistema, isso reduz a redundância e a capacidade do conjunto de réplicas. Esses sistemas normalmente são para fins de teste.
Este tutorial pressupõe que você tenha instalado o MongoDB em cada sistema que fará parte do seu conjunto de réplicas. Se você ainda não instalou o MongoDB, consulte os tutoriais de instalação.
Procedimentos
Implemente um conjunto de réplicas de três nós geograficamente redundante
Importante
Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.
Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.
Para um sistema de conjunto de réplicas de três membros geograficamente redundante, você deve decidir como distribuir seu sistema. Algumas possíveis distribuições para os três membros são:
Em três data centers: um membro para cada site.
Em dois data centers: dois membros do Site A e um membro do Site B. Se um dos membros do conjunto de réplicas for um árbitro [1], distribua o árbitro para o Site A com um membro portador de dados.
Observação
A distribuição de membros do conjunto de réplicas em dois centros de dados fornece benefícios de um único centro de dados. Em uma distribuição de dois centros de dados ,
Se um dos centros de dados ficar inativo, os dados ainda estarão disponíveis para leituras, diferentemente de uma distribuição de centro de dados único.
Se o centro de dados com uma minoria dos membros ficar inativo, o conjunto de réplicas ainda pode servir operações de gravação, bem como operações de leitura.
No entanto, se o centro de dados com a maioria dos membros cair, o conjunto de réplicas se tornará somente leitura.
Se possível, distribua membros em pelo menos três data centers. Para conjuntos de réplicas do servidor de configuração (CSRS), a prática recomendada é distribuir por três (ou mais, dependendo do número de membros) centros. Se o custo do terceiro data center for proibitivo, uma possibilidade de distribuição é distribuir uniformemente os membros da propriedade de dados nos dois data centers e armazenar o membro restante na nuvem, se a política da sua empresa permitir.
Inicie cada membro do conjunto de réplicas com as opções apropriadas.
Para cada membro, inicie uma instância do mongod
com as seguintes configurações:
Defina a opção
replication.replSetName
como o nome do conjunto de réplicas. Se seu aplicativo se conectar a mais de um conjunto de réplicas, cada conjunto deverá ter um nome distinto.Defina a opção
net.bindIp
como o nome do host/ip ou uma lista delimitada por vírgulas de nomes de host/ips.Defina quaisquer outras configurações conforme apropriado para seu sistema.
Neste tutorial, as três instâncias do mongod
são associadas com os seguintes hosts:
Membro do conjunto de réplicas | nome de anfitrião |
---|---|
Membro 0 |
|
Membro 1 |
|
Membro 2 |
|
O exemplo a seguir especifica o nome do conjunto de réplicas e a associação ip por meio das opções de linha de comando --replSet
e --bind_ip
:
Aviso
Antes de vincular a um não localhost (por exemplo, acessível IP ), certifique-se de ter protegido seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte a Lista de verificação de segurança para implementações autogerenciadas. No mínimo, procure habilitar a autenticação e fortalecer a infraestrutura de rede.
mongod --replSet "rs0" --bind_ip localhost,<hostname(s)|ip address(es)>
Para <hostname(s)|ip address(es)>
, especifique o(s) nome(s) de host e/ou endereço(s) IP da instância mongod
que os clientes remotos (incluindo os outros membros do conjunto de réplicas) podem usar para se conectar à instância.
Como alternativa, você pode especificar o replica set name
e o ip addresses
em um arquivo de configuração:
replication: replSetName: "rs0" net: bindIp: localhost,<hostname(s)|ip address(es)>
Para iniciar o mongod
com um arquivo de configuração, especifique o caminho do arquivo de configuração com a opção --config
:
mongod --config <path-to-config>
Em implantações de produção, você pode configurar um script de entrada para gerenciar este processo. Os scripts de inicialização estão além do escopo deste documento.
Conecte a uma mongosh
das mongod
instâncias de.
Na mesma máquina em que um dos mongod
está sendo executado (neste tutorial, mongodb0.example.net
), inicie o mongosh
. Para se conectar ao mongod
escutando localhost na porta padrão do 27017
, basta emitir:
mongosh
Dependendo do seu caminho, você pode precisar especificar o caminho para o binário mongosh
.
Se o seu mongod
não estiver executando na porta padrão, especifique a opção --port
para mongosh
.
Inicie o conjunto de réplicas.
No mongosh
, execute rs.initiate()
no membro do conjunto de réplicas 0.
Importante
Execute rs.initiate()
em apenas uma e apenas uma instânciamongod
para o conjunto de réplicas.
Importante
Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.
Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.
rs.initiate( { _id : "rs0", members: [ { _id: 0, host: "mongodb0.example.net:27017" }, { _id: 1, host: "mongodb1.example.net:27017" }, { _id: 2, host: "mongodb2.example.net:27017" } ] })
O MongoDB inicia um conjunto de réplicas, usando a configuração padrão do conjunto de réplicas.
Visualizar a configuração do conjunto de réplicas.
Utilize o rs.conf()
para exibir o objeto de configuração do conjunto de réplicas:
rs.conf()
O objeto de configuração do conjunto de réplicas é semelhante ao seguinte:
{ "_id" : "rs0", "version" : 1, "protocolVersion" : NumberLong(1), "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("585ab9df685f726db2c6a840") } }
Opcional. Configure a elegibilidade do nó para se tornar primary.
Em alguns casos, você pode preferir que os membros de um centro de dados sejam eleitos como primários antes dos membros dos outros centros de dados. Você pode modificar o priority
dos membros de modo que os membros de um data center tenham priority
mais alto do que os membros dos outros data centers.
Alguns membros do conjunto de réplicas, como os membros que têm restrições de rede ou recursos limitados, não devem ser capazes de se tornar primários em um failover. Configure membros que não devem se tornar primários para ter prioridade 0.
Por exemplo, para reduzir a elegibilidade relativa do membro localizado em um dos locais (neste exemplo, mongodb2.example.net
), defina a prioridade do membro como 0.5
.
Visualize a configuração do conjunto de réplicas para determinar a posição da array do
members
para o membro. Tenha em mente que a posição da array não é a mesma do_id
:rs.conf() Copie o objeto de configuração do conjunto de réplicas para uma variável (para
cfg
no exemplo abaixo). Em seguida, na variável, defina a prioridade correta para o membro. Em seguida, passe a variável parars.reconfig()
para atualizar a configuração do conjunto de réplica.Por exemplo, para definir a prioridade para o terceiro membro na array (ou seja, o membro na posição 2), emita a seguinte sequência de comandos:
cfg = rs.conf() cfg.members[2].priority = 0.5 rs.reconfig(cfg) Observação
O método
rs.reconfig()
shell pode forçar a atual primária a renunciar, causando uma eleição. Quando o primário for desativado, todos os clientes serão desconectados. Este é o comportamento pretendido. Embora o tempo médio para eleger um novo primário normalmente não deva exceder 12 segundos, certifique-se sempre de que todas as alterações na configuração da réplica ocorram durante os períodos de manutenção agendados.
Após esses comandos retornarem, você terá um conjunto de réplicas de três membros geograficamente redundante.
Verifique se o conjunto de réplicas tem um primary.
Utilize o rs.status()
para identificar a primária no conjunto de réplicas.
Implante um conjunto de réplicas de cinco membros geograficamente redundante
Importante
Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.
Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.
Para um sistema de conjunto de réplicas de cinco membros geograficamente redundante, você deve decidir como distribuir seu sistema. Algumas possíveis distribuições para os cinco membros são:
Em três data centers: dois membros no site A, dois membros no site B, um membro no site C.
Em quatro data centers: dois membros em um local e um membro nos outros três locais.
Em cinco centros de dados: um nó em cada site.
Em dois data centers: três membros no site A e dois membros no site B. Se possível, evite distribuir a réplica do servidor de configuração definida em apenas dois data centers.
Observação
A distribuição de membros do conjunto de réplicas em dois centros de dados fornece benefícios de um único centro de dados. Em uma distribuição de dois centros de dados ,
Se um dos centros de dados ficar inativo, os dados ainda estarão disponíveis para leituras, diferentemente de uma distribuição de centro de dados único.
Se o centro de dados com uma minoria dos membros ficar inativo, o conjunto de réplicas ainda pode servir operações de gravação, bem como operações de leitura.
No entanto, se o centro de dados com a maioria dos membros cair, o conjunto de réplicas se tornará somente leitura.
Se possível, distribua membros em pelo menos três data centers. Para conjuntos de réplicas do servidor de configuração (CSRS), a prática recomendada é distribuir por três (ou mais, dependendo do número de membros) centros. Se o custo do terceiro data center for proibitivo, uma possibilidade de distribuição é distribuir uniformemente os membros da propriedade de dados nos dois data centers e armazenar o membro restante na nuvem, se a política da sua empresa permitir.
Inicie cada membro do conjunto de réplicas com as opções apropriadas.
Para cada membro, inicie uma instância do mongod
com as seguintes configurações:
Defina a opção
replication.replSetName
para o nome do conjunto de réplicas,Se seu aplicativo se conectar a mais de um conjunto de réplicas, cada conjunto deverá ter um nome distinto. Alguns drivers agrupam conexões de conjunto de réplicas por nome de conjunto de réplicas.
Defina a opção
net.bindIp
como o nome do host/endereço IP ou uma lista delimitada por vírgulas de nomes de host/endereços IP eDefina quaisquer outras configurações conforme apropriado para seu sistema.
Neste tutorial, as cinco instâncias do mongod
são associadas com os seguintes hosts:
Membro do conjunto de réplicas | nome de anfitrião |
---|---|
Membro 0 |
|
Membro 1 |
|
Membro 2 |
|
Membro 3 |
|
Membro 4 |
|
O exemplo a seguir especifica o nome do conjunto de réplicas e a associação ip por meio das opções de linha de comando --replSet
e --bind_ip
:
Aviso
Antes de vincular a um não localhost (por exemplo, acessível IP ), certifique-se de ter protegido seu cluster contra o acesso não autorizado. Para obter uma lista completa de recomendações de segurança, consulte a Lista de verificação de segurança para implementações autogerenciadas. No mínimo, procure habilitar a autenticação e fortalecer a infraestrutura de rede.
mongod --replSet "rs0" --bind_ip localhost,<hostname(s)|ip address(es)>
Para <hostname(s)|ip address(es)>
, especifique o(s) nome(s) de host e/ou endereço(s) IP da instância mongod
que os clientes remotos (incluindo os outros membros do conjunto de réplicas) podem usar para se conectar à instância.
Como alternativa, você pode especificar o replica set name
e o hostnames/ip
addresses
em um arquivo de configuração:
replication: replSetName: "rs0" net: bindIp: localhost,<hostname(s)|ip address(es)>
Para iniciar o mongod
com um arquivo de configuração, especifique o caminho do arquivo de configuração com a opção --config
:
mongod --config <path-to-config>
Em implantações de produção, você pode configurar um script de entrada para gerenciar este processo. Os scripts de inicialização estão além do escopo deste documento.
Conecte a uma mongosh
das mongod
instâncias de.
Na mesma máquina em que um dos mongod
está sendo executado (neste tutorial, mongodb0.example.net
), inicie o mongosh
. Para se conectar ao mongod
escutando localhost na porta padrão do 27017
, basta emitir:
mongosh
Dependendo do seu caminho, você pode precisar especificar o caminho para o binário mongosh
.
Se o seu mongod
não estiver executando na porta padrão, especifique a opção --port
para mongosh
.
Inicie o conjunto de réplicas.
No mongosh
, execute rs.initiate()
no membro do conjunto de réplicas 0.
Importante
Execute rs.initiate()
em apenas uma e apenas uma instânciamongod
para o conjunto de réplicas.
rs.initiate( { _id : "rs0", members: [ { _id: 0, host: "mongodb0.example.net:27017" }, { _id: 1, host: "mongodb1.example.net:27017" }, { _id: 2, host: "mongodb2.example.net:27017" }, { _id: 3, host: "mongodb3.example.net:27017" }, { _id: 4, host: "mongodb4.example.net:27017" } ] })
Visualizar a configuração do conjunto de réplicas.
Utilize o rs.conf()
para exibir o objeto de configuração do conjunto de réplicas:
rs.conf()
O objeto de configuração do conjunto de réplicas é semelhante ao seguinte:
{ "_id" : "rs0", "version" : 1, "protocolVersion" : NumberLong(1), "writeConcernMajorityJournalDefault" : true, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 3, "host" : "mongodb3.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 4, "host" : "mongodb4.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "catchUpTakeoverDelayMillis" : 30000, "getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("5df2c9ccc21c478b838b98d6") } }
Opcional. Configure a elegibilidade do nó para se tornar primary.
Em alguns casos, você pode preferir que os membros de um centro de dados sejam eleitos como primários antes dos membros dos outros centros de dados. Você pode modificar o priority
dos membros de modo que os membros de um data center tenham priority
mais alto do que os membros dos outros data centers.
Alguns membros do conjunto de réplicas, como os membros que têm restrições de rede ou recursos limitados, não devem ser capazes de se tornar primários em um failover. Configure membros que não devem se tornar primários para ter prioridade 0.
Por exemplo, para reduzir a elegibilidade relativa do membro localizado em um dos locais (neste exemplo, mongodb2.example.net
), defina a prioridade do membro como 0.5
.
Visualize a configuração do conjunto de réplicas para determinar a posição da array do
members
para o membro. Tenha em mente que a posição da array não é a mesma do_id
:rs.conf() Copie o objeto de configuração do conjunto de réplicas para uma variável (para
cfg
no exemplo abaixo). Em seguida, na variável, defina a prioridade correta para o membro. Em seguida, passe a variável parars.reconfig()
para atualizar a configuração do conjunto de réplica.Por exemplo, para definir a prioridade para o terceiro membro na array (ou seja, o membro na posição 2), emita a seguinte sequência de comandos:
cfg = rs.conf() cfg.members[2].priority = 0.5 rs.reconfig(cfg) Observação
O método
rs.reconfig()
shell pode forçar a atual primária a renunciar, causando uma eleição. Quando o primário for desativado, todos os clientes serão desconectados. Este é o comportamento pretendido. Embora o tempo médio para eleger um novo primário normalmente não deva exceder 12 segundos, certifique-se sempre de que todas as alterações na configuração da réplica ocorram durante os períodos de manutenção agendados.
Após esses comandos retornarem, você terá um conjunto de réplicas de cinco membros geograficamente redundante.
Verifique se o conjunto de réplicas tem um primary.
Utilize o rs.status()
para identificar a primária no conjunto de réplicas.