Linuxienwow maintenant je vais devoir me faire pousser la barbe
en l'occurance c'est sortir le bazooka pour tuer la mouche, redis n'ayant aucune dépendancesBrunni (./3931) :C'est en fait une utilisation parfaitement dans l'objectif de fork(), et la raison même pour laquelle fork() existe. Le fait qu'il soit souvent utilisé conjointement à exec n'est que parce que c'est un cas d'usage très fréquent.
Je te parle plutôt sur le principe ; disons que fork convient mais ce n'est à mon avis qu'une utilisation détournée de l'outil puisque ce dont tu as besoin est seulement l'un de ses effets de bord, à savoir le copy-on-write, et même pas le fork lui-même (processus additionnel ; un thread semble bien plus indiqué pour cette tâche, comme ça pas besoin d'IPC pour savoir quand c'est terminé).
spectras (./3934) :Je pense que l'idée était bien de faire un clone de la base de données avec copie effective lors de la modification et de donner ce clone au processus léger pour qu'il l'archive.
Un thread n'est *pas* indiqué pour cette tâche, parce que pendant la sauvegarde, la base de données continue de fonctionner, et est donc modifiée. Si tu réalisais cette tâche dans un thread, soit tu obtiendrais une base de données corrompue, soit tu devrais implémenter toi-même un mécanisme de copy-on-write manuel.
spectras (./3934) :J'espère qu'il ne tente pas une nouvelle sauvegarde lorsque la précédente n'est pas terminée.
Il n'y a pas besoin d'IPC, parce que le processus de la base de données n'a pas besoin d'être averti de la fin de la sauvegarde, vu qu'il n'est pas affecté par elle.
spectras (./3934) :
Enfin, même s'il était possible de demander à l'OS de prendre un instantané et de l'écrire dans un fichier (ce que aucun OS ne permet à ma connaissance)
ça ne permettrait pas de réaliser la sauvegarde, car l'OS n'est pas capable de faire une serialization propre des structures mémoire de la base de données.
RHJPP (./3935) :Je ne vois pas en quoi ça poserait problème.
J'espère qu'il ne tente pas une nouvelle sauvegarde lorsque la précédente n'est pas terminée.
Enfin, même s'il était possible de demander à l'OS de prendre un instantané et de l'écrire dans un fichier (ce que aucun OS ne permet à ma connaissance), ça ne permettrait pas de réaliser la sauvegarde, car l'OS n'est pas capable de faire une serialization propre des structures mémoire de la base de données.
Uther (./3937) :Je ne sais pas comment ça a été fait, mais il est possible qu'une telle situation pose problème. S'il n'y a qu'un unique fichier de sauvegarde, alors la nouvelle instance se heurtera à un fichier déjà ouvert et bloqué par la précédente. Il y a ce problème même si un fichier temporaire est utilisé pendant la sauvegarde afin de ne pas altérer le dernier fichier complet tant que la nouvelle copie n'est pas complète. Si chaque sauvegarde créait un nouveau fichier, alors les performances du serveur pourraient être dramatiquement diminuées par toutes les instances de sauvegarde en cours. En effet, chaque nouvelle instance ralentirait les précédentes en cours et il existerait un seuil du rapport taille de la sauvegarde sur intervalle entre les sauvegardes à partir duquel le nombre d'instances ne ferait qu'augmenter au cours du temps. Mais il est peu probable qu'il y ait un fichier par sauvegarde car la taille occupée sur le disque serait un peu trop énorme.RHJPP (./3935) :Je ne vois pas en quoi ça poserait problème.
J'espère qu'il ne tente pas une nouvelle sauvegarde lorsque la précédente n'est pas terminée.
)
Kevin Kofler (./3942) :Bonjour "Monsieur je ne sais pas comment ça se passe dans la vie active"...
Il suffit de sauvegarder moins souvent que la durée de la sauvegarde. Si on estime que la sauvegarde durera 10 ms au maximum, on sauvegarde toutes les 60 secondes et on est tranquille.
RHJPP (./3935) :fork()
Je pense que l'idée était bien de faire un clone de la base de données avec copie effective lors de la modification et de donner ce clone au processus léger pour qu'il l'archive.
RHJPP (./3935) :Si.
J'espère qu'il ne tente pas une nouvelle sauvegarde lorsque la précédente n'est pas terminée.
RHJPP (./3939) :Non. Jamais. Parce que si ton serveur plante pendant la sauvegarde (coupure de courant par exemple), tu perds toutes tes données.
'il n'y a qu'un unique fichier de sauvegarde
spectras (./3955) :Heu et alors ? Je t'explique seulement ce que tu n'avais visiblement pas compris dans l'intervention de Brunni, qu'il était sous-entendu que le clonage était de toute façon nécessaire lors de l'utilisation de processus légers et que l'usage d'une méthode à copie effective lors de la modification est ce qu'on attend de ce clonage.
fork() Opérationn terminée. Il n'est pas besoin de faire autre chose, fork() crée un clone instantanément. Le nouveau processus sauvegarde tranquillement la base, en ayant la garantie qu'elle ne bougera pas. Pendant ce temps, l'autre processus continue d'utiliser la base comme d'habitude. Chacun a la sienne, indépendante de l'autre.
Ha oui, doubler voir plus le trafic vers le disque parce que tu as été incapable de voir qu'une sauvegarde était déjà en cours, et par conséquent compromettre les performances de ton serveur ne te dérange pas ?RHJPP (./3935) :Si. Non seulement il tente, mais ça fonctionne très bien.
J'espère qu'il ne tente pas une nouvelle sauvegarde lorsque la précédente n'est pas terminée.
Ce paragraphe ne se limite pas à une phrase. Ha ho tiens, la phrase suivante elle disait quoi en fait ?RHJPP (./3939) :Non. Jamais. Parce que si ton serveur plante pendant la sauvegarde (coupure de courant par exemple), tu perds toutes tes données.
'il n'y a qu'un unique fichier de sauvegarde
Rien que le petit cite au début de ce post montre que le mécanisme de fork() n'est pas compris par RHJPPOuais, ça montre surtout que toi t'as rien compris de la discussion. Brunni ne parlait pas de fork lui-même, mais de ce par quoi il aurait pu être remplacé pour effectuer la sauvegarde. Je répondais seulement là-dessus.
(sans animosité aucune, c'est normal de ne pas connaître quand on ne développe pas sous unix)Ce serait bien d'essayer de comprendre ce que disent les autres quand ça te semble aussi idiot (bah oui, peut-être que t'as pas compris un truc) au lieu de les prendre pour des demeurés.
C'est juste que comparer fork() et les threads quand on ne sait pas comment l'un des deux fonctionne, c'est compliqué.Pourquoi parlerait-on de remplacer les uns par les autres alors ? Juste pour le plaisir d'une discussion dépourvue de sens ?
