Unité 5.3 : Bases de données relationnelles (Managed PostgreSQL / MariaDB)

Introduction

La couche relationnelle est le lieu où se concentrent les décisions de conception les plus déterminantes de FinCorp. Le grand livre d'une banque ne peut pas perdre silencieusement des transactions validées, mais une couche qui bloque les écritures chaque fois qu'un nœud présente un dysfonctionnement constitue à elle seule une forme d'interruption de service. Les services de base de données gérés vous permettent de régler avec précision ce curseur entre durabilité et disponibilité, à condition de comprendre ce que chaque paramètre garantit et quelles commodités la plateforme ne propose délibérément pas. Cette unité aborde les décisions relatives à la réplication, à la mise à l'échelle, au basculement, à l'accès et à la récupération, puis construit le cluster relationnel de FinCorp dans Data Center Designer en intégrant ces décisions.

Le cadrage honnête revêt ici une importance plus grande que d'habitude. Il n'existe ni répliques en lecture, ni produit de basculement géré, et le Backup Service n'interagit pas avec une base de données gérée. Chaque lacune dispose d'un motif natif qui s'articule autour d'elle, et un architecte qui traite ces éléments comme des entrées de conception plutôt que comme des fonctionnalités manquantes obtient une couche de données plus propre et plus prévisible.

1. La décision du mode de réplication

Un cluster PostgreSQL managé est un nœud principal avec un total de un à cinq instances, soit jusqu'à quatre nœuds secondaires. Le mode de réplication régit le contrat entre une transaction validée et sa durabilité sur ces nœuds, et c'est la décision unique qui définit le RPO du cluster. PostgreSQL prend en charge deux modes actuels : Asynchrone (par défaut) et Strictement synchrone. Un troisième mode, le Synchrone non strict, est obsolète pour les nouveaux clusters et ne doit pas être choisi ; les clusters existants qui l'utilisent peuvent être passés en mode asynchrone ou strictement synchrone via l'API du mode de réplication.

Asynchrone confirme une transaction dès qu'elle est écrite sur le disque du nœud principal ; la réplication vers les nœuds secondaires se produit en arrière-plan, avec un retard typique de quelques millisecondes. L'avantage est la latence d'écriture la plus faible. Le coût est un RPO non nul : si le nœud principal tombe en panne avant qu'un engagement récent ait été répliqué, cet engagement est perdu lors de la promotion d'un nœud secondaire. Le pire cas documenté pour le chemin de sauvegarde est la perte de jusqu'à 30 minutes ou 16 Mo de données si toutes les répliques perdent leurs données simultanément, car les données archivées sont expédiées par tranches de 16 Mo ou toutes les 30 minutes, selon ce qui survient en premier. Sur un cluster multi-nœuds sain, l'exposition réaliste est de quelques millisecondes de transactions en cours, mais le point architectural demeure : le mode asynchrone échange une petite fenêtre de perte de données bornée contre la disponibilité et la latence.

Strictement synchrone retient la validation jusqu'à ce qu'au moins un nœud secondaire synchrone ait la transaction, de sorte qu'aucune donnée validée n'est perdue lors d'une bascule, y compris en cas de défaillance du stockage du nœud principal avec une perte simultanée de tous les nœuds secondaires. Le prix se paie en deux endroits. La latence subit un surcoût constant par transaction, car chaque COMMIT attend désormais la réplication (la latence inter-nœuds est généralement inférieure à 1 ms, mais ajoutée à chaque écriture). Plus important encore, ce mode sacrifie la disponibilité au profit de la durabilité : si aucun nœud secondaire synchrone n'est disponible, le nœud principal cesse d'accepter les écritures plutôt que de continuer sans protection. Pour l'exploiter en toute sécurité, il faut donc un minimum de trois instances, afin que la perte d'un nœud laisse encore un nœud principal et un nœud secondaire synchrone. Provisionner moins de nœuds est le piège classique, car une défaillance d'un seul nœud secondaire arrête alors toutes les écritures.

Le tableau suivant, issu de la documentation, met en contraste les deux modes qui doivent être utilisés en production :

