Sommaire 27 Historique des changements MySQL
2.5 Changer de version de MySQL
2.5.2 Passer de la version 4.0 à la version 4
En général, vous devez suivre les instructions suivantes pour passer de MySQL 4.0 à 4.1 : Vérifiez la liste des modifications de cette section, vous voir si elles ont un impact sur vos applications.
•
Lisez la liste des nouveautés de la version 4.1 pour identifier les nouvelles fonctionnalités significatives pour vos projets. Changements de la version 4.1.x (Gamma) .
•
Si vous faites fonctionner MySQL sur Windows, voyez Mise à jour de MySQL sous Windows . Note importante : Les premières versions de MySQL 4.1 sur Windows ne contiennent pas de programme d'installation. Voyez Installer les binaires sous Windows pour des instructions sur l'installation d'une telle distribution.
•
Après mise à jour du serveur, mettez à jour les tables de droits, pour accepter des colonnes
Password
plus grande. La procédure utilise le script mysql_fix_privilege_tables
et est décrite dans la section Mise à jour des tables de droits . Les implications du changement de gestion du mot de passe est décrit plus loin dans cette section. Si vous ne le faîtes pas, MySQL ne pourra pas utiliser le protocole sécuritaire pour l'identification.
•
Si vous utilisez la réplication, voyez la section Mettre à jour une architecture de réplication pour mettre à jour votre installation.
•
Le moteur de table Berkeley DB table est passé en version DB 4.1 (depuis la 3.2), et il dispose d'un nouveau format de log. Si vous devez revenir en version 4.0, vous devrez utiliser mysqldump
pour exporter vos tables BDB
au format texte, et effacer tout les fichiers
log.XXXXXXXXXX
avant de redémarrer le serveur MySQL 4.0 et de réimporter les données.
•
Le support des jeux de caractères a été amélioré. si vous avez des tables qui contiennent des données représentées dans un jeu de caractères que MySQL 4.1 supporte directement, vous pouvez convertir ces colonnes vers le bon jeu de caractères avec les instructions du chapitre Conversion des colonnes de caractères version 4.0 en format 4.1 .
•
Si vous utilisez un vieux module DBD−mysql
( Msql−MySQL−modules
) vous devez mettre à jour le module
DBD−mysql
. Tout ce qui est plus récent que DBD−mysql
2.xx doit convenir.Si vous ne mettez pas à jour, certaines commandes telles que DBI−>do()
ne rapporteront pas correctement les erreurs.
•
L'option −−defaults−file=option−file−name
vous donnera une erreur si le fichier d'option n'existe pas.
•
Plusieurs comportements visibles ont changé entre MySQL 4.0 et MySQL 4.1 pour corriger des bogues critiques et rendre MySQL plus compatible avec le standard SQL. Ces changements peuvent affecter votre application.
Certains des comportement 4.1 peuvent être testés en version 4.0 avant de passer à la 4.1. Nous avons ajouté l'option −−new
de démarrage de mysqld
pour les versions supérieure à la 4.0.12. Options de ligne de commande mysqld
.
Cette option vous donne le comportement de la version 4.1 pour les modifications les plus critiques. Vous pouvez aussi activer ces comportements pour une connexion particulière en utilisant la
commande SET @@new=1
, pour désactiver cette option avec SET @@new=0
.
Si vous pensez que certains des changements de la version 4.1 vous affecteront, nous vous recommandons, avant de passer en version 4.1, de télécharger la dernière version 4.0, et de l'exécuter avec l'option −−new
en plus de vos configuration habituelles :
[mysqld−4.0] new
De cette manière, vous pouvez tester le comportement de la version 4.1 depuis votre serveur 4.0. Cela vous donnera le temps de supprimer les anomalies, et de passer sans problème à la version 4.1, ultérieurement. En faisant cela, vous n'allez pas rencontrer de bug accidentel lors du
changement, que vous n'aurez pas corrigé grâce à −−new
.
Voici une liste complète, vous indiquant ce à quoi vous devez faire attention lors du changement de version :
Modification du serveur :
Toutes les colonnes et tables ont désormais un jeu de caractères, qui apparaît dans le résultat de la commande SHOW CREATE TABLE
et mysqldump
. Jeux de caractères . (MySQL 4.0.6 et plus récent peuvent lire les nouveaux fichiers de dump, mais pas les plus anciennes versions de MySQL). Cela ne doit pas affecter les applications qui n'utilisent qu'un seul jeu de
caractères.
•
Le format de définition de table du fichier .frm
a légèrement changé en version 4.1. Les versions de MySQL 4.0 à partir de la 4.0.11 peuvent lire le nouveau format .frm
directement, mais les versions plus anciennes ne le peuvent pas. Si vous devez déplacer des tables de la version 4.1 vers une version 4.0.11, passez plutôt par mysqldump
. mysqldump
, exporter les structures de tables et les données .
•
Note importante : si vous mettez à jour en version InnoDB
−4.1.1 ou plus récent, il sera difficile de revenir à une version plus ancienne, 4.0 or 4.1.0! Ceci est dû aux versions de
InnoDB
qui ne reconnaissent pas les espaces de table multiples.
•
Si vous utilisez plusieurs serveurs sur la même machine Windows, vous devriez utiliser l'option −−shared_memory_base_name
avec des valeurs différentes sur toutes les machines.
•
L'interface des fonctions UDF
agrégeantes a un peu changé. Vous devez commencer par déclarer une fonction xxx_clear()
pour chaque fonction agrégeante XXX()
.
•
Evolution du client : mysqldump
dispose des options −−opt
et −−quote−names
, qui sont activées par défaut. Vous pouvez les désactiver avec −−skip−opt
et −−skip−quote−names
.
•
Evolution du SQL :
La comparaison de chaînes fonctionne maintenant conformément au standard SQL : au lieu de supprimer les espaces de fin de chaîne avant la comparaison, nous complétons les chaînes courte avec des espaces. Le problème est que maintenant, 'a' > 'a\t'
, ce qui n'était pas le cas avant. Si vous avez des tables avec des colonnes CHAR
ou VARCHAR
dont le dernier caractères peut être de code ASCII(32)
ou plus petit, vous devez utiliser la commande REPAIR TABLE
ou myisamchk
.
•
Lorsque vous utilisez des commandes DELETE
multi−tables, vous devez utiliser les alias de tables que vous voulez effacer, et non pas le véritable nom de la table. Par exemple, au lieu de :
DELETE test FROM test AS t1, test2 WHERE ...
faîtes :
DELETE t1 FROM test AS t1, test2 WHERE ...
•
TIMESTAMP
est maintenant retourné comme une chaîne, au format 'YYYY−MM−DD HH:MM:SS'
. L'option −−new
peut être utilisée depuis la version 4.0.12, pour que le serveur adopte le comportement de la version 4.1 pour ce point. Si vous voulez recevoir la version entière de la valeur, comme en version 4.0, il suffit d'ajouter +0 à chaque colonne TIMESTAMP
:
mysql> SELECT ts_col + 0 FROM tbl_name;
La largeur d'affichage des colonnes TIMESTAMP
ne sont plus supportées. Par exemple, si vous déclarez une colonne de type TIMESTAMP(10)
, le nombre (10)
est ignoré.Ces changements sont nécessaires pour respecter les standards SQL. Dans une future version, une autre
modification aura lieu, mais restera compatible avec celle−ci : la taille de la valeur TIMESTAMP
indiquera le nombre de chiffres voulu pour les fractions de secondes.
•
Les valeurs binaires, comme 0xFFDF
, sont maintenant supposées être des chaînes et non pas des nombres. Cela corrige des problèmes avec les jeux de caractères, où il est plus pratique d'insérer une chaîne comme une chaîne binaire. Avec cette modification, vous devez utiliser la fonction CAST()
si vous voulez comparer des valeurs binaires avec les entiers :
mysql> SELECT CAST(0xFEFF AS UNSIGNED INTEGER) < CAST(0xFF AS UNSIGNED INTEGER); −> 0
Si vous n'utilisez pas CAST()
, une comparaison lexicale de la chaîne aura lieu :
mysql> SELECT 0xFEFF < 0xFF; −> 1
Utiliser des chaînes binaires dans un contexte numérique, ou bien comparer des valeurs avec les opérateurs comme =
devrait fonctionner comme auparavant. L'option −−new
peut être utilisée à partir de la version 4.0.13 pour que le serveur 4.0 se comporte comme le serveur 4.1.
•
Les fonctions qui retournent des DATE
, DATETIME
, ou TIME
sont désormais traitées lors de leur arrivée sur le client. Par exemple, en MySQL 4.1, vous obtenez le résultat suivant :
mysql> SELECT CAST("2001−1−1" as DATETIME); −> '2001−01−01 00:00:00'
En MySQL 4.0, le résultat est différent :
mysql> SELECT CAST("2001−1−1" as DATETIME); −> '2001−01−01'
•
Les valeurs DEFAULT
ne peuvent plus être spécifiées pour les colonnes de type AUTO_INCREMENT
. En 4.0, la clause DEFAULT
est ignorée silencieusement. En 4.1, une erreur survient.
•
LIMIT
n'accepte plus les arguments négatifs. Utilisez 18446744073709551615 au lieu de −1.
•
SERIALIZE
n'est plus une option valide pour la variable sql_mode
. Il faut utiliser la commande SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
à la place. SERIALIZE
n'est plus valide comme option de −−sql−mode
pour mysqld
, non plus. Utilisez −−transaction−isolation=SERIALIZABLE
.
•
Changement de l'interface C :
Certaines fonctions C telles que mysql_real_query()
retournent maintenant 1
en cas d'erreur, et non plus −1
. Vous aurez peut être à changer certaines anciennes applications comme ceci :
if (mysql_real_query(mysql_object, query, query_length) == −1) {
printf("Erreur"); }
Modifiez le test de comparaison à 0 :
if (mysql_real_query(mysql_object, query, query_length) != 0) {
printf("Erreur"); }
•
Gestion des mots de passe :
Le mécanisme de mot de passe a changé en version 4.1 pour assurer une meilleure sécurité, mais cela pose des problèmes de compatibilité, si vous avez encore des clients qui utilisent les
bibliothèques 4.0 ou plus ancien. Il est probable que vous ayez de tels clients, s'ils se connectent depuis des serveurs distants qui n'ont pas encore adopté la version 4.0. La liste suivante présente les stratégies de mise à jour. Elle représentent différents compromis entre la compatibilité et la sécurité.
Ne passez pas en version 4.1. Aucun comportement ne changera, mais vous ne pourrez pas utiliser les nouvelles fonctionnalités du protocole de la version 4.1. MySQL a amélioré le protocole client/serveur de la version 4.1, en ajoutant les commandes préparées et le
support des jeux de caractères. Commandes préparées en C .
•
Passez en version 4.1, utilisez le script mysql_fix_privilege_tables
pour agrandir la colonne Password
de la table user
pour qu'elle puisse contenir les nouveaux hashs de mots de passe. Mais lancez le serveur avec l'option −−old−passwords
pour que les clients pre−4.1 puissent continuer d'utiliser leurs anciens comptes. Finalement, lorsque tous les clients seront passés en version 4.1, vous pourrez cesser d'utiliser l'option −−old−passwords
. Vous pouvez aussi changer les mots de passe de vos comptes MySQL pour adopter le nouveau format.
•
Passez en version 4.1 et utilisez le script mysql_fix_privilege_tables
pour aggrandir la colonne
Password
de la table user
. Si vous savez que tous les clients sont passés en version 4.1, n'utilisez pas l'option −−old−passwords
. Au lieu de cela, changez les mots de passe de tous les comptes, pour qu'ils adoptent le nouveau format. Une installation 100% 4.1 est la plus sûre.
•
D'autres informations sur le nouvel algorithme de protection des mots de passe et les opérations les concernants sont disponibles dans la section Chiffrement des mots de passe en MySQL 4.1 . Client does not support authentication protocol
.