Criando um cliente

Usando Mongo::Client

Para se conectar a um MongoDB deployment, crie um objeto Mongo::Client . Forneça uma lista de hosts e opções ou umURI de connection string para o construtor ''Mongo::Client''. O banco de dados selecionado do cliente tem como padrão admin.

Por padrão, o driver detectará automaticamente a topologia usada pelo sistema e se conectará adequadamente.

Para se conectar a uma implantação local autônomo do MongoDB, especifique o host e a porta do servidor. Na maioria dos casos, você também especificaria o nome do reconhecimento de data center ao qual se conectar; se nenhum nome de reconhecimento de data center for especificado, o cliente utilizará o reconhecimento de data center admin :

Mongo::Client.new([ '127.0.0.1:27017' ], database: 'mydb')
# Or using the URI syntax:
Mongo::Client.new("mongodb://127.0.0.1:27017/mydb")

Para se conectar ao MongoDB Atlas, especifique o URI de implantação do Atlas:

Mongo::Client.new("mongodb+srv://username:myRealPassword@cluster0.mongodb.net/mydb?w=majority")

O driver descobrirá todos os nós no cluster e se conectará a eles conforme necessário.

Mongo::Client.new(...) do |client|
  # work with the client
end

Seleção do reconhecimento de data center

Por padrão, o cliente se conectará ao reconhecimento de data center admin .

O banco de dados admin é um banco de dados especial do MongoDB, frequentemente usado para tarefas administrativas e para armazenar dados administrativos, como usuários e roles (embora usuários e roles também possam ser definidos em outros bancos de dados). Em um cluster fragmentado, o banco de dados do admin existe nos servidores de configuração em vez dos servidores de shard. Embora seja possível usar o banco de dados admin para operações comuns (como armazenar dados do aplicativo), isso não é recomendado, e o aplicativo deve especificar explicitamente o banco de dados que deseja usar.

O reconhecimento de data center pode ser especificado durante a construção do Client :

# Using Ruby client options:
client = Mongo::Client.new(['localhost'], database: 'mydb')
# Using a MongoDB URI:
client = Mongo::Client.new('mongodb://localhost/mydb')

Dada uma instância Client , o método use pode ser invocado para obter uma nova instância Client configurada com o reconhecimento de data center especificado:

client = Mongo::Client.new(['localhost'], database: 'mydb')
admin_client = client.use('admin')
# Issue an administrative command
admin_client.database.command(replSetGetConfig: 1).documents.first

Existem outros reconhecimento de data center especiais no MongoDB que devem ser usados somente para os fins declarados:

• O banco de dados de configuração .

• O banco de dados local .

• O banco de banco de dados do $external , que é usado com PLAIN, Kerberos e X.509 mecanismos de autenticação .

Tipos de conexão

Por padrão, o driver descobrirá o tipo de sistema ao qual é instruído a se conectar (exceto para sistemas com balanceamento de carga) e se comportará da maneira que corresponde ao tipo de sistema. As subseções abaixo descrevem como o driver se comporta em cada um dos tipos de implantação, bem como como forçar um comportamento específico, ignorando a detecção automática do tipo de implantação.

Observe que a detecção do tipo de sistema acontece quando o driver recebe a primeira resposta de qualquer um dos servidores aos quais é instruído a se conectar (a menos que o modo de balanceamento de carga seja solicitado, consulte abaixo). O driver permanecerá na topologia descoberta ou configurada mesmo que a implantação subjacente seja substituída por uma de um tipo diferente. Em particular, ao substituir um conjunto de réplicas por um cluster fragmentado no mesmo endereço, a instância do cliente deve ser recriada (por exemplo, reiniciando o aplicativo) para que ele se comunique com o cluster fragmentado.

Atualmente, a descoberta automática de sistemas com balanceamento de carga não é suportada. As implantações com carga balanceada serão tratadas como implantações de seu tipo subjacente, que geralmente seriam clusters fragmentados. O driver não funcionará corretamente ao tratar uma implantação com balanceamento de carga como um cluster fragmentado; portanto, quando a implantação é com balanceamento de carga, o cliente deve ser explicitamente configurado para se conectar a um balanceador de carga.

