Skip navigation links

Contactez l'Equipe Commerciale

Tél: 01 57 60 83 57
Tél: +33 1 57 60 83 57 (de l'étranger)
USA/Canada Subscription Renewals: +1-866-221-0634

Contactez-nous »
Renouvelez Votre Abonnement »

MySQL Newsletter - Subscribe Today!

Questions fréquemment posées (FAQ) pour MySQL Cluster.

» MySQL Cluster Database

Questions générales

Aspects techniques

» MySQL Cluster Manager

Questions générales

Q: Qu'est-ce que MySQL Cluster ?
R : MySQL Cluster est une base de données transactionnelle open source en temps réel conçue pour un accès « always-on » rapide aux données dans des conditions de haut débit. MySQL Cluster utilise une architecture « shared-nothing » qui ne nécessite aucun investissement en infrastructure supplémentaire pour garantir une disponibilité à 99,999 % des données sans point unique de défaillance.

MySQL Cluster permet une prise en charge simultanée des données en mémoire et sur disque accessibles via une interface SQL voire, éventuellement, par le biais d'une interface Java ou d'une interface C++ native hautement performante.
Q: Qu'est-ce que MySQL Cluster Carrier Grade Edition ?
R : L'édition MySQL Cluster Carrier Grade Edition (CGE) se différencie par l'importance qu'elle accorde à l'évolutivité, la capacité d'adaptation et les performances du produit. MySQL Cluster CGE comprend des méthodes d'accès aux données optimisées essentielles, notamment dans le secteur des télécommunications, ainsi que des options pour la réplication géographique et l'ajout en ligne de nœuds de données.
Q: Quelles sont les références clients de MySQL Cluster ?
R : Voir http://www.mysql.fr/customers/cluster/ 

Q: Quelles sont les licences proposées pour MySQL Cluster ?
R : Pour en savoir plus sur les éditions commerciales de MySQL Cluster et sur les fonctionnalités de ce produit, cliquez ici.

Consultez la page consacrée à notre politique en matière de licence : /about/legal/licensing/index.html
Q: Quelle est la version actuelle de MySQL Cluster ?
R : La version actuelle est MySQL Cluster 7.1. MySQL 5.1 est intégré et fourni avec MySQL Cluster. Consultez la documentation relative aux versions spécifiques intégrées. (http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html)
Q: MySQL Cluster exige-t-il un matériel ou un logiciel spécial ?
R : Non. MySQL Cluster a été conçu pour fonctionner sur du matériel grand public. 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. 

Q: Quelle est la configuration système requise pour MySQL Cluster ?
R :
Système d'exploitation :Voir la liste actuelle des plateformes prises en charge »
Processeur:Intel/AMD x86, UltraSPARC
Mémoire:1 Go minimum de mémoire vive (RAM)
Disque dur interne (HDD):3 Go
Réseau:Un ou plusieurs nœuds (Gigabit Ethernet - TCP/IP)
Q : Comment évaluer si une charge de travail est adaptée à MySQL Cluster ? ?
R : SDu fait de l’architecture « shared-nothing » distribuée de MySQL Cluster, savoir maîtriser les types des charges de travail les mieux desservies par cet outil est un aspect primordial. Le tableau ci-dessous résume les caractéristiques clés dont vous devez tenir compte au moment d’examiner MySQL Cluster d’après vos besoins.
Cas idéal pour MySQL Cluster Compléments d’autres moteurs de stockage MySQL
Débit en écriture élevé avec réponse à faible latence Taille de base de données supérieure à 2 To
Disponibilité à 99,999 % avec reprise inférieure à une seconde et récupération automatique Lignes exigeant plus de 8 Ko de mémoire (à l’exception des objets BLOB) et 128 champs
Besoins d’évolutivité impossibles à prévoir Capacité requise de stockage des objets supérieure à 2 Mo
Accès principalement aux clés primaires ou aux sous-composants d’une clé primaire à plusieurs champs Volume élevé de rapports impliquant la nécessité d’analyses de tables complètes avec jointures complexes
Jointures simples Prise en charge des clés étrangères
Vous devez également vous poser les questions suivantes pour justifier le recours à MySQL Cluster dans vos projets tout en ciblant un haut niveau de disponibilité et de performance en temps réel.
Q : Quelles sont les applications idéales pour MySQL Cluster ?
R : Les tables à gérer à l’aide de MySQL Cluster sont partitionnées et distribuées sur des nœuds distincts ; MySQL Cluster utilise une architecture parallèle dotée de plusieurs nœuds maîtres. Cette caractéristique favorise l’exécution simultanée de très gros volumes d’opérations en lecture ET en écriture. Toutes les mises à jour sont instantanément à la disposition de l’ensemble des nœuds d’applications (API SQL ou NDB) permettant d’accéder aux données stockées dans les nœuds de données.
Lors de la distribution progressive des charges en écriture sur tous les nœuds de données, MySQL Cluster est capable de garantir de très hauts niveaux de débit en écriture et d’évolutivité pour les charges de travail transactionnelles. Qui plus est, MySQL Cluster peut exploiter un grand nombre de nœuds SQL exécutés en parallèle, et ce dans une configuration où chaque nœud gère plusieurs connexions et permet la prise en charge d’applications transactionnelles hautement concurrentes.
Tenant compte des éléments examinés ci-avant, voici en guise d’exemple les applications dans lesquelles le déploiement de MySQL Cluster a été un succès. Consultez une liste complète des études de cas utilisateur et des applications MySQL.
  • Services AAA (Authentication/Authorization/Accounting)
  • Serveur d’applications
  • Magasin de données LDAP/RADIUS/Diameter
  • Services de commerce électronique (paniers, transactions de paiement, gestion des commandes, etc.)
  • Services IMS (IP Multimedia Subsystem)
  • Nœuds de réseau intelligent
  • Services géo-localisés/de présence
  • Magasins/files d’attente des messages
  • Fourniture de contenu nomade
  • Magasins et portails d’applications en ligne
  • Jeux en ligne
  • Traitement des paiements
  • Plateformes de fourniture de services et services à valeur ajoutée dans le secteur des télécoms
  • Bases de données d’abonnés (HLR, HSS, etc.)
  • Services VoIP, IPTV et de vidéo à la demande
  • Gestion de sessions Web
Q : Dois-je tester/certifier de nouveau mon application conformément à une nouvelle version de MySQL Cluster ?
R : Au final, cette décision revient au propriétaire de l’application et a pour objectif de parvenir à un équilibre entre le temps et les efforts à consacrer pour retester l’application par rapport à la probabilité prévue et l’impact d’un problème détecté si l’application est déployée sans tests supplémentaires. Le propriétaire de l’application doit également évaluer s’il est nécessaire de mesurer encore une fois les performances de cette dernière face à la nouvelle version de MySQL Cluster.
Deux raisons principales pourquoi une application peut échouer en cas de transfert vers une nouvelle version de MySQL Cluster :
  • Changement d’API ou fonctionnel volontairement apporté à MySQL Cluster
  • Bogue dans le code introduit par erreur dans la version publiée
Il existe trois catégories de changement de version pour MySQL Cluster :
  • Version principale : signalée par la lettre « X » dans le changement de version X.Y.Z. Ces versions présentent généralement des fonctions innovantes clés et des changements importants en matière d’évolution du code. La probabilité que de nouveaux bogues ou changements d’API/fonctionnels non compatibles avec votre application soient introduits dans une version principale est bien plus importante que pour les versions mineures ou les versions de maintenance.
  • Version mineure : signalée par la lettre « Y » dans le changement de version X.Y.Z. De par leur aspect fonctionnel et évolutif en matière de code, les changements généralement apportés dans ces versions sont modestes (des changements qui apparaîtront moins importants encore si vous les comparez à la toute dernière version de maintenance de la précédente version plutôt qu’à une version antérieure).
  • Versions de maintenance : signalées par la lettre « Z » dans le changement de version X.Y.Z. Ces versions ont pour objectif d’apporter des correctifs aux bogues et problèmes constatés et non des changements fonctionnels. Le risque majeur est que l’un des correctifs engendre un nouveau problème.
MySQL fournit les ressources suivantes qui peuvent aider les propriétaires des applications dans leur prise de décision :
  • Pour les versions principales et mineures, des livres blancs et des séminaires Web à votre disposition décrivent les améliorations fonctionnelles clés : http://www.mysql.fr/products/database/cluster/resources.html
  • La section consacrée au plan de développement de MySQL Cluster dans le guide de référence de ce dernier offre un aperçu des changements fonctionnels survenus dans chaque version principale et mineure. Vous pouvez vous procurer le dernier guide de référence à l’adresse suivante : http://dev.mysql.com/doc/#cluster.
  • Les changements apportés dans une version de maintenance (en terme de description des bogues corrigés) sont décrits dans le fichier « ChangeLog » inclus avec chaque version.
  • Les rapports des bogues actifs et résolus sont disponibles à l’adresse http://bugs.mysql.com.
  • Consultez également notre guide d’évaluation et d’autres ressources produit pour en savoir plus sur MySQL Cluster.

Aspects techniques

Q : Quelles sont les applications idéales pour MySQL Cluster ? ?
R :
  • Disponibilité
    • 99,999 % (temps d'arrêt inférieurs à 5 minutes par an)
  • Performances
    • Temps de réponse de 5 à 10 millisecondes (avec réplication synchrone et accès via API NDB)
    • Débit supérieur à 10 000 transactions répliquées par seconde sur un cluster à 2 nœuds, avec 1 processeur par nœud (configuration minimale)
    • Débit supérieur à 100 000 transactions répliquées par seconde sur un cluster à 4 nœuds, avec 2 processeurs par nœud (configuration basse)
  • 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.
    MySQL Cluster est une base de données en mémoire distribuée* qui; dans le cadre des requêtes atomiques (telles que la recherche de clés primaires), est rapide et sans surprise. En revanche, l'architecture distribuée n'est pas une solution idéale pour des requêtes ultra complexes avec un grand nombre de jointures. De meilleures performances peuvent être obtenues si l'application bénéficie de la fonctionnalité de prise en compte de la distribution (ce qui permet de conserver et de gérer dans le même nœud de données tous les enregistrements auxquels la transaction a accès). À l'aide de l'API NDB, les transactions peuvent faire l'objet d'un traitement par lots en vue d'accroître davantage les performances.

    *Notez que MySQL Cluster autorise aussi la prise en charge des données sur disque, améliorant encore la flexibilité et l'évolutivité qu'offre la base de données.
    Q: Combien de serveurs physiques sont-ils nécessaires pour créer une configuration de cluster minimale ?
    R : Pour une redondance acceptable, deux nœuds serveur MySQL, deux nœuds de données et un nœud de gestion sont recommandés. À des fins d'évaluation, il est possible de n'utiliser qu'un seul serveur physique mais l'évaluation aurait lieu à un niveau très élémentaire. 

    Q: Est-il possible de scinder géographiquement les nœuds de données ?
    R : Cette approche n'est ni recommandée, ni prise en charge. La latence entre les nœuds de données au sein du cluster ne devrait pas être trop importante et les nœuds devraient généralement se trouver dans le même datacenter ou la même armoire. Néanmoins, MySQL Cluster CGE autorise la réplication géographique et vous permet de disposer de deux installations de cluster distinctes dans une configuration maître/esclave. Ce type de réplication est asynchrone si on le compare à la réplication synchrone entre nœuds de données dans une installation de cluster unique. Par conséquent, la latence n'a aucune incidence sur les performances de l'application. 

    Q: Quelles API d'accès aux données sont disponibles pour MySQL Cluster ?
    R : Les applications peuvent être développées au moyen de n'importe quel connecteur MySQL. MySQL Cluster CGE offre en plus une connectivité native avec C++, Java et LDAP. 

    Q: Les interfaces des applications 32 bits sont-elles différentes des interfaces 64 bits ?
    R : Non. Les interfaces sont les mêmes. 

    Q: MySQL Cluster convient-il en qualité de base de données embarquée?
    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 »
    Q: Qu'est-ce que la réplication géographique dans le cas de MySQL Cluster ?
    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. 

    Q: La réplication est-elle bidirectionnelle ?
    R : Oui. La réplication unidirectionnelle et bidirectionnelle est prise en charge dans MySQL Cluster CGE. 

    Q: Lorsqu'il est utilisé comme base de données en mémoire, MySQL Cluster risque-t-il de perdre des données ?
    R : En règle générale, les configurations MySQL Cluster disposent au moins de deux 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. 

    Q: MySQL Cluster inclut-il une option sans 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.

    Top of Page



    Questions fréquemment posées (FAQ) pour MySQL Cluster Manager

    Q: MySQL Cluster Manager est-il un logiciel open source ?
    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’une ou plusieurs licences de l’édition MySQL Cluster CGE, contactez l’équipe commerciale MySQL.
    Q: Qu’est-ce que MySQL Cluster Manager ?
    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.
    Q: Quels sont les avantages de MySQL Cluster Manager ?
    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.
    Q: Pouvez-vous donner un exemple pratique dans le cadre duquel MySQL Cluster Manager améliore la productivité et réduit les risques de temps d’arrêt ?
    R : À titre d’exemple, les opérations de gestion qui exigent le redémarrage propagé d’une base de données MySQL Cluster qui, elle-même nécessitait auparavant 46 commandes1 manuelles et prenait 2 heures et demie sur le temps d’un DBA2, 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.
    Q: Quel type de fonction de gestion MySQL Cluster Manager fournit-il ?
    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 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.
    Q: MySQL Cluster Manager gère-t-il le cluster tout entier ou seulement les nœuds individuels au sein de ce cluster ?
    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.
    Q: Quel type de fonction de surveillance MySQL Cluster Manager offre-t-il ?
    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.
    Q: De nombreuses fonctions de MySQL Cluster Manager sont déjà disponibles ou peuvent être intégrées dans des scripts. Quel en est l’avantage ?
    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.
    Q: MySQL Cluster Manager peut-il récupérer des nœuds défaillants dans un cluster ?
    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.
    Q: Ainsi, MySQL Cluster Manager peut gérer, surveiller et récupérer tous les nœuds au sein d’un cluster ?
    R : Oui. À l’exception des nœuds d’applications qui utilisent l’API NDB native, il est capable de gérer, de surveiller et de récupérer les nœuds de données, les nœuds de gestion et les nœuds SQL (nœuds serveur MySQL).
    Q: La défaillance d’un agent MySQL Cluster Manager a-t-elle un impact sur la disponibilité de la base de données MySQL Cluster ?
    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.
    Q: Comment MySQL Cluster Manager est-il mis en œuvre dans la base de données MySQL Cluster ?
    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.
    Q: Quel impact MySQL Cluster Manager a-t-il sur les précédentes approches de gestion de MySQL 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).
    Q: Ai-je toujours besoin de nœuds de gestion au sein de mon cluster ?
    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.
    Q: MySQL Cluster Manager permet-il de redémarrer des agents défaillants ?
    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/.
    Q: Est-il possible de resynchroniser automatiquement des agents MySQL Cluster Manager récupérés avec d’autres agents ?
    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.
    Q: MySQL Cluster Manager peut-il maintenir des données de configuration lors de tous les redémarrages ?
    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.
    Q: Comment MySQL Cluster Manager garantit-il que la configuration du cluster reste cohérente sur tous les nœuds du cluster ?
    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 des communications et la synchronisation des demandes de reconfiguration, les risques d’erreurs résultant de la distribution manuelle des fichiers de configuration sont écartés.
    Q: Est-il possible de rétrograder MySQL Cluster Manager vers des clusters existants déjà déployés ?
    R : Cela est possible mais uniquement via une procédure manuelle documentée à l’adresse suivante : http://dev.mysql.com/doc/cluster-manager/en/mcm-install-cluster-migrating.html.
    Notez que cette procédure n’exige aucun temps d’arrêt de la part du cluster lorsque vous redémarrez tous les nœuds afin d’utiliser les nouveaux fichiers de configuration définis pour la gestion du cluster. La procédure est proposée « en l’état » et il incombe aux utilisateurs de l’adapter au mieux selon leurs besoins et de confirmer qu’elle fonctionne avant de tenter de l’appliquer à leur base de données en direct.
    Q: Est-il possible de gérer mes déploiements de MySQL Cluster à l’aide de MySQL Enterprise Monitor ?
    R : Vous pouvez faire appel à MySQL Enterprise Monitor pour surveiller les nœuds d’API serveur MySQL que vous déployez dans le cadre du cluster mais pas les nœuds de données ou de gestion.
    Un point essentiel à retenir est que, si MySQL Enterprise Monitor ne gère pas actuellement les nœuds de données, vous pouvez néanmoins l’utiliser pour la gestion et la surveillance des nœuds d’API serveur MySQL intervenant dans le déploiement d’un cluster. MySQL Enterprise Monitor peut surveiller l’état des nœuds d’API serveur MySQL et fournir des données de mesure des performances. Il offre également un avantage avec la présence du Query Analyzer qui permet d’afficher les requêtes trop exigeantes en termes de temps et de ressources.
    Q: MySQL Cluster Manager prend-il en charge le protocole SNMP ?
    R : Pas dans la première version.
    Q: MySQL Cluster Manager permet-il de surveiller et de gérer la réplication géographique ?
    R : Pas dans la première version.
    Q: MySQL Cluster Manager peut-il gérer l’ajout de nouveaux nœuds dans le cluster ?
    R : Pas dans la première version.
    Q: Quelles plateformes MySQL Cluster Manager prend-il en charge ?
    R : Consultez la page Plates-formes prises en charge.
    Q: Quelles versions de la base de données MySQL Cluster sont prises en charge par MySQL Cluster Manager ?
    R : MySQL Cluster 6.3 et version supérieure.
    Q: Comment puis-je en savoir davantage sur MySQL Cluster Manager ?
    R : En consultant les ressources à votre disposition, notamment : Livre blanc MySQL Cluster Manager


    1Une configuration MySQL Cluster de base composée de 4 nœuds de données MySQL Cluster, 2 nœuds serveur SQL MySQL et 2 nœuds de gestion MySQL Cluster installés sur des serveurs individuels (8 au total). Les opérations menées au total incluent les commandes suivantes : 1 vérification préliminaire de l’état du cluster, 8 commandes ssh par serveur, 8 commandes d’arrêt par processus, 4 commandes scp pour les fichiers de configuration (2 commandes mgmd et 2 commandes mysqld), 8 commandes de démarrage par processus, 8 vérifications pour les processus démarrés et rejoints, 8 vérifications de finalisation des processus et 1 vérification pour la finalisation du cluster tout entier. Le nombre total de commandes ne comprend pas la modification manuelle de chaque fichier de configuration. Cette phase exclut les étapes de préparation visant à copier le nouveau package logiciel sur chaque hôte et à définir son emplacement : Mysql> add package --basedir=/usr/local/mysql_7_0_7 7.0

    2Redémarrage par un DBA de 4 nœuds de données MySQL Cluster, chacun étant composé de 6 Go de données et exécution de 10 000 opérations par seconde : http://www.clusterdb.com/mysql-cluster/mysql-cluster-data-node-restart-times/.


    Top of Page