2014-06-10 3 views
0

je suis nouveau dans la réplication mongo.Mongo ReplicaSet expliquer

J'ai deux serveurs et je définis un primaire sur un serveur et secondaire à l'autre.

Je développe une application web en utilisant spring et spring-data et j'utiliser cette configuration xml pour accéder à mongo:

<mongo:mongo id="mongoConnection" replica-set="IP-Primary:27017,IP-Secondary:27017"> 
     <mongo:options 
      connections-per-host="100" 
      threads-allowed-to-block-for-connection-multiplier="50" 
      connect-timeout="10000" 
      max-wait-time="50000" 
      slave-ok="true" 
      auto-connect-retry="true" 
      write-number="1" 
      write-timeout="0" 
      write-fsync="false"/> 
</mongo:mongo> 
<beans:bean id="mongoWriteConcern" class="com.mongodb.WriteConcern"> 
    <beans:constructor-arg type="int" name="w" value="2"/></beans:bean> 
<beans:bean id="mongoCredentials" 
    class="org.springframework.data.authentication.UserCredentials"> 
    <beans:constructor-arg name="username" value="xxx" /> 
    <beans:constructor-arg name="password" value="yyy" /> 
</beans:bean> 
<beans:bean id="myTemplate" 
    class="org.springframework.data.mongodb.core.MongoTemplate"> 
    <beans:constructor-arg ref="mongoConnection" /> 
    <beans:constructor-arg name="databaseName" value="dbName" /> 
    <beans:constructor-arg name="userCredentials" ref="mongoHotelCredentials" /> 
    <beans:property name="writeConcern" ref="mongoWriteConcern"/> 
</beans:bean> 

Peut-il vous plaît quelqu'un me expliquer ce qui est le flux sur le jeu de réplicas?

Il écrira d'abord sur le primaire et automatiquement l'écriture primaire au secondaire? Est-ce que le framework va vérifier la connexion réussie à chaque base de données et "élire" un primaire si le primaire actuel n'est pas disponible (donc élire secondaire comme primaire)? Si oui, que se passe-t-il lorsque le primaire reviendra?

Merci!

+0

Je voudrais commencer ici: http://docs.mongodb.org/manual/core/replication-introduction/ –

Répondre

2

flux de base de la réplication:

Votre application (client) écrit principal de l'ensemble de la réplique. Les opérations d'écriture sont stockées dans un fichier journal (oplog), et oplog réplique vers des fichiers secondaires soit par 'réplication chaînée' (par défaut) ou réplique du membre le plus proche, configurable, lisez ici http://docs.mongodb.org/manual/tutorial/manage-chained-replication/.

"Il écrira d'abord sur le primaire et automatiquement l'écriture primaire au secondaire?"

Écrit dans le fichier principal, stocké dans oplog, oplog répliqué dans secondaire, puis écrit dans secondaire. C'est automatique, mais vous devez prendre en compte la latence du réseau. Les facteurs de latence comprennent la distance entre le noeud principal et le noeud secondaire, ainsi que les obstacles tels que le pare-feu. Il y a beaucoup de choses que vous pouvez jouer avec la réplication de MongoDB, par ex. paramètre writeConcern supérieur pour augmenter la cohérence (au coût du débit), configurer le secondaire retardé pour agir en tant que sauvegarde, priorité d'élection pour chaque secondaire (utile pour le multi-centre de données), etc

"Le framework vérifiera-t-il la réussite de la connexion à chaque base de données et "élire" un primaire si le primaire actuel est indisponible (donc élire secondaire comme primaire)? Si oui, que se passe-t-il lorsque le primaire reviendra? "

Il y a une 'pulsation' entre les membres d'un ensemble de réplicas. Si un membre tombe en panne, d'ici 10 à 30 secondes, les autres membres détecteront le battement de cœur de la perte et marqueront ce membre comme indisponible. Si le membre décédé est un primaire, le processus électoral aura lieu et un nouveau primaire sera élu. Il est important de garder le nombre «impair» de membres (3, 5, 7 ... jusqu'à 12 membres avec 7 membres votants) http://docs.mongodb.org/manual/core/replica-set-architecture-four-members/

Lorsque ce primaire rabaissé reviendra, il deviendra secondaire, avec des opérations non traitées (opérations non appliquées aux fichiers secondaires) stockées dans le dossier 'rollback' qui doivent être réintégrées manuellement dans la base de données ou supprimées.