PostgreSQL permet également de modifier les garanties de validation par transaction, et l'asymétrie est importante : vous ne pouvez pas imposer une validation synchrone sur un cluster asynchrone (sans nœud secondaire synchrone, tout paramètre plus strict se réduit à la validation locale), mais vous pouvez exécuter un cluster strictement synchrone et assouplir des transactions individuelles à synchronous_commit=local là où une petite perte de données est acceptable. La valeur par défaut défendable est donc de configurer le cluster avec la garantie la plus stricte dont la charge de travail a besoin et d'assouplir sélectivement, et non l'inverse.

MariaDB supprime cette décision entièrement. Managed MariaDB est uniquement asynchrone : un seul mode de réplication, le mode par défaut. C'est une décision de périmètre, et non un défaut à contourner. MariaDB fonctionne sur des Virtual Servers (et non des instances Cube), utilise le stockage SSD Premium avec les moteurs InnoDB, MyISAM ou Aria, et n'offre que des versions LTS, actuellement à partir de 10.6. Si une charge de travail de FinCorp a réellement besoin de validations sans perte de données, elle doit être sur PostgreSQL en mode strictement synchrone, et non sur MariaDB. Le choix du moteur est donc en partie une décision de durabilité, et non seulement de dialecte SQL.

1.1 Ce que la bascule automatique fait à l'intérieur d'un cluster

La bascule à l'intérieur d'un seul cluster est automatique et n'a besoin d'aucun produit externe. Lorsque le nœud principal devient indisponible, un nœud secondaire est promu. En mode asynchrone, tout nœud secondaire peut être promu et les transactions non répliquées sont perdues ; en mode strictement synchrone, seul un nœud secondaire détenant toutes les transactions confirmées est éligible, ce qui est la raison pour laquelle le mode ne peut pas perdre de données validées. Au plus un nœud secondaire synchrone existe à la fois, et s'il tombe en panne, un autre est automatiquement élevé au rôle synchrone. Cette promotion intra-cluster est l'intégralité de la bascule managée de la plateforme pour une base de données : elle protège contre la perte de nœuds à l'intérieur d'un seul cluster, et non entre clusters ou régions.

2. Mise à l'échelle des lectures sans répliques de lecture

Les serveurs secondaires PostgreSQL existent pour la haute disponibilité, et non pour traiter le trafic de lecture. Il n'y a aucune réplique de lecture : vous ne pouvez pas diriger le trafic de rapports ou les requêtes intensives en lecture vers un serveur secondaire, et il n'existe pas de point de terminaison en lecture seule géré. Il s'agit d'une limite stricte de la plateforme, et le modèle natif qui la remplace comporte deux volets.

Premièrement, une limite de connexions qui est dérivée, et non choisie. Le nombre maximal de connexions à un cluster PostgreSQL est calculé à partir de la taille de la RAM et n'est pas configurable par l'utilisateur. La correspondance documentée est la suivante :

Parmi celles-ci, 11 connexions sont réservées à l'usage système, de sorte que le budget utilisable par l'application est la valeur du tableau moins onze. La conséquence est qu'il est impossible de résoudre une tempête de connexions en modifiant un paramètre ; les seuls leviers sont une augmentation de la RAM (jusqu'à la limite de 1000 connexions) ou une réduction du nombre de connexions réelles. Pour un parc de microservices ou une interface front-end serverless qui ouvre bien plus de connexions logiques que la limite ne le permet, la solution est le pooling.

Deuxièmement, le pool de connexions géré (pgbouncer). Vous pouvez l'activer sur le cluster ; la seule chose que vous configurez est le mode du pool. Le mode Transaction (par défaut) restitue la connexion au pool à la fin de chaque transaction, ce qui multiplexe de nombreuses connexions clients sur un petit nombre de connexions backend, et constitue le bon choix pour le trafic web et microservices typique. Le mode Session maintient la connexion backend jusqu'à la déconnexion du client, ce qui n'est nécessaire que lorsqu'une session dépend d'un état lié à la connexion, tel que des variables de session ou des instructions préparées qui doivent persister. Le pool écoute sur un port différent : 6432 au lieu du port par défaut 5432 de la base de données, de sorte que son activation implique également une modification de la configuration du client, et non une bascule transparente. Les applications doivent être dirigées vers le port 6432 pour en tirer parti.

