Bases de données

En commander une, ce à quoi chaque disposition survit, et pourquoi la réplication n'est pas une sauvegarde.

Une base de données gérée se commande séparément de toute application, parce qu'elle leur survit. Vous redéploierez une application cent fois contre la même base de données.

La plateforme la crée, la maintient en service, applique les correctifs et vous remet les identifiants une seule fois. Ce qu'elle contient vous appartient.

Choisir une disposition

Il y en a trois, et chacune ajoute exactement une capacité à la précédente.

Simple. Une seule copie. Ce qu'il y a de moins cher qui soit encore une base de données. Pas de bascule : si la machine qui l'héberge tombe, la base est injoignable jusqu'à son retour. Adaptée au développement et à la préproduction, où une interruption n'est qu'un désagrément.

Simple avec pool de connexions. La même copie unique, précédée d'un pool de connexions. Elle résiste à un afflux de clients, mais pas à la perte de sa machine. Choisissez-la quand votre application ouvre de nombreuses connexions de courte durée — ce que font la plupart des frameworks web — et que vous ne payez pas encore pour la disponibilité.

Haute disponibilité. Plusieurs copies, dont l'une est la primaire et accepte les écritures pendant que les autres la suivent. Si la primaire tombe, une autre prend le relais et votre application se reconnecte à la même adresse. C'est la seule disposition qui survit à la perte d'une machine.

Pourquoi le nombre de copies est impair

Trois ou cinq, jamais deux ou quatre. Décider quelle copie est aux commandes exige l'accord d'une majorité. Un nombre pair peut se couper en deux et ne s'accorder sur personne — ce qui rend deux copies moins disponibles qu'une seule, car la moindre panne ne laisse aucune majorité et la base cesse d'accepter les écritures pour éviter de se corrompre.

Se connecter

Vous recevez une seule adresse. Utilisez-la, et rien d'autre. Elle reste valable quand la primaire change, et c'est tout l'intérêt : votre application ne devrait jamais savoir ni se soucier de quelle copie est aux commandes.

Les identifiants sont affichés une seule fois, à la création de la base ou à l'ajout d'un utilisateur. Ils ne peuvent plus être récupérés ensuite. Si vous les perdez, créez-en de nouveaux.

Les sauvegardes ne sont pas de la réplication

Ce point mérite son propre titre, car c'est le malentendu le plus coûteux de ce document.

La réplication copie chaque écriture sur chaque copie, fidèlement et immédiatement. Y compris l'écriture que vous ne vouliez pas faire. Une table supprimée, un DELETE avec une mauvaise condition, une migration lancée sur la mauvaise base — tout cela est parfaitement répliqué sur chaque copie en quelques instants.

La réplication vous protège de la panne du matériel. Les sauvegardes vous protègent des erreurs des personnes et des logiciels. Ce sont des problèmes différents, qui demandent des mécanismes différents. Il vous faut les deux.

Les sauvegardes ne sont pas activées par défaut. Activez-les, choisissez l'heure, et vérifiez une fois qu'une restauration fonctionne avant d'en avoir besoin.

Cas particuliers à connaître avant d'y être confronté

La base indique qu'elle tourne, mais votre application ne peut pas s'y connecter. Une instance est marquée comme en service dès que ses éléments sont créés, un peu avant que l'une des copies ait été élue primaire. Pendant la première demi-minute environ, c'est optimiste. Réessayez.

Les connexions sont refusées sous la charge. Une base de données accepte un nombre fixe de connexions. Une application avec de nombreuses copies, chacune ouvrant son propre pool, les épuisera bien avant que la base soit réellement occupée. Utilisez la disposition avec pool de connexions, et réduisez la taille du pool dans votre application — une application web n'a presque jamais besoin de la valeur par défaut livrée avec son framework.

Une bascule a eu lieu et des transactions en cours ont échoué. C'est normal. Tout ce qui n'était pas validé à la mort de la primaire est perdu ; une promotion ne peut pas inventer le résultat d'une transaction que personne n'a terminée. Les applications importantes devraient réessayer une transaction échouée plutôt que de supposer qu'elle a réussi.

Une bascule a eu lieu et une écriture très récente manque. Les copies suivent la primaire avec un léger retard. Si la primaire tombe dans cet intervalle, l'écriture qu'elle a confirmée peut ne pas avoir atteint la copie qui a pris le relais. L'intervalle est court, mais il n'est pas nul. Si votre application ne peut absolument pas le tolérer, dites-le avant de commander — le compromis est des écritures plus lentes contre aucune perte, et il doit être choisi délibérément.

Une copie est très en retard. C'est généralement une requête de longue durée sur cette copie, ou une rafale d'écritures plus importante que ce que le lien peut transporter. Elle rattrape son retard d'elle-même. Une copie trop en retard n'est pas promue lors d'une bascule, car la promouvoir ferait perdre davantage que l'autre option.

Le disque est plein. Tout s'arrête, y compris la possibilité de supprimer des lignes — ce qui nécessite d'écrire. Surveillez la taille ; n'attendez pas.

Vous avez supprimé la base de données. Elle a disparu, et tout ce qu'elle contenait avec. La confirmation est volontairement fastidieuse.

Pour continuer