Problème Mysql Restauration Rsync

[Baobab]

Bonjour à tous,

Je travaille actuellement à remplacer notre serveur de données SME8. Le procédé est donc simple dans la théorie :
- Je prend la dernière sauvegarde Rsync sur DD de notre ancien serveur
- J'installe SME8 sur le nouveau serveur en le configurant comme l'ancien.
- Je connecte mon DD usb et je suis la procédure http://smeserver.pialasse.com/index.php/Rsync#Restauration_de_la_sauvegarde_enti.C3.A8re
- La restauration s'est faite pendant la nuit dernière et tout semble parfaitement fonctionner sauf....(ce serait trop beau, vous le savez autant que moi)

...que MySQL ne semble plus fonctionner. Ce que je contate :
- Mes sites n'accèdent plus à leurs bases de données
- Je ne peux plus me logguer sur l'interface "myadmin" de MySQL
- Pourtant : j'accède à la console de MySQL en tapant "mysql" dans la commande du serveur

Ce que j'ai fait :
Ne pouvant me logguer sur le myadmin, j'ai tout de suite pensé à un problème de mot de passe et j'ai trouvé ceci sur le net : http://geekeries.de-labrusse.fr/?p=380, mais chez moi ces deux mots de passe concordent parfaitement, donc ce n'est pas ça...

A partir de là, je joue avec les mots et leurs position sur google depuis tout à l'heure, mais je n'ai pas encore une piste concluante. Je ne connais pas assez le fonctionnement de MySQL pour savoir d'où cela peut provenir.

Avez-vous une idée ?
Merci d'avance !

Baobab

[jdh]

(Je connais assez mal SME.)

Je ne sais si la 'sauvegarde SME' inclue une sauvegarde de MySQL. (Je l'espère).

La gestion d'accès à MySQL repose sur quelques principes de base :
- l'écoute du moteur MySQL : se configure dans /etc/mysql/my.cnf, il est possible de choisir si MySQL écoute sur 127.0.0.1 ou sur l'ip d'une carte réseau (bind=0.0.0.0 pour toutes les cartes)
- les users avec mots de passe et droits d'accès spécifiques on non.

Pour le dernier point, il faut regarder à minima les 2 tables mysql.user et mysql.db. (mysql est la base, les 2 tables sont user et db).
Je vérifierai ces 2 tables par comparaison, avec par exemple :
mysql -u root -p(mdp)
>show databases;
>use mysql;
>select host,user,password from user;
>select host,db,user from db;

[Baobab]

Salut Jdh,

Merci pour ta réponse, je déprime un peu tout seul à mon usine devant ces problèmes.

Apparemment sur SME, pas de répertoire "mysql" dans /etc, mais my.cnf se trouve directement dans /etc
Par contre, dans ce fichier, il ne semble pas y avoir grand chose :

Code : Tout sélectionner

[mysqld]
pid-file=/var/run/mysqld/mysqld.pid
basedir=/usr
datadir=/var/lib/mysql
skip-innodb
socket=/var/lib/mysql/mysql.sock
skip-networking
log-error=/var/log/mysqld.log
max_allowed_packet=16M
user=mysql


[mysqld_safe]


Est-ce que tu penses qu'il manque du contenu ?
Et malheureusement, je n'ai pas le moyen de comparer les fichiers car je ne peux pas faire fonctionner les deux serveurs en même temps (l'ancien et le nouveau).
Mais je vais peut-être comparer avec le contenu de la sauvegarde
EDIT : Sur la sauvegarde j'ai exactement la même chose

Pour ce qui est de regarder les tables en se connectant à Mysql, dés que je rentre en tant que root (donc en tapant le mot de passe associé), j'ai une erreur 1045 "access denied" qui s'affiche. Ca peut peut-être t'aider à voir d'où cela vient ?

baobab

[jdh]

La ligne 'skip-networking' indique que MySQL n'écoute que sur 127.0.0.1.
Il faut donc nécessairement se connecter avec '-h 127.0.0.1'.

Il serait judicieux de démarrer mysql sans autorisation pour vérifier que toutes les bases existent.
Le site de mysql doit donner des pistes ...

[Baobab]

Salut,

Merci Jdh, j'ai essayé de me connecter aussi avec -h 127.0.0.1, mais j'ai une autre erreur "Error 2003" "can't connect to mysql server on 127.0.0.1".

