Archive

Archives pour la catégorie ‘Bases de données’

Les différents moteurs de stockage de MySQL: MyISAM

29/11/2023 Aucun commentaire

II. Le moteur MyISAM

  • Licence : GPL
  • Version de MySQL : Depuis la version 3.23, MyISAM a remplacé le moteur ISAM
  • Type : Moteur Non transactionnel.
  • Domaines d’application :
    – Recherche FULL-TEXT (texte intégrale).
    – Tables en lecture seule.
    – Tables de Log.
  • Information : Documentation officielle de MyISAM

II-A. Description

Depuis sa création, il est devenu le moteur par défaut de MySQL. Il a remplacé Isam en y ajoutant des extensions. En raison de sa souplesse, simplicité et rapidité, MyISAM gagne en popularité dans les applications du web.

Il est très utilisé pour le web car, comme il ne gère ni les clés étrangères, ni les transactions, il n’a pas à vérifier la validité des enregistrements. Cela permet donc un précieux gain de temps sur des tables très fréquemment ouvertes en écriture/lecture.

En effet, lorsque vous faites des suppressions sur des champs de type VARCHAR, CHAR, BLOB ou TEXT, le moteur supprime le contenu mais la place précédemment supprimée est conservée et peut être réutilisée ultérieurement.
OPTMIZE va défragmenter la table afin de gagner de la place et ainsi faciliter l’accès aux données sur cette table.

 

Sélectionnez
OPTIMIZE maTable;

Rien ne sert d’exécuter cette commande sur toutes les tables en permanence. Vous risquez de faire baisser les performances si beaucoup de connexions s’effectuent en même temps.
Cette commande doit être utilisée seulement sur des tables dont la taille évolue rapidement.

D’après ses détracteurs, MySQL ne serait pas capable de gérer les transactions.
En réalité, les personnes ayant utilisé MySQL ne savaient pas qu’il était possible de changer de moteur. Ils sont tombés sur le moteur par défaut, MyISAM, qui ne gère pas les transactions.

Une table MyISAM utilise trois fichiers :
  • maTable.FRM : Fichier de définition de la table
  • maTable.MYD : Fichier contenant les données de la table
  • maTable.MYI : Fichier d’index

Lire la suite…

Categories: Bases de données Tags: ,

Les différents moteurs de stockage de MySQL: InnoDB

29/11/2023 Aucun commentaire

X. Le moteur InnoDB

  • Licence : GPL niveau 2. Société InnoBase, filiale depuis 2005 de la société Oracle.
  • Version de MySQL : Par défaut depuis la version 4.0 de MySQL mais il y est possible de l’installer sur une version 3.23 de MySQL.
  • Type : Transactionnel
  • Domaines d’application : Application nécessitant une fiabilité de l’information avec une gestion des transactions

X-A. Description

InnoDB, est le moteur transactionnel le plus utilisé à l’heure actuelle dans les secteurs dit sensibles, c’est-à-dire nécessitant une cohérence et une grande intégrité des données.
Jusqu’à la version 5.1 incluse, c’est le seul moteur supportant les contraintes de clés étrangères (intégrité référentielle).

Il n’est pas concevable d’avoir des informations faisant référence à quelque chose d’inexistant. Peut-on imaginer un numéro de sécurité sociale qui ne soit pas associé à une personne ou un code postal associé à aucune ville ?
Il y a des domaines d’application où les données doivent être fiables à 100%.

Au-delà de l’intégrité référentielle, InnoDB propose des mécanismes transactionnelles présentant une grande compatibilité aux critères ACID.

X-B. Organisation interne

Avec une base de données composée de tables utilisant le moteur InnoDB, il est important de ne pas utiliser les mêmes méthodes qu’avec une base contenant uniquement des tables MyISAM.
Avec les tables utilisant le moteur MyISAM, il est facile de copier, supprimer une base de données : il suffit de copier le répertoire se trouvant dans le répertoire /Data/ portant le même nom que la base de données.
De là, il est possible de le déplacer vers un autre serveur, de réaliser une autre base de donnés à partir de celle-ci, d’effectuer des sauvegardes.
Par contre, si la base de données comporte des tables utilisant le moteur InnoDB, il faudra faire plus attention.
En effet, toutes les données de toutes les tables de toutes les bases sont stockées dans un espace de tables commun. De ce fait, la base devient un peu plus rigide.

