Comment configurer MongoDB Java driver MongoOptions pour une utilisation en production?

Mis à jour à 2.9:

• AutoConnectRetry signifie simplement que le pilote tentera automatiquement de se reconnecter au(X) serveur (s) après des déconnexions inattendues. Dans les environnements de production, vous voulez généralement que cet ensemble soit true.

• ConnectionsPerHost {[7] } sont la quantité de connexions physiques qu'une seule instance Mongo (c'est singleton donc vous en avez généralement une par application) peut établir à un processus mongod/mongos. Au moment de l'écriture, le pilote java établissez cette quantité de connexions éventuellement même si le débit de requête réel est faible (dans les mots d'ordre, vous verrez la statistique" conn " dans mongostat augmenter jusqu'à ce qu'elle atteigne ce nombre par serveur d'applications).

  Il N'est pas nécessaire de définir ce paramètre supérieur à 100 dans la plupart des cas, mais ce paramètre est l'un de ces "tester et voir" choses. Notez que vous devrez vous assurer que vous définissez ce niveau suffisamment bas pour que le nombre total de connexions à votre serveur ne dépasse pas

  db.serverStatus().connections.available

  Dans production nous avons actuellement cela à 40.

• ConnectTimeout. Comme son nom l'indique, le pilote attendra avant qu'une tentative de connexion ne soit annulée. Définissez timeout sur quelque chose de long (15-30 secondes)à moins qu'il n'y ait une chance réaliste et attendue que cela entrave les tentatives de connexion réussies. Normalement si une tentative de connexion prend plus de quelques secondes votre infrastructure réseau n'est pas capable de débit.

• MaxWaitTime. Nombre de ms un thread attendra qu'une connexion soit disponible sur le pool de connexions, et déclenche une exception si cela ne se produit pas à temps. Conserver par défaut.

• SocketTimeout. Standard socket timeout valeur. Réglé sur 60 secondes (60000).

• ThreadsAllowedToBlockForConnectionmultiplier. Multiplicateur pour connectionsPerHost qui indique le nombre de threads autorisés à attendre les connexions deviennent disponibles si la piscine est actuellement épuisé. C'est le paramètre qui provoquera le " com.mongodb.DBPortPool $ SemaphoresOut: hors de sémaphores pour obtenir la connexion db" exception. Il lancera cette exception une fois que cette file d'attente de threads dépasse la valeur threadsAllowedToBlockForConnectionmultiplier. Par exemple, si connectionsPerHost est 10 et que cette valeur est 5, jusqu'à 50 threads peuvent bloquer avant que l'exception susmentionnée ne soit levée.

  Si vous attendez de grands pics le débit qui pourrait provoquer de grandes files d'attente augmente temporairement cette valeur. Nous l'avons à 1500 en ce moment pour exactement cette raison. Si votre charge de requête dépasse systématiquement le serveur, vous devez simplement améliorer votre situation matérielle/mise à l'échelle en conséquence.

• ReadPreference. (mis à jour, 2.8+) utilisé pour déterminer la préférence de lecture par défaut et remplace "slaveOk". Configurez un ReadPreference via l'une des méthodes de classe factory. Une description complète de la les paramètres les plus courants peuvent être trouvés à la fin de ce post

