KumoMTA utilise RocksDB pour le spool des files. Il survit aux plantages et aux redémarrages, mais les files d'un nœud mort restent bloquées sur le disque de ce nœud.
Deux modèles de résilience :
1. Une paire de nœuds par shard avec un stockage NVMe partagé / DRBD. Si le nœud A tombe, le nœud B monte le spool et reprend. La bascule la plus rapide, mais lourde à exploiter.
2. Actif/actif avec une brève tolérance aux envois en double. Le spool reste local. Si un nœud tombe, le nouveau mail part vers les nœuds restants. Le mail déjà dans le spool mort attend la remise en service (en général moins de 30 min sur une infrastructure moderne). Acceptez de courts retards en échange d'une résilience simple.
La plupart des ESP choisissent le n° 2. Ils gardent en plus des machines de secours prêtes à monter un snapshot depuis le stockage objet.
Sauvegardez le spool : les checkpoints RocksDB peuvent être copiés vers S3 toutes les heures. Testez la restauration sur un nouveau nœud chaque trimestre.
Connectez-vous pour garder une trace de ce que vous avez lu.