Mongo::Client.new([ '127.0.0.1:27017' ], database: 'mydb')
Mongo::Client.new([ '127.0.0.1:27017', '127.0.0.1:27018' ], database: 'mydb')
# Or using the URI syntax:
Mongo::Client.new("mongodb://127.0.0.1:27017,127.0.0.1:27018/mydb")

Mongo::Client.new([ '127.0.0.1:27017', '127.0.0.1:27018' ],
  database: 'mydb', replica_set: 'myapp')
# Or using the URI syntax:
Mongo::Client.new("mongodb://127.0.0.1:27017,127.0.0.1:27018/mydb?replicaSet=myapp")

Mongo::Client.new([ '127.0.0.1:27017', '127.0.0.1:27018' ],
  database: 'mydb', connect: :replica_set)
# Or using the URI syntax:
Mongo::Client.new("mongodb://127.0.0.1:27017,127.0.0.1:27018/mydb?connect=replica_set")

Mongo::Client.new("mongodb+srv://username:myRealPassword@cluster0.mongodb.net/test?w=majority")

Mongo::Client.new([ '1.2.3.4:27017', '1.2.3.5:27017' ], database: 'mydb')
Mongo::Client.new("mongodb://1.2.3.4:27017,1.2.3.5:27017/mydb")

Mongo::Client.new("mongodb+srv://username:myRealPassword@cluster0.mongodb.net/test?w=majority")

Mongo::Client.new([ '127.0.0.1:27017', '127.0.0.1:27018' ],
  database: 'mydb', connect: :sharded)
# Or using the URI syntax:
Mongo::Client.new("mongodb://127.0.0.1:27017,127.0.0.1:27018/mydb?connect=sharded")

Mongo::Client.new([ '1.2.3.4:27017' ], database: 'mydb', direct_connection: true)
# Or using the URI syntax:
Mongo::Client.new("mongodb://1.2.3.4:27017/mydb?directConnection=true")

Mongo::Client.new([ '1.2.3.4:27017' ], database: 'mydb', connect: :direct)
# Or using the URI syntax:
Mongo::Client.new("mongodb://1.2.3.4:27017/mydb?connect=direct")

Mongo::Client.new([ '1.2.3.4:27017' ], database: 'mydb', load_balanced: true)
# Or using the URI syntax:
Mongo::Client.new("mongodb://1.2.3.4:27017/mydb?loadBalanced=true")

Mongo::Client.new([ '1.2.3.4:27017' ],
  database: 'mydb', load_balanced: true, connect: :load_balanced)
# Or using the URI syntax:
Mongo::Client.new("mongodb://1.2.3.4:27017/mydb?loadBalanced=true&connect=load_balanced")

require 'mongo'
# Replace the placeholders with your credentials
uri = "mongodb+srv://<username>:<password>@cluster0.sample.mongodb.net/?retryWrites=true&w=majority"
# Set the server_api field of the options object to Stable API version 1
options = { server_api: { version: "1" } }
# Create a new client and connect to the server
client = Mongo::Client.new(uri, options)
# Send a ping to confirm a successful connection
begin
  admin_client = client.use('admin')
  result = admin_client.database.command(ping: 1).documents.first
  puts "Pinged your deployment. You successfully connected to MongoDB!"
rescue Mongo::Error::OperationFailure => ex
  puts ex
ensure
  client.close
end

Notas de URI do SRV

Quando o driver se conecta a um URI de protocolo mongodb+srv , lembre-se do seguinte:

1. A pesquisa de URI do SRV é realizada de forma síncrona quando o cliente é construído. Se essa pesquisa falhar por algum motivo, a construção do cliente falhará com uma exceção. Quando um cliente é construído com uma lista de hosts, o driver tentará entrar em contato e monitorar esses hosts enquanto o objeto do cliente existir. Se um desses hosts não for resolvido inicialmente, mas puder ser resolvido mais tarde, o driver poderá estabelecer uma conexão com esse host quando ele ficar disponível. A pesquisa inicial do URI do SRV deve ser bem-sucedida na primeira tentativa; pesquisas de host subsequentes serão repetidas pelo driver conforme necessário.