Lire la suite…

Categories: Bases de données Tags: ,

Sécurisez votre serveur MySQL sous Unix

19/11/2023 Aucun commentaire

I. Introduction

Les bases de données (notamment MySQL) sont des éléments primordiaux dans un système d’informations. Elles sont incontournables dans de nombreuses entreprises et les données qu’elles contiennent sont souvent d’une importance cruciale. Ignorer la sécurité du système de gestion de base de données serait une erreur grave tant les conséquences d’une détérioration de la base pourraient s’avérer désastreuses.

Ce document explique quelques moyens simples d’améliorer et maintenir la sécurité de MySQL sous système Unix (Linux, BSD…). Il est bien sûr impensable de croire que les conseils de cet article suffiront à obtenir une sécurité optimale.

À l’instar de la sécurisation du SGBD, il faudra veiller à sécuriser le système d’exploitation de la machine hôte, les autres services actifs (serveurs HTTP, FTP…), le réseau, l’accès physique à cette machine et bien sûr vos applications (éviter les failles d’injection SQL).

II. Exécution du serveur : utilisateur système non privilégié

Après installation du serveur MySQL, beaucoup de personnes ont la fâcheuse habitude de lancer le daemon avec les privilèges de l’utilisateur système root. Ce choix peut s’expliquer par une envie d’utiliser la méthode la plus rapide : le serveur MySQL doit lire et écrire dans certains fichiers auxquels l’utilisateur régulier n’a pas accès ; en le lançant avec les privilèges root, on a l’assurance que MySQL aura les droits nécessaires.

Cette méthode d’exécution parait anodine. Cependant, elle peut conduire à des dégâts énormes. Le processus du daemon MySQL tournant avec les privilèges super-utilisateur, il a tous les droits sur le système. Imaginons maintenant qu’un pirate puisse prendre contrôle de ce processus (généralement par exploitation d’une faille de type buffer overflow dans MySQL), il deviendra dès lors le maître absolu de la machine hôte du serveur. Il pourra créer des fichiers, installer des programmes, lire des données confidentielles, ou supprimer des données.

Bien sûr, si une faille est présente dans MySQL, cela n’est pas la faute de l’administrateur. Mais ce n’est pas une raison pour ne pas s’en protéger. Il est impossible d’empêcher un pirate d’exploiter une telle faille. Les seuls à pouvoir le faire sont les développeurs de MySQL AB, qui, dans une telle situation, proposeront une nouvelle version du serveur.

De son côté, l’administrateur du serveur peut limiter les dégâts afin que le pirate ayant pris le contrôle du processus MySQL ne puisse pas détruire autre chose que la base de données (ce qui n’est déjà pas mal !). Le principe est assez simple : créer un utilisateur spécial dont la seule fonction sera de lancer MySQL. Cet utilisateur doit posséder le moins de droits système possible. La solution optimale serait que cet utilisateur n’ait accès qu’aux fichiers propres à MySQL.

Les administrateurs qui ont suivi le fichier INSTALL ou la documentation officielle de MySQL auront remarqué que la création d’un utilisateur « mysql » est préconisée.

Pour les autres, nous allons voir comment y remédier. Les commandes suivantes permettent de créer un groupe système mysql ainsi qu’un utilisateur mysql appartenant au groupe précédemment créé.

# groupadd mysql
# useradd -g mysql mysql

Pour des raisons de sécurité, il est préférable de s’assurer que cet utilisateur ne puisse pas se logger et ne possède pas de home. La commande suivante permet de spécifier ces options sous OpenBSD. Les paramètres de la commande useradd n’étant pas les mêmes d’un système à l’autre, référez-vous au manuel (man useradd) pour obtenir une commande équivalente chez vous.

# useradd -d /nonexistent -s /sbin/nologin -g mysql mysql

Sous Linux, vous pouvez spécifier /bin/false en tant que shell de l’utilisateur pour qu’il ne puisse pas se logger.

Maintenant que notre utilisateur est créé, nous allons lui donner accès en lecture/écriture aux répertoires de données (tables, index, enregistrements…) de MySQL. Pour cela, nous allons le désigner comme propriétaire de ces fichiers. Par la même occasion, nous nous assurons que l’utilisateur système root est propriétaire des autres fichiers de MySQL :

# cd REPERTOIRE_MYSQL
# chown -R root .
# chown -R mysql data
# chgrp -R mysql .

