La feuille de triche essentielle pour l'ingénierie AWS : EC2 → serveurs Lambda → faux serveurs EBS → disques durs S3 → disques durs lents VPC → cosplay de LAN IAM → permission refusée CloudWatch → "nous avons datadog à la maison"

Ne jamais exécuter de requêtes sans un délai d'expiration. Une seule requête malveillante ou un pic de charge peut entraîner des blocages ou un temps d'arrêt de l'application sans cela. Réfléchissons à pourquoi. Considérons le cas où une requête de longue durée est introduite par inadvertance dans notre application. La base de données traite généralement uniquement des requêtes de courte durée (10 ms ou moins) et soudainement, nous avons une nouvelle requête qui prend 1000 ms par exécution. Non seulement cela va monopoliser les ressources, mais cela va également faire exploser le nombre de transactions simultanées. Nous atteindrons soit les limites de connexion, soit les limites de transaction, soit nous utiliserons 100 % du CPU / IOPS de la base de données. Maintenant, considérons le même scénario, mais nous plaçons un délai d'expiration de 250 ms sur chaque transaction (côté base de données), avec une logique de réessai avec un retour exponentiel + jitter (côté application). Nous avons maintenant limité le rayon d'impact de toute requête unique. Les requêtes de longue durée seront interrompues, et la logique de retour minimise le risque de troupeaux tonitruants. En surveillant ces délais d'expiration, nous pouvons rapidement identifier la requête problématique et annuler le changement.

Le journal d'écriture anticipée (WAL) est à la fois la manière dont les bases de données s'engagent rapidement et comment elles récupèrent en toute sécurité après des pannes. En dehors des arbres B, c'est probablement la structure la plus importante dans Postgres et MySQL. (cela s'appelle le "journal de réexécution" dans le monde de MySQL)