Cluster MySQL à charge équilibrée sans équilibreur de charge

Je cherche à créer un cluster MySQL à charge équilibrée, mais sans l'équilibreur de charge réel, afin de ne pas ajouter un autre point de défaillance ou de complexité.

Ce que je pensais, c'était d'avoir les éléments suivants:

1. Avoir une configuration maître-maître pour MySQL

2. Sur chaque client, placez un simple proxy à tour de rôle qui ferait pivoter les demandes entre les serveurs.

Est-ce possible? Ou existe-t-il de meilleures façons d'y parvenir?

Veuillez lire mon autre réponse à cette question avant d'utiliser un proxy MySQL de quelque sorte que ce soit. Si vous avez 2 serveurs maître-maître sur lesquels un CMS écrit et 10 httpd qui ne lisent que cela, tout ira bien, mais (comme indiqué dans l'autre réponse) ce n'est pas toujours le cas. Tu as été prévenu.

MySQL Proxy est un programme simple qui se situe entre votre client et le ou les serveurs MySQL qui peuvent surveiller, analyser ou transformer leur communication. Sa flexibilité permet des utilisations illimitées; les plus courants comprennent: l'équilibrage de charge; basculement; analyse des requêtes; filtrage et modification des requêtes; et beaucoup plus.

.

HAProxy est une solution gratuite, très rapide et fiable offrant une haute disponibilité, un équilibrage de charge et un proxy pour les applications TCP et HTTP

Si vous l'exécutiez en mode TCP, cela pourrait être encore mieux que Wackamole. Si je devais choisir entre eux, j'utiliserais HAProxy. De plus, HAProxy peut avoir beaucoup de backends, Waclamole ne peut en avoir que 2. Notez que HAProxy est "stupide", il connecte les sockets sans regarder ce qu'il y a à l'intérieur du flux - le proxy MySQL dédié pourrait avoir la possibilité de pointer diverses requêtes vers des serveurs spécifiés .

Il convient probablement de mentionner Galera Replication pour MySQL pour une véritable configuration MySQL multi-maîtres. Galera est un protocole de réplication synchrone, de sorte que les applications peuvent lire et écrire sur n'importe lequel des serveurs MySQL. Voici un petit tutoriel: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial

Quant aux équilibreurs de charge devant les serveurs MySQL, utilisez un connecteur MySQL qui prend en charge cette fonctionnalité (par exemple, Connector / J pour Java ou Mysqlnd pour php)

Si vous ne disposez pas d'un connecteur capable de le faire, utilisez quelque chose comme un proxy HA. Ce script configure automatiquement HA Proxy et maintient la liste des bons serveurs MySQL: https://github.com/severalnines/haproxy

Meilleures salutations,

Vinay

www.severalnines.com

La réplication maître-maître n'est pas aussi bonne qu'on pourrait le penser, il en va de même pour le proxy à tour de rôle et les solutions «faciles» similaires. Si vous validez les données en collision sur des serveurs séparés assez rapidement (plus rapidement que le délai entre les serveurs, qui sur les serveurs de production peut durer jusqu'à une seconde *), les deux accepteront les données. Si vous avez un serveur d'enchères, vous venez de vendre deux fois la même voiture . Qui l'a acheté? Cela dépend de la DB que vous demanderez!

L'application doit savoir qu'il existe en fait 2 bases de données et qu'elle doit connaître leurs deux adresses IP. Si vous voulez "vendre", vous devez fe

DB_number = `auction_number` % `number_of_databases`

( %est pour modulo)

... et validez-le dans la base de données DB_number. Si vous obtenez une erreur de connexion, faites-le peut-être avec l'autre (mais dans le cas d'un serveur d'enchères, j'afficherais simplement une erreur).

