Base de données

1. Problématique

Jusqu’à présent, nous avons utilisé une base de données dite standalone (autonome) : une seule instance démarrée sur un serveur (modèle on-premise) ou démarrée sous forme de container. Le problème est évident : il n’y a aucune tolérance aux pannes. En cas d’arrêt volontaire ou non du service, notre application eni-todo n’est plus accessible. C’est donc un SPOF que nous allons éliminer. 

Plusieurs solutions permettent d’assurer une disponibilité, avec ou sans Kubernetes. Parmi celles basées sur MySQL ou MariaDB en mode cluster, on distingue les solutions multimaîtres, où tous les serveurs sont actifs en lecture et en écriture et se synchronisent entre eux, et les solutions de type master-réplicas, où un maître accepte les écritures, et les replicas les lectures, avec une répartition des enregistrements (les shards).

On trouve par exemple les solutions Galera (multimaîtres) ou Vitess (master-réplicas).

Dans le chapitre Déploiement avec Kubernetes, nous avons présenté une ébauche de solution basée sur les StatefulSets, avec une instance MariaDB maître et un ou plusieurs réplicas. Comme il n’y a qu’un seul maître et que les réplicas sont en lecture, si on perd le maître, alors des manipulations sont nécessaires pour...