Migrer une base de données mysql 5.5 à mysql 8.0

Version imprimable

20/02/2023, 18h20
NickyBee

Migrer une base de données mysql 5.5 à mysql 8.0

Bonjour

Je viens de changer de serveur qui est en MySQL 8.0
Et ma base de donnée est sur MySQL 5.5

Comment faire une migration en bonne et due forme.
Car après avoir fait l'exportation en SQL puis la réimportation.
Impossible de mettre à jour certaines tables de la base.
J'ai l'impression qu'il se perd dans les index.

Est ce qu'il y a un correctif pour passé la base en 8.0

Cordialement
20/02/2023, 21h10
NickyBee

Inser Update Duplicate Entry Mysql 8.0

Suite à la migration

Voici l'erreur que cela génère lors de l import de nouveau produit dans ma base de donnée

Code:

[INSERT INTO PC7_PRODUCT(ID, CATEGORY_ID, TITLE, TITLE_CLEAN, FILENAME, MANUFACTURER, MANUFACTURER_CODE, EAN_UPC, MIN_PRICE, MAX_PRICE, STORE_COUNT, ISVALID, STANDBY, SPECIAL_OFFER, PAGE_TITLE, PAGE_KEYWORDS, PAGE_DESCRIPTION, FIELD_1, FIELD_2, FIELD_3, FIELD_4, FIELD_5, FIELD_6, FIELD_7, FIELD_8, FIELD_9, DATE_ADDED) VALUES('203133', '475', 'Baskets montantes Converse CHUCK TAYLOR ALL STAR CORE HI', 'Baskets montantes Converse CHUCK TAYLOR ALL STAR CORE HI', 'baskets-montantes-converse-chuck-taylor-all-star-core-hi', '72', 'M7650C', '886952780425', '0', '0', '0', 'Y', '0', 'N', '', '', '', '', '', '', '', '', '', '', '', '', '2023-02-20 21:01:09')] - Duplicate entry '203133' for key 'PC7_PRODUCT.PRIMARY' -

Avez vu une idée de l'erreur dans la base de donnée

Cordialement
21/02/2023, 21h40
Séb.

Ta table PC7_PRODUCT contient déjà une ligne dont la colonne ID vaut "203133".
Peut-être un précédent import, ou un contrainte qui n'était pas présente dans la table d'origine.
22/02/2023, 11h14
escartefigue

bonjour,

Si la table cible est une table vide et sans lien avec d'autres tables, alors il faut vérifier le paramétrage des identifiants (valeur initiale et incrément, voir ICI) puis charger les différentes tables sans mentionner les colonnes identifiantes dans les ordres INSERT. Ce faisant, le moteur va automatiquement ajouter les nouvelles valeurs d'identifiants.

Si la cible n'est pas vide ou qu'elle est liée à d'autres tables à charger, alors il s'agit d'une convergence de données.
Auquel cas il faut d'abord renuméroter les tables possédant les identifiants (les PK) en tenant compte des valeurs d'identifiants déjà présentes dans la cible, enregistrer les correspondances entre identifiant source et identifiant cible, puis propager cette correspondance dans les tables liées (celles possédant des FK).
Une convergence de S.I. est un projet en soi, la partie technique est une chose (unicité des identifiants), mais il faut aussi identifier les doublons fonctionnels.
22/02/2023, 19h40
Artemus24

Salut NickyBee.

Citation:

Envoyé par NickyBee

Je viens de changer de serveur qui est en MySQL 8.0

