Solutions de dimensionnement pour MySQL (réplication, clustering)

Question

À la démarrage , nous travaillons actuellement sur les solutions de dimensionnement de notre base de données. Les choses deviennent quelque peu déroutantes (du moins pour moi) avec MySQL, qui a le cluster MySQL , réplication et < a href = "http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication.html" rel = "noreferrer"> Réplication de cluster MySQL (à partir de la version 5.1.6) ), qui est une version asynchrone du cluster MySQL. Le manuel MySQL explique certaines des différences entre FAQ sur les clusters , mais il est difficile de savoir quand utiliser l'un ou l'autre.

J'apprécierais les conseils de personnes connaissant bien les différences entre ces solutions et leurs avantages et inconvénients, et quand recommandez-vous de les utiliser chacune.

Answer 1

J'ai beaucoup lu sur les options disponibles. J'ai également mis la main sur High Performance MySQL 2nd Edition, que je recommande vivement.

Voici ce que j'ai réussi à reconstituer:  

Mise en cluster

La mise en cluster au sens général consiste à répartir la charge sur plusieurs serveurs qui apparaissent à une application externe en tant que serveur unique.

Cluster NDB MySQL

MySQL NDB Cluster est un moteur de stockage distribué, en mémoire et sans partage, avec réplication synchrone et partitionnement automatique des données (excusez-moi, j’emprunte littéralement au livre High Performance, mais ils l’ont très bien décrit). Cela peut être une solution très performante pour certaines applications, mais les applications Web ne fonctionnent généralement pas bien avec cette application.

Le problème majeur est qu'au-delà de requêtes très simples (ne touchant qu'une table), le cluster devra généralement rechercher des données sur plusieurs nœuds, ce qui permettra à la latence du réseau de s'introduire et ralentira considérablement le temps de traitement des requêtes. Étant donné que l’application considère le cluster comme un seul ordinateur, elle ne peut pas lui indiquer le noeud vers lequel extraire les données.

De plus, l'exigence en mémoire n'est pas réalisable pour de nombreuses bases de données volumineuses.

Séquoia continu

Ceci est une autre solution de clustering pour MySQL, qui agit comme un middleware sur le serveur MySQL. Il offre une réplication synchrone, un équilibrage de charge et un basculement. Cela garantit également que les demandes obtiennent toujours les données de la dernière copie, en choisissant automatiquement un nœud contenant les nouvelles données.

J'ai lu des bonnes choses dessus, et dans l’ensemble, cela semble assez prometteur.

Fédération

La fédération est similaire à la mise en cluster, donc je l'ai tirée ici aussi. MySQL offre la fédération via le moteur de stockage fédéré. Semblable à la solution de cluster NDB, il fonctionne bien avec des requêtes simples uniquement - mais pire encore, le cluster pour les requêtes complexes (car la latence du réseau est beaucoup plus élevée).

Réplication et équilibrage de la charge

MySQL possède la capacité intégrée pour créer des réplications d’une base de données sur différents serveurs. Cela peut être utilisé à de nombreuses fins: partage de la charge entre serveurs, sauvegardes à chaud, création de serveurs de test et basculement.

La configuration de base de la réplication implique un serveur principal gérant principalement les écritures et un ou plusieurs esclaves gérant uniquement les lectures. Une variante plus avancée est celle de la configuration maître-maître , qui permet de redimensionner les écritures au format bien en ayant plusieurs serveurs écrivant en même temps.

Chaque configuration a ses avantages et ses inconvénients, mais l'un des problèmes qu'ils partagent tous est le délai de réplication: comme la réplication MySQL est asynchrone, tous les nœuds ne disposent pas toujours des données les plus récentes. Cela nécessite que l'application soit consciente de la réplication et qu'elle incorpore des requêtes prenant en compte la réplication pour fonctionner comme prévu. Pour certaines applications, cela peut ne pas poser de problème, mais si vous avez toujours besoin des données les plus récentes, les choses se compliquent un peu.

La réplication nécessite un certain équilibrage de la charge pour la répartir entre les nœuds. Cela peut être aussi simple que certaines modifications du code de l'application ou l'utilisation de solutions matérielles et logicielles dédiées.

Éclatement et partitionnement

La fragmentation est une approche couramment utilisée pour adapter les solutions de base de données. Vous divisez les données en fragments plus petits et les répartissez autour de différents nœuds de serveur. Cela nécessite que l'application soit consciente de la modification apportée au stockage de données pour fonctionner efficacement, car elle doit savoir où trouver les informations dont elle a besoin.

