Revenir à des instances de bdd centralisées
Je sais que cela va contre notre modèle actuel de déploiement. Voici donc l'histoire et le pourquoi de la réflexion, et il faut que nous prenions une décision sur le sujet.
Jusqu'il y a 3 ans nous deloyons sans compose (plusieurs générations d'infrastructure) et nous avions sur chaque serveur un ou deux serveurs de bdd centraux où nous gerions les configurations et les accès.
Ça n'était pas pratique parce que cela obligeait à gérer les comptes. C'était discutable pour la sécurité comme on ne gérait pas finement les permissions des comptes, ni les quotas de ressources.
Compose est arrivé et avec lui l'habitude de déclarer un serveur de bdd par projet. Cela simplifie amplement la gestion puisque les comptes sont locaux et les erreurs beaucoup moins impactantes. Cela nous a permis de déployer plus vite et plus souvent.
Puis s'est posé la question des backups. On copiait les ressources disque en sachant que cela avait ses limites, et on les a atteintes il y un an en ayant beaucoup de mal à restaurer d'abord une base, puis en n'ayant pas les outils pour récupérer les MDP Matrix. Nous avons alors décidé de configurer systématiquement des journaux de transactions plutôt que de mener des sauvegardes full. Cela fonctionne mais nécessite de la maintenance encore pas automatisé pour checkpoint régulièrement et ne pas cumuler les journaux sur des mois.
Puis s'est posée la question de la haute dispo dans le cadre d'acides. On s'oriente là bas vers un cluster de bdd hautement disponible entre sites. Difficile de multiplier cet effort par le nombre de projets.
Se posait hier la question du debugging. Pour m'aider j'aurais pu déployer un Percona ou des outils ad-hoc sur le serveur de feeds, mais c'est très lourd et beaucoup d'efforts pour juste une base.
Je me demande (n'en suis pas encore convaincu) s'il n'est pas temps de revenir à l'ancien pattern. C'est ce que fait l'industrie cloud : on prend une base spécialisée chez aws, on arrête de piloter du conteneur avec du volume persistant.
Si on prend cette direction on pourrait l'imaginer en plusieurs étapes :
- déployer un serveur central postgres par hyperviseur (helvet en priorité)
- y configurer une réplication binaire vers le site de sauvegarde un peu plus propre que le borg des wal
- tester (!) le restore
- y gérer les permissions et y tester l'isolation
- y configurer du monitoring précis
- y migrer un à un les services, en commençant par ceux qui viennent de MySQL
- au besoin garder un ou deux petits MySQl avec des backups full simples à gérer
- dans le cadre de Acides avancer doucement vers une haute disponibilité de ce service pour pouvoir rapidement déplacer un service d'un serveur à l'autre.