La commande précédente suppose que le dossier de données de MySQL se trouve dans le même répertoire que les autres fichiers de MySQL. Dans le cas contraire, adaptez la commande selon votre installation.

Assurons-nous ensuite que seuls l’utilisateur et le groupe mysql puissent avoir accès aux fichiers de données :

# chmod -R 660 data
# chmod 700 data/mysql

Une fois les droits attribués, nous pouvons lancer le serveur MySQL en spécifiant que l’utilisateur mysql que nous venons de créer sera le propriétaire du processus. Pour cela, deux possibilités s’offrent à nous.

La première est de rajouter une option à la commande permettant de lancer le serveur MySQL :

# cd REPERTOIRE_MYSQL
# bin/mysqld_safe --user=mysql &

La seconde consiste à modifier le fichier de configuration de MySQL (ex : /etc/my.cnf) afin de spécifier que l’utilisateur par défaut pour l’exécution du serveur est mysql. Il ne sera dès lors plus nécessaire de le répéter lors du lancement du serveur.

[mysqld]
user= mysql

Vérifions enfin que notre serveur MySQL tourne avec des droits limités. Pour cela, nous allons utiliser la commande ps après lancement de MySQL.

ps -aux | grep 'mysql'

La première colonne du résultat de la commande indique le propriétaire du processus. Si votre configuration est correcte, vous devriez donc voir mysql.

Lire la suite…

MySQL: Améliorer les performances grâce au partitionnement

19/11/2023 Aucun commentaire

mysql partitionnementI. Introduction

I-A. Définition

Pour tout bon informaticien, le terme « partitionnement » n’est pas inconnu. Cependant, bien que le partitionnement d’un disque dur soit devenu une banalité, l’utilisation du partitionnement en base de données reste encore rare.

Faisons tout d’abord un rappel sur le partitionnement d’un disque dur. L’intérêt de créer différentes partitions est de pouvoir organiser les données : des partitions sont réservées aux fichiers des systèmes d’exploitation installés et d’autres pour les données personnelles (photos, téléchargements…).

Dans cet article, nous allons nous intéresser au partitionnement dans le domaine des bases de données, et plus exactement au partitionnement de tables. Le but est, comme pour les disques durs, d’organiser les données. Néanmoins, nous n’allons pas utiliser cette organisation pour simplifier nos requêtes, mais bien pour en améliorer les performances !

I-B. Les types de partitionnement

Deux grands types de partitionnement sont utilisés pour partitionner une table :

  • partitionnement horizontal : les enregistrements (= lignes) d’une table sont répartis dans plusieurs partitions. Il est nécessaire de définir une condition de partitionnement, qui servira de règle pour déterminer dans quelle partition ira chaque enregistrement.

Exemple : nous disposons d’une table Amis et nous choisissons de la partitionner en

deux partitions :

  1. Les amis dont la première lettre du prénom est comprise entre A et M,
  2. Les amis dont la première lettre du prénom est comprise entre N et Z.
Image non disponible

Pour récupérer la liste complète de nos amis, il sera nécessaire de regrouper le contenu de nos deux partitions. Pour ce faire, une simple opération d’union d’ensembles suffit ;

  • partitionnement vertical : les colonnes d’une table sont réparties dans plusieurs partitions. Cela peut être pratique pour écarter des données fréquemment utilisées d’autres auxquelles l’accès est plus rare.

Exemple : nous disposons d’une table Amis contenant les prénom et photo de chacun de nos amis. Les photos prenant de la place et étant rarement accédées, nous décidons de les écarter des autres données.

Image non disponible

Comme vous pouvez le remarquer, les deux partitions contiennent l’identifiant des amis. Cela est nécessaire afin de garder le lien entre les données de chaque enregistrement. Ainsi, pour récupérer toutes les informations des amis, il suffit de faire une jointure entre les deux partitions.

Nous connaissons maintenant les deux types de partitionnement. Il est bien sûr possible d’utiliser un partitionnement vertical et un partitionnement horizontal sur une même table, ainsi que de partitionner sur plusieurs niveaux, c’est-à-dire définir des partitions de partitions.

I-C. Les avantages du partitionnement

