17.3.4.4 Définitions des noeuds de stockage dans un cluster MySQL

La section [DB] (et son alias [NDBD] ) servent à configurer le comportement des noeuds de stockage. Il y a de nombreux paramètres spécifiés qui contrôlent les tailles de buffer, les tailles de files ou les délais d'expiration, etc. Le seul paramètre obligatoire est soit ExecuteOnComputer ou HostName et le paramètre NoOfReplicas qui doit être défini dans la section [DB DEFAULT] . La plupart des paramètres doivent être dans la section [DB DEFAULT] . Seuls les paramètres explicitement présentés comme ayant une valeur local peuvent être modifiés dans la section [DB] . HostName , Id et ExecuteOnComputer doivent être définies dans la section [DB] .

La valeur de Id , ou l'identité d'un noeud de stockage peut être allouée au démarrage du noeud. Il est toujours possible d'assigner un identifiant dans un fichier de configuration.

[DB]Id

Cette identitiant est l'identité du noeud, utilisé pour référencer le noeud dans le cluster. C'est un entier compris entre 1 et 63. Chaque noeud du cluster doit avoir une identité distincte.

[DB]ExecuteOnComputer

Cela fait référence à un des ordinateurs définis dans la section 'Computer'.

[DB]HostName

Ce paramètre revient à spécifier un ordinateur sur lequel placer l'exécution. Il définit un nom d'hôte sur lequel réside le noeud de stockage. Ce paramètre ou ExecuteOnComputer est obligatoire.

[DB]ServerPort

Chaque noeud dans le cluster utiliser un port pour se connecter avec les autres noeuds du cluster. Ce port est aussi utilisé pour les connexions lors de la phase de mise en place. Ce port par défaut sera utilisé pour s'assurer qu'aucun noeud sur le même ordinateur ne reçoit le même numéro de port. Le numéro de port minimum est 2202.

[DB]NoOfReplicas

Ce paramètre ne peut être configuré que dans la section [DB DEFAULT] car c'est un paramètre global. Il définit le nombre de répliques de chaque table stockée dans le cluster. Ce paramètre spécifie aussi la taille du groupe de noeuds. Un groupe de noeud est un ensemble de noeuds qui stockent les mêmes informations.Les groupes de noeuds sont formés implicitement. Le premier groupe est formé par les noeuds de stockage avec les identités les plus petites, puis par ordre d'identité croissante. Par exemple, supposons que nous avons 4 noeuds de stockage et que NoOfReplicas vaut 2. Les quatres noeuds de stockage ont les identifiants 2, 3, 4 et 5. Le premier groupe de noeud sera formé par les noeuds 2 et 3, et le second groupe sera formé de 4 et 5. Il est important de configurer le cluster pour que les noeuds d'un même groupe ne soit pas placé sur le même ordinateur. Sinon, cela pourrait conduire à avoir un point de faiblesse : un seul ordinateur peut planter le cluster.

Si aucune identité n'est spécifiée, alors l'ordre des noeuds de stockage va être le facteur déterminant du groupe de noeuds. Le groupe de noeud ainsi généré peut être affiché avec la commande SHOW dans le client de gestion.

Il n'y a pas de valeur par défaut, et la valeur maximale est 4.

[DB]DataDir

Ce paramètre spécifie le dossier où les fichiers de traces, les fichiers de log, et les fichiers d'erreurs sont rangés.

[DB]FileSystemPath

Ce paramètre spécifie le dossier où tous les fichiers créés pour stocker les meta-données, les logs de REDO, les logs de UNDO et les fichiers de données sont rangés. La valeur par défaut est DataDir . Le dossier doit être créé avant de lancer le processus 'ndbd' .

