[SQL][Mediawiki] Pb table user aprés MAJ Wheezy vers Jessie

Blacksad · Février 21, 2016, 10:12pm

Bonjour/bonsoir,

En préambule, je ne connais pas grande chose en base de donnée.

J’ai un serveur actuellement en Wheezy avec un serveur mysql 5.5.

uname -a Linux info-co-lamp 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 x86_64 GNU/Linux

mysql -V mysql Ver 14.14 Distrib 5.5.46, for debian-linux-gnu (x86_64) using readline 6.2

J’ai voulu le mettre à jour vers Jessie, tout s’est presque bien passé mais la mise à jour de mysql m’a pourri mes tables, impossible de me connecter au wiki.

Je suis revenu sur mon état initial en Wheezy où tout fonctionne bien.

J’ai ensuite essayé, sans migrer totalement vers Jessie de migrer mysql vers mariadb (qui est en faite le but recherché de l’opération), même résultat.

Voici par exemple la table user avant migration:

Après:

L’un de vous aurait-il une piste, je ne trouve pas de cas similaire sur le net ou plutôt je ne dois pas chercher comme il faut avec les bon mots clés…

EDIT:
Aussi, si ça peut aider, une sauvegarde de ma bdd mysql et une restauration de ces bases sur un autre serveur en mariadb donne le même résultat.

Merci pour toute l’aide que vous pourrez apporter

Blacksad · Février 21, 2016, 10:13pm

Up, je ne trouve pas de piste et reste donc en Wheezy pour le moment.

debianhadic · Février 21, 2016, 10:13pm

Tu as exporté tes tables en SQL ? (Suite de commandes INSERT)

Blacksad · Février 21, 2016, 10:13pm

J’ai tenté :

De migrer de la version de mysql Wheezy vers Jessie sans export/import
De mysql Wheezy vers MariaDB Jessie sans export/import

Dans ces cas je ne sais pas trop ce qu’il se passe, c’est des MAJ de paquet debian, il me demande le MDP admin de la BDD et fait sa tambouille.

J’ai aussi utilisé une sauvegarde (dump) de mes bases fonctionnelles (mysql sous wheezy donc), et tenté sa restauration (dans une BDD mariaDB) par ligne de commande (même résultat)

Puis comme tu le suggères j’ai essayé avec une session phpmyadmin sur ma BDD fonctionnelle et une de test d’importer à l’aide d’Insert (fastidieux car ne peut se faire d’un seul coup étant donné le nombre de ligne).

Chaque fois j’arrive au même résultat, je me demande même si ce n’est pas “normal”. Peut être que ces champs ne sont plus en clair ou je ne sais pas… toujours est-il qu’aprés restauration il m’est impossible de me connecter au mediawiki (ce qui m’a amené à regarder la tête de la bdd des users)

Blacksad · Février 21, 2016, 10:13pm

Je viens de regarder de quelles versions je parle exactement.

Dans le 1er cas c’est une MAJ de mysql-server 5.5.46-0+deb7u1 vers 5.5.46-0+deb8u1
mysql-server-core-5.5

Autrement dit c’est la même version… bizarre que ça me cause tant de problème

Je vais tenter de mettre à jour vers Jessie en maintenant ce paquet dans sa version wheezy pour voir ce que ça donne

will7991 · Février 21, 2016, 10:13pm

Hello

Peux tu poster :

Un desc de ta table user telle qu’elle est dans Wheezy
La partie du mysqldump qui concerne ta table user (le CREATE TABLE IF NOT EXISTS …)
Un desc de ta table user telle qu’elle a été restaurée dans Jessie sous MySQL
Un desc de ta table dans MariaDB

Blacksad · Février 21, 2016, 10:13pm

Bonjour et merci,

Je vais essayer de rassembler tout ça en recréant le cas.

Pour ce qui est du descriptif de la table sous Wheezy est-ce que c’est bien de cela que tu parles :

Voilà ce qui change lors du passage de mysql Wheezy vers MariaDB Jessie

