J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en moyenne
50 octets CHAR chacun), mais c'est gérable.
D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?
Par ailleurs, il est une autre question que je me pose. Pour cette fois,
j'ai inséré mes données dans la table par 'copié/collé' depuis un fichier
calc, c'est à dire que je l'ai fait en deux fois. Est-il possible, en
faisant usage de OO Base, de copier directement à partir d'un fichier
texte csv avec des données séparées par des point virgules ? J'ai
constaté qu'en copié collé ce n'était pas possible, ce dont je me doutais
un peu.
J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en moyenne
50 octets CHAR chacun), mais c'est gérable.
D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?
Par ailleurs, il est une autre question que je me pose. Pour cette fois,
j'ai inséré mes données dans la table par 'copié/collé' depuis un fichier
calc, c'est à dire que je l'ai fait en deux fois. Est-il possible, en
faisant usage de OO Base, de copier directement à partir d'un fichier
texte csv avec des données séparées par des point virgules ? J'ai
constaté qu'en copié collé ce n'était pas possible, ce dont je me doutais
un peu.
J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en moyenne
50 octets CHAR chacun), mais c'est gérable.
D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?
Par ailleurs, il est une autre question que je me pose. Pour cette fois,
j'ai inséré mes données dans la table par 'copié/collé' depuis un fichier
calc, c'est à dire que je l'ai fait en deux fois. Est-il possible, en
faisant usage de OO Base, de copier directement à partir d'un fichier
texte csv avec des données séparées par des point virgules ? J'ai
constaté qu'en copié collé ce n'était pas possible, ce dont je me doutais
un peu.
Bernard wrote:D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?
Tu peux tout à fait faire une archive du répertoire, il suffira de la
décompresser au bon endroit sur ton autre machine et ça tournera.
Bernard wrote:
D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?
Tu peux tout à fait faire une archive du répertoire, il suffira de la
décompresser au bon endroit sur ton autre machine et ça tournera.
Bernard wrote:D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?
Tu peux tout à fait faire une archive du répertoire, il suffira de la
décompresser au bon endroit sur ton autre machine et ça tournera.
Tu peux tout à fait faire une archive du répertoire, il suffira de la
décompresser au bon endroit sur ton autre machine et ça tournera.
Tu peux tout à fait faire une archive du répertoire, il suffira de la
décompresser au bon endroit sur ton autre machine et ça tournera.
Tu peux tout à fait faire une archive du répertoire, il suffira de la
décompresser au bon endroit sur ton autre machine et ça tournera.
Bonjour à tous,
Je précise tout de suite que je débute sur les bases de données, et que,
autre singularité, je ne travaille pas sous MSWIN, mais sous Linux
(Debian Lenny pour mon desktop, Ubuntu Hardy Heron sur mon laptop).
Jusqu'alors, je me contentais de gérer mes bases avec StarCalc
(OpenOffice Calc), tableur voisin de MS EXCEL. Lorsque lesdites bases ont
dépassé 65536 lignes, j'ai dû me résoudre à les fractionner, ce qui n'est
pas génial, surtout lorsqu'on doit faire des tris et autres opérations.
Alors j'ai essayé OpenOffice BASE avec MySQL, sur les conseils reçus par
les utilisateurs rencontrés sur fr.comp.os.linux.configuration, lesquels
m'ont recommandé de venir ici pour des questions plus précisément ciblées
sur les bases de données.
J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en moyenne
50 octets CHAR chacun), mais c'est gérable.
A ce stade, je me pose quelques questions, nul doute qu'il y en aura
prochainement davantage.
D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
avec user et grp : 'mysql'
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?
Bonjour à tous,
Je précise tout de suite que je débute sur les bases de données, et que,
autre singularité, je ne travaille pas sous MSWIN, mais sous Linux
(Debian Lenny pour mon desktop, Ubuntu Hardy Heron sur mon laptop).
Jusqu'alors, je me contentais de gérer mes bases avec StarCalc
(OpenOffice Calc), tableur voisin de MS EXCEL. Lorsque lesdites bases ont
dépassé 65536 lignes, j'ai dû me résoudre à les fractionner, ce qui n'est
pas génial, surtout lorsqu'on doit faire des tris et autres opérations.
Alors j'ai essayé OpenOffice BASE avec MySQL, sur les conseils reçus par
les utilisateurs rencontrés sur fr.comp.os.linux.configuration, lesquels
m'ont recommandé de venir ici pour des questions plus précisément ciblées
sur les bases de données.
J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en moyenne
50 octets CHAR chacun), mais c'est gérable.
A ce stade, je me pose quelques questions, nul doute qu'il y en aura
prochainement davantage.
D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
avec user et grp : 'mysql'
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?
Bonjour à tous,
Je précise tout de suite que je débute sur les bases de données, et que,
autre singularité, je ne travaille pas sous MSWIN, mais sous Linux
(Debian Lenny pour mon desktop, Ubuntu Hardy Heron sur mon laptop).
Jusqu'alors, je me contentais de gérer mes bases avec StarCalc
(OpenOffice Calc), tableur voisin de MS EXCEL. Lorsque lesdites bases ont
dépassé 65536 lignes, j'ai dû me résoudre à les fractionner, ce qui n'est
pas génial, surtout lorsqu'on doit faire des tris et autres opérations.
Alors j'ai essayé OpenOffice BASE avec MySQL, sur les conseils reçus par
les utilisateurs rencontrés sur fr.comp.os.linux.configuration, lesquels
m'ont recommandé de venir ici pour des questions plus précisément ciblées
sur les bases de données.
J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en moyenne
50 octets CHAR chacun), mais c'est gérable.
A ce stade, je me pose quelques questions, nul doute qu'il y en aura
prochainement davantage.
D'abord, cette base MySQL, comment en fait on des sauvegardes ?
J'ai trouvé que, sur mon système, les bases sont stockées dans:
/var/lib/mysql/'nombase'/
avec user et grp : 'mysql'
Comment puis-je copier ces bases, sur un cdrom, une clef usb ou un disque
externe par exemple ? Puis-je compresser ces fichier avant de les
sauvegarder ?
Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à un
moment de la journée arrêter ta base, alors tu as au moins deux solutions :
faire une recopie avec cp et les options d'archives qui vont bien (man cp)
ou mieux un rsync avec les bonnes options (man rsync),
de /var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Si tu as besoin du moteur INNODB, par exemple pour gérer des transactions ou
l'intégrité référentielle et la cascade, là ton choix est simple : si tu
veux du gratuit tu arrêtes ta base et tu recopies, sinon c'est payant
l'utilitaire un peu équivalent à mysqlhotcopy pour les bases INNODB n'est
pas libre ou en tout cas pas gratuit, il faut l'acheter chez MySQL AB. Si
c'est un truc de boulot tu peux sans doute acquérir cet outil, c'est
beaucoup plus propre, et puis il faut bien qu'ils vivent.
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la base
dans un fichier texte, souvent sous forme d'instructions SQL d'insert pour
pouvoir recréer les bases et y réinjecter les données en restauration.
Beaucoup plus long que de faire un rsync sur une arborescence à mon goût.
Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à un
moment de la journée arrêter ta base, alors tu as au moins deux solutions :
faire une recopie avec cp et les options d'archives qui vont bien (man cp)
ou mieux un rsync avec les bonnes options (man rsync),
de /var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Si tu as besoin du moteur INNODB, par exemple pour gérer des transactions ou
l'intégrité référentielle et la cascade, là ton choix est simple : si tu
veux du gratuit tu arrêtes ta base et tu recopies, sinon c'est payant
l'utilitaire un peu équivalent à mysqlhotcopy pour les bases INNODB n'est
pas libre ou en tout cas pas gratuit, il faut l'acheter chez MySQL AB. Si
c'est un truc de boulot tu peux sans doute acquérir cet outil, c'est
beaucoup plus propre, et puis il faut bien qu'ils vivent.
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la base
dans un fichier texte, souvent sous forme d'instructions SQL d'insert pour
pouvoir recréer les bases et y réinjecter les données en restauration.
Beaucoup plus long que de faire un rsync sur une arborescence à mon goût.
Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à un
moment de la journée arrêter ta base, alors tu as au moins deux solutions :
faire une recopie avec cp et les options d'archives qui vont bien (man cp)
ou mieux un rsync avec les bonnes options (man rsync),
de /var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Si tu as besoin du moteur INNODB, par exemple pour gérer des transactions ou
l'intégrité référentielle et la cascade, là ton choix est simple : si tu
veux du gratuit tu arrêtes ta base et tu recopies, sinon c'est payant
l'utilitaire un peu équivalent à mysqlhotcopy pour les bases INNODB n'est
pas libre ou en tout cas pas gratuit, il faut l'acheter chez MySQL AB. Si
c'est un truc de boulot tu peux sans doute acquérir cet outil, c'est
beaucoup plus propre, et puis il faut bien qu'ils vivent.
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la base
dans un fichier texte, souvent sous forme d'instructions SQL d'insert pour
pouvoir recréer les bases et y réinjecter les données en restauration.
Beaucoup plus long que de faire un rsync sur une arborescence à mon goût.
Alarch wrote:Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync),
de /var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Comme je l'ai déjà dit, c'est une très mauvaise idée.
Si tu as besoin du moteur INNODB, par exemple pour gérer des transactions
ou l'intégrité référentielle et la cascade, là ton choix est simple : si
tu veux du gratuit tu arrêtes ta base et tu recopies, sinon c'est payant
l'utilitaire un peu équivalent à mysqlhotcopy pour les bases INNODB n'est
pas libre ou en tout cas pas gratuit, il faut l'acheter chez MySQL AB. Si
c'est un truc de boulot tu peux sans doute acquérir cet outil, c'est
beaucoup plus propre, et puis il faut bien qu'ils vivent.
On peut également utiliser la réplication, et sauvegarder la base
répliquée.
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.
Plus long mais plus fiable. La vitesse est la seule raison pour
laquelle tu n'aime pas dumper ?
Alarch wrote:
Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync),
de /var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Comme je l'ai déjà dit, c'est une très mauvaise idée.
Si tu as besoin du moteur INNODB, par exemple pour gérer des transactions
ou l'intégrité référentielle et la cascade, là ton choix est simple : si
tu veux du gratuit tu arrêtes ta base et tu recopies, sinon c'est payant
l'utilitaire un peu équivalent à mysqlhotcopy pour les bases INNODB n'est
pas libre ou en tout cas pas gratuit, il faut l'acheter chez MySQL AB. Si
c'est un truc de boulot tu peux sans doute acquérir cet outil, c'est
beaucoup plus propre, et puis il faut bien qu'ils vivent.
On peut également utiliser la réplication, et sauvegarder la base
répliquée.
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.
Plus long mais plus fiable. La vitesse est la seule raison pour
laquelle tu n'aime pas dumper ?
Alarch wrote:Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync),
de /var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Comme je l'ai déjà dit, c'est une très mauvaise idée.
Si tu as besoin du moteur INNODB, par exemple pour gérer des transactions
ou l'intégrité référentielle et la cascade, là ton choix est simple : si
tu veux du gratuit tu arrêtes ta base et tu recopies, sinon c'est payant
l'utilitaire un peu équivalent à mysqlhotcopy pour les bases INNODB n'est
pas libre ou en tout cas pas gratuit, il faut l'acheter chez MySQL AB. Si
c'est un truc de boulot tu peux sans doute acquérir cet outil, c'est
beaucoup plus propre, et puis il faut bien qu'ils vivent.
On peut également utiliser la réplication, et sauvegarder la base
répliquée.
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.
Plus long mais plus fiable. La vitesse est la seule raison pour
laquelle tu n'aime pas dumper ?
Merci d'avance pour vos conseils et recommandations.
Merci d'avance pour vos conseils et recommandations.
Merci d'avance pour vos conseils et recommandations.
Bernard wrote:Bonjour à tous,
Je précise tout de suite que je débute sur les bases de données, et
que, autre singularité, je ne travaille pas sous MSWIN, mais sous Linux
(Debian Lenny pour mon desktop, Ubuntu Hardy Heron sur mon laptop).
Jusqu'alors, je me contentais de gérer mes bases avec StarCalc
(OpenOffice Calc), tableur voisin de MS EXCEL. Lorsque lesdites bases
ont dépassé 65536 lignes, j'ai dû me résoudre à les fractionner, ce qui
n'est pas génial, surtout lorsqu'on doit faire des tris et autres
opérations.
Alors j'ai essayé OpenOffice BASE avec MySQL, sur les conseils reçus
par les utilisateurs rencontrés sur fr.comp.os.linux.configuration,
lesquels m'ont recommandé de venir ici pour des questions plus
précisément ciblées sur les bases de données.
J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en
moyenne 50 octets CHAR chacun), mais c'est gérable.
Qu'entends-tu par parcourir tes enregistrements ? Juste les afficher à
l'écran ou y effectuer un traitement. Parce qu'en local les temps que tu
annonces me semblent incroyablement longs. Tu n'aurais pas des problèmes
d'index inexistants sur des champs de tri courants ?
Bernard wrote:
Bonjour à tous,
Je précise tout de suite que je débute sur les bases de données, et
que, autre singularité, je ne travaille pas sous MSWIN, mais sous Linux
(Debian Lenny pour mon desktop, Ubuntu Hardy Heron sur mon laptop).
Jusqu'alors, je me contentais de gérer mes bases avec StarCalc
(OpenOffice Calc), tableur voisin de MS EXCEL. Lorsque lesdites bases
ont dépassé 65536 lignes, j'ai dû me résoudre à les fractionner, ce qui
n'est pas génial, surtout lorsqu'on doit faire des tris et autres
opérations.
Alors j'ai essayé OpenOffice BASE avec MySQL, sur les conseils reçus
par les utilisateurs rencontrés sur fr.comp.os.linux.configuration,
lesquels m'ont recommandé de venir ici pour des questions plus
précisément ciblées sur les bases de données.
J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en
moyenne 50 octets CHAR chacun), mais c'est gérable.
Qu'entends-tu par parcourir tes enregistrements ? Juste les afficher à
l'écran ou y effectuer un traitement. Parce qu'en local les temps que tu
annonces me semblent incroyablement longs. Tu n'aurais pas des problèmes
d'index inexistants sur des champs de tri courants ?
Bernard wrote:Bonjour à tous,
Je précise tout de suite que je débute sur les bases de données, et
que, autre singularité, je ne travaille pas sous MSWIN, mais sous Linux
(Debian Lenny pour mon desktop, Ubuntu Hardy Heron sur mon laptop).
Jusqu'alors, je me contentais de gérer mes bases avec StarCalc
(OpenOffice Calc), tableur voisin de MS EXCEL. Lorsque lesdites bases
ont dépassé 65536 lignes, j'ai dû me résoudre à les fractionner, ce qui
n'est pas génial, surtout lorsqu'on doit faire des tris et autres
opérations.
Alors j'ai essayé OpenOffice BASE avec MySQL, sur les conseils reçus
par les utilisateurs rencontrés sur fr.comp.os.linux.configuration,
lesquels m'ont recommandé de venir ici pour des questions plus
précisément ciblées sur les bases de données.
J'ai donc désormais une serveur mysql, et j'essaye de gérer l'essentiel
via l'interface proposée par OO_Base. C'est un peu lent (3 minutes pour
parcourir une base de 65,000 enregistrements du premier au dernier, 6
minutes pour une base de 115568 enregistrements de 19 champs d'en
moyenne 50 octets CHAR chacun), mais c'est gérable.
Qu'entends-tu par parcourir tes enregistrements ? Juste les afficher à
l'écran ou y effectuer un traitement. Parce qu'en local les temps que tu
annonces me semblent incroyablement longs. Tu n'aurais pas des problèmes
d'index inexistants sur des champs de tri courants ?
Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync), de
/var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.
Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync), de
/var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.
Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync), de
/var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.
Le Thu, 08 Oct 2009 10:31:48 +0200, Alarch a écrit:Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync), de
/var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Si on veut éviter les soucis, cela ne suffit pas.
Il faut aussi sauvegarder les *programmes* et toutes les bibliothèques
utilisées par le SGBDR.
Parce que sinon, le jour où l'on met à jour le moteur, les anciennes
sauvegardes ne seront pas nécessairement compatibles au niveau binaire
(il peut suffire d'avoir un changement dans les options de compilation ou
un passage 32bits vers 64bits pour avoir des données stockées
différements sur le disque) et donc potentiellement inutilisables... sauf
à reinstaller l'ancienne version ce qui peut être plus ou moins simple,
mais en tout cas bien plus rapide si on a pensé à sauvegarder les
programmes et pas seulement les données.
A noter que pour tout projet non trivial, je ne pense pas qu'on puisse
admettre d'arrêter la base, d'autant que ce n'est pas pour un temps court
déterminé genre pour une mise à jour, mais un temps plus ou moins long,
proportionnel à la quantité de données à exporter, temps non connu
d'avance.
Si on veut vraiment ce genre de sauvegardes il vaut mieux :
- soit avoir de la réplication, et comme ca on peut arrêter l'esclave
quand on veut pour faire la sauvegarde à cet endroit
(étant donné que la présence de l'esclave est déjà une sauvegarde en soi,
en tout cas au niveau de la défaillance du serveur principal, pas au
niveau d'un DELETE FROM mal utilisé)
- soit avoir la coopération du SGBDR pour pouvoir faire un snapshot du
système de fichier sans stoper le SGBDR. PostgreSQL permet cela dans les
versions récentes, MySQL je ne sais pas.
Ou utiliser d'autres fonctionnalités d'icelui, si présentes, comme le
"log shipping".Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.
Cela a cependant l'avantage de fournir un résultat dans un format
"neutre" qui s'affranchit grandement des différences de version du
programme. Par contre il peut se poser, pour certains SGBDRs, un problème
de cohérence des données.
Le Thu, 08 Oct 2009 10:31:48 +0200, Alarch a écrit:
Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync), de
/var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Si on veut éviter les soucis, cela ne suffit pas.
Il faut aussi sauvegarder les *programmes* et toutes les bibliothèques
utilisées par le SGBDR.
Parce que sinon, le jour où l'on met à jour le moteur, les anciennes
sauvegardes ne seront pas nécessairement compatibles au niveau binaire
(il peut suffire d'avoir un changement dans les options de compilation ou
un passage 32bits vers 64bits pour avoir des données stockées
différements sur le disque) et donc potentiellement inutilisables... sauf
à reinstaller l'ancienne version ce qui peut être plus ou moins simple,
mais en tout cas bien plus rapide si on a pensé à sauvegarder les
programmes et pas seulement les données.
A noter que pour tout projet non trivial, je ne pense pas qu'on puisse
admettre d'arrêter la base, d'autant que ce n'est pas pour un temps court
déterminé genre pour une mise à jour, mais un temps plus ou moins long,
proportionnel à la quantité de données à exporter, temps non connu
d'avance.
Si on veut vraiment ce genre de sauvegardes il vaut mieux :
- soit avoir de la réplication, et comme ca on peut arrêter l'esclave
quand on veut pour faire la sauvegarde à cet endroit
(étant donné que la présence de l'esclave est déjà une sauvegarde en soi,
en tout cas au niveau de la défaillance du serveur principal, pas au
niveau d'un DELETE FROM mal utilisé)
- soit avoir la coopération du SGBDR pour pouvoir faire un snapshot du
système de fichier sans stoper le SGBDR. PostgreSQL permet cela dans les
versions récentes, MySQL je ne sais pas.
Ou utiliser d'autres fonctionnalités d'icelui, si présentes, comme le
"log shipping".
Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.
Cela a cependant l'avantage de fournir un résultat dans un format
"neutre" qui s'affranchit grandement des différences de version du
programme. Par contre il peut se poser, pour certains SGBDRs, un problème
de cohérence des données.
Le Thu, 08 Oct 2009 10:31:48 +0200, Alarch a écrit:Et bien la sauvegarde de MySQL dépend de plusieurs choses. Si tu peux à
un moment de la journée arrêter ta base, alors tu as au moins deux
solutions : faire une recopie avec cp et les options d'archives qui vont
bien (man cp) ou mieux un rsync avec les bonnes options (man rsync), de
/var/lib/mysql/labase/ sur un répertoire de sauvegarde de ton choix
(éventuellement distant sur un serveur de sauvegarde).
Si on veut éviter les soucis, cela ne suffit pas.
Il faut aussi sauvegarder les *programmes* et toutes les bibliothèques
utilisées par le SGBDR.
Parce que sinon, le jour où l'on met à jour le moteur, les anciennes
sauvegardes ne seront pas nécessairement compatibles au niveau binaire
(il peut suffire d'avoir un changement dans les options de compilation ou
un passage 32bits vers 64bits pour avoir des données stockées
différements sur le disque) et donc potentiellement inutilisables... sauf
à reinstaller l'ancienne version ce qui peut être plus ou moins simple,
mais en tout cas bien plus rapide si on a pensé à sauvegarder les
programmes et pas seulement les données.
A noter que pour tout projet non trivial, je ne pense pas qu'on puisse
admettre d'arrêter la base, d'autant que ce n'est pas pour un temps court
déterminé genre pour une mise à jour, mais un temps plus ou moins long,
proportionnel à la quantité de données à exporter, temps non connu
d'avance.
Si on veut vraiment ce genre de sauvegardes il vaut mieux :
- soit avoir de la réplication, et comme ca on peut arrêter l'esclave
quand on veut pour faire la sauvegarde à cet endroit
(étant donné que la présence de l'esclave est déjà une sauvegarde en soi,
en tout cas au niveau de la défaillance du serveur principal, pas au
niveau d'un DELETE FROM mal utilisé)
- soit avoir la coopération du SGBDR pour pouvoir faire un snapshot du
système de fichier sans stoper le SGBDR. PostgreSQL permet cela dans les
versions récentes, MySQL je ne sais pas.
Ou utiliser d'autres fonctionnalités d'icelui, si présentes, comme le
"log shipping".Sinon bien entendu il reste toujours les solutions de "dump", perso je
n'aime pas trop ça mais bon. L'idée est de recopier les données de la
base dans un fichier texte, souvent sous forme d'instructions SQL
d'insert pour pouvoir recréer les bases et y réinjecter les données en
restauration. Beaucoup plus long que de faire un rsync sur une
arborescence à mon goût.
Cela a cependant l'avantage de fournir un résultat dans un format
"neutre" qui s'affranchit grandement des différences de version du
programme. Par contre il peut se poser, pour certains SGBDRs, un problème
de cohérence des données.