Petite précision, MySql est un SGBDR (Système de Gestion de Bases de Données Relationnel.

Citation:

Envoyé par NickyBee

Est ce qu'il y a un correctif pour passé la base en 8.0

A priori non, si tu respectes le standard des bases de données.

Citation:

Envoyé par NickyBee

Avez vu une idée de l'erreur dans la base de donnée

Tu trouves la solution en bout de ligne : "Duplicate entry '203133' for key 'PC7_PRODUCT.PRIMARY' -.
Tu as un doublon sur l'une des valeur de ta primary key.

Origine possible du problème : tu as oublié de vider ta table avant de la recharger.

Est-ce que tu fusionnes plusieurs tables en une seul ?
Dans ce cas, il faudrait effectuer une migration et non un simple bidouillage.
Par exemple id=1 de ta deuxième table que tu fusionnes avec la première devra passer à la valeur id=1001.
Dans ce cas, il faut modifier tous les id=1 qui sont succeptible d'être en clef étrangère pour les passer à id=1001.
En espérant aussi, que id=1001 ne soit pas déjà utilisé dans ta première table.

Il serait bien que tu nous indiques ce que tu fais exactement.
Nous ne connaissons pas le contexte de ta base de données, et tout ce que nous pouvons dire ne sont que des suppositions.

Cordialement.
Artemus24.
@+

Artemus24
Voici ce que j'ai fait

1 - Creer ma base de donnée sur mon nouveau serveur qui utilise mysql 8.0
2 - Exporter mes tables en un fichier sql de mon ancienne base de donnée et ancien serveur qui utilise mysql 5.5
3 - Importer mes tables en un fichier sql sur ma nouvelle base de donnée
4 - Faire une mise à jour des produits de ma table
5 - Et il y a plusieurs table dans ma base de donnée

Et Sur une autre base de donnée j'ai une autre erreur

Code:

1
2
3
4
5
LOAD DATA LOCAL INFILE '/home/xxx/www.domaine.com/upload/merchant/34/im_product.sql' INTO TABLE xxxx_-zapoza.PC7_PRODUCT FIELDS TERMINATED BY '|' ENCLOSED BY '\'' LINES TERMINATED BY ' ' (ID, CATEGORY_ID, TITLE, TITLE_CLEAN, FILENAME, MANUFACTURER, MANUFACTURER_CODE, EAN_UPC, MIN_PRICE, MAX_PRICE, STORE_COUNT, ISVALID, STANDBY, SPECIAL_OFFER, FIELD_1, FIELD_2, FIELD_3, FIELD_4, FIELD_5, FIELD_6, FIELD_7, FIELD_8, FIELD_9, DATE_ADDED)] - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-zapoza.PC7_PRODUCT FIELDS TERMINATED BY '|' ENCLOSED BY '\'' LINES TERMINATED B' at line 1 -
- error in file admin/product_import_feed_functions_ml.php on line # 0 : executeUpdate
- error in file admin/product_import_feed_functions_ml.php on line # 0 : doFeedFileFinalTask
- error in file admin/product_import_feed_functions.php on line # 0 : processFeedFileML
- error in file admin/autofeed_cronjob.php on line # 0 : processFeedFile

Salut NickyBee.

Euh, je ne comprends pas trop là.
Tu parles d'importer et d'exporter tes bases de données à partir d'un fichier ".sql" et tu nous donnes un exemple d'erreur sur un "load data local infile".
Ce n'est pas du tout le même format de fichier à charger dans MySql.

Voici un exemple pour exporter une base de données :

Code:

mysqldump --no-create-db --opt --databases ta_base --result-file=f:/ta_base.sql

Pour importer une base de données :

Code:

mysql mysql < f:/ta_base.sql