2. O driver procura opções de URI nos registros TXT do DNS correspondentes aos registros SRV. Essas opções podem ser substituídas pelas opções de URI especificadas no URI e pelas opções Ruby, nessa ordem.

3. Como as opções de URI são recuperadas em uma query de DNS separada da pesquisa de SRV, em ambientes com conectividade de rede não confiável, a query de opção de URI pode falhar quando a pesquisa de SRV for bem-sucedida. Essa falha faria com que o driver usasse a fonte de autenticação errada, levando a falhas de autenticação. Isso pode ser resolvido especificando explicitamente a fonte de autenticação:

   Mongo::Client.new("mongodb+srv://username:myRealPassword@cluster0.mongodb.net/test?w=majority&authSource=admin")

4. Se a topologia do objeto Client construído for desconhecida ou for um cluster fragmentado, o driver começará a monitorar os registros DNS SRV especificados em busca de alterações e atualizará automaticamente a lista de servidores no cluster. As atualizações serão interrompidas se a topologia se tornar única ou um conjunto de réplicas.

Opções do cliente

Mongo::Cliento construtor do aceita uma série de opções que configuram o comportamento do driver. As opções podem ser fornecidas no hash de opções como opções Ruby, no URI como opções de URI ou ambos. Se uma opção Ruby e a opção análoga URI forem fornecidas, a opção Ruby terá precedência.

{ read:
  { mode: :secondary,
    tag_sets: [ "data_center" => "berlin" ],
    max_staleness: 5,
  }
}

{ write_concern: { w: 2 } }

Opções de tempo limite

Conexões TLS

Para se conectar ao MongoDB deployment usando TLS:

• Ative conexões TLS em Mongo::Client.

• Especifique o certificado TLS do cliente.

• Especifique o certificado CA para verificar o certificado TLS do servidor.

client = Mongo::Client.new(["localhost:27017"],
  ssl: true,
  ssl_cert: 'path/to/client.crt',
  ssl_key: 'path/to/client.key',
  ssl_ca_cert: 'path/to/ca.crt',
)

client = Mongo::Client.new(["localhost:27017"],
  ssl: true,
  ssl_cert: 'path/to/client.pem',
  ssl_key: 'path/to/client.pem',
  ssl_ca_cert: 'path/to/ca.crt',
)

client = Mongo::Client.new(
  "mongodb://localhost:27017/?tls=true&tlsCertificateKeyFile=path%2fto%2fclient.pem&tlsCertificateKeyFile=path%2fto%2fca.crt")

Mongo.tls_context_hooks.push(
  Proc.new { |context|
    context.ciphers = ["AES256-SHA"]
  }
)
# Only the AES256-SHA cipher will be enabled from this point forward

Conexões IPv4/IPv6

Quando um cliente é construído com localhost como o nome do host, ele tentará uma conexão IPv4 somente (ou seja, se localhost resolver para 127.0.0.1 e ::1, o driver tentará se conectar apenas a 127.0.0.1).

Quando um cliente é construído com nomes de host diferentes de localhost, ele tentará as conexões IPv4 e IPv6, dependendo dos endereços para os quais os nomes de host são resolvidos. O driver respeita a ordem em que getaddrinfo retorna os endereços e tentará se conectar a eles sequencialmente. A primeira conexão bem-sucedida será usada.

Atualmente, o driver não implementa o algoritmoHappyEeballs.

Configuração de manutenção de atividade TCP

Quando permitido pela configuração do sistema e pelo tempo de execução da linguagem Ruby, o driver habilita a manutenção de atividade TCP e, para cada um dos parâmetros de manutenção listados abaixo, define o valor do respectivo parâmetro para o valor especificado se o valor do sistema puder ser determinado e for maior que o valor do driver listado:

• tcp_keepalive_time: 120 segundos

• tcp_keepalive_intvl: 10 segundos

• tcp_keepalive_cnt: 9 sondas

Para usar valores mais baixos ou alterar os parâmetros em ambientes como o JRuby que não expõem as APIs necessárias, ajuste os parâmetros no nível do sistema, conforme descrito na seção de manutenção de atividade das Perguntas frequentes do MongoDB Diagnostics.

Pool de conexões

