Pb MySQL sur Debian

Bonjour Bernard,

Le 19/02/2016 16:33, Bernard Schoenacker a écrit :

bonjour,
est il encore possible de basculer les tables au format csv ?

Pour ça il faudrait pouvoir les consulter, donc au moins 'monter' la
base correspondante dans le serveur, mais on n'y arrive pas...

passer à PgSQL ?

Next step mais ça résoud pas la question de comment retrouver ces
données avec ce que le serveur nous a laissé...

Greg

Le Fri, 19 Feb 2016 16:17:46 +0100,
Grégoire COUTANT <gregoire.coutant@gmail.com> a écrit :

Bonjour à tous,
Notre serveur interne à planté cette nuit lors des dumps de
sauvegarde des DB.
Un de nos logiciels (redmine) a perdu (!) sa base innodb et nous
n'arrivons pas à récupérer les données.

Quelques explications :
- Le script de dump de la nuit à fait planté le serveur MySQL
- Ce plantage à fait perdre des fichiers frm
- Nous avons toujours le fichier ibdata qui fait 80 Go (avec les
données dedans normalement)
- Nous avons récupéré un backup d'il y a deux jours des fichiers
frm, quand on le met en place, ça ne change rien.

On se dit que les données sont dans le ibdata mais tout ce qu'on a
essayé ne fonctionne pas (repair etc...), on n'accède pas à la base.

Avez-vous des idées de comment faire ?

Merci d'avance

Greg

bonjour,

est il encore possible de basculer les tables au format csv ?

passer à PgSQL ?

slt
bernard

Le 19 févr. 2016 à 16:17, Grégoire COUTANT <gregoire.coutant@gmail.com> a écrit :

Bonjour à tous,
Notre serveur interne à planté cette nuit lors des dumps de sauvegarde des DB.
Un de nos logiciels (redmine) a perdu (!) sa base innodb et nous n'arrivons pas à récupérer les données.

Quelques explications :
- Le script de dump de la nuit à fait planté le serveur MySQL
- Ce plantage à fait perdre des fichiers frm
- Nous avons toujours le fichier ibdata qui fait 80 Go (avec les données dedans normalement)
- Nous avons récupéré un backup d'il y a deux jours des fichiers frm, quand on le met en place, ça ne change rien.

Les backups sont-ils faits en incrémental ? Dans le cas contraire, je n'ai jamais trouvé de ressource

expliquant comment on recolle les fichiers bruts qui sortent du backup.

Quand on fait un backup incrémental, on peut choisir le format de fichier en sortie… SQL, CSV, etc.

Ph. Gras

On se dit que les données sont dans le ibdata mais tout ce qu'on a essayé ne fonctionne pas (repair etc...), on n'accède pas à la base.

Avez-vous des idées de comment faire ?

Merci d'avance

Greg

Bonjour,

Le 19/02/2016 17:13, Philippe Gras a écrit :

Les backups sont-ils faits en incrémental ?

Un script génère un dump via la fonction mysqldump et les dumps sont
archivés sur un autre serveur via backuppc.
Les dumps des deux derniers jours ont plantés le serveur et sont donc à
0 octet

Dans le cas contraire, je n'ai jamais trouvé de ressource
expliquant comment on recolle les fichiers bruts qui sortent du backup.

C'est du innodb, j'ai cherché aussi mais rien trouvé encore

Greg

Le 19 févr. 2016 à 18:17, Grégoire COUTANT <gregoire.coutant@gmail.com> a écrit :

Bonjour,

Le 19/02/2016 17:13, Philippe Gras a écrit :

Les backups sont-ils faits en incrémental ?

Un script génère un dump via la fonction mysqldump et les dumps sont archivés sur un autre serveur via backuppc.
Les dumps des deux derniers jours ont plantés le serveur et sont donc à 0 octet

Dans le cas contraire, je n'ai jamais trouvé de ressource
expliquant comment on recolle les fichiers bruts qui sortent du backup.

D'après ce que je lis, ça devrait te sortir un fichier SQL :
http://cipcnet.insa-lyon.fr/sqltut/nexen/mysqldump.html

Ce n'est pas le cas ?

C'est du innodb, j'ai cherché aussi mais rien trouvé encore

