Solutions de dimensionnement pour MySQL (réplication, clustering)
Au startup , je travaille à, nous étudions maintenant des solutions de dimensionnement pour 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 la réplication de cluster MySQL (version 1.1.6), qui est une version asynchrone. du cluster MySQL. Le manuel MySQL explique certaines des différences entre son cluster FAQ , mais il est difficile de savoir quand utiliser l'une ou l'autre.
J'apprécierais tout conseil de la part de personnes connaissant bien les différences entre ces solutions et leurs avantages et inconvénients, et quand recommandez-vous de les utiliser.
J'ai beaucoup lu sur les options disponibles. J'ai également mis la main sur la deuxième édition de High Performance MySQL, que je recommande vivement.
C’est ce que j’ai réussi à reconstituer:
Clustering
Le clustering au sens général consiste à répartir la charge sur plusieurs serveurs qui apparaissent à une application externe en tant que serveur unique.
MySQL NDB Cluster
MySQL NDB Cluster est un moteur de stockage distribué, en mémoire, sans rien partagé, 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à des 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 nœud à partir duquel extraire les données.
En outre, 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 quelques bonnes choses dessus et, dans l'ensemble, cela semble assez prometteur.
Fédération
La fédération est semblable au regroupement, alors 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 plus compliquées (car la latence du réseau est beaucoup plus élevée).
Réplication et équilibrage de 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 nombreux égards - division de la charge entre serveurs, sauvegardes à chaud, création de serveurs de test et reprise en ligne.
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 master-master , qui permet également de mettre à l'échelle des écritures 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 - puisque 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 charge pour répartir la charge 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.
Eclatement et partitionnement
Sharding est une approche couramment utilisée pour mettre à l'échelle des solutions de bases 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.
Il existe des frameworks d'abstraction disponibles pour aider à gérer le partage des données, tels que Hibernate Shards , une extension de l'ORM Hibernate (malheureusement en Java. J'utilise PHP). HiveDB est une autre solution qui prend également en charge le rééquilibrage des fragments.
Autres
Sphinx
Sphinx est un moteur de recherche de texte intégral qui peut être utilisé pour bien plus que des recherches tests. 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 connaisse le 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. L'éclatement de zones à problèmes spécifiques (énormes tableaux) est également indispensable pour pouvoir évoluer horizontalement.
Je vais aussi essayer de tester Continuent Sequoia et voir s'il peut réellement faire ce qu'il promet, car il impliquera le moins de changements possibles dans le code de l'application.
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 à haute disponibilité)
Le cluster nécessite que votre base de données entière 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 coûteuse).
Je pense que, sauf si HA est super important (lire: probablement pas), c'est plus compliqué (et argent) que ça vaut. La réplication est plus souvent la meilleure solution.
Edit: J'ai oublié de mentionner également que Cluster n'autorise pas les clés étrangères et que les analyses de plage sont plus lentes que sur les autres moteurs. Voici un lien qui parle de Limitations connues de MySQL Cluster
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:
Tous deux datent de 2007, le support de clustering est peut-être plus puissant maintenant, mais à ce moment-là, ils ont choisi la réplication.
La chose intéressante à propos de la réplication est que c'est facile. Il suffit de configurer 2 boîtes mysql, de changer l’identifiant du 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 correspondant à l'esclave 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
Donc, assurez-vous que chaque esclave obtient un ID de serveur incrémenté de 1 (donc le prochain esclave est le serveur 3)
configurez un nom d'utilisateur et un mot de passe sur lesquels l'esclave peut se connecter, puis exécutez change master en MASTER_Host = 'x.x.x.x'; change master en MASTER_PASSWORD = "xxxxx";
etc.
enfin, lancez "démarrer esclave";
Up vient votre esclave et commence à se répliquer. chérie hein!
Cela suppose que vous commencez avec 2 serveurs vides. Ensuite, vous pouvez vider votre base de données sur le serveur maître et, lorsqu’elle se charge là-bas, elle se chargera é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 elle .. soooo facile ...
Lors de mon étude sur la haute disponibilité, je suis tombé sur de nombreuses solutions et probablement dans notre cas, système qui nécessitait davantage d’écriture, j’ai trouvé le cluster DRBD meilleur que le cluster NDB car il fournit plus de transactions par seconde.
Mysql Replication peut vous fournir un ordinateur de secours pouvant être utilisé en tant qu'esclave en lecture ou en cas de récupération 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 de défaillance, utilisez le mode C, sinon optez pour B.
J'ai essayé de répertorier certaines des connaissances acquises lors de la configuration du cluster DRBD sur 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 suis encore à découvrir la configuration Master-Master sur DRBD. Mettra à jour au fur et à mesure que je réussis.
Merci.
à mon avis, la confusion ici me renvoie juste à 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. Ainsi, après un certain 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 bref, 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 alimentant le Erlang/OTP applications. Java et PHP accéder aux données de mnesia sur mesure REST (récemment Épargne) API utilisant JSON et XML comme formats d’échange.
La couche d'accès aux données a extrait l'accès aux données dans Mnesia et aux anciennes données livrées dans MySQL Cluster si nécessaire. Mnesia est là essentiellement pour alimenter les applications Erlang/OTP. Une fois qu’il s’agit de données, nous les intégrons 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 hautement fragmentées et indexées, les requêtes fonctionnent très bien et la base de données est répliquée sur 2 emplacements connectés via un tunnel.
Un peu 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 complexe des données 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 sa simultanéité massive (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 vérifier mnesia et qui sait, cela pourrait répondre à plusieurs de vos besoins en matière de distribution ou de réplication.
La limitation "en mémoire" nous empêche d'utiliser le cluster MySQL pour nos données d'environ 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 "actif" à la fois). Le basculement est automatique, utilise la même adresse IP et est rapide comme un redémarrage de MySQL, ce qui est donc une bonne solution pour nous.
Je ne les ai pas utilisées, mais d'après les documents, je dirais que la réplication est la solution privilégiée si la charge la plus importante est la lecture de la base de données.
Le cluster MySQL est une bête étrange et chaque fois que nous l’évaluons, il est soit très mal exécuté, soit peu fiable.
C'est horriblement compliqué à installer (vous avez besoin d'au moins trois nœuds, peut-être plus). De plus, il n'y a aucune disposition pour que les clients basculent, vous devez donc le faire vous-même (ou utiliser quelque chose d'autre pour agir en tant que proxy, etc.).
C'est extrêmement astucieux, car il effectue un partitionnement automatique sur la clé primaire, ce qui vous permet de mettre à l'échelle les écritures, et aussi parce qu'il n'a 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 remplacer un autre moteur de base de données (par exemple, InnoDB), que ce soit en termes de performances ou de fonctionnalités.