root@info-co-lamp:~# apt-get install mariadb-server Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires : apache2.2-bin apache2.2-common lesstif2 libplrpc-perl libxp6 texlive-xetex tipa wwwconfig-common Veuillez utiliser « apt-get autoremove » pour les supprimer. Les paquets supplémentaires suivants seront installés : apache2 apache2-bin apache2-data apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common cpp cpp-4.9 dpkg fontconfig fontconfig-config g++ g++-4.9 gcc gcc-4.9 gcc-4.9-base libalgorithm-c3-perl libapache2-mod-php5 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libarchive-extract-perl libasan1 libatomic1 libcgi-fast-perl libcgi-pm-perl libcilkrts5 libclass-c3-perl libclass-c3-xs-perl libcloog-isl4 libcpan-meta-perl libdata-optlist-perl libdata-section-perl libdb5.3 libdbd-mysql-perl libdbi-perl libfcgi-perl libfontconfig1 libgcc-4.9-dev libgcc1 libgd3 libgomp1 libhtml-parser-perl libisl10 libitm1 libjpeg62-turbo libjson-c2 liblocale-gettext-perl liblog-message-perl liblog-message-simple-perl liblsan0 liblua5.1-0 libmodule-build-perl libmodule-pluggable-perl libmodule-signature-perl libmotif-common libmpc3 libmro-compat-perl libnet-dbus-perl libnet-ssleay-perl libopenjpeg5 libpackage-constants-perl libparams-util-perl libperl4-corelibs-perl libpod-latex-perl libpod-readme-perl libpoppler46 libquadmath0 libregexp-common-perl libsocket-perl libsoftware-license-perl libstdc++-4.9-dev libstdc++6 libsub-exporter-perl libsub-install-perl libterm-readkey-perl libterm-ui-perl libtext-charwidth-perl libtext-iconv-perl libtext-soundex-perl libtext-template-perl libtiff5 libtsan0 libubsan0 libuuid-perl libvpx1 libxm4 libxml-parser-perl mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server-10.0 mariadb-server-core-10.0 perl perl-base perl-modules php-wikidiff2 php5 php5-cli php5-common php5-curl php5-gd php5-gmp php5-json php5-ldap php5-mcrypt php5-mysql rename xpdf Paquets suggérés : apache2-doc apache2-suexec-pristine apache2-suexec-custom cpp-doc gcc-4.9-locales g++-multilib g++-4.9-multilib gcc-4.9-doc libstdc++6-4.9-dbg gcc-multilib autoconf automake libtool flex bison gdb gcc-doc gcc-4.9-multilib libgcc1-dbg libgomp1-dbg libitm1-dbg libatomic1-dbg libasan1-dbg liblsan0-dbg libtsan0-dbg libubsan0-dbg libcilkrts5-dbg libquadmath0-dbg php-pear libclone-perl libmldbm-perl libsql-statement-perl libgd-tools libdata-dump-perl libstdc++-4.9-doc mariadb-test tinyca perl-doc libterm-readline-gnu-perl libterm-readline-perl-perl libb-lint-perl libcpanplus-dist-build-perl libcpanplus-perl libfile-checktree-perl libobject-accessor-perl php5-user-cache Paquets recommandés : php5-readline Les paquets suivants seront ENLEVÉS : cpp-4.7 g++-4.7 gcc-4.7 gcc-4.7-base libstdc++6-4.7-dev mysql-client-5.5 mysql-server mysql-server-5.5 mysql-server-core-5.5 Les NOUVEAUX paquets suivants seront installés : apache2-bin apache2-data cpp-4.9 g++-4.9 gcc-4.9 gcc-4.9-base libalgorithm-c3-perl libarchive-extract-perl libasan1 libatomic1 libcgi-fast-perl libcgi-pm-perl libcilkrts5 libclass-c3-perl libclass-c3-xs-perl libcloog-isl4 libcpan-meta-perl libdata-optlist-perl libdata-section-perl libdb5.3 libfcgi-perl libgcc-4.9-dev libgd3 libisl10 libjpeg62-turbo libjson-c2 liblog-message-perl liblog-message-simple-perl liblsan0 liblua5.1-0 libmodule-build-perl libmodule-pluggable-perl libmodule-signature-perl libmotif-common libmpc3 libmro-compat-perl libopenjpeg5 libpackage-constants-perl libparams-util-perl libperl4-corelibs-perl libpod-latex-perl libpod-readme-perl libpoppler46 libregexp-common-perl libsoftware-license-perl libstdc++-4.9-dev libsub-exporter-perl libsub-install-perl libterm-readkey-perl libterm-ui-perl libtext-soundex-perl libtext-template-perl libtiff5 libtsan0 libubsan0 libvpx1 libxm4 mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server mariadb-server-10.0 mariadb-server-core-10.0 php5-json rename Les paquets suivants seront mis à jour : apache2 apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common cpp dpkg fontconfig fontconfig-config g++ gcc libapache2-mod-php5 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libdbd-mysql-perl libdbi-perl libfontconfig1 libgcc1 libgomp1 libhtml-parser-perl libitm1 liblocale-gettext-perl libnet-dbus-perl libnet-ssleay-perl libquadmath0 libsocket-perl libstdc++6 libtext-charwidth-perl libtext-iconv-perl libuuid-perl libxml-parser-perl perl perl-base perl-modules php-wikidiff2 php5 php5-cli php5-common php5-curl php5-gd php5-gmp php5-ldap php5-mcrypt php5-mysql xpdf 46 mis à jour, 65 nouvellement installés, 9 à enlever et 171 non mis à jour. Il est nécessaire de prendre 74,0 Mo dans les archives. Après cette opération, 96,5 Mo d'espace disque supplémentaires seront utilisés. Souhaitez-vous continuer [O/n] ? O