Je ne vois pas ce que ça change avec autre chose, mais bon…
http://www.tux-planet.fr/mysql-les-principales-differences-entre-myisam-et -innodb/

Greg

SQL c'est tellement bizarre que j'ai depuis longtemps renoncé à comprendre.

Le seul truc que je demande à mon backup, c'est de me sortir un SQL, et puis

c'est tout ! Désolé.

Ph. Gras=

--047d7b5d8d3901b409052c231712
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

T'as essayé de redémarrer mysql avec un ancien frm de la mêm e base ?
Si tu n'as pas de frm, mysql ne peut pas retrouver la structure de tes
tables.

Avec de la chance ça peut fonctionner.

J

Le 19 février 2016 à 18:34, Philippe Gras <ph.gras@worldonline.fr > a écrit :

Le 19 févr. 2016 à 18:17, Grégoire COUTANT <gregoire.couta nt@gmail.com> a
écrit :

> Bonjour,
>
> Le 19/02/2016 17:13, Philippe Gras a écrit :
>> Les backups sont-ils faits en incrémental ?
>
> Un script génère un dump via la fonction mysqldump et les dum ps sont
archivés sur un autre serveur via backuppc.
> Les dumps des deux derniers jours ont plantés le serveur et sont d onc à
0 octet
>
>> Dans le cas contraire, je n'ai jamais trouvé de ressource
>> expliquant comment on recolle les fichiers bruts qui sortent du backup .

D'après ce que je lis, ça devrait te sortir un fichier SQL :
http://cipcnet.insa-lyon.fr/sqltut/nexen/mysqldump.html

Ce n'est pas le cas ?
>
> C'est du innodb, j'ai cherché aussi mais rien trouvé encore

Je ne vois pas ce que ça change avec autre chose, mais bon…

http://www.tux-planet.fr/mysql-les-principales-differences-entre-myisam-e t-innodb/
>
> Greg
>
SQL c'est tellement bizarre que j'ai depuis longtemps renoncé à comprendre.

Le seul truc que je demande à mon backup, c'est de me sortir un SQL, et
puis

c'est tout ! Désolé.

Ph. Gras

--
bartoua est votre ami

--047d7b5d8d3901b409052c231712
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div>Hello,</div><div><br></div><div>T&#39;as essayé de redémarrer mysql avec un ancien frm de la même base ?</div><di v>Si tu n&#39;as pas de frm, mysql ne peut pas retrouver la structure de te s tables.</div><div><br></div><div>Avec de la chance ça peut fonctionn er.</div><div><br></div><div>J</div></div><div class="gmail_extra"><br><d iv class="gmail_quote">Le 19 février 2016 à 18:34, Philippe Gra s <span dir="ltr">&lt;<a href="mailto:ph.gras@worldonline.fr" target= "_blank">ph.gras@worldonline.fr</a>&gt;</span> a écrit :<br><blockquot e class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc sol id;padding-left:1ex"><span class=""><br>
Le 19 févr. 2016 à 18:17, Grégoire COUTANT &lt;<a href="ma ilto:gregoire.coutant@gmail.com">gregoire.coutant@gmail.com</a>&gt; a à ©crit :<br>
<br>
&gt; Bonjour,<br>
&gt;<br>
&gt; Le 19/02/2016 17:13, Philippe Gras a écrit :<br>
&gt;&gt; Les backups sont-ils faits en incrémental ?<br>
&gt;<br>
&gt; Un script génère un dump via la fonction mysqldump et les du mps sont archivés sur un autre serveur via backuppc.<br>
&gt; Les dumps des deux derniers jours ont plantés le serveur et sont donc à 0 octet<br>
&gt;<br>
&gt;&gt; Dans le cas contraire, je n&#39;ai jamais trouvé de ressource <br>
&gt;&gt; expliquant comment on recolle les fichiers bruts qui sortent du ba ckup.<br>
<br>
</span>D&#39;après ce que je lis, ça devrait te sortir un fichier SQL :<br>
<a href="http://cipcnet.insa-lyon.fr/sqltut/nexen/mysqldump.html" rel=" noreferrer" target="_blank">http://cipcnet.insa-lyon.fr/sqltut/nexen/mysq ldump.html</a><br>
<br>
Ce n&#39;est pas le cas ?<br>
<span class="">&gt;<br>
&gt; C&#39;est du innodb, j&#39;ai cherché aussi mais rien trouvé encore<br>
<br>
</span>Je ne vois pas ce que ça change avec autre chose, mais bon⠀¦<br>
<a href="http://www.tux-planet.fr/mysql-les-principales-differences-entre -myisam-et-innodb/" rel="noreferrer" target="_blank">http://www.tux-pla net.fr/mysql-les-principales-differences-entre-myisam-et-innodb/</a><br>
&gt;<br>
&gt; Greg<br>
&gt;<br>
SQL c&#39;est tellement bizarre que j&#39;ai depuis longtemps renoncé à comprendre.<br>
<br>
Le seul truc que je demande à mon backup, c&#39;est de me sortir un SQ L, et puis<br>
<br>
c&#39;est tout ! Désolé.<br>
<br>
Ph. Gras<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class ="gmail_signature">bartoua est votre ami</div>
</div>

