Bonjour Otomatic; Tout s'est passé comme prévu, SAUF, après
Je n'avais pas confiance aux nouvelles versions MySQL donc j'a essayé de charger les sauv dans la 29 et il y a plein de messages fonds rose. Rien ne se charge (les BDD j'ai jamais aimé ça!) Du coup, étant donné qu'intuitivement je pensais que celles de la 17 était bonnes , je n'ai surtout pas pris le risque de toucher à la 17 qui a ses 7 BDD.
Tous les sites fonctionnent, je n'ai vraiment pas vu d'anomalie bon impossible eu égard au nombre de texte de vérifier tout mais je vois bien que tout est cohérant
Sauriez vous si il y aurait un avantage de travailler sur une 5.6.29 plutôt qu'une5. 6.17 - car pour mon nouveau site je me demande du coup si je vide complètement la 5.6.29 et travaille dessus…
Ou bien dois je installer encore d'autres version? J'ai très peur de ces pb de compatibilité avec les hébergements ensuite.
Les versions de PHP cochée n'entre pas en ligne de compte toutes les versions sont compatibles .
Puis je simplement vider le répertoire qui contient les bases de la 29 et refaire un essais d'import normal ? ( j'ai l'impression que ces messages concerne des redondance entre le contenu déjà présent et les anciennes que j'importe dedans Enfin voilà tout fonctionne et c'est le principal
J'attends vos avis pour savoir si je dois aller plus loin Jean-Mi à demain
Que j'essaye toutes les nouvelles versions, cela se comprend aisément, mais que vous vouliez faire de même, n'est pas du bon sens, à moins de vouloir corriger un éventuel bug ou utiliser une nouvelle fonctionnalité.
Gardez précieusement les versions qui répondent à vos attentes et, à partir de celles-ci, effectuez les exports des données, au besoin base de données par base de données et même table par table.
Il est préférable d'avoir sept cents fichiers d'export qu'un seul énorme ; on va mettre plus de temps pour les générer (Quoique !), mais c'est plus fiable et pérenne et ce qui compte, c'est bien la fiabilité de vos données.
En fait les VERSIONS mySQL 5.6.17 et 5.6.29 se sont installées à mon insus de mon plein gré À l"occasion de l'install des packages décrits précisément dans ce post et qui sont les seules maj que j'ai faites: Envoyé par: jammi (---.w90-38.abo.wanadoo.fr) Date: 16 January 2017 à 16:33
J'avais en tout cas nécessairement besoin de passer à une version 5.6 minimum
_____________________________________________
Le projet initial de passer en MariaDB, venant seulement de l'aspect commercila et ed la perte d'autonomie de MySQL qui me parait risquée à terme. MariaDB semblant la seule alternative à prori définitivement libre.
Par ailleurs
Je me rends compte de deux choses: ►je risque d'être contraint de passer par des système d'hébergement où je n'aurais pas le choix entre toutes les versions de BDD (et ce n'est pas mon 1er critère de choix) ►Je vous ai déjà écrit que des hébergeurs très en pointe dans les critères qui m'interessent sont eux, éventuellement en retard dans leur MAJ de Versions BDD. _________________________________________________ Loin de moi l'idée de vouloir compliquer ce qui peut être simple , vous avez d'ailleurs constaté il ya a un an mes rétiscence à passer sous wamp3 eu égard à mes pb techniques inhérents aux pré-requis. Donc si ça roule en mySQL 5.6.17 j'y suis j'y reste ___________________________________________________ Mes sauvegardes j'ai fais des bases complete et lors ed mes essais d'hier, je en vous ai pas récisé que j'avais fait également des sauv de BDD avec 5.6.17 dès que j'ai vu que cela fonctionnait. Je vais faire un essais d'import entre ces SAUV et 5.6.29 (deux série 6 passées par mysql_upgrade, cela va peut être fonctionner) Dans la série 5.6 quand on fait un import de base SQL et qu'une base de nom strictement identique existe. Ça doit l'écraser ? Nous ne sommes pas contraint de virer la précédente? ______________________________________________________
Je vous poserais je crois des questions sur wampserver3_x64_adminer4.2.5 et MySQLDumper1.24.4 seulement si cela semble être utile en fonction du nouvel hébergement Mais j'ai beaucoup de travail entre temps.
>Dans la série 5.6 quand on fait un import de base SQL et qu'une base de nom > strictement identique existe. Ça doit l'écraser ? Ça n'écrasera les bases de données, tout comme les tables, que si cela est explicitement spécifié. Ça dépend..... des paramètres du « sqldump » à l'export.
Dans le fichier SQL, il peut y avoir, pour les bases de données : DROP DATABASE IF EXISTS`mabase`; CREATE DATABASE IF NOT EXISTS `mabase` .... i;
Tout comme pour les tables : DROP TABLE IF EXISTS `matable`; CREATE TABLE IF NOT EXISTS `matable` .... ;
Mais bon je ne mes suis, en matière de sauv, jamais servi que des paramètres que je trouve sur le net. Les requetes en ligne de commande ça remonte aux années 90 pour moi et si parfois Pour vous un code 是中国人 Pour moi cinquante paramètres d'export זו היא עברית
Avant d'avancer : est ce normal en 5.6.29 que la colonne "replication maitre" soit absente entre l'interclassement et l'action?
Car si je dois refaire un ptit coup de mysql_upgrade autant le savoir; car en 5.6.17 elles sont toutes cochées vert répliquées dans cette colonne toute belle
> Les requetes en ligne de commande ça remonte aux années 90 pour moi et si parfois Ce sont des instructions SQL présentes dans les fichiers SQL d'export.
> st ce normal en 5.6.29 que la colonne "replication maitre" soit absente moi pas savoir.