Problème : table user crashed….

Accueil FORUM Entraide générale Problème : table user crashed….

Ce sujet a 13 réponses, 3 participants et a été mis à jour par  lecardiologue, il y a 10 ans et 8 mois.

14 sujets de 1 à 14 (sur un total de 14)
  • Auteur
    Messages
  • #2326

    lecardiologue
    Participant

    J’ai tenté une restauration de mes bases copiées sur mon synology n°1 sur mon synology n°2.
    Je suis parti du Synology n°2 « vierge » sur lequel j’ai activé Mysql et dans lequel j’ai copié les bases que j’explotais normalement avec Medintux sur le syno n°1.

    Lorsque je me connecte avec phpMyAdmin sue le 2è syno il me liste bien toutes les bases (sur le menu de gauche) que j’ai copiées mais il ne peut lire aucune table (par contre il arrive à lire les tables des bases « mysql », « information schéma » et « test » et j’obtiens le message d’erreur :

    mysql Innodb – Table ‘user’ is marked as crashed and should be repaired

    En dehors de la copie des bases sur le syno 2 je n’ai fait que retablir les privilèges utilisateurs.
    Comme je suis pas trop « balèze » j’aimerai qu’on m’indique la marche a suivre pour réparer ces tables défectueuses.

    Merci et bonsoir à tous !

    #2327
    idetl
    idetl
    Participant

    Bonjour, je suggérerais dans un 1er temps de réaliser quelque chose de semblable à ceci sur le synology.

    La « restauration de mes bases copiées sur mon synology n°1 sur mon synology n°2 » ne concernait-elle que les bases medintux ou également les autres, dont user ?

    #2328

    lecardiologue
    Participant

    Bonjour idetl !

    J’ai copié de manière brute toutes les bases résidentes (donc y compris « user » de mon syno 1 vers le syno 2 au moyen d’un disque externe USB3.

    Je ne comprends pas pourquoi Medintux ne retrouve pas les tables de DrTuxTest alors qu’elles ont été copiées intégralement sur le syno 2. De même la base « user1 » est devenu « user2 » (sur le syno 2) sans modification lors de la copie. et c’est pareil pour toutes les autres bases….

    phpMyAdmin dit donc que la table user est crashée. La c’est un sacré mysthère pour moi mais il y a surement une explication a tout cela.

    Voilà je cherche a retaurer de façon a verifier que mes sauvegardes sont fiables (voir sujet suivant).

    #2329
    idetl
    idetl
    Participant

    J’ai copié de manière brute toutes les bases résidentes (donc y compris « user » de mon syno 1 vers le syno 2 au moyen d’un disque externe USB3.

    Qu’entendez-vous précisément par « copié de manière brute toutes les bases résidentes » ?

    Quelle méthode avez-vous utilisée ? Vous avez fait un export dans phpmyadmin sur le 1 puis re-import via phpmyadmin sur le 2 ?

    #2330

    lecardiologue
    Participant

    « J’ai copié de manière brute toutes les bases résidentes » :

    Je m’explique : j’ai ouvert une console putty SSH sur mon PC Ubuntu et me suis loggé sur mon syno 2 au dos duquel j’ai branché mon support USB3 où j’avais stocké tous les repertoires des bases de MEDINTUX (du syno n°1) mais aussi les bases mysql, information schéma et test.

    J’ai fait un cp -R /supportUSB3/repertoires contenant les bases de mon syno n°1 /chemin vers le repertoire de stockage des bases sur le syno n°2

    Ensuite j’ai lancé phpmyadmin en me loggant en root pour vérifier le listage des bases stockées : j’ai bien trouvé toutes bases que j’avais copié.

    En revanche impossibilité de lire les tables de chaque bases avec le fameux message indiquant la table user crashée….

    Je me demande si lors de la copie les tables préexistantes sur le syno 2 (mysql, information schéma et test) ont été écrasées par les nouvelles….

    J’espère que je me suis bien expliqué sur la procédure.

    Qu’en pensez vous ?

    #2331
    idetl
    idetl
    Participant

    Je crains que ce ne soit pas la bonne méthode ! Une base de données n’est pas exactement un fichier au même titre qu’un autre et sa copie doit passer par des outils appropriés, ce que n’est pas en l’occurrence cp…

    Idem d’ailleurs pour une sauvegarde de BD : sauvegarder le fichier de la base ne garantit en rien un retour à l’opérationnel après « restauration ».

    Il faut exporter (on dit dumper) les tables de la BD, vous obtenez alors un fichier SQL contenant tout ce qui est nécessaire, et réimporter ces ordres SQL (donc ces tables tant en structure que contenu) dans la nouvelle base.

    PhpMyAdmin le permet, ainsi que mysqldump. En très court, ça peut être en shell :

    mysqldump table_source | mysql -C table_cible
    #2332

    lecardiologue
    Participant

    « Je crains que ce ne soit pas la bonne méthode ! » : en tous cas c’est le type de réponse que j’espérais.
    Cette statégie initiale (copie des repertoires « tels quels » pour faire la sauvegarde) m’a été proposée par un membre du forum. L’ayant testé à plusieurs reprises elle a systématiquement abouti à un echec, mais cela partait certainement d’une bonne intention et puis je ne suis pas un spécialiste de mysql…..

    Heureusement j’ai fait également des sauvegardes avec mysqldump suivant un script retrouvé sur internet.
    Je vais donc tester suivant ta methode en shell. le seul problème c’est que avec mysqldump la sauvegarde me coût 35 mn avec une base de 9Go environ.

    Merci pour le coup de main, je vais tester !

    #2333
    idetl
    idetl
    Participant

    Cette statégie initiale (copie des repertoires « tels quels » pour faire la sauvegarde) m’a été proposée par un membre du forum. L’ayant testé à plusieurs reprises elle a systématiquement abouti à un echec, mais cela partait certainement d’une bonne intention et puis je ne suis pas un spécialiste de mysql…..

    J’entends et lis fréquemment ce type de « mésaventure »…

    Il y a, paraît-il, des forums Internet où vous pouvez obtenir des indications de gens, sans doute bien intentionnés aussi, pour prendre tel ou tel médicament par rapport à des symptômes que vous décririez. Il y a fort à parier que la motivation première de ceux qui ont recours à ces « conseils » soit d’ordre économique : mauvaise couverture, pas de mutuelle, etc… Il n’est en effet généralement pas difficile de trouver un médecin alentour.
    Ça peut fonctionner, pas nécessairement durablement ceci-dit, mais dans certains cas ça peut finir par coûter cher ! (y compris et surtout au delà de l’aspect purement financier).

    Dans le cas d’un logiciel pour un usage professionnel, en tant qu’informaticien de métier, j’aurais tendance à conseiller de recourir à un professionnel pour bon nombre d’opérations potentiellement critiques (et ça peut le devenir très vite). La problématique est alors peut-être d’en trouver un compétent et pas « assassin » dans le secteur… Sinon, ça reste une question d’appréciation des risques et leur gestion.

    #2335

    lecardiologue
    Participant

    Pour être franc la stratégie du « copier-coller » les bases m’a été proposée par un membre de ce forum prétendant être administrateur système, ce qu’il est peut-être et je ne suis pas là pour contester ses déclarations.

    Moi je cherchais un moyen sur, rapide et fiable (mais je suis peut-être trop exigeant…et oui ça peut arriver !) pour un plan de sauvegarde + restauration de mes bases.

    J’ai une question sur mysqldump : où faut-il que je place la base « source » pour pouvoir la restaurer ? Dans un repertoire quelconque ? je cherche la bonne syntaxe pour la commande…

    #2336
    idetl
    idetl
    Participant

    Je vais vous proposer une méthode peut-être plus simple pour recopier votre base medintux : phpmyadmin (PMA) que vous avez sur les synology.

    Sur syno1, dans PMA, vous sélectionnez la base, puis l’onglet « Exporter » et vous avez là une rubrique « Méthode d’exportation », vous devriez pouvoir laisser le choix « Rapide – n’afficher qu’un minimum d’options ». Cliquez dans « Exécuter », enregistrer le fichier SQL qui sera généré sur votre disque USB connecté au syno 1, par exemple.

    Quand c’est terminé, démontez et déconnectez le disque USB, puis connectez-le au syno 2.

    Sur syno2, dans PMA, si elle existe déjà, videz la base medintux de toutes les tables existantes, ou supprimez la base et recréez en une nouvelle vide de toute table. Il faut que la base de données existe (vide).

    Sélectionnez la base et ouvrez l’onglet « Importer ». Cliquez dans le bouton « Parcourir… » de la rubrique « Fichier à importer » pour aller chercher le fichier SQL généré précédemment, sur le disque USB. Puis cliquez dans le bouton « Exécuter ».

    Vos tables exportées du syno 1 sont alors importées (a priori) correctement dans la base sur syno 2.

    En cas de problème, consultez un spécialiste. ;o))

    #2337

    lecardiologue
    Participant

    Je vais vous proposer une méthode peut-être plus simple pour recopier votre base medintux : phpmyadmin (PMA) que vous avez sur les synology.

    En réalité j’envisageais bien d’utiliser cette methode mais l’importation de DrTuxTest (base trop grosse = 9Go environ) n’aboutit pas car phpmyadmin se « tape une indigestion grave » (il faudrait que je modifie les paramètres de phpmyadmin en modifiant certaines options mais là je n’ai plus de temps et il faut que j’opte pour une methode simple. J’ai préféré importer avec l’outil du set_bases de Medintux ce qui a abouti à un succès, ce qui m’a permis de lancer Medintux puis DrTux.exe sans souci. J’ai retrouvé tous mes patients listés.

    J’ai également testé la methode en ligne de commande #mysql -u -p DrTuxTest.sql < /chemin de ma base stockée sur USB/DrTuxTest.sql et ça a également marché. Je dispose donc de deux methodes possible pour une durée de restauration raisonnable (je pense).
    En tous cas merci beaucoup « idetl » pour tous les conseils prodigués.
    Dès que j’en aurais le temps je ferai un ajout complementaire sur le wiki dans la section : installation de Medintux sur SYNO. 😉

    PS : comment on fait pour ajouter sur un sujet qu’il est résolu+++

    #2338
    rescue
    rescue
    Participant

    Bonsoir lecardiologue,

    Pour être franc la stratégie du « copier-coller » les bases m’a été proposée par un membre de ce forum prétendant être administrateur système, ce qu’il est peut-être et je ne suis pas là pour contester ses déclarations.

    Oui c’est moi qui a proposé ce copier coller et j’assume complètement.

    Je ne sais pas si vous avez pris le temps quand même de faire les choses correctement.
    Avant de toucher un serveur on arrête le service on fait ce qu’on a faire et ensuite on redémarre le service, c’est évident.

    Ce type de backup je le réalise régulièrement sur mes serveurs et bien plus complexe.
    J’ai voulu vous aidez en proposant une solution simple mais la prochaine fois je passerai à coté. Je ne suis pas fâché mais très déçu.

    Je vous remercie pour vos compliments, ça fait plaisir de vous lire.

    #2339

    lecardiologue
    Participant

    Bonjour rescue, je suis désolé que vous ayez mal interprété mes propos, franchement il y a malentendu ;-).

    Je ne sais pas si vous avez pris le temps quand même de faire les choses correctement.
    Avant de toucher un serveur on arrête le service on fait ce qu’on a faire et ensuite on redémarre le service, c’est évident.

    C’est peut-être évident pour vous mais pas pour moi, je soigne des patients au quotidien, pas des serveurs…..

    J’ai voulu vous aidez en proposant une solution simple mais la prochaine fois je passerai à coté

    je ne comprends pas votre réaction….d’autant que je reste persuadé que la solution que vous avez proposé est réellement la plus simple de toutes mais il faut qu’elle soit applicable à ma configuration.
    C’est vous qui voyez……si un jour vous avez besoin de mes services…..

    J’arrête la de gaspiller du temps

    #2340

    lecardiologue
    Participant

    je suis navré pour la réponse précédente, la typographie n’est pas celle que je souhaitais utiliser, les balises m’ont donné un rendu texte bien trop gros et ne reflètent pas le sentiment que je souhaitais communiquer dans ce post.

14 sujets de 1 à 14 (sur un total de 14)

Vous devez être connecté pour répondre à ce sujet.