Des cadres d'abstraction sont disponibles pour vous aider à gérer le partage des données, tels que les Hibernate Shards , une extension à l'ORM Hibernate (qui est malheureusement en Java. J'utilise PHP). HiveDB est une autre solution de ce type qui prend également en charge le rééquilibrage des fragments.

Autres

Sphinx

Sphinx est un moteur de recherche en texte intégral qui peut être utilisé bien plus que pour des recherches de test. Pour de nombreuses requêtes, il est beaucoup plus rapide que MySQL (en particulier pour le regroupement et le tri) et permet d'interroger des systèmes distants en parallèle et d'agréger les résultats, ce qui le rend très utile pour une utilisation avec le sharding.

En général, sphinx doit être utilisé avec d'autres solutions de dimensionnement pour obtenir davantage de matériel et d'infrastructure disponibles. L’inconvénient est que, là encore, il faut que le code de l’application prenne conscience du sphinx pour l’utiliser à bon escient.

Résumé

Les solutions de dimensionnement diffèrent en fonction des besoins de l'application qui en a besoin. Pour nous et pour la plupart des applications Web, je pense que la réplication (probablement multi-maître) est la solution avec un équilibreur de charge répartissant la charge. La fragmentation de zones à problèmes spécifiques (énormes tableaux) est également indispensable pour pouvoir évoluer horizontalement.

Je vais également essayer Continuent Sequoia et voir s'il peut vraiment faire ce qu'il promet, car il impliquera le moins de modifications possibles dans le code de l'application.

Answer 2

Avertissement: je n'ai pas utilisé MySQL Cluster, je ne fais donc que partir de ce que j'ai entendu.

MySQL Cluster est une solution de haute disponibilité. C'est rapide, parce que tout est en mémoire, mais le vrai argument de vente est la disponibilité. Il n'y a pas de point d'échec unique. Avec la réplication, par contre, si le maître tombe en panne, vous devez en fait basculer sur le réplica et il peut y avoir un peu de temps mort. (bien que la solution DRBD soit une autre alternative offrant une haute disponibilité)

Le cluster nécessite que toute votre base de données tienne dans la mémoire. Cela signifie que chaque ordinateur du cluster doit disposer de suffisamment de mémoire pour stocker la base de données entière. Donc, ce n'est pas une solution réalisable pour les très grandes bases de données (ou du moins, c'est une solution très chère).

Je pense que si HA n’est pas très important (lire: probablement pas), c’est plus tracas (et argent) que ça en vaut la peine. La réplication est plus souvent la meilleure solution.

Modifier: J'ai également oublié de mentionner que le cluster ne permet pas les clés étrangères et que les analyses de plage sont plus lentes que sur les autres moteurs. Voici un lien sur Limitations connues de MySQL Cluster

Answer 3

Il y a de bonnes discussions sur la façon dont les personnes qui gèrent drupal.org ont structuré leurs serveurs de base de données:

• le blog de Dries Buytaert
• blog WorkHabits

Les deux sont de 2007, le support du clustering est peut-être plus puissant maintenant, mais au moment où ils ont choisi la réplication.

Answer 4

Ce qui est bien avec la réplication, c'est que c'est facile. Il vous suffit de configurer 2 boîtes mysql, de modifier l'ID serveur sur la deuxième boîte, puis de pointer la deuxième boîte vers la première en utilisant le changement de maître à commander.

Voici l'exemple de configuration esclave approprié my.cnf

#
#       Log names
#

log-bin=binlog
relay-log=relaylog
log-error=errors.log

#
#       Log tuning
#

sync_binlog = 1
binlog_cache_size = 1M

#
#       Replication rules (what are we interested in listening for...)
#
#       In our replicants, we are interested in ANYTHING that isn't a permission table thing
#

replicate-ignore-db =      mysql
replicate-wild-ignore-table=mysql.%

#
#       Replication server ID
#

server-id      =        2

Assurez-vous donc que chaque esclave obtient un ID de serveur incrémenté de 1 (le prochain esclave est donc le serveur 3)

configurer un nom d'utilisateur et un mot de passe sur lesquels l'esclave peut se connecter, Puis courir change master en MASTER_HOST = 'x.x.x.x'; change master en MASTER_PASSWORD = "xxxxx" ;;

et ainsi de suite.

Enfin, exécutez "Démarrer l'esclave;"

Up vient votre esclave et commence à se répliquer. doux hein!

Cela suppose que vous commencez avec 2 serveurs vides. Ensuite, vous pouvez vider votre base de données sur le serveur maître. Lorsqu’elle se charge là-bas, elle se charge également sur l’esclave.

Vous pouvez vérifier le statut de l'esclave en exécutant:

afficher le statut de l'esclave \ G

Amusez-vous avec ça .. tellement facile ...

Answer 5

Lors de mon étude sur la haute disponibilité, je suis tombé sur de nombreuses solutions et probablement dans notre cas, qui nécessitait davantage d’écriture système, j’ai trouvé le cluster DRBD meilleur que le cluster NDB car il fournit plus de transactions à la seconde.

Mysql Replication peut vous fournir un ordinateur de secours pouvant être utilisé comme esclave de lecture ou en cas de reprise après sinistre.

Grâce aux différents modes de gestion des transactions fournis par DRBD, vous pouvez réduire les performances de la réplication des données au niveau du périphérique sur le réseau. Pour un système fiable qui ne devrait perdre aucune transaction en cas d’échec, utilisez le mode C, sinon optez pour le mode B.

J'ai essayé de répertorier certaines des connaissances acquises lors de la configuration du cluster DRBD à l'adresse http: / /www.techiegyan.com/?p=132