will7991 · Février 21, 2016, 10:13pm

Salut,

Ok pour le descriptif de la table dans wheezy, mais pour le reste, ce n’est pas tout à fait ce que je voulais

Quand je parlais du mysqldump, en fait il me fallait un extrait du fichier de sauvegarde.
Peut être l’as tu fait depuis phpmyadmin ? Si c’est le cas, depuis une console, lance cette commande :

Ca te génèrera un fichier wididb_user.sql.

Regarde l’instruction “CREATE TABLE user …” et la première ligne "INSERT INTO user …"
Compare entre ce que phpmyadmin et mysqldump

Mais, il y a un truc qui me chagrine : l’utilisation de types binaires partout. Je n’ai pas l’habitude de faire comme ça…

A tu la même version de phpmyadmin entre wheezy et jessie (je suppose que non). Sans avoir étudié à fond la question, je pense qu’il y a un loup quelque part :
stackoverflow.com/questions/1687 … -is-unchec
stackoverflow.com/questions/2695 … phpmyadmin

Blacksad · Février 21, 2016, 10:13pm

Le fichier est lourd à ouvrir, il fallait juste que je trouve sans planter notepad++, c’est bien ce que tu veux:

[code]DROP TABLE IF EXISTS user;
/*!40101 SET @saved_cs_client = @@character_set_client /;
/!40101 SET character_set_client = utf8 /;
CREATE TABLE user (
user_id int(10) unsigned NOT NULL AUTO_INCREMENT,
user_name varbinary(255) NOT NULL DEFAULT ‘’,
user_real_name varbinary(255) NOT NULL DEFAULT ‘’,
user_password tinyblob NOT NULL,
user_newpassword tinyblob NOT NULL,
user_newpass_time binary(14) DEFAULT NULL,
user_email tinyblob NOT NULL,
user_touched binary(14) NOT NULL DEFAULT ‘\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,
user_token binary(32) NOT NULL DEFAULT ‘\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,
user_email_authenticated binary(14) DEFAULT NULL,
user_email_token binary(32) DEFAULT NULL,
user_email_token_expires binary(14) DEFAULT NULL,
user_registration binary(14) DEFAULT NULL,
user_editcount int(11) DEFAULT NULL,
PRIMARY KEY (user_id),
UNIQUE KEY user_name (user_name),
KEY user_email_token (user_email_token),
KEY user_email (user_email(50))
) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=binary;
/!40101 SET character_set_client = @saved_cs_client */;

–
– Dumping data for table `user`