La mise à l'échelle des lectures à proprement parler est résolue un niveau au-dessus, dans le cache. Étant donné que les serveurs secondaires ne peuvent pas servir les lectures, le modèle de mise à l'échelle des lectures de la plateforme est le cache In-Memory DB (Unité 5.5) placé devant la couche relationnelle sur le réseau privé, combiné au pooling pour protéger le budget de connexions. Les lectures fréquentes sont absorbées par le cache, le primaire relationnel gère les écritures et les lectures en cas de manquement au cache, et le pooling maintient le nombre de connexions sous la limite dérivée de la RAM. Cette composition cache-plus-pooling est ce que signifie « mettre à l'échelle les lectures » sur cette plateforme, et c'est pourquoi l'Unité 5.5 est une dépendance directe de tout service FinCorp à forte intensité de lecture, et non une option facultative.

3. Reprise sur incident entre clusters et accès privé

La promotion intra-Cluster (section 1.1) est le seul mode de reprise sur incident géré. Il n'existe aucun produit de reprise sur incident géré qui s'étend sur plusieurs clusters ou régions, et, plus important encore, il n'existe aucune réplication de base de données native inter-régions ou inter-clusters. Si FinCorp a besoin d'une continuité au-delà d'un seul Cluster, cette continuité est conçue, et elle est pilotée, non répliquée, au niveau de la base de données.

Le modèle natif inter-clusters est la reprise sur incident DNS orchestrée par le client (construit en Unité 3.7, réexaminé pour la résilience en Unité 7.1). Deux clusters indépendants sont mis en place, maintenus synchronisés par l'application ou par des opérations de dump/restore périodiques, et une vérification d'état externe redirige un enregistrement Cloud DNS à TTL faible vers le point de terminaison sain. Cloud DNS lui-même n'est pas conscient de l'état ; il sert l'enregistrement que vous définissez. Deux propriétés guident la conception : DNS ne pilote que les nouvelles connexions, si bien que les sessions existantes ne migrent pas et que l'application doit se reconnecter proprement ; et le temps de récupération est dominé par le plancher de TTL de l'enregistrement de reprise sur incident, le levier que vous réglez pour le RTO. Comme le second cluster est une base de données distincte, il s'agit d'un mécanisme de disponibilité avec son propre RPO, régi par la manière dont vous maintenez les deux synchronisés, et non d'un miroir à perte nulle.

L'accès est limité aux points de terminaison privés. Un cluster géré n'a pas d'IP publique ; il n'est accessible que depuis l'intérieur du centre de données virtuel via un LAN privé. Lors de la création, vous sélectionnez un centre de données, un LAN et une IP privée. Les connexions sont protégées par TLS par défaut : le mode SSL est prefer et ne peut pas être désactivé par le client, le certificat du serveur étant émis par une autorité de confiance. Plusieurs plages CIDR internes sont réservées par la plateforme et ne peuvent pas être utilisées pour l'IP privée du cluster. L'avantage est que la couche de données se situe derrière l'équilibreur de charge privé de couche 4 de l'architecture en couches canonique (Unité 1.2), n'est jamais exposée à Internet, et n'est atteinte que par la couche d'application et le cache.

4. Migration et récupération : Dump/Restore et PITR

Deux faits définissent le plan de continuité des données pour les bases de données relationnelles managées, et les deux constituent des contraintes à prendre en compte lors de la conception.

Le Backup Service ne couvre pas les bases de données managées. Le Backup Service basé sur Acronis effectue la sauvegarde des VM et du Block Storage, mais pas du DBaaS, et les instantanés du Block Storage correspondent à un retour arrière au niveau de la VM, et non à des sauvegardes cohérentes au niveau de la base de données. La continuité des données s'appuie uniquement sur deux mécanismes natifs : la récupération point-in-time managée, et le dump/restore logique.

