RHJPP (./3935) :
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.

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.

RHJPP (./3935) :
J'espère qu'il ne tente pas une nouvelle sauvegarde lorsque la précédente n'est pas terminée.

Si.
Non seulement il tente, mais ça fonctionne très bien.

RHJPP (./3939) :
'il n'y a qu'un unique fichier de sauvegarde

Non. Jamais. Parce que si ton serveur plante pendant la sauvegarde (coupure de courant par exemple), tu perds toutes tes données.


Enfin, j'ai le sentiment que le fonctionnement de fork() est un mystère pour beaucoup de monde. Depuis une page maintenant, il y a des incompréhensions quant au mécanisme de sauvegarde de redis. Rien que le petit cite au début de ce post montre que le mécanisme de fork() n'est pas compris par RHJPP (sans animosité aucune, c'est normal de ne pas connaître quand on ne développe pas sous unix). C'est juste que comparer fork() et les threads quand on ne sait pas comment l'un des deux fonctionne, c'est compliqué.