Mongo::Client instâncias têm um pool de conexões por servidor ao qual o cliente está conectado. O pool cria conexões sob demanda para dar suporte às operações simultâneas do MongoDB emitidas pelo aplicativo. Não há afinidade de thread para conexões.

A instância do cliente abre uma conexão adicional por servidor conhecido para monitorar o estado do servidor.

O tamanho de cada pool de conexões é limitado a max_pool_size, que o padrão é 5. Quando um thread no aplicativo inicia uma operação no MongoDB, ele tenta recuperar uma conexão do pool para enviar essa operação. Se houver algumas conexões disponíveis no pool, ele verificará uma conexão do pool e a usará para a operação. Se não houver conexões disponíveis e o tamanho do pool for menor que max_pool_size, uma nova conexão será criada. Se todas as conexões estiverem em uso e o pool tiver atingido seu tamanho máximo, o thread aguardará que uma conexão seja retornada ao pool por outro thread. Se max_pool_size estiver definido como zero, não haverá limite para o número máximo de conexões no pool.

Cada pool tem um limite de número de conexões que podem se conectar simultaneamente a um servidor. Esse limite é chamado de max_connecting e o padrão é 2. Se o número de conexões que estão se conectando a um servidor atingir esse limite, o pool aguardará que uma tentativa de conexão seja bem-sucedida ou falhe antes de tentar criar uma nova conexão. Se o seu aplicativo tiver um grande número de threads, talvez você queira aumentar max_connecting para evitar que os threads aguardem o estabelecimento de uma conexão.

O número de segundos que a thread aguardará até que uma conexão fique disponível é configurável. Esta configuração, chamada wait_queue_timeout, é definida em segundos. Se esse tempo limite for atingido, um Timeout::Error será gerado. O padrão é 1 segundo.

A partir da versão 2.11 do driver, o driver cria conexões até a configuração min_pool_size . Antes da versão 2.11 do driver, o driver sempre criava conexões sob demanda. Em todas as versões do driver, depois que uma conexão for estabelecida, ela será mantida no pool pelo driver, desde que o tamanho do pool não exceda min_pool_size.

Observe que, se min_pool_size estiver definido para um valor maior que zero, o driver estabelecerá esse número de conexões com secundários em sistemas de conjuntos de réplicas, mesmo que o aplicativo não execute leituras secundárias. O objetivo dessas conexões é fornecer failover mais rápido quando o primário muda.

Veja um exemplo de estimativa do número de conexões que um aplicativo multithread abrirá: Um cliente conectado a um conjunto de réplicas de 3 nós abre 3 soquetes de monitoramento. Ele também abre quantos soquetes forem necessários para oferecer suporte às operações simultâneas de um aplicativo multithread em cada servidor, até max_pool_size . Se o aplicativo usar apenas o primário (o padrão), somente o pool de conexões primárias crescerá e o total de conexões será de no máximo 8 (5 conexões para o pool primário + 3 conexões de monitoramento). Se o aplicativo usar uma read preference para consultar os secundários, seus pools também crescerão e o total de conexões poderá chegar a 18 (5 + 5 + 5 + 3).

A configuração padrão de um Mongo::Client funciona para a maioria dos aplicativos:

client = Mongo::Client.new(["localhost:27017"])

Crie este cliente uma vez para cada processo e reutilize-o para todas as operações. É um erro comum criar um novo cliente para cada solicitação, o que é muito ineficiente e não é para isso que o cliente foi projetado.

Para suportar um número extremamente alto de operações simultâneas do MongoDB em um processo, aumente max_pool_size:

client = Mongo::Client.new(["localhost:27017"], max_pool_size: 200)

Para oferecer suporte a um número extremamente alto de threads que compartilham o mesmo cliente em um processo, aumente max_connecting:

client = Mongo::Client.new(["localhost:27017"], max_pool_size: 200, max_connecting: 10)

Qualquer número de threads pode aguardar a disponibilidade das conexões e pode aguardar a configuração padrão (1 segundo) ou wait_queue_timeout :

client = Mongo::Client.new(["localhost:27017"], wait_queue_timeout: 0.5)

Quando #close é chamado em um cliente por qualquer thread, todas as conexões são fechadas:

