Questions sur MySQL avec OO_Base

Bernard wrote:

Là, je fais référence à des temps constatés lors de l'exploitation d'une
base mysql via OpenOffice.org BASE. Un fichier csv de 65,000 lignes
demande à peu près 3 minutes pour s'intégrer à ma base mysql par copié/
collé. Ensuite je fais l'ajout de la deuxième partie, et çà prend à peu
près le même temps. Par contre, si je fais la manip, non plus via
OO_Base, mais directement sous MySQL, via une ligne de commande que j'ai
adaptée d'après une doc trouvée par Google Search, çà ne prend pas 3
minutes, mais seulement 0.15 sec, comme affiché à la fin du processus.

Je comprends mieux, il vaut en effet mieux injecter un fichier via la ligne
de commande que par une interface graphique.

Revenons à OO Base. Si j'ouvre la table, ce qui s'affiche à l'écran
précise : line 1 of 50. Il n'y a en effet que 50 lignes affichées. Si je
fais 'suite', il s'affiche davantage, mais après 2 ou 3 pression sur la
touche PAGE_DOWN, il y a un délai d'attente avant que ne s'affiche la
suivante. Reste la possibilité de cliquer sur le bouton '>>|' (dernière
fiche). Lorsque je clique là dessus, j'attends environ 3 minutes s'il
s'agit d'une table de 65,000 lignes, environ 6 minutes pour mon fichier
entier (115568 lignes), avant d'arriver à la dernière ligne. Pendant le
temps d'attente, je ne vois rien se passer, le bouton '>>|' a disparu, et
un 'top' dans un terminal m'indique que 99% de la CPU et 60% de la
mémoire sont accaparés par OpenOffice. A la fin du processus, le bouton
réapparaît, et je me retrouve avec un tableau indiquant, non plus 'line 1
of 50', mais 'line 115568 of 115568'. Ensuite, si je clique sur '|<<', le
retour à la ligne 1 est quasiment instantané, idem pour le retour à la
dernière ligne. Et, désormais, au lieu d'afficher 'line 1 of 50', çà
affiche 'line 1 of 115568'. Une fois ce premier parcours achevé, les va
et vient entre la première et la dernière ligne sont quasiment
instantanés.

Il doit y avoir une mise en cache, je n'ai jamais utilisé OO Base comme
interface, mais ce que tu décris ne fait pas très envie. J'utilise en
général des bases via des interfaces web en bête Php et je n'a jamais
constaté des temps de latence pareils avec MySQL (ni PostgreSQL non plus).
Mais Php a des fonctions de connexion directe, sans ODBC et autres couches
rajoutées pour ces sgbd là alors qu'il me semble que OO pas par ODBC.

Merci de ces renseignements.

Le Fri, 09 Oct 2009 14:44:57 +0200, Alarch a écrit:

Mais la sauvegarde des exécutables ne se fait q'une fois lors de chaque
mise à jour importante, pas quotidiennement non ?

En théorie oui, puisqu'ils ne bougent pas. En pratique il me paraît
évident qu'un jour on va faire une mise à jour même mineur (aptitude
upgrade, yum upgrade, etc.) et qu'on va oublier la sauvegarde derrière.
Mieux vaut donc sauvegarder tout à chaque fois, avec un outil comme
rsnapshot par exemple, qui utilise des liens durs, x copies du même
fichier ne prendront que la place d'une instance.

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é)

Oui cela pose tout de même la question du temps d'arrête de l'esclave et
de tout ce qu'il va devoir "rattrapper après la sauvegarde".