Dans ton fichier ".sql", tu as quelque chose dans ce genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 -- -- Structure de la table `tab_exemple` -- DROP TABLE IF EXISTS `tab_exemple`; CREATE TABLE `tab_exemple` ( `id` integer unsigned auto_increment NOT NULL PRIMARY KEY, `libelle` char(10) NOT NULL, `date` date NOT NULL, `time` time NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED; -- -- Vider la table avant d'insérer `tab_access` -- TRUNCATE TABLE `tab_exemple`; -- -- Contenu de la table `tab_exemple` -- INSERT INTO `tab_exemple` (`libelle`, `date`, `time`) VALUES ('un', '2015-08-01', '13:45:17'), ('deux', '2015-08-25', '20:17:58'), ('trois', '2015-08-23', '16:33:25'); COMMIT;
Ta requête "load data local infile" semble ne pas avoir la bonne syntaxe MySql :
Code:

1 2 3 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-zapoza.PC7_PRODUCT FIELDS TERMINATED BY '|' ENCLOSED BY '\'' LINES TERMINATED B' at line 1 -
Tu as un tiret dans le nom de ta table. Est-ce une faute de frappe ?
Surtout que tu as un tiret après un souligné. MySql va interpréter cela comme une soustraction.

Mets ce nom de table entre quote inversée ` (ALT GR + 7).

Cordialement.
Artemus24.
@+

Citation:
Envoyé par Artemus24
Salut NickyBee.

Euh, je ne comprends pas trop là.
Tu parles d'importer et d'exporter tes bases de données à partir d'un fichier ".sql" et tu nous donnes un exemple d'erreur sur un "load data local infile".
Ce n'est pas du tout le même format de fichier à charger dans MySql.

Voici un exemple pour exporter une base de données :

Code:

mysqldump --no-create-db --opt --databases ta_base --result-file=f:/ta_base.sql

Pour importer une base de données :

Code:

mysql mysql < f:/ta_base.sql

Dans ton fichier ".sql", tu as quelque chose dans ce genre :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 -- -- Structure de la table `tab_exemple` -- DROP TABLE IF EXISTS `tab_exemple`; CREATE TABLE `tab_exemple` ( `id` integer unsigned auto_increment NOT NULL PRIMARY KEY, `libelle` char(10) NOT NULL, `date` date NOT NULL, `time` time NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED; -- -- Vider la table avant d'insérer `tab_access` -- TRUNCATE TABLE `tab_exemple`; -- -- Contenu de la table `tab_exemple` -- INSERT INTO `tab_exemple` (`libelle`, `date`, `time`) VALUES ('un', '2015-08-01', '13:45:17'), ('deux', '2015-08-25', '20:17:58'), ('trois', '2015-08-23', '16:33:25'); COMMIT;
Ta requête "load data local infile" semble ne pas avoir la bonne syntaxe MySql :
Code:

1 2 3 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-zapoza.PC7_PRODUCT FIELDS TERMINATED BY '|' ENCLOSED BY '\'' LINES TERMINATED B' at line 1 -
Tu as un tiret dans le nom de ta table. Est-ce une faute de frappe ?
Surtout que tu as un tiret après un souligné. MySql va interpréter cela comme une soustraction.

Mets ce nom de table entre quote inversée ` (ALT GR + 7).

Cordialement.
Artemus24.
@+
Artemus

Mon nom de table a bien un - ce n'est pas une faute de frappe.

Maintenant je repart sur une nouvelle table vierge sur laquelle de créer mes nouvelles tables.

Lors de la création de l'une d'elle j'ai un message d'erreur
Code:

1 2 3 [CREATE TABLE PC7_POPULAR_CATEGORY (CATEGORY_ID INT (11) UNSIGNED NOT NULL, RANK TINYINT (3) UNSIGNED DEFAULT '1' NOT NULL, PRIMARY KEY(CATEGORY_ID), UNIQUE(CATEGORY_ID), INDEX IndexCATEGORY_ID (CATEGORY_ID), INDEX IndexRANK (RANK), FOREIGN KEY(CATEGORY_ID) REFERENCES PC7_CATEGORY (ID) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8] - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'RANK TINYINT (3) UNSIGNED DEFAULT '1' NOT NULL, PRIMARY KEY(CATEGORY_ID), UNIQUE' at line 1 - - error in file admin/install/create-addons.php on line # 0 : executeUpdate - error in file admin/install/create.php on line # 0 : unknown
As tu une idée de cette erreur ?
Cordialement

Salut NickyBee.

"rank" est un mot réservé.
Evite d'utiliser des mots réservés si tu ne les mets pas entre apostrophe inversées.
Je te le répète : mets tes nom de colonnes entre ` (ALT GR + 7).
Ils ne seront pas interprétés par MySql.

Pourquoi utilises-tu les majuscules ? Ca fonctionne aussi en minuscule.

Il est inutile de créer un "unique index" et un "index" sur la clef primaire, Mysql le fait déjà.
La valeur numérique 1, par defaut, que tu mets dans la colonne "RANK", ne doit pas être mis entre apostrophe.
MySql va l'interpréter comme une chaine de caractères.

Ta clef étrangère est mal déclaré.

Code:

CONSTRAINT `FK_01` FOREIGN KEY (`categorie_id`) REFERENCES `pc7_categoriy` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
Code:

1 2 3 4 5 CREATE TABLE PC7_POPULAR_CATEGORY ( `CATEGORY_ID` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, `RANK` TINYINT UNSIGNED NOT NULL DEFAULT 1, FOREIGN KEY(`CATEGORY_ID`) REFERENCES `PC7_CATEGORY` (`ID`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8
Cordialement.
Artemus24.
@+

24/02/2023, 18h45
NickyBee

Bizarre

Avant mes tables fonctionnées correctement en Mysql5.5 et maintenant que je suis basculé mysql 8.0 elle a des problèmes de création de table et de clef primaire

Je suis perdu
24/02/2023, 19h02
Artemus24

Salut NickyBee.

Il y a eu des évolutions depuis la version MySql 5.0.
MySql ne respecte pas toujours les normes et il se peut que tu les ai enfreints.
Afin de minimaliser ses changements, tu aurais dû migrer ton environnement à chaque nouvelle version de MySql.
C'est ce que je vais, et je te rassure, j'ai aussi des problèmes de compatibilités.
Cela se passe plus dans le paramétrage du fichier "my.ini" qu'au niveau des applications que j'ai développés.

En ce moment, j'essaye de migrer apache et MySql vers le mode SSL.
Cela fonctionne pour Apache, mais j'ai encore des problèmes avec MySql.
J'ai un problème avec le PDO car il ne reconnais pas le mode SSL et je suis obligé de le désactiver dans mes requêtes.
Et le pire, je ne sais pas pourquoi cela ne fonctionne pas.

Cordialement.
Artemus24.
@+
24/02/2023, 19h14
NickyBee

Artemus

Je pense que mon problème est sur la clé primaire, je constate avoir 2 ou 3 cle primaire sur une table. (est ce normal)

Donc sur mes tables je dois supprimer l index sur les clefs primaires ?

Est ce normal d'avoir un index ou plusieurs index sur une table sans être clefs primaires ?

Nicky
25/02/2023, 06h17
Artemus24

Salut Nickybee.

Citation:

Envoyé par NickyBee

Je pense que mon problème est sur la clé primaire, je constate avoir 2 ou 3 cle primaire sur une table. (est ce normal)

Il n'est pas possible d'avoir plusieurs clefs primaire sur une table.
Tu voulais certainement dire plusieurs index sur la clef primaire, oui, c'est possible mais il faut voir l'intérêt de procéder ainsi.

Citation:

Envoyé par NickyBee

Donc sur mes tables je dois supprimer l index sur les clefs primaires ?

Ne supprime surtout pas ta clef primaire.

A quoi sert un index, en dehors de la clef primaire et de la clef étrangère ?
Cela sert à améliorer les performances sur une requête.
Dans un select, quand tu fais un "where table1.col1 = table2.col2", mysql ne sachant pas ou se trouve la valeur recherchée va parcourir la première table depuis le début jusqu'à la fin.
Si ta table est très volumineuse, cela risque de prendre énormement de temps, d'où l'intérêt d'améliorer les performences.

Citation:

Envoyé par NickyBee

Est ce normal d'avoir un index ou plusieurs index sur une table sans être clefs primaires ?

La clef primaire est une clef cluster dans mysql.
Cela permer de ranger les lignes sur le disque dans l'ordre spécifié par cette clef primaire.
Ainsi les lignes ayant les mêmes valeurs de cette clef sont contigues sur le disque et permet de ne faire qu'une lecture physque pour les obtenir.
L'intérêt est d'améliorer les performances d'accès aux lignes.

La clef étrangère comme la clef primaire sont des index techniques.
Cela signifie que leur valeur n'ont aucun sens fonctionnelle, mais servent à relier des lignes d'une manière hiérarchique entre elle.
Plusieurs lignes de la table fille vont pointer vers une seule ligne de la table mêre.

Il est possible dans une table d'avoir plusieurs identifiants.
Un identifiant permet d'accéder à une ligne de manière unique.
Comme tu ne peux avoir qu'une seule clef primaire, l'autre devient alors un "unique index".
Donc oui, il est possible d'avoir d'autres index, qui servent, comme je l'ai dit, surtout pour des questions de performances.

Ton problème ne concerne pas tes index.
Ton problème concerne l'ordre d'installation des tables dans ta nouvelle base de données.
Tu comprends que la table mère doit être installée avant la table fille, à cause que la valeur contenue dans la colonne de la table fille, qui est une clef étrangère, doit exister aupréalable dans la table mère.

Si tu as un problème de doublon dans la clef primaire, c'est beaucoup plus grave car ce problème existait déjà avant.
Ou alors, tu as fait une mauvaise manipulation lors de ton importation.

Il est difficile de t'aider car je ne connais pas ton application et j'ignore les problèmes que tu rencontres.

Ne pas oublier aussi que dans ton SGBDR d'origine, pour exporter, tu vas certainement utiliser un ancien PhpMyAdmin.
Il y a aussi de forte chance que celui-ci ne soit plus du tout en phase avec le PhpMyAdmin du SGBDR de destination.

Il y a fort longtemps, quand je faisais des migrations, celles-ci prenaient plusieurs mois.
Il fallait convertir fonctionnellement les données de l'ancienne application dans la nouvelle.
Nous étions obligés de travailler avec des gestionnaires qui nous montraient comment convertir ces données.
Il arrivait qu'eux-mêmes ne savaient pas trop comment faire puisqu'ils ne connaissaient pas bien la nouvelle application.
Je n'avais aucun outil à ma disposition, sauf le cobol. Je travaillais sur IBM et BULL, gros système à l'époque.
Nous étions obliger de créer des programmes cobol, juste pour décharger les tables en créant des fichiers séquentielles où toutes les données étaient lisible.
Nous devions ensuite convertir fonctionnellement ces données pour qu'elles soient exploitables dans la nouvelle application.
A partir de ces nouveaux fichiers séquentiels, nous utilisions des outils pour les charger dans la nouvelle base de données.
La migration en elle même devait durer le moins de temps possible, en général un week-end et nous n'avions droit à aucun problème durant cette phase.
D'où plusieurs simulation avant le jour fatidique !

J'ai fait beaucoup de migrations autour des années 2000, entre autre à cause du passage des années de deux chiffres à quatre chiffres.
Ainsi que le passage du matériel BULL vers IBM.

Cordialement.
Artémus24.
@+
03/03/2023, 14h01
escartefigue

Citation:

Envoyé par Artemus24

Citation:

Envoyé par NickyBee

Artemus

Je pense que mon problème est sur la clé primaire, je constate avoir 2 ou 3 cle primaire sur une table. (est ce normal)
Donc sur mes tables je dois supprimer l index sur les clefs primaires ?
Est ce normal d'avoir un index ou plusieurs index sur une table sans être clefs primaires ?
Nicky

Il n'est pas possible d'avoir plusieurs clefs primaire sur une table.
Tu voulais certainement dire plusieurs index sur la clef primaire, oui, c'est possible mais il faut voir l'intérêt de procéder ainsi.

On ne peut pas avoir plusieurs PK sur une seule table, par contre, une PK peut se composer de plusieurs colonnes.
Les PK multi colonnes sont la règle dans le cas de tables associatives (tables issues d'une association du MCD et dont la PK est composée des identifiants hérités de chaque type d'entité participant à l'association), c'est également le cas en cas d'identification relative (fréquement utilisée pour les lignes de facture, les lignes de commande, les chambres d'hôtel...)

Il est tout à fait normal d'avoir d'autres index que l'index PK sur une table.
La PK porte le plus souvent sur des identifiants techniques (type identity, auto_increment, serial...) qui sont à la fois concis et stables.
Les autres index portent sur des colonnes fonctionnelles (recherche par nom, par n° de sécurité sociale, par SIREN...).
Après, il ne faut pas avoir une pléthore d'index sur une même table, car ça ralentit les mises à jour et les servitudes.