2026 : Mac Mini loué 7×24 — matrice Redis AOF/RDB : fenêtres de persistance, maxmemory et seuils disque

Lecture : 10 min

« Sur un Mac Mini Apple Silicon loué en 7×24, Redis partage CPU, cache disque et SSD APFS avec workers et agents : la bonne combinaison appendfsync, save et maxmemory-policy évite que persistance et jobs marathon ne se disputent la bande passante au pire moment. »

Public : équipes qui colocalisent courtier ou cache Redis avec des tâches longues. Livrable : sections Risques, comparatif de configuration (tableaux), surveillance et seuils, FAQ, guide d’achat vers achat sans connexion. Liens : matrice Celery, SQLite WAL, FAQ ligne d’eau disque.

Risques

Un hôte unique loué concentre files, journaux et persistance : trois zones où la marge disparaît vite.

  1. Réécriture AOF. BGREWRITEAOF augmente temporairement espace et I/O ; si un save RDB déclenche un fork au même créneau, les workers perdent des p99 et les heartbeats sautent.
  2. Pression mémoire. Sans maxmemory explicite et politique adaptée, RSS grimpe jusqu’au swap macOS ; une politique LRU mal choisie sur un rôle « courtier » peut évincer des clés que vous croyiez durables.
  3. Falaise disque. Instantanés APFS, couches conteneur et appendonly.aof grossissent ensemble : sous un seuil critique, la persistance devient incident majeur plutôt que routine.

Comparatif de configuration

Repères pour Redis 7 sur Apple Silicon ; validez avec votre débit d’écriture réel.

Stratégies appendfsync

appendfsync Fenêtre durabilité Profil I/O Note Mini loué
always Fsync fréquent ; perte minimale après crash brutal Charge fsync élevée ; sensible aux voisins disque Rare si workers lourds sur le même SSD
everysec Environ jusqu’à ~1 s d’écritures récentes perdues Équilibre courant charge / sûreté Point de départ typique colocalisé
no Fenêtre plus large selon noyau Moins de fsync explicites Redis Caches éphémères ou réplication externe

Règles save (RDB)

Ligne save Sens Cas d’usage
save 900 1 Snapshot si ≥1 changement en 15 min Méta peu volatile
save 300 10 10 changements en 5 min Charge modérée bornée
save 60 10000 Fort churn ⇒ snapshots fréquents Nœud cache dédié ; surveiller disque
save "" Désactive RDB automatique AOF primaire + backup orchestré

maxmemory et éviction

maxmemory-policy Comportement Bon profil
volatile-lru Éviction LRU parmi clés avec TTL Sessions / drapeaux expirables
allkeys-lru LRU sur toutes les clés au plafond Caches reconstituables
volatile-ttl Priorité aux TTL les plus proches Files sensibles au temps
noeviction Écritures refusées si plein Sémantique courtier sans perte silencieuse

Fenêtre de sauvegarde

Créneau Action Garde-fou
Avant copie BGSAVE ou save planifié ; copier dump.rdb hors machine Vérifier espace libre avant fork
Entretien AOF BGREWRITEAOF quand la file est basse Ne pas empiler RDB lourd même heure
Après copie Somme contrôle ou restauration bac à sable ≥ deux générations + copie distante

Surveillance et seuils d’alerte

Reliez métriques à actions : throttle producteurs, page humaine ou pause jobs non critiques avant blocage.

  • Mémoire. Alerte vers ~80 % du plafond maxmemory ; critique si ~90 % soutenu plusieurs minutes. Écart used_memory_rss vs used_memory ⇒ fragmentation.
  • Disque. Jaune ~20 % libre sur volume données ; rouge ~10 % ou erreurs snapshot ; suivez aussi la vitesse de remplissage.
  • Persistance. Signaler aof_rewrite_in_progress prolongé hors baseline ou durée bgsave anormale.
  • Clients. Pics blocked_clients / rejected_connections précèdent souvent cascades workers.

Cinq gestes marathon 7×24

  1. Mesurer octets/s et churn ; choisir appendfsync après profilage réel sur le SSD loué.
  2. Fixer maxmemory sous RAM physique moins OS, agents et workers ; accoupler politique au rôle.
  3. Décaler save, BGREWRITEAOF, instantanés APFS et rotation logs pour éviter doubles pics.
  4. Exporter INFO persistence ; exercice trimestriel restauration dump.rdb ou AOF réécrit.
  5. Documenter levier d’urgence : pause enqueue dès seuil jaune disque, avant lecture seule ou noyau sous pression.

Repères citables : everysec par défaut sauf preuve always ; maxmemory + politique explicite ; disque jaune ~20 % libre, rouge ~10 % ; créneaux sauvegarde disjoints des réécritures.

FAQ

AOF + RDB sur un seul Mini ?
Oui si marge disque et fenêtres nocturnes ; sinon une voie principale + copies externes réduisent chevauchement fork.
always vs everysec ?
always resserre la perte ; everysec limite fsync quand le disque sert déjà batch et brokers.
Politique pour files mélangées cache ?
Séparer instances ou DB logiques ; évitez LRU global sur données devant survivre à une pression mémoire.
Espace pour réécriture AOF ?
Prévoir duplication temporaire + snapshots ; garde absolue en Go sur petits SSD, pas seulement un pourcentage.

Guide d’achat

Dimensionnez RAM pour cap maxmemory + marge workers, SSD pour AOF, RDB et journaux, cœurs pour que persistance ne monopolise pas la socket.

  • Privilégiez stockage interne rapide plutôt que montages réseau pour chemins Redis 7×24.
  • En forte écriture, volume ou répertoire dédié aux AOF isole la concurrence avec artefacts batch.
  • Parcours public : achat.html — paiement sans connexion préalable, puis alignez unités launchd sur les créneaux ci-dessus.

Synthèse. Redis stable sur Mini loué exige fenêtres de persistance explicites, plafond mémoire honnête et tête disque avant pics. Accueil, tarifs, aide, achat sans compte.

Choisissez un nœud Mac pour Redis 7×24

Mini Apple Silicon pour Redis colocalisé et tâches longues. Accueil, tarifs, aide, achat sans compte, blog.

Voir les forfaits Louer maintenant Centre d’aide

Mac Mini loué pour persistance Redis : achat, aide, blog.

Louer un Mini pour Redis 7×24