La récupération point-in-time est le filet de sécurité sur place. Le service managé combine des sauvegardes de base périodiques avec l'archivage continu du Write-Ahead Log, de sorte qu'une sauvegarde représente une plage de temps plutôt qu'un instant unique. Les sauvegardes sont créées lors de la création d'un cluster, lors de l'augmentation de sa version majeure, et lors de l'exécution d'une opération PITR ; elles sont stockées chiffrées dans un bucket IONOS Cloud Object Storage de la même région (les bases de données situées dans une région sans Object Storage sont sauvegardées dans eu-central-2). La rétention est par défaut de 7 jours et peut être configurée de 1 à 365 jours via l'API v2 ; sa réduction purge les sauvegardes plus anciennes que la nouvelle fenêtre. Une restauration cible un horodatage ISO-8601 non inclusif recoveryTargetTime, ne peut utiliser qu'une sauvegarde de la même version majeure ou d'une version antérieure, exige que le cluster soit AVAILABLE, peut déplacer la base de données vers une autre région, et rend la base de données indisponible pendant la durée de l'opération (le service recommande au moins 4 Go de RAM pendant une restauration, avec un retour à la configuration initiale par la suite). Considérez la fenêtre par défaut de 7 jours comme une échéance : si la politique d'audit de FinCorp nécessite une récupérabilité plus longue, augmentez explicitement la rétention lors de la conception, plutôt que de découvrir cette lacune pendant un incident.

Le dump/restore est le seul chemin de migration en entrée ou en sortie. Il n'existe ni assistant d'importation managé, ni migration basée sur la réplication vers le service. Le déplacement d'une base de données PostgreSQL existante sur la plateforme, ou depuis celle-ci, utilise les outils logiques standards pg_dump, pg_restore, et psql ; pour MariaDB, l'équivalent est mariadb-dump. Les contraintes découlent de la règle des points d'accès privés : comme le cluster cible n'est accessible que depuis l'intérieur du VDC, la restauration doit s'exécuter depuis un hôte sur le LAN privé du cluster (par exemple, une VM de saut dans la couche applicative), et le basculement entraîne une indisponibilité réelle proportionnelle à la taille du jeu de données pendant le chargement du dump. C'est l'entrée relationnelle du plan de migration de l'Unité 7.4, où la vague des bases de données est la vague dump/restore. Planifiez-la comme une opération dimensionnée et planifiée, et non comme une synchronisation en arrière-plan.

Une mise en garde concernant les identifiants a un poids réel : les identifiants utilisateur définis lors de la création du cluster sont les seuls établis par le chemin de création, et ils ne sont configurables qu'une seule fois. Capturez-les dans le coffre-fort de secrets lors de la provisionnement, car il n'existe pas de chemin de réinitialisation pratique par la suite.

Déroulement de la mise en œuvre de DCD

