Le 19/07/2013 10:13, Frédéric de Villamil a écrit :
Le 19 juil. 2013 à 10:12, "LEFEVRE Hugo" mailto:hugo.lefe...@siih5962.fr>> a écrit :
Bonjour,
Je travaille actuellement sur une architecture MySQL et cette
discutions m'amène a une petite question.
Peu t'ont envisager d'avoir un serveur mast
Le 19 juil. 2013 à 10:12, "LEFEVRE Hugo" a écrit :
> Bonjour,
>
> Je travaille actuellement sur une architecture MySQL et cette discutions
> m'amène a une petite question.
> Peu t'ont envisager d'avoir un serveur master en
> innodb-flush-log-at-trx-commit a 0 et un slave avec cette variable
Bonjour,
Je travaille actuellement sur une architecture MySQL et cette discutions
m'amène a une petite question.
Peu t'ont envisager d'avoir un serveur master en
innodb-flush-log-at-trx-commit a 0 et un slave avec cette variable a 1?
Wallace a écrit :
Le 18/07/2013 20:12, Etienne Decham
Le 18/07/2013 20:12, Etienne Dechamps a écrit :
> On 07/18/2013 05:46 PM, Bégault Luc wrote:
>> Attention, cette méthode si elle fonctionne avec des tables MyIsam peut
>> poser des problèmes avec InnoDB
>> (http://dev.mysql.com/doc/refman/5.5/en/innodb-backup.html => pour un
>> snapshot fichier, my
On 18/07/2013 20:12, Etienne Dechamps wrote:
Techniquement tu n'as pas besoin de locker. Si le moteur de base de
données est implémenté correctement (plus précisément s'il utilise
fsync() correctement, et pour InnoDB j'imagine que c'est le cas) il est
capable de résister sans problème à une coupu
Salut,
Regarde backup-manager (paquet debian disponible), il gère les
sauvegardes MySQL (entre autres), fait les LOCK pour conserver la
cohérence, sait zipper le résultat et l'envoyer via FTP / sFTP.
Léo.
On 18/07/2013 17:33, Gaël wrote:
Hello !
J'ai un serveur (toujours le même), sur leq
On 07/18/2013 05:46 PM, Bégault Luc wrote:
Attention, cette méthode si elle fonctionne avec des tables MyIsam peut
poser des problèmes avec InnoDB
(http://dev.mysql.com/doc/refman/5.5/en/innodb-backup.html => pour un
snapshot fichier, mysql dit que le serveur doit etre arrété).
Si c'est vrai, a
On 07/18/2013 04:47 PM, Florent Rivoire wrote:
Un principe pour avoir un backup cohérent :
=> tu mets ton /var/lib/mysql dans un partition qui est un volume LVM
Et ensuite, ton script de backup fait ceci :
=> tu lock chaque base (FLUSH TABLES WITH READ LOCK de mémoire, cf la doc)
Techniquement
On 18/07/13 17:47, Florent Rivoire wrote:
Un principe pour avoir un backup cohérent :
=> tu mets ton /var/lib/mysql dans un partition qui est un volume LVM
Et ensuite, ton script de backup fait ceci :
=> tu lock chaque base (FLUSH TABLES WITH READ LOCK de mémoire, cf la doc)
=> tu prends un snap
On 18/07/2013 17:47, Florent Rivoire wrote:
Un principe pour avoir un backup cohérent :
=> tu mets ton /var/lib/mysql dans un partition qui est un volume LVM
Et ensuite, ton script de backup fait ceci :
=> tu lock chaque base (FLUSH TABLES WITH READ LOCK de mémoire, cf la doc)
=> tu prends un sn
Le 18/07/2013 17:33, Gaël a écrit :
Hello !
Salut !
[...]
J'ai lu autour de mysql dump, mais si j'ai bien compris, ça ne bloque
pas l'accès à la base pendant le dump, donc il peut y avoir des
écritures simultanées et ça met le truc en vrille.
M'enfin j'ai pas tout tout compris, donc je vous
La réponse dépend beaucoup du fait que tu pisse faire une coupure de service ou
non.
Sébastien Mureau a écrit :
J'en connais qui ne s'emmerdent pas avec le dump, ils font une copie des
fichiers présent dans le rep ou elles sont et les importes direct ...
On est loin des procédures habituelles
La méthode décrite par Florent est de loin la plus efficace pour avoir
une base cohérente.
J'imagine que cela la cohérence ne peut être véritablement garantie
que si les modifications de la base se font via des transactions
commitées.
A défaut, le delta de changements non pris en compte est minim
J'en connais qui ne s'emmerdent pas avec le dump, ils font une copie des
fichiers présent dans le rep ou elles sont et les importes direct ...
On est loin des procédures habituelles ...
Le 18 juillet 2013 17:33, Gaël a écrit :
> Hello !
>
>
> J'ai un serveur (toujours le même), sur lequel sont
Salut,
Un très bon script Bash qui correspond exactement à ta demande a savoir
un dump par base.
http://sourceforge.net/projects/automysqlbackup/
Franck
°°°
Franck Leroy
Telemaque - SOPHIA ANTIPOLIS
°°°
Le 18/07/2013 17
Un principe pour avoir un backup cohérent :
=> tu mets ton /var/lib/mysql dans un partition qui est un volume LVM
Et ensuite, ton script de backup fait ceci :
=> tu lock chaque base (FLUSH TABLES WITH READ LOCK de mémoire, cf la doc)
=> tu prends un snapshot de ton volume LVM
=> tu unlock les base
Hello,
je te renvoie vers ce premier hangops français qui traite le sujet des
backup MySQL => http://www.mysqlplus.fr/2013/06/20/dbhangopsfr-live/
Les dump logique sont bien pour de petites bases, mais lorsque tu veux
remonter ta DB ça risque de prendre une plomb !
Aussi si tu souhaites tou
:34
À : French SysAdmin Group
Objet : [FRsAG] Sauvegarde MySQL
Hello !
J'ai un serveur (toujours le même), sur lequel sont hébergés une trentaine
de site.
Il y a aussi une vingtaine de bases de données MySQL.
Système sous debian, pas de trucs compliqués, y'a juste apache/php/my
Hello !
J'ai un serveur (toujours le même), sur lequel sont hébergés une trentaine
de site.
Il y a aussi une vingtaine de bases de données MySQL.
Système sous debian, pas de trucs compliqués, y'a juste apache/php/mysql et
des services alacon dont on se fout ici.
Je cherche une solution fonction
19 matches
Mail list logo