client.close

Observe que, ao criar um cliente usando a sintaxe de bloco descrita acima, o cliente é automaticamente fechado após o término da execução do bloco.

Uso com servidores forking

Ao usar o mongo Ruby driver em um aplicativo Web com um servidor Web de bifurcação, como o Puma, ou quando o aplicativo de outra forma bifurca, cada processo (pai e filho) deve ter suas próprias conexões de cliente. Isso ocorre porque:

1. Os threads Ruby em segundo plano, como aqueles usados pelo driver Ruby MongoDB para monitorar o estado da conexão, não são transferidos para o processo filho.

2. Descritores de arquivo, como soquetes de rede, são compartilhados entre processos pai e filho, o que pode causar conflitos de E/S.

Em relação (1), se você não reiniciar os threads de monitoramento do driver no processo filho após a bifurcação, embora seu filho possa inicialmente parecer funcionar corretamente, você eventualmente verá Mongo::Error::NoServerAvailable exceções se/quando o estado do cluster MongoDB mudar, por exemplo , devido a erros de rede ou um evento de manutenção.

Em relação ao 2, se um processo filho reutilizar os descritores de arquivo dos pais, você verá Mongo::Error::SocketError erros com mensagens como Errno::EPIPE: Broken pipe e EOFError: end of file reached.

Quando o driver Ruby for usado em um aplicação da web, se possível, recomendamos não criar nenhuma instância Mongo::Client no processo pai (antes da bifurcação dos funcionários) e, em vez disso, criar apenas instâncias de cliente nos funcionários.

# Immediately before fork
client.close

# Immediately after fork
client.reconnect