LOCK TABLES user WRITE;
/*!40000 ALTER TABLE user DISABLE KEYS /;
INSERT INTO user VALUES (1,‘Cr’,‘Christophe’,’’,’’,NULL,’’,‘20151219165423’,‘29872680f35cc6a21358538b349431ef’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20101125061707’,3636),(2,‘Christophe’,‘Christophe Requier’,’’,’’,NULL,’’,‘20130611182119’,‘1e315cf246de06186cc31e8648867eb1’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20101204183616’,598),(3,‘Cb’,‘Christophe’,’’,’’,NULL,’’,‘20151215111527’,‘41224a621f15988378a84c0362a120f5’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20110908120832’,1055),(4,‘Am’,‘am’,’’,’’,NULL,’’,‘20151215071204’,‘9f5beddfdc0daaf5465e5edfd30c76a4’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20111126071210’,280),(5,‘Rb’,‘Romain’,’’,’’,NULL,’’,‘20130611182119’,‘2ab477bee1877cb4186fe6bfa8b77c25’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20120716121958’,7),(6,‘Ycalmettes’,‘Yohan’,’’,’’,NULL,’’,‘20151218141422’,‘312b95f21eefeb8e0c853212e19fd4b5’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130305071817’,390),(7,‘Testmdp’,’’,’’,’’,NULL,’’,‘20130611182119’,‘1e041467f35a52c3e37b1606c85af874’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130520183138’,0),(8,‘Df’,’’,’’,’’,NULL,’’,‘20150624140855’,‘b75bbec00a7009365389cef0f5aacc14’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130521114836’,107),(9,‘Fs’,’’,’’,’’,NULL,’’,‘20150402062449’,‘da54417f43d7b1af8b4b10079bf3a59d’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130521114922’,0),(10,‘Kgoubert’,‘Kevin’,’’,’’,NULL,’’,‘20130611182119’,‘f1dfe67f7e2edbd3bf842b9ae864f2e6’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130521130918’,3),(11,‘Kévin’,’’,’’,’’,NULL,’’,‘20151218140109’,‘34ad93242f8a121b6a427aa56d7663e6’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130530063534’,218),(12,‘Gv’,’’,’’,’’,NULL,’’,‘20151127100835’,‘aad8efbd1e74a7f158adfbcc01cbea8b’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130530064315’,1),(13,‘Jg’,’’,’’,’’,NULL,’’,‘20151016075330’,‘74d74e9666c68cbfd887865fe3a52772’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130530075011’,9),(14,‘Romain’,’’,’’,’’,NULL,’’,‘20151216083736’,‘004140d16fcec6d5ec6f8445c4a6ddc2’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130531105738’,444),(15,‘Ja’,’’,’’,’’,NULL,’’,‘20151214150040’,‘918d643f33886329af8831830aac3265’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130615041252’,2),(16,‘Kevin’,’’,’’,’’,NULL,’’,‘20151130051429’,‘1c845dc0e81aaec6c7b01608315375ef’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130721043106’,41),(17,‘Dn’,’’,’’,’’,NULL,’’,‘20150721075108’,‘c978348a3b3cc679bf3ceb81f4ca96c8’,NULL,’\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0’,NULL,‘20130729122308’,0);
/!40000 ALTER TABLE user ENABLE KEYS */;
UNLOCK TABLES;[/code]

J’ai reproduit le cas mais vu les MAJ PHP/apache2 etc… il faut maintenant que j’arrive à faire fonctionner phpmyadmin pour te montrer la table après MAJ mais ça va arriver

Suite à la lecture des liens que tu donnes:
En effet phpmyadmin aussi se met à jour… et j’ai toujours regardé mes tables de cette manière.
Pour ce qui est de la MAJ des BDD j’ai essayé par apt puis comme c’était foireux j’ai importé ma sauvegarde par ligne de commande puis depuis phpmyadmin pour la table user (mais les autres tables sont peut-être tout aussi vérolées)

EDIT:
Voilà la table après migration sur MariaDB, dsl pour le délai, c’est laborieux, d’autant que je ne peux pas m’y consacrer à 100% je perd un temps fou, je pensai que le WE serait tranquille !

pix.isalo.org/upload/original/1452934081.png

On voit que les binary que tu n’aimais pas ont disparu

Blacksad · Février 21, 2016, 10:13pm

Le Wiki étant un outil en production devenu indispensable, j’ai du revenir à son état fonctionnel sous Jessie.

J’ai remonté un environnement de test sur une machine disponible: LAMP Debian Jessie à jour avec Mediawiki fonctionnel (installation de base).

La table user contient bien un utilisateur (celui créé lors de l’installation du mediawiki), qui peut se connecter au wiki bien sûr. Il apparait normalement dans phpmyadmin (pas de code hexa dans les champs).