Le partitionnement apporte plusieurs avantages à un administrateur de base de données. Voici les principaux intérêts du partitionnement :

  • pouvoir créer des tables plus grandes que la taille permise par un disque dur ou par une partition du système de fichiers : il est tout à fait possible de stocker des partitions à des endroits (partitions, disques, serveurs…) différents ;
  • pouvoir supprimer très rapidement des données qui ne sont plus utiles et utilisées : si ces données sont placées sur une partition séparée, il suffit de détruire la partition pour supprimer toutes les données ;
  • optimiser grandement certaines requêtes : les données étant organisées dans différentes partitions, le SGBD n’accède qu’aux données nécessaires lors des requêtes. Sans partitionnement, tous les enregistrements sont pris en compte.

Enfin, notons que le partitionnement de tables est généralement utilisé avec des bases de données réparties où les données sont placées sur des sites géographiques (éloignés ou proches) différents. Cet article se limite au partitionnement sur site local, mais les principes évoqués sont valides pour le partitionnement distant.

I-D. Notes à propos de MySQL

Dans MySQL, le partitionnement n’est géré de manière automatique qu’à partir de la version 5.1. Lors de la rédaction de cet article, MySQL 5.1 est encore en version bêta et par conséquent, il est possible que des bogues subsistent.

De plus, il est important de noter que seules les fonctionnalités de base du partitionnement seront disponibles dans la version finale de MySQL 5.1. Mais il est évident que les versions futures du SGBD apporteront leur lot d’améliorations.

Lire la suite…

Ten MySQL performance tuning settings after installation

16/11/2023 Comments off

mysql performance tuningIn this blog we’re going to discuss the top ten MySQL performance tuning settings that you can implement after an installation.

When we are hired for a MySQL performance audit, we are expected to review the MySQL configuration and to suggest improvements. Many people are surprised because in most cases, we only suggest changing a few MySQL performance tuning settings after installation – even though hundreds of options are available. The goal of this post is to give you a list of some of the most critical settings.

We already made such suggestions in the past here on this blog a few years ago, but things have changed a lot in the MySQL world since then!

Before we start…

Even experienced people can make mistakes that can cause a lot of trouble. So before blindly applying the recommendations of this post, please keep in mind the following items:

  • Change one setting at a time! This is the only way to estimate if a change is beneficial.
  • Most settings can be changed at runtime with SET GLOBAL. It is very handy and it allows you to quickly revert the change if it creates any problem. But in the end, you want the setting to be adjusted permanently in the configuration file.
  • A change in the configuration is not visible even after a MySQL restart? Did you use the correct configuration file? Did you put the setting in the right section? (all settings in this post belong to the [mysqld] section)
  • The server refuses to start after a change: did you use the correct unit? For instance, innodb_buffer_pool_size should be set in bytes while max_connection is dimensionless.
  • Do not allow duplicate settings in the configuration file. If you want to keep track of the changes, use version control.
  • Don’t do naive math, like “my new server has 2x RAM, I’ll just make all the values 2x the previous ones”.

Basic settings fro MySQL performance

Here are 3 MySQL performance tuning settings that you should always look at. If you do not, you are very likely to run into problems very quickly.

innodb_buffer_pool_size: this is the #1 setting to look at for any installation using InnoDB. The buffer pool is where data and indexes are cached: having it as large as possible will ensure you use memory and not disks for most read operations. Typical values are 5-6GB (8GB RAM), 20-25GB (32GB RAM), 100-120GB (128GB RAM).

innodb_log_file_size: this is the size of the redo logs. The redo logs are used to make sure writes are fast and durable and also during crash recovery. Up to MySQL 5.1, it was hard to adjust, as you wanted both large redo logs for good performance and small redo logs for fast crash recovery. Fortunately crash recovery performance has improved a lot since MySQL 5.5 so you can now have good write performance and fast crash recovery. Until MySQL 5.5 the total redo log size was limited to 4GB (the default is to have 2 log files). This has been lifted in MySQL 5.6.

Starting with innodb_log_file_size = 512M (giving 1GB of redo logs) should give you plenty of room for writes. If you know your application is write-intensive and you are using MySQL 5.6, you can start with innodb_log_file_size = 4G.

max_connections: if you are often facing the ‘Too many connections’ error, max_connections is too low. It is very frequent that because the application does not close connections to the database correctly, you need much more than the default 151 connections. The main drawback of high values for max_connections (like 1000 or more) is that the server will become unresponsive if for any reason it has to run 1000 or more active transactions. Using a connection pool at the application level or a thread pool at the MySQL level can help here.

Lire la suite…