[Réplication] Y a-t-il un danger à supprimer le log-bin ?

[Huntress]

Bonjour,

j'ai tenté une réplication, j'ai fais plusieurs essais tous ont marché jusqu'au moment où je devais faire un essai sur le VRAI serveur. La base mysql datait ce qui fait que je ne pouvais pas créer un utilisateur de réplication (me manquait super et replication slave).
J'ai donc bidouillé les droits (j'ai changé l'host) de PhpMyAdmin afin d'avoir le droit de toucher à mysql.user. Ceci fait j'ai pu créer mon utilisteur de réplication, mais entre temps j'avais oublié les modifs faites et j'ai tenté la réplication, et ça n'a donc pas marché... normal.

La question que je me pose... est-ce que j'ai pu pourrir avec ce dernier essai le journal binaire... d'abord est-ce possible de le pourrir ? Et en fait... bon disons les choses clairement j'ai envie de supprimer tous les log-bin existants, il y'en a 5 dont le dernier qui fait 102 Mo... c'est un serveur de prod et j'aimerais ne pas tout bousiller...

Fait étrange, ce serveur n'a jamais connu la réplication si je peux dire et pourtant le fichier de conf était totalement configuré pour en faire un maître... ceci peut-il être dû à une opération de backup ?

Voilà si qq un pouvait me donner ses lumières concernant le log-bin, je lui serais très reconnaissante

Question subsidiaire : Comment le serveur MySQL décide-t-il de clôturer un journal binaire et d'en ouvrir un autre, parce que les tailles sont complètement délirantes d'un fichier à l'autre : 79 octets, 79 o, 493 Mo, 56 Ko et 102 Mo

[Huntress]

J'ai répondu à ma question subsidiaire. Pour ceux que ça intéresse :

mysqld va ajouter une extension au nom du fichier de log binaire qui est un nombre automatiquement incrémenté chaque fois que vous exécutez mysqladmin refresh, mysqladmin flush-logs, FLUSH LOGS ou redémarrez le serveur. Un nouveau fichier de log sera automatiquement créé lorsque le fichier en cours atteint la taille de max_binlog_size. Un fichier de log binaire peut être plus grand que max_binlog_size si vous utilisez de grandes transactions : une transaction est écrite dans le log binaire d'un seul coup, et n'est jamais répartie entre plusieurs fichiers.

[Huntress]

J'ai recommencé la procédure du début et créé un utilisateur de réplication... et finalement je pense que le soucis vient de là... je vous laisse regarder :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
mysql> SELECT * FROM user WHERE user='rep' \G
*************************** 1. row ***************************
            Host: %
            User: rep
        Password: 29bad1457ee5e49e
     Select_priv: N
     Insert_priv: N
     Update_priv: N
     Delete_priv: N
     Create_priv: N
       Drop_priv: N
     Reload_priv: Y
   Shutdown_priv: N
    Process_priv: N
       File_priv: N
      Grant_priv: N
 References_priv: N
      Index_priv: N
      Alter_priv: N
      Super_priv: N
 Repl_slave_priv: Y
Repl_client_priv: N
1 row IN SET (0.02 sec)

Ce qui est déroutant c'est le webmin qui présente cette ligne :

Code :

rep 	Any 	29bad1457ee5e49e 	Reload | Super

Donc là je me dit que l'ordre des colonnes (ou bien toute la structure) de mysql.user à son importance ! nan ?

Si vous m'aidez pas, faites moi au moins la conversation, j'ai l'impression d'être seule eu monde lol

Version de MySQL : 4.0.17-standard-log

[Maximilian]

Envoyé par Huntress

La base mysql datait ce qui fait que je ne pouvais pas créer un utilisateur de réplication (me manquait super et replication slave).

