Bonjour,
Je viens d’installer dolibarr 7.0.3 sur un serveur VPS de OVH en debian 9 pour y migrer un dolibarr qui était hébergé sur un lifetime hosting de qualité médiocre (dolibarr 7.0.3 également) nombreux downtime et plus assez de ressources ram pour générer des factures en pdf depuis dolibarr.
J’ai fait une copie des data de l’ancien vers le nouveau comme indiqué dans la procédure sauvegarde/ restauration sans souci
ensuite j’ai fait un mysqldump de la base de données (MySQL or MariaDB 5.6.41) sur l’ancien serveur et je l’injecte dans le nouveau serveur (base de donnée MySQL or MariaDB 5.5.5-10.1.26-MariaDB-0+deb9u1) avec la commande indiquée dans la procédure de restauration /usr/bin/mysql hnbdolibarr -h localhost -P 3306 -u dolibarr -p* < mysqldump_hagricob_doli590_7.0.3_201811171517.sql
Et j’ai l’erreur suivante: ERROR 1005 (HY000) at line 25: Can’t create table hnbdolibarr.llxdi_accounting_account (errno: 121 « Duplicate key on write or update »)
J’ai lu sur le web un problème similaire mais je ne trouve pas comment résoudre mon problème concrètement:
Je dois éditer ma sauvegarde .sql? comment?
Je dois dropper ma base de donnée sur le nouveau serveur et recommencer?
Merci de votre aide…
Bonsoir,
La nouvelle base est-elle vide (aucune tables) ou a-t-elle était créée par l’installation de la nouvelle instance de dolibarr ?
J’effectue de nombreuse migration de base et à chaque fois, pour éviter toute difficultés, je vide complètement la base destinataire (suppression de toute les tables).
Cordialement,
Sylvain Legrand.
1 « J'aime »
exact elle n’est pas vide, je vais voir comment vider cela
un grand merci
sudo /usr/bin/mysql hnbdolibarr -h localhost -P 3306 -u dolibarr -p****** -e « show tables; » | awk ‹ /^prefixe_tables/ {print « set_foreign_key_checks=0;drop table hnbdolibarr. »$1";"} ›
je lance la commande ci dessus pour tenter de vider le tout est-ce correct?
Ensuite je relance l’importation de la base sql et j’obtiens… la même erreur que précédemment
Tiré de la doc:
(je teste de de suite et bin toujours la même erreur pourtant j’étais optimiste…)
Dans tous les cas, votre dump sql doit désactiver les vérifications de Foreign Keys pendant la restauration, sinon votre backup sql ne pourra pas être restauré à cause des clashs entre les Foreign Keys! Exemple: Ajouter FOREIGN_KEY_CHECKS au tout début et à la fin du fichier sql:
-- SQL Dump
-- Server version: 5.5.8
SET FOREIGN_KEY_CHECKS=0;
SET SQL_MODE=« NO_AUTO_VALUE_ON_ZERO »;
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT /;
/!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS /;
/!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION /;
/!40101 SET NAMES utf8 */;
CREATE TABLE IF NOT EXISTS llx_accountingaccount (
INSERT INTO …
CREATE TABLE …
INSERT INTO …
…
SET FOREIGN_KEY_CHECKS=1;
Warning.png Mysqldump (que ce soit par l’outil en ligne de commande ou par la fonction Sauvegarde de Dolibarr) est le moyen le plus sûr de sauvegarder vos données, car il est développé par les même développeurs que MySQL et est donc toujours à jour. PhpMyAdmin et les logiciels tiers peuvent générer un dump SQL valide, mais le code SQL résultant peut être obsolète ou manquer de certaines fonctionnalités (en fonction des options que vous choisissez).
Bonjouir,
Personnellement j’utilise un outil externe type PHPMyAdmin pour vider la base.
Cordialement,
Sylvain Legrand.