Vous allez maintenant créer le cluster relationnel de FinCorp : un cluster privé PostgreSQL multi-nœuds sur le VDC existant de FinCorp, avec un mode de réplication délibéré, une fenêtre de maintenance réelle et un chemin de connexion privé vers le LAN de l'application. Cela met en œuvre la décision relative à la couche de données des sections 1 à 3. La condition préalable est un VDC existant doté d'un LAN privé déjà utilisé par la couche applicative (la topologie de l'Unité 3.1) ; le Cluster se connectera à ce LAN avec une IP privée que vous choisissez pour éviter la plage DHCP.

Objectif de construction : Créer un cluster privé multi-nœuds avec mode de réplication, fenêtre de maintenance et détails de connexion.

Étapes (dans Data Center Designer) :

1. Ouvrir Menu > Bases de données > PostgreSQL. L'aperçu affiche les ressources allouées à votre contrat et le nombre utilisé ; vérifiez qu'il reste de la marge avant de créer le Cluster.
2. Cliquez sur Créer un cluster. Fournissez un Nom du cluster qui encode l'environnement et la couche de FinCorp, et sélectionnez l'Emplacement (région) qui satisfait à la décision de résidence prise dans l'Unité 1.4. La région est une décision de placement, pas quelque chose à reconsidérer plus tard.
3. Choisissez la version PostgreSQL parmi l'ensemble pris en charge (actuellement 14, 15 ou 16). Sélectionner une version majeure actuelle garantit la plus longue période de mise à niveau.
4. Sélectionnez le Mode de réplication. Pour la charge de travail de niveau comptable de FinCorp, choisissez Strictement synchrone et assurez-vous que le nombre d'instances à l'étape suivante est d'au moins trois, afin qu'une perte unique d'un serveur secondaire n'interrompe pas les écritures. Pour les services sensibles à la latence et tolérants aux pertes, laissez-le sur Asynchrone. Ne sélectionnez pas le mode synchrone non strict obsolète.
5. Définissez l'Emplacement de sauvegarde (région). Vous pouvez placer les sauvegardes dans une région différente de celle de la base de données pour une protection hors site ; prenez cette décision en fonction des exigences d'audit et de résidence, plutôt que d'accepter aveuglément la valeur par défaut.
6. Dans la Configuration des instances, définissez les CPU et la RAM par instance (n'oubliez pas que la limite de connexions est dérivée de la RAM), choisissez un Type de stockage (SSD Premium est la valeur par défaut ; conservez-le pour la charge de travail de la base de données, et notez que le SSD en dessous d'environ 100 Go n'est pas recommandé), et saisissez la Taille du stockage. Réglez le nombre d'instances de sorte qu'un cluster strictement synchrone ait trois nœuds ou plus.
7. Dans la Configuration réseau, sélectionnez le Centre de données, le LAN du centre de données utilisé par la couche applicative, et une IP privée. Il n'y a pas de point d'accès public. Pour trouver une IP privée sûre, notez que le DHCP du LAN utilise un /24, donc réutilisez les trois premiers octets du sous-réseau applicatif et choisissez une adresse se terminant entre .3 et .10, que le DHCP n'attribue jamais, pour éviter un conflit.
8. Dans la Période de maintenance, choisissez un Jour et une Heure de début (UTC). Choisissez un créneau à faible trafic réel, car la maintenance s'exécute dans une fenêtre de 4 heures à partir de cette heure de début. Laisser cela sans contrainte effective invite à des travaux perturbateurs pendant les heures ouvrables.
9. Dans la Création d'utilisateur, définissez le Nom d'utilisateur et le Mot de passe initiaux. Ce sont les identifiants avec lesquels le Cluster est créé ; capturez-les immédiatement dans le magasin de secrets, car le chemin de création est l'endroit prévu pour les définir.
10. Créez le Cluster. Une fois qu'il atteint le statut DISPONIBLE, connectez-vous depuis un hôte sur le même LAN privé en utilisant l'IP privée attribuée ou le nom DNS renvoyé sur le port 5432. Si vous activez plus tard le pooler géré (pgbouncer), redirigez les clients vers le port 6432 et choisissez le mode transaction, sauf si une fonction à portée de session impose le mode session.

Erreurs courantes :

• Provisionner un cluster strictement synchrone avec moins de trois instances. Avec un seul serveur secondaire, une défaillance unique du serveur secondaire arrête toutes les écritures, car le mode strict refuse d'abandonner la réplication synchrone. Dimensionnez à trois nœuds ou plus avant de choisir le mode strict.
• Choisir le mode synchrone non strict obsolète pour un nouveau Cluster. Utilisez Asynchrone ou Strictement synchrone ; le mode intermédiaire ne garantit pas la durabilité multi-nœuds dans toutes les circonstances et n'existe que comme chemin hérité.
• Attribuer au Cluster une IP privée dans la plage DHCP. Les conflits cassent la connectivité de manière intermittente ; réutilisez les trois premiers octets du LAN et choisissez une adresse se terminant entre .3 et .10.
• Définir une fenêtre de maintenance pendant les heures ouvrables, ou la traiter comme cosmétique. La maintenance s'exécute dans une fenêtre de 4 heures à partir de l'heure de début que vous choisissez ; choisissez un créneau hors pointe réel.
• S'attendre à ce que les serveurs secondaires servent le trafic de lecture ou constituent un point d'accès de lecture géré. Il n'y a pas de répliques de lecture ; scalez les lectures avec le cache In-Memory DB et le pooler pgbouncer, et n'oubliez pas que le pooler est sur le port 6432.
• Supposer que le Backup Service ou une capture d'écran Block Storage protège la base de données. Aucun ne couvre DBaaS. La continuité de la base de données est la PITR (rétention par défaut de 7 jours, définie délibérément) plus la sauvegarde/restauration.
• Perdre les identifiants initiaux de la base de données. Ils sont définis une seule fois sur le chemin de création, sans réinitialisation pratique ; stockez-les au moment du provisionnement.

Une illustration courte côté client des deux faits qui mènent le plus souvent à l'erreur, le point d'accès privé et le port du pooler :

# Direct connection (port 5432), from a host on the cluster's private LAN
psql -h pg-xxxxxxxx.postgresql.de-fra.ionos.com -U fincorp_app -d ledger

# Through the managed pooler (transaction mode): same host, port 6432
psql -h pg-xxxxxxxx.postgresql.de-fra.ionos.com -U fincorp_app -d ledger --port=6432

Résumé

La couche relationnelle gérée concentre les décisions de durabilité de FinCorp : le mode de réplication de PostgreSQL définit le RPO du Cluster (asynchrone pour les charges de travail à faible latence tolérant la perte de données ; strictement synchrone avec trois nœuds ou plus pour une perte nulle des données validées ; jamais le mode non strict obsolète), tandis que MariaDB supprime ce choix en étant uniquement asynchrone. La mise à l'échelle en lecture ne se fait pas avec des répliques, qui n'existent pas, mais avec un cache In-Memory et le pooler pgbouncer face à une limite de connexions dérivée de la RAM. Le basculement est automatique au sein d'un Cluster et orchestré entre Clusters grâce à des vérifications d'état DNS. L'accès est limité aux points d'entrée privés, et la continuité est assurée par la PITR et les opérations dump/restore, car le Backup Service ne couvre pas les bases de données. Le build DCD engage ensuite ces choix dans un Cluster réel.

Points clés :

• Le mode de réplication PostgreSQL est le réglage du RPO : Asynchrone (par défaut) accepte une fenêtre de perte bornée pour la latence ; Strictement Synchrone ne perd aucune donnée validée mais exige un minimum de trois nœuds et arrête les écritures si aucun nœud de secours synchrone n'est disponible. Le mode Synchrone non strict est obsolète ; MariaDB est uniquement asynchrone.
• Il n'y a pas de répliques de lecture. Mettez à l'échelle les lectures avec le cache In-Memory et le pooler pgbouncer géré (mode transaction par défaut, port 6432) ; la limite de connexions est dérivée de la RAM (jusqu'à 1000, moins 11 réservées) et n'est pas configurable.
• Le basculement est automatique au sein d'un Cluster (promotion du nœud de secours) ; le basculement inter-Clusters est orchestré par un re-pointage Cloud DNS à TTL faible, piloté par une vérification d'état externe, qui ne dirige que les nouvelles connexions et dont le plancher de TTL détermine le RTO.
• Les Clusters sont limités aux points d'entrée privés, avec TLS imposé (prefer, non désactivable côté client), et doivent être assignés une IP privée hors de la plage DHCP.
• Le Backup Service ne couvre pas le DBaaS. La continuité est assurée par la PITR (rétention par défaut de 7 jours, réglable de 1 à 365 jours) et par dump/restore (pg_dump/pg_restore/psql, ou mariadb-dump), exécutés depuis un hôte sur le LAN privé du Cluster ; c'est le chemin de migration à l'entrée et à la sortie.

Terminologie importante :

• Réplication Strictement Synchrone : Un commit n'est confirmé qu'après que le nœud de secours synchrone l'a conservé, et le nœud principal refuse les écritures plutôt que de fonctionner sans protection ; garantit une perte nulle des données validées au prix de la disponibilité et de la latence par transaction.
• Réplication Asynchrone : Le nœud principal confirme un commit lors de l'écriture locale et réplique en arrière-plan ; latence la plus faible, avec une fenêtre de perte de données bornée en cas de basculement.
• Pooler pgbouncer : Le pooler de connexions géré, configuré uniquement par mode de pool (transaction ou session), accessible sur le port 6432, utilisé pour maintenir les connexions clients sous la limite dérivée de la RAM.
• Récupération à un instant donné (PITR) : Restauration sur place à un horodateur choisi non inclusif en utilisant des sauvegardes de base et des WAL archivés, conservées 7 jours par défaut (configurable de 1 à 365 jours).

Lectures complémentaires

• Unité 5.5 : Base de données en mémoire (couche de cache) : la moitié du motif sans répliques de lecture qui concerne la mise à l'échelle en lecture et l'externalisation des sessions.
• Unité 3.7 : DNS et routage de basculement : le mécanisme de basculement inter-cluster référencé ici.
• Unité 5.7 : Protection des données et cycle de vie : la manière dont PITR, dump/restore, instantanés et archivage dans Object Storage composent un plan de continuité unique.
• Unité 7.4 : Migration et basculement hybride : l'endroit où la vague de base de données est planifiée en tant que vague dump/restore.