17.9. Réplication de messages

HornetQ supporte la possibilité de continuer à fonctionner après un basculement d'un ou de plusieurs serveurs. Ceci est en partie réalisé grâce au support de basculement lorsque des connexions de clients migrent d'un serveur live vers un serveur de sauvegarde en cas d'un basculement de serveur live. Pour conserver le serveur de sauvegarde actuel, les messages sont répliqués du serveur live vers le serveur de sauvegarde en continu par deux stratégies: store partagé et réplication. Cette section couvre la stratégie de réplication.

La réplication de messages entre un serveur direct et un serveur de sauvegarde est effectué par le biais du trafic réseau car les serveurs live et de sauvegarde ne partagent pas les mêmes stores de données. Toutes les revues sont répliquées entre les deux serveurs, tant que les deux serveurs sont dans le même cluster et ont le même nom d'utilisateur et mot de passe de cluster. Tout le trafic de données (persistantes) reçu par le serveur live est répliqué sur le serveur de sauvegarde.

Quand le serveur de sauvegarde est en ligne, il cherche à trouver et à se connecter à un serveur live pour tenter la synchronisation. Une fois synchronisé, il n'est plus disponible en tant que serveur de sauvegarde. Le synchronisation peut prendre un long moment selon le volume de données à synchroniser et la vitesse du réseau.

La façon dont un serveur de sauvegarde recherche un serveur live pour répliquer les données dépend de savoir si le paramètre de backup-group-name a été défini dans le fichier hornetq-configuration.xml. Un serveur de sauvegarde se connectera à un serveur live qui partage le même nom de groupe uniquement. En l'absence de ce paramètre, un serveur de sauvegarde va essayer de se connecter à un serveur live.

Dans le cas d'un serveur live ayant échoué, le serveur de sauvegarde correctement configuré et synchronisé reprendra ses fonctions. Le serveur de sauvegarde permettra d'établir si le serveur live a échoué, s'il n'a pas pu s'y connecter, mais est encore capable de se connecter à plus de la moitié des autres serveurs dans le cluster. Si plus de la moitié des autres serveurs du cluster échouent également de répondre, cela indique une panne générale de réseau et le serveur de sauvegarde attendra pour réessayer la connexion au serveur live.