--047d7b5d8d3901b409052c231712--

Bonjour,

Comme tu as l'air toujours bloqué, je me lance :

Le 19/02/2016 16:17, Grégoire COUTANT a écrit :

Bonjour à tous,
Notre serveur interne à planté cette nuit lors des dumps de sauvegarde
des DB.
Un de nos logiciels (redmine) a perdu (!) sa base innodb et nous
n'arrivons pas à récupérer les données.

Quelques explications :
- Le script de dump de la nuit à fait planté le serveur MySQL
- Ce plantage à fait perdre des fichiers frm
- Nous avons toujours le fichier ibdata qui fait 80 Go (avec les
données dedans normalement)
- Nous avons récupéré un backup d'il y a deux jours des fichiers frm,
quand on le met en place, ça ne change rien.

On se dit que les données sont dans le ibdata mais tout ce qu'on a
essayé ne fonctionne pas (repair etc...), on n'accède pas à la base.

Avez-vous des idées de comment faire

Quelques remarques :

Tu as l'air d'avoir 2 types de sauvegardes :

- mysqldump (2 dernières sauvegardes à 0 .... mais as-tu d'autres
sauvegardes ? )

- backup des fichiers bruts frm (et ibdata ?)

Si je ne dis pas de bêtises, tes backups de frm et ibdata ne peuvent
être fonctionnels que si leur backup a été effectué en même temps avec
mysql arrêté ... est-ce la cas ?

Comme tes dumps mysql ont l'air HS, il faut que tu utilises tes
sauvegardes de fichiers bruts (frm, ibdata et aussi ib_logfile je suppose).

Si tu possèdes d'autres sauvegardes mysqldump de tes bases, il est
possible que ta config de base de mysql, qui permet pourtant de faire
tourner de gros ibdata, ne soit pas suffisamment taillé pour importer
les mêmes gros ibdata.

Je n'ai plus accès aux valeurs que j'avais modifiées, mais il faudrait
peut-être déjà voir avec :

innodb_flush_method
innodb_buffer_pool_size
innodb_log_file_size
innodb_log_buffer_size

plus d'autres valeurs affectant la gestion de la mémoire par mysql.
Un serveur de test pour tester les réimports de base serait un plus.

Essayer aussi de limiter mysql à localhost le temps des réimports de dumps.

De plus, il est recommandé (si pas déjà fait) d'avoir un ibdata par base :

innodb_file_per_table

Voilà quelques pistes.

Samuel.

Bonjour à tous, un retour sur le sujet.
Au final nous avons exploré toutes les pistes, rien n'a fonctionné :-(

Nous avons passé du temps à faire du fine tuning sur la conf (enfin pas
si fine que ça quand même !), en séparant les bases notamment et nous
avons activé les logs binaires (même sans réplication) afin de récupérer
plus facilement les datas en cas de perte.

C'est le dump sur un fichier trop gros qui faisait planter le serveur,
donc mysql plantait et le dump était corrompu....

Nous sauvegardons maintenant les bases via dump mais aussi directement
les fichiers frm, ibf etc...

Merci à tous pour vos pistes !

Greg

--001a1139879a4b6e0e052cf9eae5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

BOnjour,

Pour info en innodb ici on active une option pour splitter les données en 1
fichier par table sur les grosses bases. Je crois que du coup ça fait 1
fichier de dump par table et donc plusieurs fichiers au lieu d'un seul
énorme.

