bonjour,
est il encore possible de basculer les tables au format csv ?
passer à PgSQL ?
bonjour,
est il encore possible de basculer les tables au format csv ?
passer à PgSQL ?
bonjour,
est il encore possible de basculer les tables au format csv ?
passer à PgSQL ?
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 à 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 à 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 à 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 à 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 à 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
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.
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.
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.
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 octetDans 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
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
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 octetDans 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.couta 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
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
Le 19 févr. 2016 à 18:17, Grégoire COUTANT <gregoire.couta 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
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
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
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
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
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
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
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à existante sinon
tu auras toujours ton ibdata à 80Go.
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à existante sinon
tu auras toujours ton ibdata à 80Go.
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à existante sinon
tu auras toujours ton ibdata à 80Go.