2026 : Mac Mini loué en 7×24 — matrice SQLite WAL : écritures par lots, checkpoint, seuils fsync et fenêtre de sauvegarde nocturne

Public : équipes qui enchaînent files d’attente, workers et petits OLTP sur un Mac Mini loué en 7×24. Vous obtiendrez une matrice reliant PRAGMA, checkpoint, compromis fsync, garde-fous disque, une checklist pour la nuit et une FAQ restauration — le tout orienté stabilité longue durée sans promesse de SLA fabricant.

Pour prolonger la réflexion côté stockage et énergie : exclusions snapshot APFS, pmset, caffeinate et batch nocturne, sauvegardes MySQL et PostgreSQL.

Trois freins typiques sur SQLite WAL distant

1. Dette de checkpoint. Écritures soutenues et wal_autocheckpoint laxiste : le -wal gonfle puis un TRUNCATE dépasse le budget latence.
2. Coût fsync. Chaque palier synchronous multiplie les fsync ; les lots ralentissent sous charge mixte.
3. Sauvegardes naïves. Copier la base seule avec WAL actif donne une image incohérente sans API backup ou checkpoint calme.

Paramètres du mode WAL

Activez WAL après acceptation des fichiers satellites et d’une sauvegarde documentée. Fixez page size et journal avant charge.

• PRAGMA journal_mode=WAL;
• PRAGMA synchronous=…; — NORMAL usuel sur SSD loué.
• PRAGMA wal_autocheckpoint=N; (pages) — plus bas = checkpoints fréquents, plus de CPU.
• PRAGMA busy_timeout — évite échecs lecteurs.
• cache_size, mmap_size — surveiller RSS.

Frontières lecture-écriture concurrentes

Un écrivain, plusieurs lecteurs ; sérialisez les mutations sur une connexion.

• Transactions pour bulk ; pas d’autocommit ligne à ligne.
• IMMEDIATE/EXCLUSIVE seulement si vous contrôlez les verrous.
• Lectures longues retardent le WAL ; bornez-les ou reportez après checkpoint.
• Pool de lecteurs courts ; SQLITE_BUSY = signal à traiter.

Seuils disque APFS et stratégie de checkpoint

Couplez checkpoint aux portes disque pour garder SSH et logs utilisables.

1. Jaune ~15 % libre : réduire lots, resserrer autocheckpoint, couper lectures non critiques.
2. Rouge ~10 % : stop imports ; wal_checkpoint(PASSIVE) ; TRUNCATE après vidange écrivains.
3. Suivre octets WAL et espace libre.
4. wal_checkpoint(RESTART) dans la fenêtre nuit avec snapshots.

Matrice décisionnelle : durabilité face au débit

Chaque colonne traduit un compromis entre durabilité réellement observée et débit mesuré sur SSD local. Sur un hôte distant, documentez toujours le choix dans votre runbook pour que l’astreinte sache quoi rollback en incident.

Liste de paramètres — fenêtre de sauvegarde nocturne

Fenêtre calme ; alignez avec pmset documenté.

• Pause écrivains ou spool ≥ 10 min.
• .backup ou wal_checkpoint(TRUNCATE) après quiescence.
• Copie : snapshot ou API ; pas fichier seul à chaud.
• integrity_check après restauration.
• Logs : durée, WAL, % libre — revue hebdo.

Sauvegarde et restauration — FAQ

Un rsync à chaud sur la base et le WAL suffit-il ?

Non sans quiesce, snapshot ou API ; sinon dump ou backup intégré.

NORMAL garantit-il l’absence totale de risque ?

Non ; moins de fsync que FULL. Voir doc SQLite de votre version.

Que faire après un checkpoint partiel ou une erreur SQLITE_BUSY ?

Monter busy_timeout, ralentir écrivains, lire le retour de wal_checkpoint, couper lectures trop longues.

Feuille de route en cinq gestes pour un SQLite stable 7×24

1. Mesurer WAL/heure avant autocheckpoint.
2. synchronous par classe ; pas finance + cache dans le même fichier.
3. Alertes 15 % / 10 % libre = runbook snapshot.
4. TRUNCATE de nuit après pause écrivains.
5. Drill trimestriel restauration scratch — chrono jusqu’à base lisible.

Repères citables

• 15 % / 10 % libre APFS : portes avant gros checkpoint.
• busy_timeout ~5 s pour mix web + batch, un écrivain.
• ~20 min quiescence si WAL > ~100 Mo — ajuster.