Passer de la version 4.0 à la version 4.1

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. See Section C.2, « Changements de la version 4.1.x (Alpha) ».

• Si vous faites fonctionner MySQL sur Windows, voyezSection 2.2.11, « Mettre à jour MySQL sous Windows ».

• Après mise à jour du serveur, mettez à jour les tables de droits, pour accepter des colonnesPasswordplus grande. La procédure utilise le scriptmysql_fix_privilege_tableset est décrite dans la sectionSection 2.6.7, « 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 sectionSection 6.6, « Changer de version 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 utilisermysqldumppour exporter vos tablesBDBau format texte, et effacer tout les fichierslog.XXXXXXXXXXavant 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 chapitreSection 10.10.2, « Conversion de colonnes version 4.0 en version 4.1 ».

• Si vous utilisez un vieux moduleDBD-mysql(Msql-MySQL-modules) vous devez mettre à jour le moduleDBD-mysql. Tout ce qui est plus récent queDBD-mysql2.xx doit convenir.

Si vous ne mettez pas à jour, certaines commandes telles queDBI->do()ne rapporteront pas correctement les erreurs.

• L'option--defaults-file=option-file-namevous donnera une erreur si le fichier d'options 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--newde démarrage demysqldpour les versions supérieure à la 4.0.12. SeeSection 5.2.1, « Options de ligne de commande demysqld».

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 commandeSET @@new=1, pour désactiver cette option avecSET

@@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--newen 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 commandeSHOW CREATE TABLEetmysqldump. SeeChapitre 10, Jeux de caractères et Unicode. (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.frma 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.frmdirectement, 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 parmysqldump. SeeSection 8.8, «mysqldump, sauvegarde des structures de tables et les données ».

• Note importante : si vous mettez à jour en versionInnoDB-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 deInnoDBqui 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_nameavec des valeurs différentes sur toutes les machines.

• L'interface des fonctionsUDFagrégeantes a un peu changé. Vous devez commencer par déclarer une fonctionxxx_clear()pour chaque fonction agrégeanteXXX().

Evolution du client :

• mysqldumpdispose des options--optet--quote-names, qui sont activées par défaut. Vous pouvez les désactiver avec --skip-optet--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 colonnesCHARouVARCHARdont le dernier caractères peut être de codeASCII(32)ou plus petit, vous devez utiliser la commandeREPAIR TABLEoumyisamchk.

• Lorsque vous utilisez des commandesDELETEmulti-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 ...

• TIMESTAMPest maintenant retourné comme une chaîne, au format'YYYY-MM-DD HH:MM:SS'. L'option--newpeut ê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 colonneTIMESTAMP:

mysql> SELECT ts_col + 0 FROM tbl_name;

La largeur d'affichage des colonnesTIMESTAMPne 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 valeurTIMESTAMPindiquera le nombre de chiffres voulu pour les fractions de secondes.

• Les valeurs binaires, comme0xFFDF, 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 fonctionCAST()si vous voulez comparer des valeurs binaires avec les entiers :

mysql> SELECT CAST(0xFEFF AS UNSIGNED INTEGER) < CAST(0xFF AS UNSIGNED INTEGER);

-> 0

Installer MySQL

Si vous n'utilisez pasCAST(), 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--newpeut ê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 desDATE,DATETIME, ouTIMEsont 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 valeursDEFAULTne peuvent plus être spécifiées pour les colonnes de typeAUTO_INCREMENT. En 4.0, la clauseDEFAULT est ignorée silencieusement. En 4.1, une erreur survient.

• LIMITn'accepte plus les arguments négatifs. Utilisez 18446744073709551615 au lieu de -1.

• SERIALIZEn'est plus une option valide pour la variablesql_mode. Il faut utiliser la commandeSET TRANSACTION

ISOLATION LEVEL SERIALIZABLEà la place.SERIALIZEn'est plus valide comme option de--sql-modepourmysqld, non plus. Utilisez--transaction-isolation=SERIALIZABLE.

Changement de l'interface C :

• Certaines fonctions C telles quemysql_real_query()retournent maintenant1en 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. SeeSection 24.2.4, « Fonctions C de commandes préparées ».

• Passez en version 4.1, utilisez le scriptmysql_fix_privilege_tablespour agrandir la colonnePasswordde la table userpour 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 scriptmysql_fix_privilege_tablespour aggrandir la colonnePasswordde 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 sectionSection 5.5.9, « Hashage de mots de passe en MySQL 4.1 ».Section A.2.3, « ErreurClient does not support authentication protocol».