Les plus grands jours de shopping en ligne de l'année approchent à grands pas. Votre base de données est-elle prête ? En ajustant 20 variables système clés de MariaDB, vous renforcerez les performances de votre base de données , évolutivité et disponibilité , garantissant ainsi à chaque client potentiel une expérience utilisateur fluide. Les variables système suivantes apparaissent à plusieurs reprises lors de la configuration d'un environnement de serveur MariaDB optimal. Mettez en œuvre nos recommandations pour les valeurs les plus adaptées et faites de la période du Black Friday au Cyber Monday de cette année votre meilleure expérience.
Quelques remarques importantes :
- N'acceptez pas ces suggestions aveuglément. Chaque environnement MariaDB est unique et nécessite une réflexion supplémentaire avant d'apporter des modifications. Vous devrez très probablement ajuster ces paramètres en fonction de votre cas d'utilisation et de votre environnement spécifiques.
- Le fichier de configuration MariaDB se trouve dans /etc/my.cnf. Chaque fois que vous modifiez ce fichier, vous devrez redémarrer le service MySQL pour que les nouvelles modifications puissent prendre effet.
20 recommandations de réglage pour le Black Friday et le Cyber Monday
1. Taille du pool de tampons InnoDB
La taille du pool de mémoire tampon InnoDB il s'agit du paramètre n° 1 à prendre en compte pour toute installation utilisant InnoDB. Le pool de mémoire tampon est l'endroit où les données et les index sont mis en cache ; l'avoir aussi grand que possible vous assurera d'utiliser de la mémoire et non des disques pour la plupart des opérations de lecture.
2. Taille du fichier journal InnoDB
innodb_log-file-size est la taille des journaux redo, qui sont utilisés pour s'assurer que les écritures sont rapides et durables. Il existe deux suggestions générales pour la taille des fichiers journaux InnoDB :
- Définir la taille totale combinée des fichiers journaux InnoDB supérieure à 25 – 50 % de la taille du pool de mémoire tampon InnoDB
ou
- Définissez une taille de fichier journal InnoDB combinée égale à une heure d'entrées de journal pendant les pics de charge
Des fichiers journaux plus volumineux peuvent ralentir la récupération en cas de panne du serveur. Cependant, ils réduisent également le nombre de points de contrôle nécessaires et réduisent les E/S de disque.
Évaluez la taille d'une heure de journaux binaires sous charge opérationnelle, puis décidez d'augmenter ou non la taille des fichiers journaux InnoDB.
La bonne taille des fichiers journaux innodb est importante pour obtenir de bonnes performances système. Le moteur de stockage InnoDB de MariaDB utilise un espace de journalisation de taille fixe (circulaire). La taille est contrôlée par innodb_log_file_size et innodb_log_files_in_group (par défaut 2). Multipliez ces valeurs pour obtenir l'espace de journalisation disponible. Bien que techniquement, cela ne devrait pas avoir d'importance si vous utilisez la variable innodb_log_file_size ou innodb_log_files_in_group pour contrôler la taille de l'espace de restauration, la plupart des gens travaillent simplement avec innodb_log_file_size et laissent innodb_log_files_in_group seul.
La taille de l'espace de restauration d'InnoDB est l'une des options de configuration les plus importantes pour les charges de travail intensives en écriture. Cependant, cela vient avec des compromis. Plus il y a d'espace de restauration configuré, mieux InnoDB peut optimiser les E/S d'écriture. Cependant, l'augmentation de l'espace de restauration signifie également des temps de récupération plus longs lorsque le système perd de l'alimentation ou se bloque pour d'autres raisons.
3. Taille du tampon de journal InnoDB
Une plus grande taille de tampon de journal InnoDB signifie moins d'E/S disque pour les transactions plus importantes. Il est suggéré de le définir sur 64 Mo sur tous les serveurs.
4. Intervalle de vidage des journaux InnoDB
La variable innodb_flush_log_at_trx_commit contrôle le moment où le vidage du tampon de journal sur le disque se produit. innodb_flush_log_at_trx_commit =1 (par défaut) vide le tampon du journal sur le disque à chaque validation de transaction. C'est l'option la plus sûre, mais aussi la moins performante.
innodb_flush_log_at_trx_commit =0 vide le tampon du journal sur le disque toutes les secondes, mais rien lors de la validation de la transaction. Jusqu'à une seconde (peut-être plus en raison de la planification des processus) peut être perdue. En cas de plantage, MySQL ou le serveur peuvent perdre des données. C'est l'option la plus rapide mais la moins sûre.
innodb_flush_log_at_trx_commit =2 écrit le tampon du journal dans un fichier à chaque validation, mais le vide sur le disque toutes les secondes. Si le cache disque dispose d'une batterie de secours (par exemple, un contrôleur RAID de cache avec batterie), il s'agit généralement du meilleur équilibre entre performances et sécurité. Un plantage de MySQL ne devrait pas faire perdre de données. Une panne de serveur ou une panne de courant peut perdre jusqu'à une seconde (peut-être plus en raison de la planification des processus). Un cache avec batterie de secours réduit cette possibilité.
Nous suggérons d'utiliser la première option pour des raisons de sécurité.
5. Capacité d'E/S InnoDB
innodb_io_capacity doit être défini approximativement sur le nombre maximal d'IOPS que le stockage sous-jacent peut gérer.
Par défaut, cette valeur est définie sur 1000. Nous vous recommandons de comparer le stockage pour déterminer si vous pouvez augmenter davantage cette valeur.
Surveillez la valeur de Threads_created. S'il continue d'augmenter à plus de quelques threads par minute, augmentez la valeur de thread_cache_size.
La taille du cache de threads est définie sur 200 dans la configuration par défaut actuelle.
Les variables table_open_cache et table_defintion_cache contrôlent le nombre de tables et de définitions à garder ouvertes pour tous les threads.
Surveillez Open_tables, Open_table_defintitions, Opened_tables et Opened_table_definitions pour déterminer la meilleure valeur. La suggestion générale est de définir table_open_cache (et par la suite table_definition_cache) suffisamment haut pour réduire le taux d'augmentation de la valeur d'état Opened_tables (et Opened_table_definitions).
table_open_cache et table_defintion_cache sont définis sur 2048 dans la configuration par défaut.
8. Cache de requête
Le cache de requête est un goulot d'étranglement bien connu qui peut être observé même lorsque la simultanéité est modérée. La meilleure option est de le désactiver dès le premier jour en définissant query_cache_size = 0 (valeur par défaut dans MariaDB 10) et d'utiliser d'autres moyens pour accélérer les requêtes de lecture :avoir une bonne indexation, ajouter des répliques pour répartir la charge de lecture ou utiliser un cache externe ( memcache ou redis, par exemple). Si vous avez déjà construit votre application MariaDB avec le cache de requêtes activé et que vous n'avez jamais remarqué de problème, le cache de requêtes peut vous être bénéfique. Dans ce cas, soyez prudent si vous décidez de le désactiver.
9. Tables temporaires, tmp_table_size et max_heap_table_size
MySQL utilise la valeur la plus faible entre max_heap_table_size et tmp_table_size pour limiter la taille des tables temporaires en mémoire. Ce sont des variables par client. Si cette valeur est élevée, cela peut aider à réduire le nombre de tables temporaires créées sur le disque, mais cela augmente également le risque d'atteindre la capacité de mémoire du serveur, car c'est par client. En règle générale, 32 M à 64 M est la valeur suggérée pour commencer pour les deux variables et ajuster si nécessaire.
Les tables temporaires sont souvent utilisées pour GROUP BY, ORDER BY, DISTINCT, UNION, les sous-requêtes, etc. Idéalement, MySQL devrait les créer en mémoire, avec le moins possible sur le disque.
Il est important de noter que les requêtes qui n'utilisent pas les jointures de manière appropriée et qui créent de grandes tables temporaires peuvent être l'une des raisons d'un nombre plus élevé de tables temporaires sur le disque. Une autre raison est que le moteur de stockage de la mémoire utilise des colonnes de longueur fixe et suppose le scénario le plus défavorable. Si les colonnes ne sont pas dimensionnées correctement (par exemple, un VARCHAR(255) pour une chaîne courte), cela influence la taille de la table en mémoire et peut la faire accéder au disque plus tôt qu'elle ne le devrait. De plus, les tables temporaires avec des colonnes de blob et de texte iront immédiatement sur le disque, car le moteur de stockage en mémoire ne les prend pas en charge.
Les deux sont actuellement définis sur 64M par défaut.
10. Niveau de journalisation des avertissements
Nous vous recommandons de définir le niveau de journalisation des avertissements sur log_warnings = 2. Cela permet d'enregistrer des informations sur les connexions abandonnées et les erreurs d'accès refusé.
Si vous êtes souvent confronté à l'erreur "Trop de connexions", max_connections est trop faible. Souvent, comme l'application ne ferme pas correctement les connexions à la base de données, vous avez besoin de bien plus que les 151 connexions par défaut. Le principal inconvénient des valeurs élevées pour max_connections (par exemple, 1 000 ou plus) est que le serveur ne répond plus s'il doit exécuter autant de transactions actives. L'utilisation d'un pool de connexions au niveau de l'application ou d'un pool de threads au niveau de MariaDB peut aider ici.
12. Isolement des transactions
Étudiez les niveaux d'isolement des transactions disponibles et déterminez le meilleur isolement des transactions pour le cas d'utilisation de votre serveur.
13. Format de journal binaire
Nous vous recommandons d'utiliser le format de journal binaire ROW pour la réplication maître-maître.
Pour aider à réduire les risques de collision entre deux maîtres écrits simultanément, les valeurs d'incrémentation automatique et de décalage d'incrémentation automatique doivent être ajustées en conséquence.
15. Sync Binlog
Par défaut, le système d'exploitation gère le vidage du binlog sur le disque. En cas de panne du serveur, il est possible de perdre des transactions du journal binaire, ce qui entraînerait une désynchronisation de la réplication. Définir sync_binlog =1 entraîne le vidage du fichier binlog à chaque commit.
C'est plus lent, mais c'est l'option la plus sûre.
16. Esclaves Crash Safe(r)
Pour aider à éviter les erreurs de réplication après une panne d'esclave, activez la récupération du journal de relais et la synchronisation du journal de relais et des fichiers d'informations du journal de relais sur le disque.
Pour avoir une réplication en chaîne (maître -> esclave -> esclave), log_slave_updates doit être activé. Cela indique à un esclave d'écrire des transactions répliquées dans son propre journal binaire afin qu'elles puissent ensuite être répliquées sur des esclaves à partir de celui-ci.
Les esclaves doivent être en lecture seule pour éviter que des données ne leur soient accidentellement écrites.
Remarque :Les utilisateurs disposant de super privilèges peuvent toujours écrire lorsque le serveur est en lecture seule.
19. Délai d'expiration du réseau esclave
La variable slave_net_timeout est le nombre de secondes pendant lesquelles l'esclave attendra un paquet du maître avant d'essayer de se reconnecter. La valeur par défaut est 3600 (1 heure). Cela signifie que si le lien tombe en panne et n'est pas détecté, il peut s'écouler jusqu'à une heure avant que l'esclave ne se reconnecte. Cela pourrait amener l'esclave à avoir soudainement jusqu'à une heure de retard sur le maître.
Nous vous recommandons de définir slave_net_timeout sur une valeur plus raisonnable, telle que 30 ou 60.
20. Regardez notre webinaire sur la préparation du Black Friday et du Cyber Monday
Regardez notre webinaire à la demande – Se préparer pour le Black Friday et le Cyber Monday – pour découvrir les quatre principes essentiels de la préparation des bases de données : mesures de sécurité pour protéger votre base de données contre les attaques malveillantes, réglage des performances pour garantir une expérience utilisateur fluide, stratégies de haute disponibilité pour vous assurer de ne manquer aucune vente et évolutivité pour se préparer à la fois à la croissance prévue et aux pics inattendus.