client.summary
=> "#<Client cluster=#<Cluster
  topology=ReplicaSetWithPrimary[localhost:14420,localhost:14421,localhost:14422,localhost:14423,name=ruby-driver-rs,v=1,e=7fffffff000000000000001f]
  servers=[#<Server address=localhost:14420 PRIMARY replica_set=ruby-driver-rs pool=#<ConnectionPool size=0 (0-5) used=0 avail=0 pending=0>>,
    #<Server address=localhost:14421 SECONDARY replica_set=ruby-driver-rs pool=#<ConnectionPool size=0 (0-5) used=0 avail=0 pending=0>>,
    #<Server address=localhost:14422 SECONDARY replica_set=ruby-driver-rs pool=#<ConnectionPool size=0 (0-5) used=0 avail=0 pending=0>>,
    #<Server address=localhost:14423 ARBITER replica_set=ruby-driver-rs>]>>"

client.summary
=> "#<Client cluster=#<Cluster
  topology=ReplicaSetWithPrimary[localhost:14420,localhost:14421,localhost:14422,localhost:14423,name=ruby-driver-rs,v=1,e=7fffffff000000000000001f]
  servers=[#<Server address=localhost:14420 PRIMARY replica_set=ruby-driver-rs NO-MONITORING pool=#<ConnectionPool size=0 (0-5) used=0 avail=0 pending=0>>,
    #<Server address=localhost:14421 SECONDARY replica_set=ruby-driver-rs NO-MONITORING pool=#<ConnectionPool size=0 (0-5) used=0 avail=0 pending=0>>,
    #<Server address=localhost:14422 SECONDARY replica_set=ruby-driver-rs NO-MONITORING pool=#<ConnectionPool size=0 (0-5) used=0 avail=0 pending=0>>,
    #<Server address=localhost:14423 ARBITER replica_set=ruby-driver-rs>]>>"

Leituras repetíveis

O driver implementa dois mecanismos para tentar ler novamente: moderno e legado. A partir da versão 2.9.0 do driver, o mecanismo moderno é usado por padrão e o mecanismo legado é preterido.

Gravações repetíveis

O driver implementa dois mecanismos para tentar novamente as gravações: moderno e legado. A partir da versão 2.9.0 do driver, o mecanismo moderno é usado por padrão em servidores que o suportam, e o mecanismo legado é preterido e desabilitado por padrão em todas as versões do servidor.

Os seguintes métodos de gravação usados nas operações diárias em collection estão sujeitos a novas tentativas de gravação:

• collection#insert_one

• collection#update_one

• collection#delete_one

• collection#replace_one

• collection#find_one_and_update

• collection#find_one_and_replace

• collection#find_one_and_delete

• collection#bulk_write (para todas as operações de declaração única, ou seja, não para update_many ou delete_many)

Exploração madeireira

Você pode usar o registrador de driver global padrão ou definir o seu. Para definir o seu:

Mongo::Logger.logger = other_logger

Consulte a documentação do Ruby Logger para obter mais informações sobre a API padrão do registrador e os níveis disponíveis.

Mongo::Logger.logger.level = Logger::WARN

my_logger = Logger.new(STDOUT)
Mongo::Client.new([ '127.0.0.1:27017' ], :database => 'test', :logger => my_logger )

Mongo::Client.new([ '127.0.0.1:27017' ], :database => 'test', :truncate_logs => false )

Compressão

Para usar a compactação de protocolo de conexão, pelo menos um compressor deve ser explicitamente solicitado usando a opção Ruby :compressors ou a opção compressors URI. Se nenhum compressor for explicitamente solicitado, o driver não usará a compressão, mesmo que as dependências necessárias para um ou mais compressores estejam presentes no sistema.

O driver escolhe o primeiro compressor dos solicitados que também é suportado pelo servidor. Atualmente, o driver suporta os compressores zstd, snappy e zlib . O compressor zstd é recomendado, pois produz a maior compressão com o mesmo consumo de CPU em comparação com os outros compressores. Para compatibilidade máxima do servidor, todos os três compressores podem ser especificados, por exemplo, como compressors: ["zstd", "snappy", "zlib"].

zstd compressor requer o zstd-ruby biblioteca a ser instalada. snappy O compressor requer o snappy biblioteca a ser instalada. Se a compactação zstd ou snappy for solicitada e a respectiva biblioteca não for carregável, o driver gerará um erro durante a criação do Mongo::Client . A compactação zlib requer que a extensão de biblioteca padrão zlib esteja presente.

O suporte do servidor para vários compressores é o seguinte:

• zstd exige e é habilitado por padrão no MongoDB 4.2 ou superior.

• snappy requer MongoDB 3.4 ou superior e está habilitado por padrão no MongoDB 3.6 ou superior.

• zlib requer MongoDB 3.6 ou superior e é habilitado por padrão no MongoDB 4.2 e superior.

Parâmetros da API do servidor

A partir do MongoDB 5.0, os aplicativos podem solicitar que o servidor se comporte de acordo com uma versão específica da API do servidor.

Os parâmetros da API do servidor podem ser especificados por meio da opção :server_api para Client. Esses parâmetros não podem ser fornecidos por meio de um URI.

Atualmente, a única versão de API definida é "1". Ele pode ser solicitado da seguinte forma:

client = Mongo::Client.new(['localhost'], server_api: {version: "1"})

MongoDB Server define versões da API como valores de string. Para conveniência, se a versão da API for fornecida como um número inteiro, o driver Ruby a stringificará e a enviará ao servidor como uma string:

client = Mongo::Client.new(['localhost'], server_api: {version: 1})

Observe que o servidor pode definir versões de API que não são inteiras em string. Os aplicativos não devem presumir que todas as versões legais da API podem ser expressas como números inteiros.

Quando uma determinada versão de API é solicitada, as operações que fazem parte dessa versão da API se comportam conforme especificado nessa versão da API. As operações que não fazem parte da versão de API especificada se comportam como se a versão de API não tivesse sido especificada. As operações cujo comportamento está sujeito à versão da API configurada são comandos, incluindo argumentos de comando, query, estágios de pipeline de agregação e argumentos.

Os aplicativos podem solicitar que o servidor rejeite todas as operações que não fazem parte da versão da API especificada definindo a opção :strict :

client = Mongo::Client.new(['localhost'], server_api: {version: "1", strict: true})

Por exemplo, como a opção :tailable não faz parte da API do servidor versão 1, a seguinte query falharia:

client = Mongo::Client.new(['localhost'], server_api: {version: "1", strict: true})
client['collection'].find({}, tailable: true)
# => Mongo::Error::OperationFailure (BSON field 'FindCommand.tailable' is not allowed with apiStrict:true. (323) (on localhost:27017, modern retry, attempt 1))

Os aplicativos podem solicitar que o servidor rejeite todas as operações que estão obsoletas na versão da API especificada, configurando a opção :deprecation_errors :

client = Mongo::Client.new(['localhost'], server_api: {version: "1", deprecation_errors: true})

Observe que, no momento em que este artigo foi escrito, não há operações obsoletas na versão "1" da API.

Se os parâmetros da API do servidor tiverem sido definidos em um objeto Client , eles serão enviados pelo cliente como parte de cada operação executada [1] .

O MongoDB Server anterior ao 5.0 não reconhece os parâmetros da API e produzirá uma variedade de erros caso a aplicação os configure. O driver Ruby enviará os parâmetros de API para todos os servidores do MongoDB 3.6 e mais recentes, mas os parâmetros da API só devem ser configurados quando o aplicativo estiver se comunicando com os servidores do MongoDB 5.0 ou mais recentes. Os parâmetros da API não podem ser enviados para servidor MongoDB 3.4 e mais antigos que usam o protocolo de conexão legado; se uma aplicação configurar os parâmetros da API e se conectar ao MongoDB 3.4 ou servidor mais antigos, o driver produzirá um erro em cada operação.

O auxiliar de comando permite que o aplicativo envie comandos construídos manualmente para o servidor. Se o cliente não estiver configurado com parâmetros de API do servidor, o auxiliar de comando poderá ser usado para emitir comandos com parâmetros de API:

client.database.command(
  ping: 1,
  apiVersion: "1",
  apiStrict: false,
  apiDeprecationErrors: false,
)

Se o cliente estiver configurado com parâmetros de API do servidor, o auxiliar de comando não poderá ser usado para emitir comandos com parâmetros de API do servidor. Isso inclui o caso em que os parâmetros da API do servidor fornecidos ao cliente e ao auxiliar de comando são idênticos. Se um cliente for construído com parâmetros de API do servidor, para enviar parâmetros de API diferentes (ou nenhum), um novo cliente deverá ser construído, do zero ou usando o método with .

Os parâmetros da API do servidor só podem ser especificados no nível do cliente. Eles não podem ser especificados no reconhecimento de data center, collection, sessão, transação ou nível de operação individual.

Configuração de desenvolvimento

A configuração padrão do impulsionador é adequada para o sistema de produção. Em desenvolvimento, algumas configurações podem ser ajustadas para proporcionar uma melhor experiência ao desenvolvedor.

• :server_selection_timeout: defina isso como um valor baixo (por exemplo, 1) se o servidor MongoDB estiver sendo executado localmente e você o iniciar manualmente. Um tempo limite de seleção de servidor baixo fará com que o driver falhe rapidamente quando não houver nenhum servidor em execução.

Configuração de produção

Considere o seguinte ao implantar um aplicativo usando o driver Ruby na produção:

• A partir da versão 2.11 do driver, a opção :min_pool_size do cliente é totalmente respeitada - o driver criará esse número de conexões para cada servidor identificado como autônomo, primary ou secundário. Nas versões anteriores do driver, o driver criava conexões sob demanda. Os aplicativos que usam :min_pool_size verão um aumento no número de conexões ociosas em todos os servidores a partir da versão 2.11 do driver e, especialmente, nos secundários em implantações de conjuntos de réplicas e nos nós em clusters fragmentados.

• Se o aplicativo for submetido a proxy reverso por outro servidor da web ou um balanceador de carga, server_selection_timeout geralmente deve ser definido como um valor mais baixo do que o tempo limite de leitura do proxy reverso. Por exemplo, otempo limite da 30 solicitação do Herói é segundos e não é configurável; se implantar um aplicativo Ruby usando MongoDB no Herói, considere reduzir o tempo limite de seleção do servidor para 20 ou 15 segundos.

Sinalizadores de recursos

A seguir está uma lista de sinalizadores de recursos que o mongo Ruby Driver fornece:

Estes sinalizadores de feição podem ser definidos diretamente no módulo Mongo ou utilizando o método options :

Mongo.validate_update_replace = true
Mongo.options = { validate_update_replace: true }