Mais si l'esclave n'est pas utilisé en production son arrêt n'a pas
d'impact, et après redémarrage il va reprendre la synchronisation, ca va
durer un certain temps oui, mais pareil cela n'aura pas d'impact sur la
production (une charge supplémentaire sur le maître, forcément, mais ca
c'est inhérent à la réplication).

Si la
sauvegarde est très longue il faut plusieurs esclaves si l'on veut
cumuler redondance et sauvegarde.

Si on veut la garantie à tout instant d'avoir 2 (ou plus) instances
complètes de la base, alors oui il faudrait probablement un esclave
spécifique à la sauvegarde si on veut faire comme ca.

Oui pour ce qui est du format tu touches juste, mais pour de gros
volumes de données j'ai des souvenirs de temps de reconstruction
tellement horriblement longs (non comparable à une restitution
d'arborescence, postulant qu'on restaure l'arbo dans un environnement
compatible) que j'avais un peu mis de côté cette solution.

PostgreSQL peut exporter dans un format compressé et faire l'importation
en parallélisant sur plusieurs processeurs.

En fait il ne semble pas y avoir de solution imparable si je te suis
bien... répliction + sauvegarde d'arborescence avec les binaires qui
vont bien + dump si on veut avoir toutes les chances ça fait beaucoup !
Et comme toujours ce n'est qu'au moment de restaurer qu'on s'apperçoit
que rien ne marche... ;-)

Il faut bien spécifier le besoin : veut-on se prémunir d'une défaillance
matérielle du serveur ou d'un malencontrueux DROP DATABASE ? Quelle
granularité pour les sauvegardes, quelle périodicité, etc.
Ca fait beaucoup de paramètres, et la "bonne" solution dépend de ceux-ci.

