Como configurar o driver MongoDB Java MongoOptions para uso em produção?

Atualizado para 2.9:

autoConnectRetry simplesmente significa que o driver tentará automaticamente se reconectar ao(s) servidor(es) após desconexões inesperadas. Em ambientes de produção, você geralmente deseja que isso seja definido como true.
conexõesPorHost são a quantidade de conexões físicas que uma única instância do Mongo (é singleton, então você geralmente tem uma por aplicativo) pode estabelecer para um processo mongod/mongos. No momento da escrita, o driver java estabelecerá essa quantidade de conexões eventualmente, mesmo que a taxa de transferência real da consulta seja baixa (em outras palavras, você verá a estatística "conn" no mongostat aumentar até atingir esse número por servidor de aplicativo).

Não há necessidade de definir isso acima de 100 na maioria dos casos, mas essa configuração é uma daquelas coisas "teste e veja". Observe que você terá que definir isso baixo o suficiente para que a quantidade total de conexões com seu servidor não exceda

db.serverStatus().connections.available

Em produção, atualmente temos isso em 40.
connectTimeout . Como o nome sugere, o número de milissegundos que o driver aguardará antes que uma tentativa de conexão seja abortada. Defina o tempo limite para algo longo (15 a 30 segundos), a menos que haja uma chance realista e esperada de que isso atrapalhe as tentativas de conexão bem-sucedidas. Normalmente, se uma tentativa de conexão demorar mais de alguns segundos, sua infraestrutura de rede não é capaz de alta taxa de transferência.
maxWaitTime . Número de ms que um thread aguardará até que uma conexão fique disponível no pool de conexões e gera uma exceção se isso não acontecer a tempo. Mantenha o padrão.
socketTimeout . Valor de tempo limite do soquete padrão. Defina para 60 segundos (60.000).
threadsAllowedToBlockForConnectionMultiplier . Multiplicador para connectionsPerHost que denota o número de encadeamentos que podem aguardar até que as conexões fiquem disponíveis se o pool estiver esgotado no momento. Esta é a configuração que causará a exceção "com.mongodb.DBPortPool$SemaphoresOut:Semáforos para obter conexão db". Ele lançará essa exceção quando essa fila de threads exceder o valor de threadsAllowedToBlockForConnectionMultiplier. Por exemplo, se o connectionsPerHost for 10 e esse valor for 5, até 50 threads podem ser bloqueados antes que a exceção mencionada acima seja lançada.

Se você espera grandes picos na taxa de transferência, isso pode fazer com que grandes filas aumentem temporariamente esse valor. Nós o temos em 1500 no momento exatamente por esse motivo. Se sua carga de consulta ultrapassar consistentemente o servidor, você deve apenas melhorar sua situação de hardware/escalonamento de acordo.
readPreference . (ATUALIZADO, 2.8+) Usado para determinar a preferência de leitura padrão e substitui "slaveOk". Configure um ReadPreference por meio de um dos métodos de fábrica de classes. Uma descrição completa das configurações mais comuns pode ser encontrada no final desta postagem
s . (ATUALIZADO, 2.6+) Este valor determina a "segurança" da gravação. Quando esse valor for -1, a gravação não relatará nenhum erro, independentemente de erros de rede ou banco de dados. WriteConcern.NONE é o WriteConcern predefinido apropriado para isso. Se w for 0, os erros de rede farão com que a gravação falhe, mas os erros do mongo não. Isso geralmente é chamado de gravações "dispare e esqueça" e deve ser usado quando o desempenho é mais importante do que a consistência e a durabilidade. Use WriteConcern.NORMAL para este modo.

Se você definir w para 1 ou superior, a gravação será considerada segura. As gravações seguras executam a gravação e a seguem por uma solicitação ao servidor para certificar-se de que a gravação foi bem-sucedida ou recuperar um valor de erro se não tiver (em outras palavras, ele envia um comando getLastError() após a gravação). Observe que até que este comando getLastError() seja concluído, a conexão é reservada. Como resultado disso e do comando adicional, a taxa de transferência será significativamente menor do que as gravações com w <=0. Com um valor w de exatamente 1, o MongoDB garante que a gravação foi bem-sucedida (ou falhou comprovadamente) na instância para a qual você enviou a gravação.

No caso de conjuntos de réplicas, você pode usar valores mais altos para w que dizem ao MongoDB para enviar a gravação para pelo menos "w" membros do conjunto de réplicas antes de retornar (ou mais precisamente, aguarde a replicação de sua gravação para membros "w" ). Você também pode definir w para a string "majority" que diz ao MongoDB para executar a gravação na maioria dos membros do conjunto de réplicas (WriteConcern.MAJORITY). Normalmente, você deve definir isso como 1, a menos que precise de desempenho bruto (-1 ou 0) ou gravações replicadas (> 1). Valores superiores a 1 têm um impacto considerável na taxa de transferência de gravação.
fsync . Opção de durabilidade que força o mongo a liberar para o disco após cada gravação quando ativado. Eu nunca tive problemas de durabilidade relacionados a um backlog de gravação, então temos isso em false (o padrão) em produção.
j *(NOVO 2.7+) *. Boolean que, quando definido como true, força o MongoDB a aguardar uma confirmação bem-sucedida do grupo de registro no diário antes de retornar. Se você tiver o registro no diário ativado, poderá habilitá-lo para maior durabilidade. Consulte http://www.mongodb.org/display/DOCS/Journaling para ver o que o journaling traz para você (e, portanto, por que você pode querer habilitar esse sinalizador).

ReadPreference A classe ReadPreference permite configurar para quais instâncias do mongod as consultas são roteadas se você estiver trabalhando com conjuntos de réplicas. As seguintes opções estão disponíveis:

ReadPreference.primary() :Todas as leituras vão apenas para o membro primário do repset. Use isso se você precisar que todas as consultas retornem dados consistentes (os gravados mais recentemente). Este é o padrão.
ReadPreference.primaryPreferred() :Todas as leituras vão para o membro primário do repset, se possível, mas podem consultar os membros secundários se o nó primário não estiver disponível. Como tal, se o primário ficar indisponível, as leituras se tornarão eventualmente consistentes, mas somente se o primário estiver indisponível.
ReadPreference.secondary() :todas as leituras vão para membros de repset secundários e o membro primário é usado apenas para gravações. Use isso apenas se você puder conviver com leituras eventualmente consistentes. Membros de repset adicionais podem ser usados para aumentar o desempenho de leitura, embora haja limites para a quantidade de membros (votantes) que um repset pode ter.
ReadPreference.secondaryPreferred() :Todas as leituras vão para os membros secundários do repset se algum deles estiver disponível. O membro primário é usado exclusivamente para gravações, a menos que todos os membros secundários fiquem indisponíveis. Além do fallback para o membro primário para leituras, é o mesmo que ReadPreference.secondary().
ReadPreference.nearest() :As leituras vão para o membro repset mais próximo disponível para o cliente de banco de dados. Use somente se leituras eventualmente consistentes forem aceitáveis. O membro mais próximo é o membro com a menor latência entre o cliente e os vários membros do repset. Como membros ocupados eventualmente terão latências mais altas, isso deveria também equilibra automaticamente a carga de leitura, embora, na minha experiência, o secundário (preferencial) pareça fazê-lo melhor se as latências dos membros forem relativamente consistentes.

Observação:todos os itens acima têm versões habilitadas para tags do mesmo método que retornam instâncias TaggableReadPreference. Uma descrição completa das tags de conjunto de réplicas pode ser encontrada aqui:Tags de conjunto de réplicas