Fondamentalement, il existe deux types principaux disponibles: les snapsnots asynchrones et fsync()
. Ils sont appelés respectivement RDB et AOF. Plus d'informations sur les modes de persistance sur la page officielle .
La gestion du signal du processus démonisé se synchronise sur le disque lorsqu'il reçoit un SIGTERM par exemple, de sorte que les données seront toujours là après un redémarrage. Je pense que le démon ou le système d'exploitation doit se bloquer avant de voir une corruption d'intégrité, même avec les paramètres par défaut (instantanés RDB).
Le paramètre AOF utilise un fichier Ajouter uniquement qui consigne les commandes reçues par le serveur et recrée la base de données à partir de zéro lors du démarrage à froid, à partir du fichier enregistré. La politique de synchronisation de disque par défaut est de vider une fois toutes les secondes (IIRC) mais peut être définie pour verrouiller et écrire sur chaque commande.
L'utilisation à la fois des instantanés et du journal incrémentiel semble offrir à la fois une approche à long terme qui ne me dérange pas si je manque quelques secondes de données avec un journal incrémentiel plus sécurisé, mais coûteux. Redis prend en charge le clustering prêt à l'emploi, de sorte que la réplication peut également être effectuée.
J'utilise moi-même le paramètre RDB par défaut et j'enregistre les instantanés sur un FTP distant. Je n'ai pas encore vu de panne ayant causé une perte de données. Une panne matérielle aiguë ou une panne de courant serait très probable, mais je suis hébergé sur un VPS. Mince chance que cela se produise :)