Importation de ma table sauvegardée sur ma Jessie de la façon suivante:

La table user est dans l’état tout pourris décris dans ma première intervention

will7991 · Février 21, 2016, 10:13pm

Salut

C’est quand même super étrange.

Je suis sous Jessie, avec donc la version de mysql que tu mentionnes.

J’ai fait un create database test (depuis le user root)
J’y ai créé la table en copiant/collant ton CREATE TABLE
J’y ai copié/collé les 2 premiers users de ton INSERT INTO user VALUES

Et ça marche sans pb. D’ailleurs, cette histoire de varbinary, je n’avais pas compris que c’était la base de mediawiki qui était faite ainsi. Soit.

C’est vraiment très curieux…

Quand tu dis : [quote]Importation de ma table sauvegardée sur ma Jessie de la façon suivante:[/quote]
Ta sauvegarde provient de phpmyadmin ou du mysqldump que je t’ai indiqué ?

PS : Si tes données sont confidentielles (tu as masqué des infos dans tes premiers screenshots), tu devrais peut-être effacer les INSERT que t’as collé

Blacksad · Février 21, 2016, 10:13pm

Ha oui, c’est parcequ’il y’a des noms de famille de collègues, j’ai édité pour les enlever, merci.

Ce matin j’ai refait quelques essais

Même version de Mediawiki sur ma Wheezy et une Jessie, j’importe toute la BDD sauf la user: nikel, à priori tout conftionne donc il y’aurait que la table user qui serait foireuse lorsqu’elle est importée alors que les requêtes, comme tu dis puisque tu as toi même testé leur intégration, semblent clean…
Je n’ai plus aisément accès au serveur cette aprés-midi, je te confirmerai demain pour les commandes tapées.

C’est quand même bizarre que les données de cette table soient modifiées:
Quand je met à jour de Wheezy vers Jessie
Quand je met à jour pour passer de mysql à MariaDB
Quand j’importe dans une nouvelle BDD

Et je ne comprend pas comment tu arrives à bien les intégrer avec la même sauvegarde que moi.
je les intègre comme tel:

Et j’ai aussi essayé de les intégrer ligne par ligne via phpmyadmin

Comment as-tu procédé ?

Sinon pour tenter de comprendre:
J’ai bloqué la MAJ de mysql-server et fait un upgrade, j’ai passé pas mal de MAJ, la table est toujours lisible bien que je sois passé à la version Jessie du paquet mediawiki (j’avais un doute à son sujet).
Ensuite j’ai fait l’essai à nouveau en débloquant mysql-server et un nouvel upgrade, la table user était modifiée.
Peut-être que ça ne vient pas d’une MAJ de mysql-server mais de celle de php ou autre…

En tout cas je pensai que c’était général mais je vais chercher plus spécifiquement chez ceux qui migrent un mediawiki de Wheezy vers Jessie car sauf surprise, user est la seule table qui réagit comme ça.

will7991 · Février 21, 2016, 10:13pm

Pas 100% exact puisque je n’utilise pas ton fichier de backup, mais les lignes que tu as collées ici

Peux tu me redire si ton backup.sql a été généré depuis phpmyadmin ou d’une ligne de commande mysqldump ?

J’ai tout fait en ligne de commande sur le serveur mysql. J’ai copié collé :

CREATE TABLE `user` ( `user_id` int(10) unsigned NOT NULL AUTO_INCREMENT, `user_name` varbinary(255) NOT NULL DEFAULT '', `user_real_name` varbinary(255) NOT NULL DEFAULT '', `user_password` tinyblob NOT NULL, `user_newpassword` tinyblob NOT NULL, `user_newpass_time` binary(14) DEFAULT NULL, `user_email` tinyblob NOT NULL, `user_touched` binary(14) NOT NULL DEFAULT '\0\0\0\0\0\0\0\0\0\0\0\0\0\0', `user_token` binary(32) NOT NULL DEFAULT '\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0', `user_email_authenticated` binary(14) DEFAULT NULL, `user_email_token` binary(32) DEFAULT NULL, `user_email_token_expires` binary(14) DEFAULT NULL, `user_registration` binary(14) DEFAULT NULL, `user_editcount` int(11) DEFAULT NULL, PRIMARY KEY (`user_id`), UNIQUE KEY `user_name` (`user_name`), KEY `user_email_token` (`user_email_token`), KEY `user_email` (`user_email`(50)) ) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=binary;

