MySQL Cluster: Questions fréquemment posées

R: MySQL Cluster associe une haute évolutivité en écriture, une performance en temps réel, une compatibilité ACID, une disponibilité de 99,999 % et le faible coût (TCO) d'une solution open source. Reposant sur une architecture distribuée multi-maîtres sans aucun point unique de défaillance, MySQL Cluster se déploie horizontalement sur du matériel standard pour traiter des charges de travail très exigeantes en lecture et en écriture, l'accès se faisant via des interfaces SQL et NoSQL.

L'infrastructure en temps réel de MySQL Cluster permet de prévoir des temps de réponse de l'ordre de quelques millisecondes et de gérer des millions d'opérations par seconde. Grâce à une prise en charge des données en mémoire et sur disque, un partitionnement automatique des données (sharding) avec équilibrage de charge et la possibilité d'ajouter des nœuds à un cluster en cours d'exécution sans aucun temps d'arrêt, MySQL Cluster garantit une évolutivité linéaire de la base de données et la possibilité de gérer les charges de travail Web les plus inattendues.

R: MySQL Cluster Carrier Grade Edition (CGE) inclut des outils de gestion et de surveillance de la base de données MySQL Cluster, associés à l'accès à Oracle Premier Support. MySQL Cluster CGE est disponible sous forme d'abonnements ou bien de licences commerciales et de services d'assistance.

• En savoir plus sur MySQL Cluster CGE
• Consultez notre politique en matière de licence

R: Voir http://www.mysql.fr/customers/cluster/.

R: La version actuelle est MySQL Cluster 7.2. MySQL 5.5 est intégré et fourni avec MySQL Cluster.

R: Non. MySQL Cluster a été conçu pour fonctionner sur du matériel standard. Avec l'aide d'un matériel spécialisé (par exemple, des interconnexions réseau SCI), il est néanmoins possible d'optimiser davantage le niveau de performance.

R:

R: Si vous répondez par "OUI" à l'une des 10 questions suivantes, vous pouvez envisager d'utiliser MySQL Cluster pour votre base de données d'application:

• Une défaillance de votre base de données entraînerait-elle des temps d'arrêt de l'application causant une interruption d'activité?
• Êtes-vous mécontent de vos temps de reprise après échec actuels?
• La base de données de votre application nécessite-t-elle une redondance intégrée pour garantir une disponibilité à 99,999 % avec reprise après échec et récupération automatiques?
• Votre base de données actuelle est-elle un goulot d'étranglement pour les écritures? Cherchez-vous des alternatives à une architecture à déploiement horizontal de ou des esclaves et/ou au partitionnement de l'application?
• Votre application est-elle sensible à une latence inférieure à la seconde?
• Vos applications/services doivent-ils fournir des temps de réponse prévisibles?
• Votre application a-t-elle des besoins d'évolutivité imprévisibles?
• Exécutez-vous une grande variété d'applications qui profiteraient de l'accès direct à des données sans toujours se fier à SQL (par ex. applications Java et OpenJPA, OpenLDAP, Web Services et applications C++)?
• Profiteriez-vous d'une architecture en cluster active/active éliminant la perte de ressources matérielles?
• Votre application implique-t-elle principalement des recherches de clés primaires et de jointures de tables retournant de petits jeux de résultats?

Consultez également notre guide d'évaluation et d'autres ressources produit pour en savoir plus sur MySQL Cluster.

R: Les applications idéales incluent:

• Des traitements transactionnels en ligne (OLTP) à volume élevé
• Une analyse en temps réel
• Des activités de commerce électronique et financières avec détection de fraudes
• Paiement mobile et micropaiement
• Gestion et mise en cache des sessions
• Diffusion en flux continu, analyse et recommandations
• Gestion et fourniture de contenu
• Jeux en ligne massivement multijoueur
• Services de communication et de présence
• Gestion du profil et droits des abonnés/utilisateurs

Consultez une liste complète des études de cas utilisateur et des applications MySQL.

R:

