Les fabricants de serveurs et les fournisseurs de cloud proposent différents types de solutions de stockage pour répondre à vos besoins en matière de bases de données. Lors de l'achat d'un nouveau serveur ou du choix d'une instance cloud pour exécuter notre base de données, nous nous demandons souvent - combien d'espace disque devons-nous allouer ? Comme nous allons le découvrir, la réponse n'est pas anodine car il y a un certain nombre d'aspects à considérer. L'espace disque est une chose à laquelle il faut penser dès le départ, car la réduction et l'expansion de l'espace disque peuvent être une opération risquée pour une base de données sur disque.
Dans cet article de blog, nous allons examiner comment dimensionner initialement votre espace de stockage, puis planifier la capacité pour prendre en charge la croissance de votre base de données MySQL ou MariaDB.
Comment MySQL utilise l'espace disque
MySQL stocke les données dans des fichiers sur le disque dur sous un répertoire spécifique contenant la variable système "datadir". Le contenu du datadir dépendra de la version du serveur MySQL, ainsi que des paramètres de configuration chargés et des variables du serveur (par exemple, general_log, slow_query_log, binary log).
Les informations réelles de stockage et de récupération dépendent des moteurs de stockage. Pour le moteur MyISAM, les index d'une table sont stockés dans le fichier .MYI, dans le répertoire de données, avec les fichiers .MYD et .frm de la table. Pour le moteur InnoDB, les index sont stockés dans le tablespace, avec la table. Si innodb_file_per_table est définie, les index seront dans le fichier .ibd de la table avec le fichier .frm. Pour le moteur de mémoire, les données sont stockées dans la mémoire (heap) tandis que la structure est stockée dans le fichier .frm sur disque. Dans le prochain MySQL 8.0, les fichiers de métadonnées (.frm, .par, dp.opt) seront supprimés avec l'introduction du nouveau schéma de dictionnaire de données.
Il est important de noter que si vous utilisez l'espace de table partagé InnoDB pour stocker les données de la table (innodb_file_per_table=OFF ), la taille de vos données physiques MySQL devrait augmenter continuellement même après avoir tronqué ou supprimé d'énormes lignes de données. La seule façon de récupérer l'espace libre dans cette configuration est d'exporter, de supprimer les bases de données actuelles et de les réimporter via mysqldump. Ainsi, il est important de définir innodb_file_per_table=ON si vous êtes préoccupé par l'espace disque, alors lors de la troncation d'une table, l'espace peut être récupéré. De plus, avec cette configuration, une énorme opération DELETE ne libérera pas d'espace disque à moins que OPTIMIZE TABLE ne soit exécuté par la suite.
MySQL stocke chaque base de données dans son propre répertoire sous le chemin "datadir". De plus, les fichiers journaux et autres fichiers MySQL associés, tels que les fichiers socket et PID, seront également créés par défaut sous datadir. Pour des raisons de performances et de fiabilité, il est recommandé de stocker les fichiers journaux MySQL sur un disque ou une partition distincts, en particulier le journal des erreurs MySQL et les journaux binaires.
Estimation de la taille de la base de données
La méthode de base pour estimer la taille consiste à trouver le taux de croissance entre deux points différents dans le temps, puis à le multiplier par la taille actuelle de la base de données. Mesurer le trafic de votre base de données aux heures de pointe à cette fin n'est pas la meilleure pratique et ne représente pas l'utilisation de votre base de données dans son ensemble. Pensez à une opération par lots ou à une procédure stockée qui s'exécute à minuit ou une fois par semaine. Votre base de données pourrait potentiellement grossir considérablement le matin, avant d'être éventuellement réduite par une opération de nettoyage à minuit.
Une possibilité est d'utiliser nos sauvegardes comme élément de base pour cette mesure. La sauvegarde physique comme Percona Xtrabackup, MariaDB Backup et l'instantané du système de fichiers produirait une représentation plus précise de la taille de votre base de données par rapport à la sauvegarde logique, car elle contient la copie binaire de la base de données et des index. La sauvegarde logique comme mysqldump ne stocke que les instructions SQL qui peuvent être exécutées pour reproduire les définitions d'objet de base de données d'origine et les données de table. Néanmoins, vous pouvez toujours obtenir un bon taux de croissance en comparant les sauvegardes mysqldump.
Nous pouvons utiliser la formule suivante pour estimer la taille de la base de données :
Où,
- B - Taille de la sauvegarde complète de la semaine en cours,
- B - Taille de la sauvegarde complète de la semaine précédente,
- Dbdonnées - Taille totale des données de la base de données,
- Baseindex - Taille totale de l'index de la base de données,
- 52 - Nombre de semaines dans une année,
- O - Année.
La taille totale de la base de données (données et index) en Mo peut être calculée à l'aide des instructions suivantes :
mysql> SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) "DB Size in MB" FROM information_schema.tables;
+---------------+
| DB Size in MB |
+---------------+
| 2013.41 |
+---------------+L'équation ci-dessus peut être modifiée si vous souhaitez utiliser les sauvegardes mensuelles à la place. Changez la valeur constante de 52 en 12 (12 mois dans une année) et vous êtes prêt à partir.
N'oubliez pas non plus de tenir compte de innodb_log_file_size x 2, innodb_data_file_path et pour Galera Cluster, ajoutez gcache.size valeur.
Estimation de la taille des journaux binaires
Les journaux binaires sont générés par le maître MySQL à des fins de réplication et de récupération ponctuelle. Il s'agit d'un ensemble de fichiers journaux contenant des informations sur les modifications de données effectuées sur le serveur MySQL. La taille des journaux binaires dépend du nombre d'opérations d'écriture et du format du journal binaire - STATEMENT, ROW ou MIXED. Le journal binaire basé sur les instructions est généralement beaucoup plus petit que le journal binaire basé sur les lignes, car il se compose uniquement des instructions d'écriture tandis que le journal basé sur les lignes se compose d'informations sur les lignes modifiées.
La meilleure façon d'estimer l'utilisation maximale du disque des journaux binaires est de mesurer la taille du journal binaire pour une journée et de la multiplier par expire_logs_days valeur (la valeur par défaut est 0 - pas de suppression automatique). Il est important de définir expire_logs_days afin que vous puissiez estimer la taille correctement. Par défaut, chaque journal binaire est plafonné à environ 1 Go avant que MySQL ne fasse pivoter le fichier journal binaire. Nous pouvons utiliser un événement MySQL pour simplement vider le journal binaire aux fins de cette estimation.
Tout d'abord, assurez-vous que la variable event_scheduler est activée :
mysql> SET GLOBAL event_scheduler = ON;Ensuite, en tant qu'utilisateur privilégié (avec les privilèges EVENT et RELOAD), créez l'événement suivant :
mysql> USE mysql;
mysql> CREATE EVENT flush_binlog
ON SCHEDULE EVERY 1 HOUR STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 2 HOUR
COMMENT 'Flush binlogs per hour for the next 2 hours'
DO FLUSH BINARY LOGS;Pour une charge de travail intensive en écriture, vous devrez probablement réduire l'intervalle à 30 minutes ou 10 minutes avant que le journal binaire n'atteigne la taille maximale de 1 Go, puis arrondir la sortie à une heure. Vérifiez ensuite le statut de l'événement à l'aide de l'instruction suivante et examinez la colonne LAST_EXECUTED :
mysql> SELECT * FROM information_schema.events WHERE event_name='flush_binlog'\G
...
LAST_EXECUTED: 2018-04-05 13:44:25
...Ensuite, jetez un œil aux journaux binaires que nous avons maintenant :
mysql> SHOW BINARY LOGS;
+---------------+------------+
| Log_name | File_size |
+---------------+------------+
| binlog.000001 | 146 |
| binlog.000002 | 1073742058 |
| binlog.000003 | 1073742302 |
| binlog.000004 | 1070551371 |
| binlog.000005 | 1070254293 |
| binlog.000006 | 562350055 | <- hour #1
| binlog.000007 | 561754360 | <- hour #2
| binlog.000008 | 434015678 |
+---------------+------------+Nous pouvons ensuite calculer la moyenne de la croissance de nos journaux binaires, qui est d'environ ~562 Mo par heure pendant les heures de pointe. Multipliez cette valeur par 24 heures et les expire_logs_days valeur :
mysql> SELECT (562 * 24 * @@expire_logs_days);
+---------------------------------+
| (562 * 24 * @@expire_logs_days) |
+---------------------------------+
| 94416 |
+---------------------------------+Nous aurons 94 416 Mo, soit environ ~95 Go d'espace disque pour nos logs binaires. Les journaux de relais de l'esclave sont fondamentalement les mêmes que les journaux binaires du maître, sauf qu'ils sont stockés du côté esclave. Par conséquent, ce calcul s'applique également aux journaux des relais esclaves.
Spindle Disk ou Solid State ?
Il existe deux types d'opérations d'E/S sur les fichiers MySQL :
- Fichiers séquentiels orientés E/S :
- Tablespace système InnoDB (ibdata)
- Fichiers journaux MySQL :
- Journaux binaires (binlog.xxxx)
- Journaux REDO (ib_logfile*)
- Journaux généraux
- Journaux de requêtes lents
- Journal des erreurs
- Fichiers orientés E/S aléatoires :
- Fichier de données fichier par table InnoDB (*.ibd) avec innodb_file_per_table=ON (par défaut).
Envisagez de placer des fichiers orientés E/S aléatoires dans un sous-système de disque à haut débit pour de meilleures performances. Il peut s'agir d'un lecteur flash - soit des SSD ou une carte NVRAM, soit des disques à broche à haut régime comme SAS 15K ou 10K, avec un contrôleur RAID matériel et une unité sauvegardée par batterie. Pour les fichiers orientés E/S séquentiels, le stockage sur disque dur avec un cache en écriture sauvegardé par batterie devrait être suffisant pour MySQL. Notez qu'une dégradation des performances est probable si la batterie est déchargée.
Nous couvrirons ce domaine (estimation du débit du disque et de l'allocation des fichiers) dans un article séparé.
Planification et dimensionnement des capacités
La planification de la capacité peut nous aider à créer un serveur de base de données de production avec suffisamment de ressources pour survivre aux opérations quotidiennes. Nous devons également répondre aux besoins imprévus, tenir compte des futurs besoins de stockage et de débit de disque. Ainsi, la planification de la capacité est importante pour s'assurer que la base de données dispose de suffisamment d'espace pour respirer jusqu'au prochain cycle d'actualisation du matériel.
Il est préférable d'illustrer cela par un exemple. Considérant le scénario suivant :
- Prochain cycle matériel :3 ans
- Taille actuelle de la base de données :2 013 Mo
- Taille actuelle de la sauvegarde complète (semaine N) :1 177 Mo
- Taille de la sauvegarde complète précédente (semaine N-1) :936 Mo
- Taille delta :241 Mo par semaine
- Ratio delta :augmentation de 25,7 % par semaine
- Nombre total de semaines en 3 ans :156 semaines
- Estimation de la taille totale de la base de données :((1 177 - 936) x 2 013 x 156)/936 =80 856 Mo ~ 81 Go après 3 ans
Si vous utilisez des journaux binaires, résumez-les à partir de la valeur que nous avons obtenue dans la section précédente :
- 81 + 95 =176 Go de stockage pour la base de données et les journaux binaires.
Ajoutez au moins 100 % d'espace en plus pour les tâches opérationnelles et de maintenance (sauvegarde locale, stockage des données, journal des erreurs, fichiers du système d'exploitation, etc.) :
- 176 + 176 =352 Go d'espace disque total.
Sur la base de cette estimation, nous pouvons conclure que nous aurions besoin d'au moins 352 Go d'espace disque pour notre base de données pendant 3 ans. Vous pouvez utiliser cette valeur pour justifier l'achat de votre nouveau matériel. Par exemple, si vous souhaitez acheter un nouveau serveur dédié, vous pouvez opter pour 6 x 128 SSD RAID 10 avec contrôleur RAID secouru par batterie qui vous donnera environ 384 Go d'espace disque total. Ou, si vous préférez le cloud, vous pouvez obtenir 100 Go de stockage par blocs avec IOPS provisionnés pour notre utilisation de la base de données de 81 Go et utiliser le stockage par blocs persistant standard pour nos journaux binaires de 95 Go et d'autres utilisations opérationnelles.
Bon dimensionnement !