• W. (mis à jour, 2.6+) cette valeur détermine la "sécurité" de l'écriture. Lorsque cette valeur est -1, l'écriture ne signale aucune erreur indépendamment des erreurs de réseau ou de base de données. WriteConcern.NONE est le WriteConcern prédéfini approprié pour cela. Si w vaut 0, les erreurs réseau feront échouer l'écriture, mais pas les erreurs mongo. Ceci est généralement appelé "feu et oublier" écrit et doit être utilisé lorsque la performance est plus importante que la cohérence et la durabilité. Utilisez WriteConcern.NORMAL pour ce mode.

  Si vous définissez w à 1 ou plus l'écriture est considérée comme sûre. Safe writes effectuez l'écriture et suivez-la par une requête au serveur pour vous assurer que l'écriture a réussi ou récupérer une valeur d'erreur si ce n'est pas le cas (en d'autres termes, il envoie une commande GetLastError() après avoir écrit). Notez que jusqu'à ce que cette commande getLastError() soit terminée, la connexion est réservée. En tant que résultat de cela et de la commande supplémentaire, le débit sera signficantly inférieur à celui des Écritures avec w

  Dans le cas des jeux de répliques, vous pouvez utiliser des valeurs plus élevées pour w qui indiquent à MongoDB d'envoyer L'écriture à au moins les membres " w "du jeu de répliques avant de retourner (ou plus précisément, attendez la réplication de votre écriture aux membres" w"). Vous pouvez également définissez w sur la chaîne "majority" qui indique à MongoDB d'effectuer l'écriture sur la majorité des membres du jeu de répliques (WriteConcern.MAJORITÉ). Typicall vous devez définir ceci à 1 sauf si vous avez besoin de performances brutes (-1 ou 0) ou d'Écritures répliquées (>1). Les valeurs supérieures à 1 ont un impact considérable sur le débit d'écriture.

• Fsync. Option de durabilité qui force mongo à vider sur le disque après chaque écriture lorsqu'elle est activée. Je n'ai jamais eu de problèmes de durabilité liés à un backlog d'écriture donc nous avons ceci sur false (la valeur par défaut) en production.

• J *(NOUVEAU 2.7+)*. Booléen que lorsqu'il est défini sur true force MongoDB à attendre une validation de groupe de journalisation réussie avant de revenir. Si vous avez activé la journalisation, vous pouvez l'activer pour une durabilité supplémentaire. Voir http://www.mongodb.org/display/DOCS/Journaling pour voir ce que la journalisation vous obtient (et donc pourquoi vous pourriez vouloir activer ceci drapeau).

ReadPreference La classe ReadPreference vous permet de configurer les requêtes des instances mongod qui sont routées si vous travaillez avec des jeux de réplicas. Les options suivantes sont disponibles :

• ReadPreference.primary () : Toutes les lectures vont au membre principal repset uniquement. Utilisez ceci si vous avez besoin que toutes les requêtes renvoient des données cohérentes (les plus récemment écrites). C'est le défaut.

• ReadPreference.primaryPreferred () : Toutes les lectures vont au membre principal repset si possible, mais peuvent interroger les membres secondaires si le nœud principal n'est pas disponible. En tant que tel, si le primaire devient indisponible, les lectures deviennent finalement cohérentes, mais seulement si le primaire est indisponible.

• ReadPreference.secondary () : Toutes les lectures vont aux membres repset secondaires et le membre principal est utilisé pour les Écritures uniquement. Utilisez ceci seulement si vous pouvez vivre avec des lectures finalement cohérentes. Des membres repset supplémentaires peuvent être utilisés pour augmenter les performances de lecture, bien qu'il y ait des limites au nombre de membres (votants) qu'un repset peut avoir.

• ReadPreference.secondaryPreferred () : Toutes les lectures vont aux membres repset secondaires si l'un d'eux est disponible. Le membre principal est utilisé exclusivement pour les Écritures à moins que tous les membres secondaires ne deviennent indisponibles. Autre que le repli vers le membre principal pour les lectures ceci est le même que ReadPreference.secondaire().

• ReadPreference.nearest () : Lit aller au membre repset le plus proche disponible pour le client de base de données. Utilisez uniquement si des lectures cohérentes sont acceptables. Le membre le plus proche est le membre avec la latence la plus faible entre le client et les différents membres repset. Puisque les membres occupés auront éventuellement des latences plus élevées, devrait également équilibrer automatiquement la charge de lecture bien que dans mon expérience secondaire (préféré) semble faire donc, mieux si les latences des membres sont relativement cohérentes.

Note: toutes les versions ci-dessus ont tag enabled versions de la même méthode qui renvoient des instances TaggableReadPreference à la place. Une description complète des balises replica set peut être trouvée ici: balises Replica Set