Aucune écriture acquittée laissée pour compte : l'épine dorsale de propriété et de récupération sous 12 heures de chaos

Le chemin heureux d'un store clé-valeur distribué est facile à réussir. Une écriture atterrit sur le primaire, se diffuse vers les réplicas, tout le monde est d'accord, vous passez à la suite. Si c'était toute l'histoire, la durabilité serait un problème résolu et cet article n'existerait pas.

Les problèmes difficiles vivent dans les coutures — ces moments brefs et maladroits où le cluster est en pleine transition. Un nœud redémarre au milieu d'une migration de partition. Un réplica prend beaucoup de retard sur le primaire actif qu'il copie, puis ce primaire bascule vers quelqu'un d'autre. La propriété d'une partition se déplace vers un nouveau nœud alors que des écritures sont encore en vol vers l'ancien. Chacun de ces cas est une fenêtre : une période de quelques secondes où, si le transfert n'est pas exactement correct, une écriture acquittée — une écriture dont on a dit au client qu'elle avait réussi — peut disparaître discrètement. Non pas parce que le moteur de stockage est bogué, mais parce que deux parties du système se sont contredites, un instant, sur qui possédait la vérité.

Cet article traite de la façon dont Zaris ferme ces fenêtres et — la partie qui compte réellement — de la façon dont nous nous sommes convaincus que cela fonctionne, en exécutant le cluster sous un chaos continu et délibéré pendant douze heures d'affilée.

L'affirmation, énoncée honnêtement

Soyons précis d'emblée, car c'est le genre d'affirmation qui invite à l'exagération. La garantie que nous formulons est :

Aucune écriture acquittée n'est perdue sous un chaos soutenu — arrêts, démarrages, redémarrages de nœuds, basculements, migrations de partitions et changements liés à la montée en charge — démontré par une exécution de certification continue et propre de 12 heures.

Ce n'est pas la même chose que « Zaris ne peut jamais perdre de données en aucune circonstance ». Aucun ingénieur honnête ne signe cette phrase. Ce que nous avons validé est une propriété spécifique et forte : une fois que le store a acquitté une écriture au client, cette écriture survit à tout le catalogue des défaillances de transition de propriété que nous savons provoquer, et le cluster converge ensuite vers un état cohérent. L'exécution de douze heures est une preuve de cette affirmation, et non une démonstration d'une invulnérabilité universelle.

Il y a une seconde nuance honnête qui importe à quiconque lit un journal de chaos. Pendant le chaos, vous verrez des clés transitoirement manquantes — une lecture qui ne trouve pas une clé qu'elle « devrait » trouver. C'est attendu et ce n'est pas une perte de données. Cela se produit parce que la réplication a une traîne asynchrone (l'écriture a été validée sur le primaire actif mais n'a pas atteint le réplica que vous avez justement lu), ou parce que le nœud qui détient la clé est, à cet instant, délibérément arrêté par le harnais de chaos. Ces clés réapparaissent à la convergence. Toute la discipline de la certification de durabilité consiste à séparer cette classe bénigne et auto-réparatrice de la perte réelle — une clé qu'aucun nœud survivant ne renverra jamais. L'exécution ne passe que lorsque la perte réelle est nulle. Transitoirement manquante puis récupérée est toléré ; définitivement disparue ne l'est pas.

Les trois coutures, et comment chacune est fermée

Couture 1 — le réplica bloqué

Imaginez une partition avec une copie active et un réplica. Le primaire actif tombe en panne, le réplica est promu, l'ancien primaire actif revient en tant que réplica — une bascule promotion/rétrogradation. Dans la mauvaise implémentation, le réplica fraîchement rétrogradé peut finir figé loin derrière le nouveau primaire actif : il a cessé de recevoir le flux de réplication normal pendant la bascule, et rien ne lui dit jamais de rattraper. Il reste là, périmé, prétendant être une copie valide. Si le nouveau primaire actif tombe alors en panne, vous promouvez un réplica auquel il manque des milliers d'écritures.