De plus, les adresses IP doivent être wackamole -d entre les deux serveurs. Dans un scénario de catastrophe, où un serveur de base de données tombe en panne pendant quelques heures en période d'utilisation maximale, vous constaterez que l'application essaiera de se connecter au serveur absent et de se bloquer jusqu'à TIMEOUT, disons, 3 secondes. Soudainement, la moitié de vos requêtes s'exécutent 3 secondes de plus (et elles finissent toutes par arriver à la même base de données - ce qui ne la fait pas fonctionner plus rapidement qu'avant la catastrophe). Cela ne rend pas votre httpd heureux, car il a probablement un pool de connexions limité de threads de gestionnaire de demandes simultanées ...

* le délai de réplication sur les serveurs de production peut atteindre une seconde complète - je l'ai testé dans une colocation à distance et dans notre centre de données et pendant 99% du temps, il est 0, mais parfois mysql affiche 1s. Sur un trafic massif, j'ai eu de nombreuses collisions en raison de l'application cliente faisant deux demandes résultant en deux requêtes, insérer et sélectionner. Dans certains cas, la ligne n'était pas encore là , nous avons donc utilisé le hachage de l'ID utilisateur et cela a résolu le problème

J'espère que vous apprendrez de mes erreurs ;-)

Un cluster de base de données MySQL à charge équilibrée (ou un autre) est assez futile. Si vous écrivez sur plusieurs serveurs, vous rencontrerez des problèmes ou vous utilisez la réplication synchrone (que MySQL ne prend pas en charge de toute façon), ce qui nuit gravement aux performances car il doit synchroniser les verrous.

Je vous recommande de diviser les charges de lecture / écriture et d'équilibrer la charge des lectures entre les esclaves mysql, et d'avoir soit un seul maître pour les écritures, soit d'utiliser une paire de basculement active / passive pour votre maître.

Essentiellement, vous ne pouvez pas mettre à l'échelle les écritures en plaçant davantage de serveurs dans une base de données en tant qu'esclaves, car chacun doit encore écrire la charge d'écriture entière de votre application.

Pour mettre à l'échelle les écritures, vous devez diviser vos données de manière logique sur plusieurs serveurs, en partitionnant ou en «partageant», etc. besoin de ça.

Vous pouvez bien sûr utiliser le cluster MySQL si vous le voulez vraiment, mais c'est un moteur complètement différent avec ses propres fonctionnalités et inconvénients - il est un peu compliqué à configurer mais fournit vraiment une base de données à charge équilibrée HA sur le matériel de base. Il souffre toujours de pénalités de performances d'écriture liées à l'utilisation de la réplication synchrone, mais vous permet de mettre à l'échelle les écritures car il a intégré le partitionnement sur les serveurs.

Un autre excellent guide sur ce sujet que j'ai trouvé ...

http://www.dancryer.com/2010/01/mysql-circular-replication

Ceci fait partie 1 d'une série de trois publications:

• Guide du cluster équilibré de charge MySQL - Partie 1 - installer les serveurs eux-mêmes et configurer la réplication MySQL.

• Guide de cluster MySQL équilibré en charge - Partie 2 - configurez un script pour surveiller l'état de vos nœuds de cluster MySQL, que nous utiliserons dans le prochain guide pour configurer notre proxy.

• Guide du cluster MySQL Load-Balanced - Partie 3 - Configuration de l'équilibreur de charge avec HAProxy, à l'aide des scripts de surveillance

Personnellement, la meilleure façon serait d'utiliser un équilibreur de charge!

Oui, cela ajoute un autre point d'échec, mais toute routine que vous mettez en place ou installez sur CHAQUE client, ajoute beaucoup plus de complexité qu'un équilibreur de charge standard ....

Le connecteur / J a la capacité d'équilibrer la charge des requêtes sur plusieurs serveurs. Ceci est principalement destiné au cluster MySQL NDB où tous les nœuds SQL auront une vue cohérente des données, mais si vous pouvez vous assurer que la base de données des deux maîtres sera raisonnablement cohérente entre ces deux maîtres, cela pourrait être sûr pour votre application.

La chaîne de connexion ressemblerait à quelque chose comme:

jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "random" & loadBalanceBlacklistTimeout = 5000

Le fractionnement des écritures ne supprimera pas la charge des serveurs car les écritures doivent toujours être répliquées.

Si vous n'utilisez que 2 serveurs, utilisez Heartbeat avec drbd et laissez drbd gérer la réplication. Si le premier serveur tombe en panne, le deuxième serveur prendra le relais. Si vous souhaitez utiliser le deuxième serveur, vous pouvez utiliser gfs sur drbd, puis exécuter le deuxième serveur en lecture seule et l'utiliser comme serveur de lecture. En cas de basculement, modifiez le serveur en lecture / écriture.

re: wackamole - wackamole n'est pas limité à 2 serveurs

Je travaille sur une série de didacticiels couvrant cela, mais c'est vraiment simple à configurer.

Afin de donner une réponse plus récente à cette question, avec la version 5.6 de MySQL, il a introduit les GTID (Global Transaction Identifieres) qui visent à rendre la réplication asynchrone plus robuste et à remettre MySQL dans la course pour HA (High Availability).

Cette section explique la réplication basée sur les transactions à l'aide des identificateurs de transaction globaux (GTID). Lorsque vous utilisez des GTID, chaque transaction peut être identifiée et suivie lorsqu'elle est validée sur le serveur d'origine et appliquée par tous les esclaves; cela signifie qu'il n'est pas nécessaire lors de l'utilisation de GTID de faire référence aux fichiers journaux ou aux positions dans ces fichiers lors du démarrage d'un nouvel esclave ou du basculement vers un nouveau maître, ce qui simplifie considérablement ces tâches. Étant donné que la réplication basée sur GTID est entièrement basée sur les transactions, il est simple de déterminer si les maîtres et les esclaves sont cohérents; tant que toutes les transactions validées sur un maître sont également validées sur un esclave, la cohérence entre les deux est garantie. Vous pouvez utiliser la réplication basée sur des instructions ou sur des lignes avec des GTID (voir Section 16.2.1, «Formats de réplication»); cependant, pour de meilleurs résultats,

Référence: 16.1.3 Réplication avec des identificateurs de transaction globale (documentation MySQL)

Je pensais que l'utilisation de HAProxy pour les requêtes d'équilibrage de charge introduisait un SPOF (Single Point Of Failure), et ajouter des battements cardiaques rend cette solution lourde.

Une solution plus simple consiste à se connecter via le connecteur Java JConnector qui vise à charger les requêtes d'équilibrage via une URL jdbc avec tous les nœuds MySQL. Il peut gérer des configurations maître / esclave ou maître / maître .

Cela permet de configurer une solution de cluster HA dès le départ avec MySQL.