et

Pour un résultat qui colle avec ta capture d’écran originale (là où ça marche).

Blacksad · Février 21, 2016, 10:13pm

[quote=“will7991”]

Peux tu me redire si ton backup.sql a été généré depuis phpmyadmin ou d’une ligne de commande mysqldump ?[/quote]

En ligne de commande, c’est certain mais par contre dire si c’est avec la commande mysqldump ou mysql, je ne sais plus exactement.

Je ne vais pas avoir la possibilité de travailler dessus cette semaine malheureusement, je m’y remet la semaine prochaine (sauf si autres urgences à gérer d’ici là …)

J’ai préparé le serveur pour pouvoir mettre à jour php/mediawiki/apache2 en gardant la version actuelle de mysql, je verrai bien ainsi si c’est bien la MAJ de mysql qui me détériore ma BDD.

La suite lundi prochain donc, encore merci pour toutes les infos/pistes données

MicP · Février 21, 2016, 10:13pm

En fait, ce que tu as caché dans cette image peut être reconstitué en fonction de ce qu’on peut lire dans l’autre image.

Les données sont donc à leur place, mais il faudrait qu’elles soient interprétées et affichées autrement que par leur valeur hexadécimale.

=======
Et plus j’y pense, plus je m’interroge de la même façon que :[quote=“will7991”]…
Et ça marche sans pb. D’ailleurs, cette histoire de varbinary, je n’avais pas compris que c’était la base de mediawiki qui était faite ainsi. Soit.

C’est vraiment très curieux…
…[/quote]

Blacksad · Février 21, 2016, 10:14pm

Du coup, d’après toi, que faudrait-il que je fasse pour que je puisse toujours me connecter au mediawiki (avant et/ou aprés la MAJ/migration qui dénature la BDD) ?

Blacksad · Février 21, 2016, 10:15pm

J’ai mis à jour vers apache2 2.4 et php5 (les versions de jessie)

Mon mediawiki est toujours accessible, la BDD est “propre”

Je met à jour phpmyadmin, ma BDD est “illisible” mais je me connecte toujours bien au mediawiki.
Tu avais raison c’est juste un affichage mais les données sont bonne.

Conclusion, mon problème ne vient pas de là mais d’un des 194 paquet qu’il me reste à mettre à jour une fois le paquet mysql débloqué …

une aiguille dans une botte de foin, dans un champ, je ne sais trop où encore, hum

EDIT: paquet mediawiki mis à jour aussi, il n’est pas en cause.

Blacksad · Février 21, 2016, 10:15pm

Bonbonbon…

Je suis allé à taton, le minimum de paquet les un après les autres autant que possible… jusqu’au moment fatidique où j’ai fini par débloquer mysql-server* dans mon préférences. Et tout fonctionne bien à priori.

No comprendo

MediaWiki 1.19.20+dfsg-2.3 PHP 5.6.17-0+deb8u1 (apache2handler) MySQL 5.5.47-0+deb8u1

Merci d’avoir cherché avec moi et de m’avoir orienté. Bizarrement je suis moyennement satisfait dans le sens où je ne capte pas pourquoi maintenant ça fonctionne…

debianhadic · Février 21, 2016, 10:16pm

Et tu n’as plus de paquets à installer ?
Si c’est le cas effectivement c’est louche …

Blacksad · Février 21, 2016, 10:16pm

Non non, aprés tous les paquets critiques liées au wiki (mediawiki, php, apache2, mysql) que j’ai passé l’un après l’autre, j’ai fini par un dist-upgrade en notant les paquets en me disant “c’est donc un de ceux là” et en fait non …

Pourtant j’ai reproduit le cas plein de fois.

Par contre j’étais focalisé sur la corruption de la table user et n’ai pas pensé quand je testais sur un serveur de test que ma connexion au wiki se fait via le module LdapAuthentication.php donc ces tests qui échouaient c’est “normal”, pas sûr que tout était en place pour que ça fonctionne (j’ai supprimé la VM depuis).

[SQL][Mediawiki] Pb table user aprés MAJ Wheezy vers Jessie

– – Dumping data for table user

–
– Dumping data for table `user`