Le correctif est un mécanisme de rattrapage des réplicas. Un réplica détecté comme bloqué loin derrière son primaire actif — non pas simplement momentanément en retard, mais véritablement figé sous l'état du primaire actif — est identifié et resynchronisé depuis le primaire actif, au lieu d'être laissé pourrir. La subtilité clé de conception est de distinguer « retard asynchrone normal » de « bloqué » : un réplica sain est toujours un peu en retard et c'est très bien ; un réplica bloqué est en retard et ne bouge pas. C'est la seconde condition qui déclenche une nouvelle extraction.

Couture 2 — la bascule qui détruit l'unique copie

La migration est l'endroit où une partition change de propriétaire. Le nœud source remet les données de la partition à la cible, et à un moment donné il y a une bascule : la propriété bascule, et la source est désormais libre d'abandonner sa copie pour récupérer l'espace. Cette étape « libre d'abandonner » est un pistolet chargé. Si la source abandonne sa copie sur la base d'une preuve de bascule périmée — un signal qui dit « la cible l'a » alors que la cible n'a pas réellement, pleinement adopté la partition — vous venez de supprimer l'unique bonne copie de ces données.

Le correctif est la sûreté de la bascule : la source ne détruit jamais son unique copie sur une preuve périmée. Un segment que le nouveau propriétaire n'a pas, de façon démontrable, pleinement adopté est conservé, non abandonné — retenu jusqu'à ce qu'il soit véritablement sûr de le lâcher. Si la cible a encore besoin de données, la source les détient encore et peut les resservir. Le principe est simple à énoncer et facile à rater : l'abandon est l'opération dangereuse, alors faites en sorte que l'abandon prouve sa sûreté, pas l'inverse.

Couture 3 — une récupération qui réconcilie dans les deux directions

Après une tempête de changements — de nombreuses pannes empilées de près — un réplica peut finir en désaccord avec son primaire actif dans l'une ou l'autre direction. Le cas évident est d'être en retard (écritures manquées). Le cas non évident, et celui qui vous mord, est d'être en avance : pendant un rebrassage chaotique, un réplica peut détenir un enregistrement que le primaire actif courant n'a plus, par exemple une mise à jour ou une suppression qui a atteint une copie mais pas l'autre avant que la propriété ne bouge.

La récupération doit donc réconcilier dans les deux directions jusqu'à la convergence — tirer les enregistrements manquants dans un réplica en retard, et réconcilier en supprimant les enregistrements en trop sur un réplica en avance — jusqu'à ce que le primaire actif et le réplica s'accordent. Une réconciliation qui ne corrigerait jamais que le « en retard » laisserait la divergence « en avance » installée là pour toujours.

Une décision de conception à l'intérieur de cela mérite d'être soulignée, car c'est le genre de chose qui distingue un mécanisme qui marche dans une démo d'un qui survit douze heures. La réconciliation côté leader réutilise les décomptes d'état de synchronisation que le cluster suit déjà. Elle ne monte pas un nouveau réseau de détection qui diffuse des sondes à travers les nœuds, et elle reste hors du chemin critique de validation de carte — le chemin critique par lequel transite déjà chaque changement de propriété. Réutiliser un signal existant signifie que la réconciliation n'ajoute aucun nouveau mode de défaillance propre ni aucune nouvelle latence aux opérations qui étaient déjà les plus délicates. Le détecteur fiable le moins coûteux est celui que vous avez déjà.

La forme de la chose

Mettez les trois coutures ensemble et l'histoire de la durabilité est un seul flux : une écriture est acquittée, le chaos survient, et chaque mécanisme attrape la défaillance correspondante avant qu'elle ne puisse se transformer en perte.

Le chemin en pointillés est la branche de la nuance honnête : les clés transitoirement manquantes qui se résolvent d'elles-mêmes. Elles convergent elles aussi ; elles n'ont simplement jamais compté comme une perte au départ.

Comment nous le savons réellement : la certification de 12 heures

Un argument de conception est une hypothèse. Le test est la preuve. Nous exécutons donc une certification de chaos continue de 12 heures face à un cluster en direct, et la barre est propre — dès l'instant où elle ne l'est plus, l'exécution a trouvé un bug et nous allons le corriger plutôt que de livrer.