Bon, je crois que pour ce week-end c'est rapé, car je me suis aperçu hier qu'il y avait un autre problème. Le contrôleur de domaine ne fonctionne pas. J'ai sortis pour tester quelques pc du domaine et je les ai ré-entré, les XP tournent dans le vide pour la connexion, et pour les seven j'ai un super message "Echec de l'ouverture de session par le service client de stratégie de groupe -- Accès Refusé". Je n'ai ça que sur les profils déjà créé par le précédent PDC, les personnes dont les comptes n'ont jamais été utilisé ne posent pas de problème (logique le PDC prend le profil défaut pour créer le nouveau profil).

J'ai pourtant eu l'impression que Rsync avait bien fait son travail, pas d'erreur, rien qui m'interpelle et pourtant, tous ces problèmes me paraissent anormaux.
Certains paramètres du manager ont aussi été perdus. La liste des domaines par exemple...

Je ne comprend pas bien, et ça me fait me poser de nombreuses question quand à la fiabilité de Rsync... Si notre serveur venait à lâcher, impossible de faire une restauration totale semble-t-il c'est très embêtant.

Je réfléchis encore un peu cet après midi pour voir ce que je peux faire, mais ça risque de se terminer que je vais remettre le vieux serveur pour la semaine prochaine.

[Franck78]

Hello,

Je ne comprend pas bien, et ça me fait me poser de nombreuses question quand à la fiabilité de Rsync

oh non, il fonctionne, c'est l'utilisateur qui est en cause !
Erreur classique : les services ne sont pas fermés avant le rsync....


bye

[jdh]

rsync fonctionne mais il y a plusieurs écueils : les services actifs (cf Franck78), les uid/gid qui pourraient être différents, synchro d'arborescence seulement, ...

Mais je pense qu'il est préférable de regarder un système "complet" de sauvegarde tel Dar ou Affa.
Le lien indiqué écrit au tout début

L'idée est de profiter de rsync et ses options pour :
1- avoir une sauvegarde 1:1 toujours à jours des dossier à sauvegarder
2- avoir des dossiers de sauvegarde secondaires journaliers contenant chacun les fichiers modifiés ou supprimés lors de la sauvegarde journalière

A contrario Dar ou Affa sont conçu pour tout sauvegarder (données issus de l'arborescence, bases mysql, ...)

Par exemple le lien http://wiki.contribs.org/Backup_server_config mentionne des instructions comme 'signal-event pre-backup' et 'signal-event pre-restore' qui pourrait être celles qui sauvegarde les bases MySQL et les restaure.

[Cool34000]

Salut,

Si ce n'est pas un problème de sauvegarde des bases MySQL comme le suggère Franck78, il est probable que le mot de passe root de MySQL de l'ancien ait été restauré sur le nouveau... Hors SME n'aime pas trop ça !
Dans ce cas, il me semble de mémoire qu'il faut réinitialiser le mot de passe root de MySQL... Pas n'importe comment : il y a une procédure qui traine sur le net pour réinitialiser le mot de passe à la mode SME.
=> Demander à google comment faire...

[unnilennium]

Bonjour je vois le post un peu tard,

mais j'espère que tu as trouvé une solution.

effectivement deux pistes:
- problème de synchronisation du mot de passe root, un moyen facile de dépister cela , connecte toi en root, et tape mysql

Code : Tout sélectionner

# mysql
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

si tu obtiens cela, alors la solution est simple : http://wiki.contribs.org/MySQL#Resettin ... t_password

- problème de base corrompue, car ouverte pendant la sauvegarde. Comme indiqué par Franck78. C'est pour cela que j'utilise aussi cela lors d'un backup rsync :

http://smeserver.pialasse.com/index.php ... e_de_mysql

[gières]

Bonsoir,

Nous utilisons Affa (avec les risques que l'on sait : http://wiki.contribs.org/Affa) mais, comme on ne sait pas bien si Affa prend correctement en charge les bdd, en plus on fait faire un dump par cron. Je crois que dump se débrouille bien avec les bases ouvertes pendant la sauvegarde ?

Est-ce que ce n'est pas une autre solution pour transférer les bases en sécurité ?

Bonne soirée.