Réplication MySQL robuste tolérante aux pannes

Question

Existe-t-il un moyen d'obtenir une réplication MySQL tolérante aux pannes? Je suis dans un environnement qui a beaucoup de problèmes de réseautage. Il semble que la réplication reçoive une erreur et s'arrête juste. J'en ai besoin pour continuer à travailler et récupérer de ces défauts. Un logiciel d'encapsulation vérifie l'état de la réplication et la redémarre en cas de perte de la position du journal. Y a-t-il une alternative?

Note: La réplication se fait à partir d'un ordinateur embarqué avec MySQL 4.1 à un ordinateur externe qui a MySQL 5.0.45

Answer 1

Considérez Cluster MySQL en utilisant le moteur NDB, il est destiné à être partagé rien et tolérant aux pannes

Answer 2

Quelle erreur obtenez-vous? Vous n'avez pas non plus décrit le schéma de réplication ou la version Mysql que vous utilisez. Les erreurs que vous obtenez sont également importantes.

La réplication s'arrête généralement en cas de conflit de clé primaire/unique dans une réplication maître-maître. Autre que cela sur une configuration de réplication Master-Slave typique, les problèmes de mise en réseau ne devraient pas causer de problèmes. Essayez d'utiliser MySQL 5.1 ou plus récent, car la réplication dans 5.0 est basée sur des instructions et provoque des problèmes dans les configurations Master-Master ou lorsque vous utilisez des procédures stockées. (Aussi, restez loin de Mysql Cluster ... remarqué le conseil sur un autre commentaire).

Answer 3

La réplication MySQL détecte normalement les problèmes et se reconnecte quand même, en continuant là où elle s'était arrêtée.

Si vous recevez des erreurs de réplication, il est probable que la source soit autre chose. La réplication de MySQL fait effectivement un "tail -f" sur le journal de requête et le rejoue sur l'esclave (c'est légèrement plus intelligent que ça, mais pas beaucoup). Si les bases de données ne sont plus synchronisées, la réplication MySQL ne détectera ni ne réparera cela, mais elle pourrait finir par l'interrompre car une mise à jour ultérieure ne peut pas continuer en raison de données conflictuelles sur l'esclave.

Les délais d'attente par défaut sur l'esclave de réplication sont beaucoup trop longs - il attend des heures (ou quelque chose) - vous aurez envie de réduire cela.

données devenir désynchronisés est difficile d'éviter, des mesures d'atténuation sont:

• réplication du moniteur en utilisant quelque chose comme mk-table contrôle de Maatkit
• Audit tout votre code pour les requêtes de réplication dangereuse
• Si vous utilisez la version 5.1, passez à la réplication par ligne, qui est moins susceptible de souffrir de ce problème.

Answer 4

Les erreurs de réplication se produisent uniquement si les bases de D'une certaine manière, avoir le serveur continue simplement signifierait des bases de données incohérentes, je doute vraiment que vous le vouliez. Dans mon expérience, la seule fois où vous vous retrouvez avec de telles erreurs est si l'un des serveurs maîtres n'a pas terminé une requête et l'esclave a remarqué.Dans tous les cas, si vous voulez vraiment que l'esclave continue par une sorte de travail chron, vous pouvez toujours exécuter une requête toutes les quelques minutes en demandant à l'esclave "SHOW SLAVE STATUS" puis en vérifiant la colonne d'erreur, si elle est présente, envoyez une commande "STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER; START SLAVE;". Mais il serait probablement plus facile d'envoyer un email à un administrateur quand mysql rencontre une erreur à la place, afin qu'il puisse étudier la source du problème et s'assurer que les bases de données sont bien synchronisées, sinon vous risquez de voir plus d'erreurs dans un proche avenir, car les bases de données deviennent de plus en plus désynchronisées.