• Disponibilité
  • 99,999 % (temps d'arrêt inférieurs à 5 minutes par an)
• Performance
  • Temps de réponse: inférieur à 5 millisecondes (avec réplication synchrone et accès via SQL). Des temps de réponse plus courts peuvent être obtenus en utilisant l'une des méthodes d'accès NoSQL.
  • Débit supérieur à 250 000 opérations de MISE À JOUR répliquées par seconde sur un serveur Intel à double socket doté de 24 Go de RAM. 2,5 millions d'opérations de MISE À JOUR dans un cluster de 8 serveurs Intel. Voir l'ensemble des essais.
• Reprise après échec
  • Une reprise inférieure à une seconde permet d'offrir des services sans interruption.
• Évolutivité
  • Déploiement horizontal, vertical et dynamique
  • Pour un déploiement horizontal rentable, appliquez l'une des solutions suivantes:
    • Ajoutez davantage de nœuds de données (8, 10, 12,...48) par cluster.
    • Ajoutez des processeurs (4, 8, etc.).
    • Ajoutez de la mémoire (16 Go, 32 Go, etc.) par nœud de données.

R: À des fins d'évaluation et de développement, vous pouvez exécuter tous les nœuds sur un seul hôte. Pour une redondance et une tolérance aux pannes complètes, vous avez besoin d'au moins 6 hôtes physiques:

• 2 nœuds de données
• 2 nœuds d'application SQL/NoSQL
• 2 nœuds de gestion

De nombreux utilisateurs colocalisent les nœuds de gestion et d'application, ce qui réduit à quatre le nombre de nœuds.

R: Oui, pourvu que votre réseau dispose des caractéristiques présentées ici

MySQL Cluster propose depuis longtemps la réplication géographique, qui consiste à distribuer des clusters vers des datacenters à distance, afin d'atténuer les effets de la latence géographique en exportant les données plus près de l'utilisateur, ainsi qu'en fournissant une capacité de récupération d'urgence.

La réplication géographique est asynchrone et peut être mise en œuvre en tant que cluster actif/actif ou actif/passif.

La réplication géographique représente le modèle de déploiement recommandé pour les déploiements sur plusieurs datacenters.

R: Les applications peuvent être développées au moyen de n'importe quel connecteur MySQL. MySQL Cluster offre en plus une connectivité native NoSQL avec Memcached, C++, Java, JPA et HTTP/REST.

R: Non. Les interfaces sont les mêmes.

R: Oui. Les éditeurs et les fournisseurs d'équipements réseaux (NEP) font souvent appel à MySQL Cluster en guise de base de données incorporée. Liste des clients »

R: La réplication géographique permet une réplication asynchrone sur des clusters géographiquement éloignés les uns des autres. Cette fonctionnalité est souvent utilisée à des fins de récupération d'urgence.

R: Oui. La réplication unidirectionnelle et bidirectionnelle est prise en charge dans MySQL Cluster. La détection et la résolution des collisions de transactions est fournie lorsque la réplication géographique bidirectionnelle est utilisée.

R: En règle générale, les configurations MySQL Cluster disposent d'au moins 2 copies de l'ensemble des données conservées sur des hôtes distincts. Pour répondre à des défaillances système générales, les journaux de transactions et les fichiers de point de contrôle sont conservés sur le disque à une fréquence qu'il est possible de configurer. En outre, toutes les données non indexées peuvent être stockées sur le disque.

R: MySQL Cluster dispose d'une option sans disque, tout comme d'une option sans ouverture de session.

Les restrictions suivantes sont à respecter en mode sans disque:

1. Aucune donnée sur disque
2. Perte de données en cas de défaillance du cluster
3. Pas de sauvegarde

Pour l'option sans ouverture de session, MySQL Cluster créera quand même des fichiers journaux mais les données ne feront l'objet d'aucun point de contrôle sur le disque.

R: Non. MySQL Cluster Manager est disponible uniquement dans le cadre de la base de données MySQL Cluster Carrier Grade Edition (CGE). Pour tout achat d'abonnements ou de licences de l’édition MySQL Cluster CGE, contactez l’équipe commerciale MySQL.

R: MySQL Cluster Manager est un logiciel qui simplifie la création et la gestion de la base de données MySQL Cluster par l’automatisation des tâches de gestion courantes.

R: Grâce à MySQL Cluster Manager, les DBA et les administrateurs système sont plus productifs, ce qui leur permet de se concentrer sur des initiatives informatiques stratégiques et de répondre plus rapidement aux besoins changeants des utilisateurs. Simultanément, les risques de temps d’arrêt des bases de données provoqués auparavant par des erreurs de configuration manuelle sont considérablement réduits.

R: À titre d'exemple, les opérations de gestion qui exigent le redémarrage propagé d'une base de données MySQL Cluster, qui nécessitait auparavant 46 commandes¹ manuelles et prenait 2 heures et demie sur le temps d'un DBA² peuvent désormais être effectuées au moyen d’une seule commande et sont entièrement automatisées avec MySQL Cluster Manager, permettant ainsi de réduire les éléments suivants:

• la complexité et la charge en matière de gestion ;
• le risque de temps d’arrêt par l’automatisation des processus de gestion de la configuration et des changements ;
• les scripts personnalisés des commandes de gestion ou le développement et le maintien des outils de gestion internes.

R: Les administrateurs ont la possibilité de créer et de supprimer des clusters entiers, puis de démarrer, arrêter et redémarrer chaque cluster au moyen d’une simple commande. Ils peuvent également ajouter des nœuds en ligne. Ils n’ont alors plus besoin de redémarrer manuellement chaque nœud de données l’un après l’autre, dans le bon ordre, ni même de créer des scripts personnalisés pour automatiser le processus.

MySQL Cluster Manager automatise les opérations de gestion en ligne, y compris la mise à niveau, la rétrogradation et la reconfiguration des clusters en cours d’exécution, tout ceci sans interrompre les applications ou les clients qui ont accès à la base de données. Les administrateurs n’ont plus besoin de modifier manuellement les fichiers de configuration et de les distribuer à d’autres nœuds du cluster, ou bien de déterminer si des redémarrages propagés sont requis. MySQL Cluster Manager gère l’ensemble de ces tâches, ce qui facilite la mise en œuvre des meilleures pratiques et simplifie, et accélère, considérablement les opérations en ligne, minimisant ainsi les risques d’erreurs.

R: Il réalise les deux opérations. MySQL Cluster Manager offre la possibilité de contrôler le cluster tout entier en tant qu’entité unique, tout en autorisant un contrôle hautement granulaire de tous les processus individuels au sein du cluster même.

R: MySQL Cluster Manager permet de surveiller l’intégrité du cluster tant au niveau d’un système d’exploitation qu’au niveau de chaque processus en interrogeant automatiquement chaque nœud dans le cluster. Il peut détecter si un processus ou serveur hôte est actif, mort ou en suspens, ce qui accélère la détection des problèmes, leur résolution et le mécanisme de reprise.

R: MySQL Cluster Manager intègre et étend les fonctions de gestion existantes en automatisant les tâches réalisées manuellement par un administrateur auparavant. Comme le démontre l’exemple ci-dessus, un processus qui exigeait 46 commandes manuelles se réduit désormais à une seule commande, chaque étape du processus étant entièrement automatisée.

En termes de scripts ou même de développement pour un système de gestion personnalisé, cette tâche peut prendre du temps, s’avérer coûteuse et générer des erreurs pour les opérations de développement, de test et de maintenance manuelles des projets. Pour un grand nombre d’activités de maintenance, ce type d’activité n’est plus nécessaire avec MySQL Cluster Manager.

Grâce à l’automatisation, MySQL Cluster Manager simplifie la gestion des clusters, tout en réduisant le coût, les risques et les efforts.

R: Oui. MySQL Cluster seul offre une fonction d’auto-réparation en cas de défaillance: le redémarrage des nœuds de données est automatique et aucune intervention manuelle n’est requise. MySQL Cluster Manager étend cette fonction grâce à la surveillance et la reprise automatique des nœuds de gestion et des nœuds SQL. Ces fonctions supplémentaires permettent de procéder à une auto-réparation plus transparente et plus complète du cluster et de restaurer pleinement les opérations et les capacités des applications.

R: Oui, à l’exception des nœuds d’applications qui utilisent l’API NDB native (par ex. des nœuds qui accèdent au cluster via les interfaces directes C++, connecteur MySQL Cluster pour Java, OpenLDAP, etc.).

R: Non. Pour garantir une opération à haute disponibilité, MySQL Cluster Manager est dissocié des processus réels de la base de données de sorte que, en cas d’arrêt ou de mise à niveau d’un agent, la base de données en cours d’exécution n’est en aucun cas affectée. MySQL Cluster Manager continue de fonctionner sur les nœuds qui subsistent lorsqu’un agent donné ou l’hôte associé n’est pas disponible.

R: MySQL Cluster Manager est mis en œuvre sous la forme d’un ensemble d’agents, avec un agent exécuté sur chaque hôte physique devant contenir les nœuds (processus) MySQL Cluster à gérer. L’administrateur connecte le client mysql régulier à l’un de ces agents, puis ces derniers communiquent et agissent de concert pour exécuter les opérations sur les nœuds qui composent le cluster.

R: Lorsque vous utilisez MySQL Cluster Manager pour gérer un déploiement MySQL Cluster, l’administrateur n’a plus besoin de modifier les fichiers de configuration (par exemple, config.ini et my.cnf) ; à la place, ces fichiers sont créés et maintenus par les agents. En fait, si vous modifiez manuellement ces fichiers, les modifications seront remplacées par les informations de configuration qui seront conservées dans les agents.

Tous les processus qui structurent le déploiement de MySQL Cluster sont démarrés, redémarrés et arrêtés par MySQL Cluster Manager. Ceci comprend les nœuds de données, les nœuds de gestion et les nœuds serveur MySQL.

De même, au cours de l’utilisation de MySQL Cluster Manager, les opérations de gestion ne doivent pas être réalisées par l’administrateur au moyen de la commande ndb_mgm (ce dernier se connecte directement au nœud de gestion, ce qui signifie que les agents eux-mêmes n’ont aucune visibilité sur les opérations effectuées).

R: L’intervention de MySQL Cluster Manager ne supprime pas l’utilité des nœuds de gestion. Ces derniers continuent d’ailleurs de jouer plusieurs rôles clés:

• Lors de leur démarrage (ou redémarrage), les nœuds de données se connectent au(x) nœud(s) de gestion pour extraire leurs données de configuration, puis à son tour, le nœud de gestion recherche ces données à partir des fichiers de configuration créés par les agents.
• Lorsque vous arrêtez ou redémarrez un nœud de données par le biais de MySQL Cluster Manager, le changement d’état est en fait réalisé par le nœud de gestion.
• Le ou les nœuds de gestion peuvent continuer d’agir en tant qu’arbitres (évitant ainsi un phénomène de "split-brain). C’est pourquoi il est primordial de poursuivre l’exécution de ces processus sur des hôtes distincts des nœuds de données.
• Certaines informations incluses dans les rapports (par exemple, l’utilisation de la mémoire) ne sont pas encore disponibles dans MySQL Cluster Manager et peuvent néanmoins être mises en pratique au moyen de l’outil ndb_mgm.

R: Il n’existe pas de processus parfait pour les agents mêmes. Pour garantir des niveaux élevés de disponibilité, l’administrateur peut opter pour un outil de surveillance des processus afin de détecter la défaillance d’un agent et automatiquement le redémarrer, par exemple en créant un script dans le répertoire /etc/init.d/.

R: Oui. Lors de leur redémarrage, les agents de gestion sont automatiquement resynchronisés avec les autres agents de gestion en cours d’exécution afin de garantir une configuration homogène dans le cluster tout entier, le tout sans aucune intervention de l’administrateur.

R: Oui. L’ensemble des informations de configuration et des identificateurs de processus MySQL Cluster sont conservés sur le disque, ce qui leur permet d’endurer des pannes système ou des redémarrages de MySQL Cluster Manager.

R: MySQL Cluster Manager prend en charge les communications asynchrones entre chaque agent de gestion afin de distribuer de manière sécurisée les demandes de reconfiguration. Les configurations demeurent ainsi cohérentes sur tous les nœuds du cluster.

Toutes les modifications sont uniquement validées lorsque tous les nœuds ont confirmé avoir reçu la demande de reconfiguration. Si un ou plusieurs nœuds ne peuvent recevoir la demande, une erreur est signalée en retour au client. Grâce à l’automatisation de la coordination des demandes de reconfiguration, les risques d’erreurs résultant de la distribution manuelle des fichiers de configuration sont écartés.

R: Consultez la page Plates-formes prises en charge.

R: MySQL Cluster 6.3 et version supérieure.

R: En consultant les ressources à votre disposition, notamment:

• Livre blanc MySQL Cluster Manager