innodb_file_per_table (
http://dev.mysql.com/doc/refman/5.7/en/innodb-multiple-tablespaces.html)

Attention il y a des manips à faire pour une base déjà exist ante sinon tu
auras toujours ton ibdata à 80Go.

David

Le 29 février 2016 à 11:35, Grégoire COUTANT <gregoire.couta nt@gmail.com> a
écrit :

Bonjour à tous, un retour sur le sujet.
Au final nous avons exploré toutes les pistes, rien n'a fonctionnà © :-(

Nous avons passé du temps à faire du fine tuning sur la conf (e nfin pas si
fine que ça quand même !), en séparant les bases notamment et nous avons
activé les logs binaires (même sans réplication) afin de r écupérer plus
facilement les datas en cas de perte.

C'est le dump sur un fichier trop gros qui faisait planter le serveur,
donc mysql plantait et le dump était corrompu....

Nous sauvegardons maintenant les bases via dump mais aussi directement le s
fichiers frm, ibf etc...

Merci à tous pour vos pistes !

Greg

--001a1139879a4b6e0e052cf9eae5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="ltr">BOnjour,<div><br></div><div>Pour info en innodb ici on act ive une option pour splitter les données en 1 fichier par table sur le s grosses bases. Je crois que du coup ça fait 1 fichier de dump par ta ble et donc plusieurs fichiers au lieu d&#39;un seul énorme.</div><div ><br></div><div>innodb_file_per_table (<a href="http://dev.mysql.com/doc/ refman/5.7/en/innodb-multiple-tablespaces.html">http://dev.mysql.com/doc/re fman/5.7/en/innodb-multiple-tablespaces.html</a>)</div><div><br></div><div> Attention il y a des manips à faire pour une base déjà exist ante sinon tu auras toujours ton ibdata à 80Go.</div><div><br></div><d iv>David</div></div><div class="gmail_extra"><br><div class="gmail_quot e">Le 29 février 2016 à 11:35, Grégoire COUTANT <span dir= "ltr">&lt;<a href="mailto:gregoire.coutant@gmail.com" target="_blank">g regoire.coutant@gmail.com</a>&gt;</span> a écrit :<br><blockquote clas s="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;pad ding-left:1ex">Bonjour à tous, un retour sur le sujet.<br>
Au final nous avons exploré toutes les pistes, rien n&#39;a fonctionn é :-(<br>
<br>
Nous avons passé du temps à faire du fine tuning sur la conf (enf in pas si fine que ça quand même !), en séparant les bases n otamment et nous avons activé les logs binaires (même sans rà ©plication) afin de récupérer plus facilement les datas en cas de perte.<br>
<br>
C&#39;est le dump sur un fichier trop gros qui faisait planter le serveur, donc mysql plantait et le dump était corrompu....<br>
<br>
Nous sauvegardons maintenant les bases via dump mais aussi directement les fichiers frm, ibf etc...<br>
<br>
Merci à tous pour vos pistes !<br>
<br>
Greg<br>
<br>
</blockquote></div><br></div>

--001a1139879a4b6e0e052cf9eae5--

Bonjour David,

Le 01/03/2016 11:06, David_dev Dev a écrit :

BOnjour,
Pour info en innodb ici on active une option pour splitter les données
en 1 fichier par table sur les grosses bases. Je crois que du coup ça
fait 1 fichier de dump par table et donc plusieurs fichiers au lieu d'un
seul énorme.

Oui c'est ce que nous avons fait (je trouve étonnant au passage que la
conf de base de MySQL n'active pas cette option par défaut).

innodb_file_per_table
(http://dev.mysql.com/doc/refman/5.7/en/innodb-multiple-tablespaces.html)
Attention il y a des manips à faire pour une base déjà existante sinon
tu auras toujours ton ibdata à 80Go.

On a en effet du dumper, modifier la conf puis réimporter le dump dans
une base vierge.

Pour info si ça peut aider voilà notre conf :

# * InnoDB
innodb_file_per_table=1
innodb_data_file_path=ibdata1:10M:autoextend
#Test optimisation innodb
innodb_buffer_pool_size = 30G
innodb_flush_method = O_DSYNC

et l'activation des logs binaires pour plus rien perdre sur certaines
bases ! :

log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
binlog_do_db = redmine

Greg