Cela fonctionne très bien sur une connexion dédiée à la réplication, c’est-à-dire de réserver des interfaces haute vitesse distinctes sur les deux machines uniquement pour la réplication drbd. Heartbeat peut parfaitement contrôler le cluster avec tous les services, c’est-à-dire les adresses IP, les partitions, drbd et mysql.

Je n'ai pas encore découvert la configuration maître-maître sur DRBD. Mettra à jour au fur et à mesure que je réussis.

Merci.

Answer 6

À mon avis, la confusion qui règne ici ne fait que me ramener à Mnesia. Avec fragmentation, gestion déclarative et pragmatique des index, Transparence de l'emplacement des répliques de base de données e.t.c

Dans notre configuration, nous exécutons à la fois MySQL Cluster et Mnesia. Nos données sont un peu saisonnières. Donc, ce qui se passe, c’est après quelque temps, nous soulageons la mnesia des données qui ne sont plus utilisées et nous les jetons dans un cluster MYSQL. Cela maintient notre mnesia efficace. Nous avons également des applications implémentées dans les principaux langages de flux (Python, Clojure e.t.c) qui utilisent les données directement de MySQL.

En résumé, nous utilisons mnesia sur MySQL Cluster. Le cluster MySQL peut gérer des ensembles de données volumineux, une base de données pouvant atteindre 50 Go et plus. Nous avons mnesia qui alimente les applications Erlang / OTP . Java et PHP accéder aux données de mnesia via des REST sur mesure (récemment Thrift ) utilisant JSON et XML comme formats d'échange .

La couche d'accès aux données a abstrait l'accès aux données dans Mnesia et aux anciennes données envoyées dans MySQL Cluster si nécessaire. Mnesia est là essentiellement pour alimenter les applications Erlang / OTP. Une fois qu’il s’accapare de données, nous le lançons dans MYSQL Cluster. La couche d'accès aux données peut accéder à la fois aux données mnesia et MySQL dans une API abstraite pour le compte de toutes les applications.

Ce que je peux dire ici, c'est que Mnesia a été la meilleure option pour nous. Les tables sont très fragmentées et indexées, les requêtes s’effectuent très bien et la base de données est répliquée sur 2 emplacements connectés via un tunnel.

Plus tôt, nous craignions que mnesia ne traite pas autant d’enregistrements que possible en raison de la taille limitée des tables. Mais nous avons trouvé cette déclaration fausse. Grâce à un bon réglage (fragmentation), nos bases de données mnesia contiennent en moyenne environ 250 millions d’enregistrements par an.

Nous avons tiré parti de la structure de données complexe d’Erlang et du fait que Mnesia peut l’avaler sans la modifier. Les applications Erlang / OTP sont les plus efficaces de toutes les autres applications dans les langages existants et, avec notre système, nous prévoyons de tout migrer vers la technologie Erlang / OTP. Depuis Erlang, nous accédons sans difficulté aux données de MySQL Cluster et exécutons les requêtes sur ses serveurs de manière très merveilleuse. En fait, nous en avons déduit que son Erlang / OTP peut utiliser pleinement les ressources du serveur MySQL en raison de son importante concurrence (Erlang).

Mnesia a très bien fonctionné pour nous. Mnesia a complètement changé la façon dont nous examinons les bases de données en raison de ses performances excitantes. Les cœurs de processeur de notre serveur Solaris restent occupés à une utilisation moyenne d’environ 48% aux heures de pointe.

Je vous conseille de consulter mnesia et qui sait, elle pourrait répondre à plusieurs de vos besoins en matière de distribution ou de réplication.

Answer 7

Je ne les ai pas utilisées, mais d'après la documentation, je dirais que la réplication est la solution préférée si la charge la plus importante est la lecture de la base de données.

Answer 8

Le "en mémoire" La limitation nous empêche d'utiliser le cluster MySQL pour nos données de près de 50 Go. Nous utilisons donc DRBD plus linux Heartbeat .

C'est un peu comme un tableau RAID entre deux (ou plus) boîtes qui maintient les bases de données / journaux / configs en synchronisation (mais un seul serveur peut être "en direct" à la fois). Le basculement est automatique, utilise la même adresse IP et est rapide comme un redémarrage de mysql. C’est donc une bonne solution pour nous.

Answer 9

Le cluster MySQL est une bête étrange et chaque fois que nous l’évaluons, il fonctionne très mal ou n’est pas fiable.

C’est terriblement compliqué à installer (vous avez besoin d’au moins trois nœuds, voire plus). En outre, il n’existe aucune disposition permettant aux clients de basculer, vous devez donc le faire vous-même (ou utiliser un autre outil pour agir en tant que proxy, etc.).

C’est extrêmement intelligent, car il effectue un partitionnement automatique sur la clé primaire, ce qui vous permet de mettre à l’échelle les écritures, mais aussi parce qu’il n’existe pas de point de défaillance unique.

Mais je pense vraiment que cela convient mieux aux cas très spéciaux pour lesquels il a été conçu. Dans la plupart des cas, il ne peut pas remplacer un autre moteur de base de données (par exemple, InnoDB) en termes de performances ou de fonctionnalités.