Ce que « chaos » signifie concrètement, soutenu pendant toute la durée :

• Changement aléatoire de nœuds — nœuds arrêtés, démarrés et redémarrés en continu, de sorte que le cluster n'est pour ainsi dire jamais dans un état pleinement stabilisé.
• Basculements — primaires actifs tués sous leurs partitions, forçant des promotions.
• Migrations de partitions — propriété se déplaçant entre nœuds pendant que la charge de travail s'exécute.
• Changements liés à la montée en charge — l'appartenance au cluster elle-même change sous charge.

Face à tout cela s'exécute une charge de travail qui vérifie en continu deux choses indépendantes. Une suite vérifie la convergence du plan de données : elle pilote de vraies écritures, suit ce qui a été acquitté et vérifie que chaque écriture acquittée est encore récupérable une fois le cluster convergé — avec cette distinction transitoire-contre-réelle appliquée rigoureusement, de sorte qu'une clé manquante parce que son nœud est actuellement arrêté n'est pas comptée comme une perte, tandis qu'une clé qu'aucun nœud ne renverra jamais l'est. L'autre suite vérifie la stabilité de l'API : que les API de contrôle et de données continuent de se comporter correctement tout au long du changement, pas seulement que les octets survivent.

L'exécution ne passe que lorsque les deux suites sont propres pendant les douze heures entières : la convergence tient dans les deux directions, aucune perte de données réelle, aucun réplica laissé en échec, aucune partition laissée avec le mauvais propriétaire. C'est le résultat que le travail sur l'épine dorsale a été conçu pour produire, et c'est le résultat que l'exécution d'endurance a démontré — des millions d'opérations acquittées à travers un chaos soutenu, une perte réelle de zéro, chaque événement de clé transitoirement manquante expliqué par les cas bénins de traîne asynchrone / nœud arrêté et résolu à la convergence.

Douze heures est une durée délibérée. Une heure de chaos vous dit que les transitions courantes fonctionnent. Les entrelacements rares et vilains — le redémarrage qui tombe exactement pendant une bascule, le second basculement avant la fin de la première récupération — sont de faible probabilité par événement, de sorte que vous n'en accumulez assez pour faire confiance au système qu'en laissant les dés rouler longtemps. Les coutures sont, presque par définition, les états dans lesquels le cluster passe le moins de temps. Vous devez rester dans la tempête assez longtemps pour continuer à les frapper.

Pourquoi cela importe si vous exécutez Zaris

Si vous exploitez un store de données, vous savez déjà que les pannes qui font mal ne sont pas les propres. Un nœud qui meurt proprement et reste mort est le cas facile. Les incidents coûteux sont les chevauchements désordonnés — un déploiement roulant les nœuds pendant qu'un rééquilibrage est en vol, un hoquet réseau qui déclenche un basculement entrant en concurrence avec une migration. Ce sont exactement les coutures dont traite ce travail.

Le point pratique à retenir est que Zaris traite la transition de propriété — promotion, rétrogradation, migration, récupération — comme une partie de première classe de l'histoire de la durabilité, et non comme une réflexion après coup boulonnée sur un moteur de stockage. Une écriture acquittée est conçue pour survivre aux transferts, l'abandon d'une copie est conçu pour prouver sa propre sûreté avant qu'il ne se produise, et la récupération est conçue pour ramener un réplica divergent à l'accord, quelle que soit la direction dans laquelle il a dérivé. Et l'affirmation est étayée par des tests d'endurance au chaos continus, avec la portée honnête énoncée clairement : aucune écriture acquittée perdue sous une panne soutenue, validée empiriquement — et non une promesse magique que les données ne peuvent jamais mal tourner.

Si vous voulez la mécanique de la façon dont les partitions, les primaires et les réplicas s'emboîtent sous tout cela, commencez par Partitionnement et réplication et le concept de Réplica dans la documentation. L'épine dorsale décrite ici est ce qui maintient ces pièces honnêtes quand le cluster passe sa pire journée.