Étendre les paiements Etsy avec Vitess : Partie 3 – Réduire le risque de coupure

Les paiements Etsy ont déplacé 40 milliards de lignes à travers 23 tables dans un environnement fragmenté géré par Vitess, en utilisant des vindexes pour le fractionnement des données. Cet article se concentre sur les erreurs qui peuvent survenir pendant la transition. Comprendre les modes de transaction de Vitess est crucial. Le mode unique maintient l'atomicité, mais le mode multiple peut entraîner des validations partielles. Le mode de validation en deux phases est expérimental et non recommandé. La réplication inverse VReplication assure la synchronisation des données entre les espaces de clés non fragmentés et fragmentés après la transition. Elle peut casser en raison de l'application de clés uniques, nécessitant des réparations telles que la suppression de lignes ou des mises à jour manuelles de la colonne Pos. Les requêtes de dispersion, où la clé de fractionnement est omise dans la clause WHERE, peuvent entraîner un volume de requête excessif et des pannes potentielles. Vitess propose désormais un drapeau --no_scatter pour les empêcher. Les requêtes incompatibles peuvent échouer après la transition. Des tests exhaustifs dans un environnement de développement sont essentiels pour identifier et résoudre ces requêtes. D'autres erreurs potentielles incluent celles liées aux constructions SQL non prises en charge, qui peuvent être résolues en mettant à jour vers des versions plus récentes de Vitess. Malgré ces risques, les transitions sont généralement réversibles, à condition que la réplication inverse VReplication fonctionne correctement. Cependant, l'impact de tout dysfonctionnement doit être soigneusement considéré.