Peux-tu être plus précise (messages d'erreur, commande utilisée...) ?

J'ai donc bidouillé les droits (j'ai changé l'host) de PhpMyAdmin afin d'avoir le droit de toucher à mysql.user. Ceci fait j'ai pu créer mon utilisteur de réplication,

Donc "à la main"... Ca peut être une solution mais passer par un GRANT me parait plus sûr.

mais entre temps j'avais oublié les modifs faites et j'ai tenté la réplication, et ça n'a donc pas marché... normal.

... pas compris

La question que je me pose... est-ce que j'ai pu pourrir avec ce dernier essai le journal binaire... d'abord est-ce possible de le pourrir ?

Tout dépend ce que tu appelles pourrir, mais normalement non.

Fait étrange, ce serveur n'a jamais connu la réplication si je peux dire et pourtant le fichier de conf était totalement configuré pour en faire un maître... ceci peut-il être dû à une opération de backup ?

Certainement, donc il me parait osé de vouloir supprimer tous les logs (qui peuvent servir pour des restaurations de données futures)...

[Huntress]

Envoyé par Maximilian

Peux-tu être plus précise (messages d'erreur, commande utilisée...) ?

Oui je peux l'être mais ça va pas t'aider, en fait aucune erreur n'était indiquée. L'utilisateur était bien créé, mais des droits lui manquait. Ma commande :

Code :

1
2
3
4
GRANT REPLICATION SLAVE, SUPER, RELOAD 
ON *.* 
TO rep@'%'
IDENTIFIED BY 'pass';

Envoyé par Maximilian

Donc "à la main"... Ca peut être une solution mais passer par un GRANT me parait plus sûr.

Oui peut être mais en même temps, c'est clair que ça marche puisque je n'avais pas la possibilité de me logger avant de changer l'host dans le webmin.

Envoyé par Maximilian

... pas compris

Ben en fait je continuais de parler de cette modif, donc n'ayant pas rechangé l'host de 'Any' en mon adresse ip, ben l'esclave ne pouvait plus trouver son maitre... bon là en fait... j'ai l'impression que j'ai fait une bourde je sais plus ou j'en suis

> edit : Nan c'est bon je m'étais pas embrouillée. En fait pour modifier la table mysql.user sur le serveur de prod à partir d'une commande local j'ai pu modifier l'host du root en mon adresse ip. Ah ben si je me suis quand même embrouillée un peu, parce que c'est forcément pas ça qui a fait foirer la réplication, puisque ça n'a aucune incidence... c'est donc forcément cette histoire de droits utilisateurs qui n'existent pas.

Envoyé par Maximilian

Tout dépend ce que tu appelles pourrir, mais normalement non.

Le pourrir, le rendre inutilisable... mais effectivement je ne pense pas que ça soit possible.

Envoyé par Maximilian

Certainement, donc il me parait osé de vouloir supprimer tous les logs (qui peuvent servir pour des restaurations de données futures).

Oui toi aussi tu trouves ça osé... j'y touche pas alors, pourtant ça me démange.

[Maximilian]

Envoyé par Huntress

Oui peut être mais en même temps, c'est clair que ça marche puisque je n'avais pas la possibilité de me logger avant de changer l'host dans le webmin.

Ben en fait je continuais de parler de cette modif, donc n'ayant pas rechangé l'host de 'Any' en mon adresse ip, ben l'esclave ne pouvait plus trouver son maitre...

OK, donc c'est au niveau de la connexion qu'il y a un problème ! (on va finir par se comprendre )

En te connectant au master via le client en ligne de commande, tu devrais avoir le message d'erreur correspondant... enfin ça c'était avant, parce que maintenant si j'ai bien compris ça fonctionne... non :

[Huntress]

Ben en fait je n'ai pas (plus) de pb de connexion au serveur master et au serveur slave depuis ma machine local.

Le soucis vient du fait que mon GRANT pour créer mon utilsateur de réplication fait mal son boulot, enfin j'insinue pas ce que c'est de sa faute...

Mais schématique ça donne ça :
- Moi : "Va m'acheter des pommes, des poires et des cerises"
- Lui revenant tout benoîtement avec des poires et des cerises : "Tiens voilà tes pommes et tes poires "
- Moi : o_O "Alors premièrement c'est pas des pommes mais des cerises, deuxièmement, elles sont où mes pommes ?"

Je crois que la meilleure chose à faire serait d'upgrader MySQL sur le serveur de prod... mais je sais pas si c'est possible Va falloir négocier.

[Maximilian]

Envoyé par Huntress

Le soucis vient du fait que mon GRANT pour créer mon utilsateur de réplication fait mal son boulot

C'est ça que je n'arrive pas à comprendre... ça se traduit par quels dysfonctionnements concrètement ?

[Huntress]

La réplication ne peut fonctionner si l'utilisateur de réplication n'a pas les droits nécessaires...

En fait tout à l'air de fonctioner, je fais mes petits update sur le master, je vais voir se qui se passe sur le slave... rien o_O d'ailleurs en faisant un show slave status, on voit que ça va pas... me demande pas quoi je sais plus. lol

Alors que sur d'autres serveurs ça fonctionne à merveille, la seule différence est la version de MySQL qui est ancienne sur celui là

[Maximilian]

Jette un oeil ici : http://dev.mysql.com/doc/mysql/en/replication-compatibility.html

[Huntress]

mysql> show slave status \G
*************************** 1. row ******************
Slave_IO_State:
Master_Host: xxx.xxx.xxx.xxx
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: xxxxx-bin.008
Read_Master_Log_Pos: 8098
Relay_Log_File: linux-relay-bin.000001
Relay_Log_Pos: 4
Relay_Master_Log_File: xxxxxx-bin.008
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 2
Exec_Master_Log_Pos: 8098
Relay_Log_Space: 4
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
1 row in set (0.00 sec)

Voilà pour le show slave.

Concernant ton lien, je sais la plupart des choses qui sont exposées dedans... Et hormis un soucis sur la table mysql.user, je ne vois pas d'où ça peut provenir

MASTER (4.0.17) -----> SLAVE (4.1.11)

D'après ton lien cela semble possible : " As far as replication is concerned, the binary log format for any MySQL 4.1.x version and any 4.0.x version is identical"

[Maximilian]

Essaie de regarder dans le log d'erreurs du slave si tu trouves quelque chose ayant un rapport avec la réplication...

[Huntress]

051005 15:53:09 [ERROR] Error reading relay log event: slave SQL thread was killed
051005 15:55:04 [Note] Slave SQL thread initialized, starting replication in log 'digiplace-bin.008' at position 8098, relay log './xxxxx-relay-bin.000001' position: 4
051005 15:55:04 [Note] Slave I/O thread: connected to master 'rep@xxx.xxx.xxx.xxxxxx', replication started in log 'xxxxxxxxxx-bin.008' at position 8098
051005 15:55:04 [ERROR] While trying to obtain the list of slaves from the master 'xxx.xxx.xxx.xxxxxx', user 'rep' got the following error: 'Access denied. You need the REPLICATION SLAVE privilege for this operation'
051005 15:55:04 [ERROR] Slave I/O thread exiting, read up to log 'digiplace-bin.008', position 8098

Voilà donc il a pas le droit REPLICATION SLAVE... je te renvoi au 3ème post de ce thread...

[Maximilian]

Envoyé par Huntress

Voilà donc il a pas le droit REPLICATION SLAVE

Au moins on en est sûr.

Refais un GRANT REPLICATION SLAVE ... sur le master puis un FLUSH PRIVILEGES, on ne sait jamais.

Sinon on peut voir le fichier de conf du slave ?

[Huntress]

Juste un truc pour rire (là en fait je viens de lui raouter le droit SUPER via le PHPMyAdmin et là c'est un aperçu de webmin) :

Code :

rep 	Any 	29bad1457ee5e49e 	Reload | SHOW DB | Super

Comme quoi la structure de mysql.user est extremement importante.

Voilà le ficher de conf du slave :

[mysqld]

server-id = 2

datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

# Default to using old password format for compatibility with old and
# shorter password hash.
# Reference: http://dev.mysql.com/doc/mysql/en/Password_hashing.html
old_passwords=1

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
err-log=/var/log/mysqld/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

[Huntress]

J'ai tenté de monter une nouvelle structure de mysql.user, visiblement ça lui plaît pas parce que MySQL refuse de démarrer... pour être une journée sans, c'est une journée sans !

Si t'as d'autre idée en attendant toujours preneuse.

Au fait j'avais retenté avec FLUSH et ça n'a rien changé... Le pb est bien cerné, mais pour lé résoudre...

[ren0]

Bonjour,

Alors cette réplication ça en est ou ?
toujours des soucis ?

[Huntress]

Salut,

Et bien c'est en suspend en fait, puisque le mieux serait d'upgrader le MySQL sur le serveur de prod... c'est pas nous qui avons la main là dessus, et c'est une base sensible, on aimerait bien ne pas tout péter
Pour le moment on fait au plus pressé... la réplication passe donc au second plan.

Mes amis les admin, merci de ne pas délester ce post, je le ferais moi même si celà devenait nécessaire.