Après effectivement une vraie bonne sauvegarde n'est qu'une sauvegarde
réellement testée en pratique, ce qui n'arrive pas toujours, enfin pas au
bon moment :-(.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>

Patrick Mevzek wrote:

Le Fri, 09 Oct 2009 14:44:57 +0200, Alarch a écrit:

Mieux vaut donc sauvegarder tout à chaque fois, avec un outil comme
rsnapshot par exemple, qui utilise des liens durs, x copies du même
fichier ne prendront que la place d'une instance.

Oui j'ai vu ça, j'ai développé tout un système de backup rsync avec liens en
dur etc. et quand ça a été fini j'ai découvert rsnapshot ! :-D, mais bon ma
solution est plus souple pour mon usage, et gère des sauvegardes sur plus
longtemps et avec une autre division des sauvegardes... on se console comme
on peu.

Oui pour ce qui est du format tu touches juste, mais pour de gros
volumes de données j'ai des souvenirs de temps de reconstruction
tellement horriblement longs (non comparable à une restitution
d'arborescence, postulant qu'on restaure l'arbo dans un environnement
compatible) que j'avais un peu mis de côté cette solution.

PostgreSQL peut exporter dans un format compressé et faire l'importation
en parallélisant sur plusieurs processeurs.

Oui pour postgres ou de gros systèmes commerciaux, encore une raison de ne
pas prendre MySQL pour les choses "sérieuses" (c'est même pas un troll,
juste une constatation).

Il faut bien spécifier le besoin : veut-on se prémunir d'une défaillance
matérielle du serveur ou d'un malencontrueux DROP DATABASE ? Quelle
granularité pour les sauvegardes, quelle périodicité, etc.
Ca fait beaucoup de paramètres, et la "bonne" solution dépend de ceux-ci.

Tout ceci va me conduire à regarder de plus près mes sauvegardes moi !

Après effectivement une vraie bonne sauvegarde n'est qu'une sauvegarde
réellement testée en pratique, ce qui n'arrive pas toujours, enfin pas au
bon moment :-(.

Oui comme les groupes électrogènes, qui ne démarrent jamais quand on en a
réellement besoins (dans les installations critiques on compte trois
groupes, un principal et deux secours au moins, et malgré les essais
périodiques et test j'ai déjà vu les trois en panne en meêm temps quand "il
fallait pas"), les sauvegardes hélas, répondent souvent aussi à cette loi
de l'emmerdement maximum.

Alarch wrote:

Ah ? pourquoi ? si la base est arrêtée c'est à mon avis la meilleure idée.

Le problème que j'ai déjà pointé, c'est le risque d'avoir des données
binaires qui seraient fortement dépendantes de l'architecture
matérielle. Par exemple, l'endianess des mots du processeur.

Cependan, pour éviter de dire n'importe quoi, je suis aller
farfouiller le code de MySQL. D'après ma lecture, il semblerait que le
problème est géré en forçant les int à etre little endian.

Finalement, avec MySQL, on peut sauvegarder la base à l'arrache.

Oui répliquer, mais il n'est pas certain que ça revienne moins cher.

Perdre toutes ces données parce que les sauvegardes ne sont plus
exploitables peut ce révéler inestimable. C'est pourquoi j me montre
aussi méfiant.

Sauf si l'on a des volumes de données énormes, mais dans ce cas là de toute
façon on ne pourra jamais réellement sauvegarder une base énorme qui
travaille beaucoup, dans un cas de ce genre il faut avoir plusieurs
serveurs de réplication, dans des sites différents avec la sécurité qui va
avec et cet ensemble de serveur constitue la sauvegarde.

Toutafé.

Qu'est-ce qui te fait dire que ton dump est plus fiable que ma copie
d'arborescence ? Du moment bien entendu que les précautions sont prises
pour soit verrouiller la base soit l'arrêter pour la recopie
d'arborescence ?

La raison principale est liée à l'interopérabilité des données. Un
fichier texte est plus interopérable qu'une série de fichiers binaires
propre à un logiciel, fusse-t-il libre.

D'ailleurs ça me fait penser, je n'ai pas regardé ça de près, mais qu'il me
semble que maintenant sur MySQL on peut avoir des logs binaires qui peuvent
être utilisés en cas de crash de la base. Est-ce que ce type de logs
pourrait être utilisés de façon analogue à un dump ?

Aucune idée.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Mickaël Wolff wrote:

Alarch wrote:

Cependan, pour éviter de dire n'importe quoi, je suis aller
farfouiller le code de MySQL. D'après ma lecture, il semblerait que le
problème est géré en forçant les int à etre little endian.

Finalement, avec MySQL, on peut sauvegarder la base à l'arrache.

Question un peu hors sujet, en dehors des systèmes IBM ou des processeurs
motorola, il y a actuellement des machines courantes qui utilisent le big
endian ?

Oui répliquer, mais il n'est pas certain que ça revienne moins cher.

Perdre toutes ces données parce que les sauvegardes ne sont plus
exploitables peut ce révéler inestimable. C'est pourquoi j me montre
aussi méfiant.

Oui c'est vrai, mais il y a tant de façon d'avoir des sauvegarde
inexploitables ! Il y a une dizaine d'années j'étais en Martinique et un
revendeur avait installé en masse des sauvegardes sur bande très cher et
avec le climat, et malgré les clims, à chaque fois les
bandes "champignonnaient" et avec cette moisissure les cassettes étaient
bonnes pour la poubelle. Pourtant le système marchait impeccablement en
métropole. Et évidemment le problème apparaît quand il faut restaurer un
dimanche matin dans un super marché avant Noël :-D

Sauf si l'on a des volumes de données énormes, mais dans ce cas là de
toute façon on ne pourra jamais réellement sauvegarder une base énorme
qui travaille beaucoup, dans un cas de ce genre il faut avoir plusieurs
serveurs de réplication, dans des sites différents avec la sécurité qui
va avec et cet ensemble de serveur constitue la sauvegarde.

La raison principale est liée à l'interopérabilité des données. Un
fichier texte est plus interopérable qu'une série de fichiers binaires
propre à un logiciel, fusse-t-il libre.

Oui ça c'est certain, d'omù l'intérêt de XML et de toutes les
solutions "texte".

Alarch wrote:

Question un peu hors sujet, en dehors des systèmes IBM ou des processeurs
motorola, il y a actuellement des machines courantes qui utilisent le big
endian ?

Très honnetment, je n'en sais rien. Je suis juste méfiant, parce que
je sais que ne pas avoir conscience des spécifications matérielles peut
amener à des horreurs (telles que l'usage de nombre flottants pour
stocker ne information monétaire (vu dans plusieurs applications « pro »
écrites en PHP/MySQL.


--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Le Thu, 08 Oct 2009 10:31:48 +0200, Alarch a écrit :

Bernard wrote:

D'abord, cette base MySQL, comment en fait on des sauvegardes ?

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 ne peux jamais l'arrêter il faut faire ce qu'on appelle une
"sauvegarde à chaud".

mon serveur MySQL, et le PC sur lequel il tourne, ne servent qu'à moi et
personne d'autre n'y accède. Les bases sur lesquelles je travaille sont
ensuite destinées à un autre serveur multi-utilisateurs, mais cet outil
là, c'est quelqu'un d'autre qui s'en occupe ; je me contente de livrer
des fichiers csv prêts à l'usage. Pour l'élaboration, la mise en forme
etc.. desdits fichiers, j'utilisais autrefois OOo_Calc (équivalent à
Excel), mais c'est devenu difficilement gérable dès l'instant où les
bases ont dépassé 65536 enregistrements (il fallait s'y prendre en
plusieurs fois, rajouter par copié/collé un fichier csv à un autre...).
D'où ma décision de m'initier à OOo_base avec MySQL. Même s'il s'agit là
sans doute d'employer de grands moyens pour quelque chose de petit, je ne
regrette pas la démarche.

Pour ce qui est des sauvegardes, je puis, en effet, arrêter mon serveur
quand je veux:

# mysqladmin --password=monpass shutdown

J'ai cependant observé une étrangeté. Si je veux redémarrer le serveur:

# /etc/init.d/mysql start (ou restart)

çà redémarre OK, mais avec l'avertissement suivant:

Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..

Ai-je raison de supposer que, dès l'instant où rien ne s'inscrit après
les deux points, la vérification n'a décelé aucune anomalie ?

Car si tu te contentais de recopier simplement l'arborescence de
/var/lib/mysql/mabase pendant qu'elle tourne, tu as un pourcentage de
chance frôlant le 100% si ta base est très sollicitée en écriture, de te
retrouver avec un état incohérent à l'arrivée (imagine que tu aies un
insert dans une table, lié avec un insert dans une autre, manque de
chance tu recopies la seconde table avant l'insert et la seconde ensuite
avec l'insert, à l'arrivée ta base est inutilisable ou à tout le moins
incohérente.



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.

J'ai un peu exploré la solution du dump. En fait c'est assez séduisant.
Cà se réalise en 3 ou 4 secondes avec ma base qui, désormais, fait
environ 140 Mégaoctets (plusieurs tables de 115 à 130,000 lignes). Je
viens d'installer un second serveur mysql sur mon portable qui tourne
sous Ubuntu Hardy Heron, et j'y ai copié le fichier dump qui a permis en
un tournemain une restauration, apparemment sans faute. Hyper rapide !
Et, s'agissant d'un fichier texte, la restauration est sans doute
possible sur n'importe quelle machine tournant sous n'importe quel OS...

Mais je me pose la question suivante : quels sont les risques de faire un
dump alors que le serveur tourne ? Il n'est pas question de l'arrèter,
car alors on n'accède plus aux commandes mysql qui permettent le dump...

Mais je me pose la question suivante : quels sont les risques de faire
un dump alors que le serveur tourne ?

Selon le SGBDR et sa version, le résultat est plus ou moins cohérent,
selon comment le SGBDR va traiter les requêtes simultanées de
modification sur les tables au moment même où elles sont exportées.

Pour le serveur en lui-même il n'y a pas de risque (si ce n'est d'être
plus lent au moment de l'exportation, et par contre coup donc de ralentir
les clients), mais les données seront donc plus au moins exploitables
selon l'activité au moment de l'opération de sauvegarde.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/prices>
<http://icann-registrars-life.dotandco.net/>