Si vous utilisez la hierarchie de dossiers recommandée, vous utiliserez le dossier /var/lib/mysql-cluster . Sous ce dossier, un autre dossier ndb_2_fs sera créé (si l'identifiant de noeud est 2), pour servir de fichier système pour le noeud.

[DB]BackupDataDir

Il est possible de spécifier le dossier où les sauvegardes seront placées. Par défaut, le dossier FileSystemPath/ BACKUP sera utilisé.

[DB]DataMemory

Ce paramètre est l'un des paramètres les plus importants, car il définit l'espace disponible pour stocker les lignes dans la bases de données. Tout l'espace DataMemory sera alloué en mémoire : il est donc important que la machine contienne assez de mémoire pour stocker DataMemory .

DataMemory sert à stocker deux choses. Il stocke les lignes de données. Chaque ligne est de taille fixe. Les colonnes VARCHAR sont stockées sous forme de colonnes à taille fixe. De plus, chaque enregistrement est stocké dans une page de 32 ko avec 128 octets d'entête. Il y a donc un peu de pertes pour chaque page, car chaque ligne n'est stockée que sur une seule page. La taille maximale d'une colonne est actuellement de 8052 octets.

DataMemory sert aussi à stocker les index ordonnés. Les index ordonnées prennent environs 10 octets par ligne. Chaque ligne dans une table est représentée par un index ordonné.

DataMemory est constitués de pages de 32ko. Ces pages sont allouées comme partitions pour les tables. Chaque table est généralement répartie en autant de partition qu'il y a de noeud dans le cluster. Par conséquent, il y a le même nombre de partition (fragments) que la valeur de NoOfReplicas . Une fois qu'une page a été allouée, n'est pas possible actuellement de la libérer. La méthode pour récupérer cet espace est d'effacer la table. Effecter une restauration de noeud va aussi compresser la partition, car toutes les lignes seront insérées dans une partition vide, depuis un autre noeud.

Un autre aspect important est que DataMemory contient aussi les informations de UNDO (annulation) pour chaque ligne. Pour chaque modification d'une ligne, une copie de la ligne est faite dans l'espace DataMemory . De plus, chaque copie va aussi avoir une instance dans l'index ordonné. Les index Hash unique sont modifié uniquement lorsque les colonnes uniques sont modifiées dans dans ce cas, une nouvelle entrée est insérée dans la table. Au moment de l'archivage (commit), l'ancienne valeur est effacée. Il est donc nécessaire de pouvoir allouer la mémoire nécessaire pour gérer les plus grosses transactions effectuée dans le cluster.

Effectuer une transaction de grande taille n'a pas d'autre intérêt avec le Cluster MySQL que la cohérence, ce qui est la base des tranasctions. Les transactions ne sont pas plus rapides, et consomment beaucoup de mémoire.

La taille par défaut de DataMemory est 80MB. La taille minimum est de 1MB. Il n'y a pas de taille maximum, mais en réalité, il faut adapter la valeur pour éviter que le système n'utilise la mémoire sur le disque, par ce que la mémoire physique a été dépassée.

[DB]IndexMemory

IndexMemory est le paramètre qui contrôle la quantité d'espace utilisée pour les index hash de MySQL Cluster. Les index hash sont toujours utilisé pour les clés primaires, les index uniques et les contraintes d'unicité. En fait, lors de la définition d'une clé primaire et d'une clé unique, deux index distincts seront créés par MySQL CLuster. Un index sera un hash utilisé pour les accès aux lignes, et pour le verrouillage. Il est aussi utilisé pour les contraintes d'unicité.La taille d'un index hash est de 25 octets plus la taille de la clé primaire. Pour les clés primaires dont la taille dépasse 32 octets, ajoutez un autre 8 octets pour des références internes.

Par exemple, observons la table suivante.

CREATE TABLE example (     a INT NOT NULL,     b INT NOT NULL,     c INT NOT NULL,     PRIMARY KEY(a),     UNIQUE(b) ) ENGINE=NDBCLUSTER;

Nous avons ici 12 octets d'entête (puisque des colonnes non nulles économisent 4 octets), plus 12 octets par ligne. De plus, nous avons deux index ordonnés sur les colonnes a et b, qui utilisent chacun 10 octets par ligne. Nous aurons aussi une clé primaire hash avec environ 29 octets par ligne. La contrainte unique est implémentée par une table séparée, avec b comme clé primaire et a comme colonne. Cette table va donc consommer encore 29 autres octets en mémoire par ligne, plus 12 octets d'entete et 8 octets pour les données.

Pour une table d'un million de lignes, nous aurons besoin de 58 Mo de mémoire pour gérer les index en mémoire, la clé primaire et la contrainte d'unicité. Pour DataMemory , nous aurons besoin de 64Mo de mémoire, pour gérer les lignes de la table de base et celles de la table d'index, plus les deux tables d'index ordonnés.

En conclusion, les index hash consomment beaucoup d'espace en mémoire vive, mais fournissent un accès accéléré aux données. Ils sont aussi utilisé dans les cluster MySQL pour gérer les contraintes d'unicité.

Actuellement, les seuls algorithmes de partitionnement sont le hashage et les index ordonnés, qui sont locaux à chaque noeud, et ne peuvent pas prendre en compte les contraintes d'unicité en général.

Un point important pour les deux options IndexMemory et DataMemory est que le total de la base de données est la taille de DataMemory et IndexMemory dans chaque groupe. Chaque groupe est utilisé pour stocker les informations répliquées, ce qui fait que si vous avez 4 noeuds avec 2 répliques, cela fait 2 groupes de noeuds, et le total de DataMemory disponible est 2* DataMemory dans chaque noeud.

Un autre aspect important est les modifications de DataMemory et IndexMemory . Tout d'abord, il est fortement recommandé d'avoir la même quantité de DataMemory et IndexMemory sur tous les noeuds. Comme les données sont distribuées équitablement entre les noeuds du cluster, l'espace disponible n'est pas supérieure à la plus petite quantité d'espace disponible sur un des noeuds du cluster, multiplié par le nombre de groupe de noeuds.

DataMemory et IndexMemory peuvent être modifiés, mais il est dangeureux de le réduire, car cela peut conduire à des problèmes de redémarrage pour un noeud, ou même pour le cluster, car il n'y aura plus assez de mémoire pour restaurer les tables. Accroitre les valeurs doit être facile à faire, mais il est recommandé, pour ce type de mise à jour, de faire une modification comparable à une mise à jour du logiciel : modificaiton du fichier du fichier de configuration, puis redémarrage du serveur de gestion, et chaque serveur est relancé manuellement, un à la fois.

IndexMemory n'est pas utilisé à cause des modifications mais à cause des insertions : ces dernières sont insérées immédiatement, alors que les effacements ne sont pris en compte que lorsque la transaction est archivée.

La valeur par défaut de IndexMemory est 18Mo. La taille minimale est de 1Mo.

[DB]MaxNoOfConcurrentTransactions

Pour chaque transaction active dans le cluster, il y a besoin d'une ligne de transaction dans l'un des noeuds du cluster. Le rôle de cette coordination de transaction est réparti entre tous les noeuds et ainsi, le nombre de lignes de transactions dans le cluster est le nombre de noeuds dans le cluster.En fait, les lignes de transactions sont allouées aux serveurs MySQL. Normalement, il y a au moins une ligne de transaction allouée dans le cluster par connexion qui utilise ou a utilisé une table dans le cluster. Par conséquent, il faut s'assurer qu'il y a plus de lignes de transation dans le cluster qu'il n'y a de connexions simultanées à tous les serveurs du cluster MySQL.

Ce paramètre doit être le même pour tous les noeuds du serveur.

Modifier ce paramètre n'est jamais facile, et peut conduire à un crash du système. Lorsqu'un noeud crashe, le noeud le plus ancien va prendre en charge l'état des transactions qui avaient lieu dans le noeud perdu. Il est donc important que ce noeud ait autant de lignes de transactions que le noeud perdu.

La valeur par défaut pour ce paramètre est 4096.

[DB]MaxNoOfConcurrentOperations

Ce paramètre est sujet à modifications par les utilisateurs. Les utilisateurs qui effectuent des transactions courtes et rapides n'ont pas besoin de lui donner une valeur trop haute. Les applications qui veulent utiliser des transactions de grande taille, impliquant de nombreuses lignes devront accroître sa valeur.

Pour chaque transaction qui modifie des données dans le clsuter, il faut allouer des lignes d'opération. Il y a des lignes d'opération au niveau de la coordination de transaction, et dans les noeuds où les transformations ont lieu.

Les lignes d'opération contiennent des informations d'état qui doivent être capables de retrouver des lignes d'annulation, des files de verrous et toutes les autres informations d'état.

Pour dimensionner le cluster afin de gérer des transactions où un million de lignes doivent être mises à jours simultanément, il faut donner à ce paramètre la valeur d'un million divisé par le nombre de noeuds. Pour un cluster ayant 4 noeuds de stockage, la valeur sera donc de 250000.

De plus, les lectures qui posent des verrous utilisent aussi des lignes d'opération. De la mémoire supplémentaire est allouée dans les noeuds locaux pour gérer les cas où la distribution n'est pas parfaite entre les noeuds.

Lorsqu'une requête impose l'utilisation d'un index hash unique, il y aura automatiquement 2 lignes d'opération pour chaque ligne de la transaction. La première représente la lecture dans la table d'index, et la seconde gère l'opération dans la table de base.

La valeur par défaut pour ce paramètre est 32768.

Ce paramètre gère en fait 2 aspects qui peuvent être configurés séparément. Le premier aspect spécifie le nombre de lignes d'opérations qui peuvent être placés dans la coordination de transaction. Le second aspect spécifie le nombre de lignes d'opérations qui seront utilisées dans la base de données locale.

Si une très grande transaction est effectuée sur un cluster de 8 noeuds, elle aura besoin d'autant de lignes d'opération pour la coordination de transaction qu'il y a de lecture, modification et effacement impliquées dans la transaction. La transaction va répartir les lignes d'opération entre les 8 noeuds. Par conséquent, s'il est nécessaire de configuer le système pour une grosse transaction, il est recommandé de configurer les noeuds séparément. MaxNoOfConcurrentOperations va toujours être utilisé pour calculer le nombre de lignes d'opérations dans la coordination de transaction.

Il est aussi important d'avoir une idée des contraintes de mémoire pour ces lignes d'opération. En MySQL 4.1.5, les lignes d'opération consomment 1Ko par ligne. Ce chiffre est appelé à réduire dans les versions 5.x.

[DB]MaxNoOfLocalOperations

Par défaut, ce paramètre est calculé comme 1,1 fois MaxNoOfConcurrentOperations ce qui est bon pour les systèmes avec de nombreuses requêtes simultanées, de petite taille. Si la configuration doit gérer une très grande transaction une fois de temps en temps, et qu'il y a de beaucoup de noeuds, il est alors recommandé de configurer cette valeur séparément.

[DB]MaxNoOfConcurrentIndexOperations

Pour les requêtes utilisant un index unique hash, un autre jeu de lignes d'opération sont temporairement utilisées durant la phase d'exécution de la requête. Ce paramètre configure la taille de la file qui acceuille ces lignes. Par conséquent, cette mémoire n'est utilisée que lors de l'exécution d'une requête, et dès la fin de l'exécution, les lignes sont libérées. L'état nécessaire pour gérer les annulations et archivages est géré par les lignes d'opérations permanantes, où la taille de la file est gérée par MaxNoOfConcurrentOperations .La valeur par défaut pour ce paramètre est 8192. Seuls les situations où un très haut niveau de paralellisme utilisant des index uniques hash doivent augmenter cette valeur. La réduction de cette valeur permet d'économiser de la mémoire, si l'administrateur est certains que le paralellisme reste rare dans le cluster.

[DB]MaxNoOfFiredTriggers

La valeur par défaut pour MaxNoOfFiredTriggers est 4000. Normalement, cette valeur doit être suffisante pour la plupart des systèmes. Dans certains cas, il est possible de réduire cette valeur si le paralellismen n'est pas trop haut dans le cluster.Cette option est utilisée lorsqu'une opération est effectuée, et affecte un index hash unique. Modifier une colonne qui fait partie d'un index unique hash ou insérer/effacer une ligne dans une table avec un index unique hash va déclencher une insertion ou un effacement dans l'index de la table. Cette ligne est utilisée durant l'attente de la fin de l'exécution de cette opération. C'est une ligne qui ne dure pas longtemps, mais elle peut malgré tout réclamer plusieurs lignes pour des situations temporaires d'écritures paralelles sur la table de base, contenant les index uniques.

[DB]TransactionBufferMemory

Ce paramètre est aussi utilisé pour lister les opérations de modifications d'index. Elle garde les informations de clé et colonne de l'opération en cours. Il doit être exceptionnel de modifier ce paramètre.De plus, les opérations de lecture et écriture utilisent un buffer similaire. Ce buffer est encore plus temporaire dans son utilisation, ce qui fait que c'est un paramètre de compilation, qui vaut 4000*128 octets (500Ko). Le paramètre st ZATTRBUF_FILESIZE dans Dbtc.hpp . Un buffer similaire pour les informations de clé, qui représente 4000*16 octets, soit 62.5ko d'espace. Ce paramètre est ZDATABUF_FILESIZE dans Dbtc.hpp . Dbtc est le module qui gère la coordination de transaction.

Des paramètres similairse existents dans le module Dblqh pour gérer les lectures et modifications lorsque les données ont été localisées. Dans Dblqh.hpp avec ZATTRINBUF_FILESIZE qui vaut 10000*128 octets (1250ko) et ZDATABUF_FILE_SIZE , qui vaut 10000*16 octets (environ 156ko). Nous n'avons aucune connaissance de situation qui soient limitées par ces valeurs.

La valeur par défaut de TransactionBufferMemory est 1Mo.

[DB]MaxNoOfConcurrentScans

Ce paramètre est utilisé pour contrôler la quantité de scans paralelles qui sont effectués dans le cluster. Chaque coordination de transaction peut gérer un certain nombre de scan de tables simultanément, et ce nombre est limité par cette option. Chaque partition va utiliser une ligne de scan dans le noeud où la partition est située. Le nombre de lignes est la taille de ce paramètre multiplié par le nombre de noeuds, ce qui fait que le cluster peut supporter le nombre maximal de scan, multiplié par le nombre de noeuds du cluster.Les scans sont effectués dans deux situations. La première est lorsqu'aucun index hash ou ordonné n'a pu être trouvé pour gérer la requête. Dans ce cas, la requête est exécutée avec un scan de table. La seconde est lorsqu'il n'y a pas d'index hash, mais seulement un index ordonné. Utiliser l'index ordonné, revient à faire un scan de table paralelle. Comme l'ordre n'est conservé que dans les partitions locales, il est nécessaire de faire le scan dans toutes les partitions.

La valeur par défaut de MaxNoOfConcurrentScans est 256. La valeur maximale est de 500.

Ce paramètre va toujours spécifier le nombre de scans possibles dans la coordination de transaction. Si le nombre local de scan n'est pas fournit, il est calculé comme le produit de MaxNoOfConcurrentScans et du nombre de noeuds de stockages du système.

[DB]MaxNoOfLocalScans

Il est possible de spécifier le nombre de lignes de scan locaux, si les scans ne sont pas totalement paralelles.

[DB]BatchSizePerLocalScan

Ce paramètre est utilisé pour calculer le nombre de lignes de verrous qui est nécessaire pour gérer les opérations de scans courantes.

La valeur par défaut est 64 et cette valeur est très liée au paramètre ScanBatchSize défini dans l'interface des noeuds.

[DB]LongMessageBuffer

Ceci est un buffer interne utilisé pour passer des messages au noeuds, et entre les noeuds. Il est hautement improbable que quiconque veuille modifier cette valeur, mais il est malgré tout disponible. Par défaut, ce paramètre vaut 1Mo.

[DB]NoOfFragmentLogFiles

Ceci est un paramètre important qui indique la taille du fichier de log de REDO. Les logs REDO sont organisés en boucle, et il est important que la fin et le début ne se chevauchent pas. Lorsque la queue et la tête se rapprochent dangeureusement l'un de l'autre, le noeud va commencer à annuler les modifications, car il n'y a plus de place pour les lignes de modifications.Le log de REDO n'est pas supprimés jusqu'à ce que trois jalons locaux soient passés depuis l'insertion dans le log. La vitesse d'apparition d'un jalon est contrôlée par un jeu de paramètres : tous ces paramètres sont donc liés.

La valeur par défaut de ce paramètre est 8, ce qui signifie que 8 jeux de 4*16Mo fichiers. Cela représente un total de 512Mo. L'unité de stockage est de 64Mo pour le log de REDO. Dans les serveurs a fort taux de modification, il faut augmenter considérablement cette valeur. Nous avons vu des cas de test où il a fallu mettre cette valeur à plus de 300.

Si les jalons sont lents à venir, et qu'il y a tellement d'écritre dans la base que les fichiers de logs sont remplis, que le fichier de log de queue ne peut pas être supprimé pour assurer la restauration, les transactions de modification seront interrompues avec une erreur interne 410, qui sera transformée en message : Out of log file space temporarily . Cette condition restera en place jusqu'à ce qu'un jalon soit atteint, et que la queue du log puisse avancer.

[DB]MaxNoOfSavedMessages

Ce paramètre limite le nombre de fichiers de trace qui seront conservés sur le serveur, avant de remplacer un ancien fichier de trace. Les fichiers de trace sont générés lorsque le noeud crash pour une raison donnée.

La valeur par défaut est de 25 fichiers de trace.

[DB]MaxNoOfAttributes

Ce paramètre définit le nombre d'attributs qui peuvent être définis dans le cluster.La valeur par défaut pour ce paramètre est 1000. La valeur minimale est 32 et il n'y a pas de maximum. Chaque attribut consomme environ 200 octets d'espace, car les meta-données sont totalement répliqués entre les noeuds.

[DB]MaxNoOfTables

Un objet de table est alloué pour chaque table, pour chaque index hash unique et pour chaque index ordonné. Ce paramètre fixe le nombre maximal d'objet de table qui soit alloué. Pour chaque attribut qui contient un type de données BLOB , une autre table est utilisée pour stocker la partie principale des données BLOB . Ces tables doivent aussi êtr prises en compte lorsque vous définissez les tables.La valeur par défaut pour ce paramètre est 128. La valeur minimale est de 8, et il n'y a pas de maximum. Il y a des limitations internes, qui empêchent d'aller au dela de 1600. Chaque objet de table consomme environs 20ko de mémoire par noeud.

[DB]MaxNoOfOrderedIndexes

Pour chaque index ordonnée dans le cluster, des objets sont alloués pour décrire ce qu'ils indexent et leurs stockage. Par défaut, chaque index défini aura un index ordonné associé. Les index uniques et les clés primaires ont tous deux un index ordonné et un index hash.La valeur par défaut pour ce paramètre est 128. Chaque objet consomme environ 10ko par noeud.

[DB]MaxNoOfUniqueHashIndexes

Pour chaque index unique (pas pour les index primaires), un table spéciale est allouée pour assurer la correspondance entre la clé primaire et la clé unique de la table indexée. Par défaut, il y aura un index ordonné de défini pour chaque index unique. Pour éviter cela, utilisez l'option USING HASH .La valeur par défaut de 64. Chaque index va consommer environ 15ko par noeud.

[DB]MaxNoOfTriggers

Pour chaque index hash unique, un trigger interne de modification, insertion ou effacement est alloué. Cela fait 3 triggers pour chaque index hash unique. Les index ordonnées utilisent un seul objet trigger. Les sauvegardes utilisent aussi trois objets trigger pour chaque table normale dans le cluster. Lorque la réplication entre cluster est supportée, elle va aussi utiliser un trigger interne.Ce paramètre limite le nombre d'objet trigger dans le cluster.

La valeur par défaut pour ce paramètre est 768.

[DB]MaxNoOfIndexes

Ce paramètre est abandonnée depuis MySQL 4.1.5. Il faut désormais utiliser MaxNoOfOrderedIndexes et MaxNoOfUniqueHashIndexes à la place.

Ce parmètre ne sert que pour les index hash unique. Il faut une ligne dans ce buffer pour chaque index hash unique défini dans le cluster.

La valeur par défaut pour ce paramètre est 128.

[DB]LockPagesInMainMemory

Pour certains systèmes d'explications tels que Solaris et Linux, il est possible de verrouiller un processus en mémoire et éviter les problèmes de swap. C'est une fonctionnalité important pour améliorer le temps réel du cluster.

Par défaut, cette fonctionnalité n'est pas activée.

[DB]StopOnError

Ce paramètre indique si le processus doit s'arrêter sur une erreur, ou s'il doit faire un redémarrage automatique.

Par défaut, cette fonctionnalité est activée.

[DB]Diskless

Dans les interfaces internes, il est possible de configurer les tables comme sans disque (littéralement, diskless ), ce qui signifie que les tables ne sont pas enregistrées sur le disque, et qu'aucun log n'est fait. Ces tables existent uniquement en mémoire. Ces tables existeront encore après un crash, mais pas leur contenu.

Cette fonctionnalité fait que le cluster entier devient Diskless , ce qui fait le les tables n'existent plus après un crash. Activer cette fonctionnalité de fait avec Y ou 1.

Lorsque cette fonctionnalité est activée, les sauvegardes sont faites, mais elles ne seront pas stockées car il n'y a pas de disque. Dans les versions futures, il est probable que les sauvegardes sans disques soient une option séparée.

Par défaut, cette fonctionnalité n'est pas activée.

[DB]RestartOnErrorInsert

Cette fonctionnalté n'est possible que lorsque la version de déboguage a été compilée, pour pouvoir insérer des erreurs à différents points de l'exécution, afin de tester les cas d'erreurs.

Par défaut, cette fonctionnalité n'est pas activée.

[DB]TimeBetweenWatchDogCheck

Pour s'assurer que le thread principal ne reste back éternellement bloqué dans une boucle infinie, il existe un garde-fou qui vérifie le fonctionnement de ce thread. Ce paramètre indique le nombre de millisecondes entre deux vérifications. Après trois essais où le processus est dans le même état, le thread est arrêté par le garde-fou.Ce paramètre peut être facilement modifié, et peut différer de noeud en noeud, même s'il y a peu de raison pour faire des traitements différents.

La durée par défaut est de 4000 millisecondes (4 secondes).

[DB]StartPartialTimeout

Ce paramètre spécifie le temps durant lequel le cluster attend les noeuds de stockage avant que l'algorithme de cluster soit appelé. Cette durée est appelée pour éviter de démarrer un cluster partiel.

La valeur par défaut de 30000 millisecondes (30 secondes). 0 signifie l'éternité, c'est à dire que tous les noeuds doivent être là pour démarrer.

[DB]StartPartitionedTimeout

Si le cluster est prêt à démarrer après avoir attendu StartPartialTimeout mais qu'il est possible qu'il soit dans un état de partionnement, alors le cluster attend encore ce délai supplémentaire.Le délai par défaut est de 60000 millisecondes (60 secondes).

[DB]StartFailureTimeout

Si le démarrage n'est pas réalisé dans le délai spécifié par ce paramètre, le démarrage du noeud échouera. En donnant la valeur de 0 à ce paramètre, il n'y au pas de délai appliqué.La valeur par défaut de 60000 millisecondes (60 secondes). Pour les noeuds de stockage avec de grandes bases de données, il faut augmenter cette valeur car le noeud peut demander jusqu'à 15 minutes pour effectuer le démarrage de plusieurs gigaoctets de données.

[DB]HeartbeatIntervalDbDb

Une des méthodes qui permet de découvrir les noeuds morts est la tachycardie (littéralement, heartbeats , battement de coeur). Ce paramètre indique le nombre de signaux qui sont envoyés, et la fréquence supposée de reception. Après avoir sauté 3 intervalles de signaux d'affilée, le noeud est déclaré mort. Par conséquent, le temps maximal de détection d'un noeud est de 4 battements.L'intervalle par défaut est de 1500 millisecondes (1.5 secondes). Ce paramètre ne doit pas être modifié de trop. Si vous utilisez 5000 millisecondes et que le noeud observé utiliser une valeur de 1000 millisecondes alors ce dernier sera rapidement déclaré mort. Ce paramètre peut être modifié progressivement, mais pas trop d'un coup.

[DB]HeartbeatIntervalDbApi

Similairement, chaque noeud de stockage émet des signaux de vie pour chaque serveur MySQL connecté, pour s'assurer qu'ils fonctionnent correctement. Si un serveur MySQL ne renvoie pas un signal dans le temps escompté, avec le même algorithme que pour la surveillance des noeuds de stockage, il est alors déclaré mort, et les transactions sont alors terminées, les ressources libérées, et le serveur ne pourra pas se reconnecter avant la fin des opérations de nettoyage.La valeur par défaut pour cet intervalle est 1500 millisecondes. Cet interval peut être différent pour le noeud de stockage, car chaque noed de stockage fonctionne indépendamment des autres noeuds de stockage qui surveille le serveur connecté.

[DB]TimeBetweenLocalCheckpoints

Ce paramètre est une exception, en ce send qu'il ne définit pas un délai avant de poser un jalon local. Ce paramètre sert à s'assurer que dans un cluster, le niveau de modification des tables n'est pas trop faible pour empêcher la pose de jalon. Dans la plupart des clusters avec un taux de modification important, il est probable que les jalons locaux soient posés immédiatement après la fin du précédent.La taille de toutes les opérations d'écriture exécutées depuis le début du jalon précédent est sommée. Ce paramètreset spécifié comme le logarithme du nombre de mots. Par exemple, la valeur par défaut de 20 signifie que 4Mo d'opérations d'écriture ont été faites; 21 représente 8Mo, et ainsi de suite. La valeur maximale de 31 représente 8Go d'opérations.

Toutes les opérations d'écritures dans le cluster sont additionnées ensemble. En lui donnant une valeur de 6 ou moins, cela va forcer les écritures de jalons continuellement, sans aucune attente entre deux jalons, et indépendemment de la charge du cluster.

[DB]TimeBetweenGlobalCheckpoints

Lorsqu'une transaction est archivée, elle est placée en mémoire principale de tous les noeuds où des données miroirs existent. Les lignes de logs de la transaction ne sont pas forcées sur le disque lors de l'archivage. L'idée ici est que pour que la transaction soit archivé sans problème, il faut qu'elle soit archivée dans 2 noeuds indépendants.

Dans le même temps, il est important de s'assurer que dans le pire cas de crash, le cluster se comporte correctement. Pour s'assurer que les transactions dans un intervalle de temps donné sont placées dans un jalon global. Un groupe entier de transction est envoyé sur le disque. Par conséquent, la transaction a été placée dans un groupe de jalon, en tant que partie d'un archivage. Ultérieurement, ce groupe de log sera placé sur le disque , et le groupe entier de transaction sera archivé sur tous les serveurs.

Ce paramètre spécifie l'intervalle entre les jalons globaux. La valeur par défaut est de 2000 millisecondes.

[DB]TimeBetweenInactiveTransactionAbortCheck

Un délai d'expiration est appliqué pour chaque transaction en fonction de ce paramètre. Par conséquent, si ce paramètre vaut 1000 millisecondes, alors chaque transaction sera vérifée une fois par seconde.La valeur par défaut pour ce paramètre est 1000 millisecondes (1 seconde).

[DB]TransactionInactiveTimeout

Si la transaction n'est pas en exécution de requête, mais attend d'autres données, ce paramètre spécifie le temps maximum d'attente des données avant d'annuler la transaction.Par défaut, ce paramètre ne limite pas l'arrivée des données. Pour des cluster en production, qui doivent s'assurer qu'aucune transaction ne bloque le serveur durant trop longtemp, il faut utiliser une valeur basse. L'unité est la millisecondes.

[DB]TransactionDeadlockDetectionTimeout

Lorsqu'une transactioon est implique dans l'exécution d'une requête, elle attend les autres noeuds. Si les autres noeuds ne répondent pas, il peut se passer 3 choses. Premièrement, le noeud peut être mort; deuxièment, l'opération peut être placée dans une file d'attente de verrou; troisièmement, le noeud impliqué peut être surchargé. Ce paramètre limite la durée de l'attente avant d'annuler la transaction.Ce paramètre est important pour la détection d'échec de noeud et le blocage de verrou. En le configurant trop haut, il est possible de laisser passer des blocages.

La durée par défaut est de 1200 millisecondes (1.2 secondes).

[DB]NoOfDiskPagesToDiskAfterRestartTUP

Lors de l'exécution d'un jalon local, l'algorithme envoie toutes les pages de données au disque. Les envoyer aussi rapidement que possible cause des charges inutiles sur le processeur, le réseau et le disque. Cette option contrôle le nombre de page à écrire par 100 millisecondes. Une page est définie ici comme faisant 8ko. C'est l'unité de ce paramètre est de 80ko par seconde. En lui donnant la valeur de 20, cela représente 1.6Mo de données envoyées sur le disque par seconde, durant un jalon local. De plus, l'écriture des log de UNDO est inclus dans cette somme. L'écriture des pages d'index (voir IndexMemory pour comprendre comment les pages d'index sont utilisées), et leur logs d'UNDO sont gérées par le paramètre NoOfDiskPagesToDiskAfterRestartACC . Ce paramètre paramètre gère les limitations d'écriture de DataMemory .

Ainsi, ce paramètre spécifie la vitesse d'écriture des jalons. Ce paramètre est important et est corrélé à NoOfFragmentLogFiles , DataMemory , IndexMemory .

La valeur par défaut de 40 (3.2Mo de pages de données par seconde).

[DB]NoOfDiskPagesToDiskAfterRestartACC

Ce paramètre a la même unité que NoOfDiskPagesToDiskAfterRestartTUP mais limite la vitesse d'écriture des pages d'index depuis IndexMemory .La valeur par défaut pour ce paramètre est 20 (1.6Mo par seconde).

[DB]NoOfDiskPagesToDiskDuringRestartTUP

Ce paramètre spécifie les mêmes limitations que NoOfDiskPagesToDiskAfterRestartTUP et NoOfDiskPagesToDiskAfterRestartACC , mais s'appliquent aux jalons locaux, exécutés sur un noeud comme une partie de jalon lors du redémarrage. Faisant partie du redémarrage, un jalon local est toujours effectué. Il est possible d'utiliser une vitesse accrue durant le redémarrage du noeud, car les activités sont alors limitées sur le serveur.Ce paramètre gère la partie de DataMemory .

La valeur par défaut de 40 (3.2Mo par seconde).

[DB]NoOfDiskPagesToDiskDuringRestartACC

Durant le redémarrage de la partie local de IndexMemory pour un jalon local.

La valeur par défaut de 20 (1.6Mo par seconde).

[DB]ArbitrationTimeout

Ce paramètre spécifie le temps que le noeud de stockage va attendre un message de l'arbitre lors d'un fractionnement du réseau.

La valeur par défaut de 1000 millisecondes (1 seconde).

Tous ces buffers sont utilisés comme interface avec le système de fichiers lors de l'écriture des lignes de log sur le disque. Si le noeud fonctionne en mode sans disque, ces paramètres peuvent prendre leur valeur minimale, car les écriture sur le disques sont simulées et toujours validées par la couche d'abstraction du moteur NDB .

[DB]UndoIndexBuffer

Ce buffer est utilisé durant les jalons locaux. Le moteur de stockage NDB utilise un mécanisme de restauration basé sur des jalons cohérents avec le log de REDO. Afin de produit un jalon valide sans bloquer le système l'enregistrement des UNDO est fait durant l'éxécution des jalons locaux. Le log de UNDO n'est activé que pour un fragment de table à chaque fois. Cette optimisation est rendue possible car les tables sont entièrement stockées en mémoire principale.

Ce buffer est utilisé pour les modification dans les index hash de clé primaire. Les insertions et les effacement réarrange les idnex hash, et le moteur NDB écrit les log d'UNDO qui associent les modifications physiquesw avec un index de page pour qu'ils puissent être appliqués même après un redémarrage. Toutes les insertions actives sont aussi enregistrées au début d'un jalon local, pour chaqu fragment.

Les lectures et modifications ne font que poser des bits de verrouillages, et altèrent un entête dans la ligne d'index. Ces modifications sont gérées par l'algorithme d'écriture des pages, pour s'assurer que ces opérations n'ont pas besoin du log d'UNDO.

Ce buffer vaut 2Mo par défaut. La valeur minimale est 1Mo. Pour la plupart des applications, c'est suffisant. Les applications qui font beaucoup d'insertions et d'effacement avec de grandes transactions en exploitant intensivement leurs clés primaires devront agrandir ce buffer.

Si le buffer est trop petit, le moteur NDB émet une erreur de code 677 qui se traduit pas "Index UNDO buffers overloaded".

[DB]UndoDataBuffer

Ce buffer a exactement le même role que UndoIndexBuffer mais est utilisée pour les données. Ce buffer est utilisé durant l'exécution d'un jalon local pour un fragment de table, et les insertions, les effacements et les modifications utilisent ce buffer.Comme les lignes du log d'UNDO tendent à être plus grandes et que plus d'informations sont stockées, ce buffer doit être aussi de plus grande taille. Par défaut, il vaut 16Mo. Pour certaines applications, cela peut être sur-dimensionné, et il est alors recommandé de réduire cette valeur. La taille minimale est de 1Mo. Il sera rare d'avoir à augmenter cette valeir. Si cette valeur doit être augmentée, commencez par vérifier vos disques et leurs performances. Si ce sont les disques qui limitent le débit, le buffer sera alors bien dimensionné.

Si ce buffer est trop petit et se remplit, le moteur NDB émet une erreur de code 891 qui se traduit par "Data UNDO buffers overloaded" .

[DB]RedoBuffer

Toutes les activités de modification doivent être enregistrées. Cela permet de repasser ces opérations au redémarrage du système. L'algorithme de restauration utilise un jalon cohérent, produit par un jalon "flou" produit par les données couplées aux pages de log d'UNDO. Puis, le log de REDO est appliqué pour rejouer toutes les modifications qui ont eu lieu depuis le redémarrage du système.

Ce buffer fait 8Mo par défaut. Sa taille minimale est de 1Mo.

Si ce buffer est trop etit, le moteur NDB émet une erreur de code 1221 qui se traduit par : "REDO log buffers overloaded" .

Un jeu de niveau d'erreur similaire peut être configuré dans le client de gestion, pour définir les niveaux d'erreurs qui doivent rejoindre le log du cluster.

[DB]LogLevelStartup

Evenements générés durant le démarrage du processus.

Le niveau par défaut est 1.

[DB]LogLevelShutdown

Evenements générés durant l'extinction programmée d'un noeud.

Le niveau par défaut est 0.

[DB]LogLevelStatistic

Evenements statistiques tels que le nombre de clés primaires lues, le nombre d'insertions, modifications et de nombreuses autres informations statistiques sur l'utilisation des buffer.

Le niveau par défaut est 0.

[DB]LogLevelCheckpoint

Evenements générés par les jalons locaux et globaux.

Le niveau par défaut est 0.

[DB]LogLevelNodeRestart

Evenements générés par un redémarrage de noeud.

Le niveau par défaut est 0.

[DB]LogLevelConnection

Evenements générés par les connexions entre les noeuds dans le cluster.

Le niveau par défaut est 0.

[DB]LogLevelError

Evenements générés par les erreurs et alertes dans le cluster. Ces erreurs ne sont pas causées par un échec de noeud, mais sont suffisamment importantes pour être rapportées.

Le niveau par défaut est 0.

[DB]LogLevelInfo

Evenements générés pour informer sur l'état du cluster.

Le niveau par défaut est 0.

[DB]BackupDataBufferSize

Lors de l'exécution d'un sauvegarde, il y a deux buffers utilisés pour envoyer des données au disque. Ce buffer sert à rassembler des données obtenues par le scan des tables du noeud. Lorsque le regroupement atteint un certain niveau, ces pages sont envoyées au disque. Ce niveau est spécifié par le paramètre BackupWriteSize . Lors de l'envoi des données sur le disque, la sauvegarde continue de remplir ce buffer, jusqu'à ce qu'il n'y ait plus de place. Lorsque la place manque, la sauvegarde marque une pause, et attent que l'écriture ait libéré de la mémoire avant de poursuivre.La valeur par défaut de 2Mo.

[DB]BackupLogBufferSize

Ce paramètre a un rôle similaire mais sert à écrire un log de toutes les écritures dans la table durant l'exécution de la sauvegarde. Le même principe s'applique à l'écriture de ces pages que pour BackupDataBufferSize , hormis le fait que lorsque la place manque, la sauvegarde échoue par manque de place. Par conséquent, la taille de ce buffer doit être assez grande pour encaisser la charge causée par les activités d'écriture durant l'exécution de la sauvegarde.La valeur par défaut de ce paramètre doit être assez grande. En fait, il est plus probable qu'une erreur de sauvegarde soit causée par le disque qui ne peut suivre la vitesse d'écriture. Si le disque est sous-dimensionné pour cette opération, le cluster aura du mal à satisfaire les besoins des autres opérations.

Il est important de dimensionner les noeuds pour que les processeurs deviennent les facteurs limitants, bien plus que les disques ou le réseau.

La valeur par défaut de 2Mo.

[DB]BackupMemory

Ce paramètre est simplement la somme des deux précédents : BackupDataBufferSize et BackupLogBufferSize .La valeur par défaut de 4Mo.

[DB]BackupWriteSize

Ce paramètre spécifie la taille des messages d'écriture sur le disque, pour le log, ainsi que le buffer utilisé pour les sauvegardes.La valeur par défaut de 32ko.