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

Introduction

Le niveau relationnel est où les décisions de conception les plus importantes de FinCorp se concentrent. Un registre bancaire ne peut pas perdre silencieusement des transactions validées, mais un niveau qui bloque les écritures chaque fois qu'un Node a des problèmes est une sorte de panne en soi. Les services de bases de données gérées vous permettent de placer ce réglage de durabilité par rapport à la disponibilité avec précision, mais seulement si vous comprenez ce que chaque paramètre garantit et quels commodités la plateforme ne propose pas délibérément. Cette unité traite des décisions de réplication, de mise à l'échelle, de basculement, d'accès et de récupération, puis construit le Cluster relationnel de FinCorp dans le Data Center Designer avec ces décisions intégrées.

Le cadre honnête est plus important que d'habitude ici. Il n'y a pas de répliques de lecture, pas de produit de basculement géré, et le Backup Service ne touche pas une base de données gérée. Chaque lacune a un modèle natif qui se compose 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 se retrouve avec un niveau de données plus propre et plus prévisible.

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

Un Managed PostgreSQL Cluster est un primaire avec une à cinq instances au total, donc jusqu'à quatre instances de secours. Le mode de réplication régit le contrat entre une transaction validée et sa durabilité à travers ces nœuds, et c'est la seule décision qui définit le RPO du Cluster. Le PostgreSQL prend en charge deux modes actuels : Asynchrone (par défaut) et Strictement Synchrone. Un troisième mode, non strict Synchrone, est obsolète pour les nouveaux clusters et ne devrait pas être choisi ; les clusters existants peuvent être déplacés vers un mode asynchrone ou strictement synchrone via la commande de réplication API.

Asynchrone confirme une transaction dès qu'elle est écrite sur le disque principal ; la réplication vers les instances de secours se fait 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 principal échoue avant qu'une récente validation ne soit répliquée, cette validation est perdue lorsque une instance de secours est promue. 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, puisque les données archivées sont expédiées en blocs de 16 Mo ou toutes les 30 minutes, selon ce qui se produit en premier. Sur un Cluster sain à plusieurs Node, l'exposition réaliste est de quelques millisecondes de validations en cours, mais le point architectural est clair : le mode asynchrone échange une petite fenêtre de perte de données limitée pour la disponibilité et la latence.

Strictement Synchrone retient la validation jusqu'à ce qu'au moins une instance de secours synchrone ait la transaction, de sorte qu'aucune donnée validée ne soit perdue pendant une bascule, y compris une défaillance de stockage principal avec une perte simultanée de toutes les instances de secours. Le prix est payé à deux endroits. La latence gagne un surcoût constant par transaction, car chaque COMMIT attend maintenant la réplication (la latence inter-Node est généralement inférieure à 1 ms, mais ajoutée à chaque écriture). Plus important encore, ce mode sacrifie la disponibilité pour la durabilité : si aucune instance de secours synchrone n'est disponible, le principal cesse d'accepter les écritures plutôt que de continuer sans protection. Pour l'exécuter en toute sécurité, vous avez donc besoin d'au moins trois instances, afin que la perte d'une instance Node laisse toujours un principal et une instance de secours synchrone. La mise à disposition de moins de nœuds est le piège classique, puisqu'une défaillance unique d'une instance de secours arrête toutes les écritures.

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

Le PostgreSQL vous 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 instance de secours synchrone, tout paramètre plus fort se réduit à local), mais vous pouvez exécuter un Cluster strictement synchrone et relaxer les transactions individuelles vers synchronous_commit=local lorsque une petite perte de données est acceptable. La valeur par défaut défendable est donc de définir le Cluster sur la garantie la plus stricte dont a besoin la charge de travail et de relaxer sélectivement, et non l'inverse.

Le MariaDB supprime entièrement cette décision. Le Managed MariaDB est asynchrone uniquement : un mode de réplication, le paramètre par défaut. Il s'agit d'une décision de portée, et non d'un défaut à contourner. Le MariaDB s'exécute sur des serveurs virtuels (et non des instances de Cube), utilise le stockage SSD Premium avec les moteurs InnoDB, MyISAM ou Aria, et expédie uniquement des versions LTS, actuellement à partir de la version 10.6. Si une charge de travail FinCorp a réellement besoin de validations sans perte de données, elle appartient au PostgreSQL en mode strictement synchrone, et non au MariaDB. Le choix du moteur est donc en partie une décision de durabilité, et non seulement une décision de dialecte SQL.

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

La bascule automatique à l'intérieur d'un seul Cluster est automatique et nécessite aucun produit externe. Lorsque le principal devient indisponible, une instance de secours est promue. En mode asynchrone, n'importe quelle instance de secours peut être promue et les transactions non répliquées sont perdues ; en mode strictement synchrone, seule une instance de secours contenant toutes les transactions validées est éligible, c'est pourquoi le mode ne peut pas perdre de données validées. Au maximum, une instance de secours synchrone existe à la fois, et si elle échoue, une autre est automatiquement élevée au rôle synchrone. Cette promotion à l'intérieur du Cluster est l'ensemble de la bascule gérée de la plateforme pour une base de données : elle protège contre la perte d'instance Node à l'intérieur d'un Cluster, et non entre les clusters ou les régions.

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

Les PostgreSQL de secours existent pour la haute disponibilité, et non pour servir le trafic de lecture. Il n'y a pas de réplicas de lecture : vous ne pouvez pas diriger le trafic de rapport ou de lecture lourd vers un secours, et il n'y a pas de point de terminaison en lecture seule géré. C'est une limite de plateforme stricte, et le modèle natif qui la remplace comporte deux parties.

Tout d'abord, un plafond de connexion qui est dérivé, et non choisi. Le nombre maximum de connexions à un PostgreSQL Cluster est calculé à partir de la taille de RAM et n'est pas configurable par l'utilisateur. Le mappage documenté est :

Sur ces connexions, 11 sont réservées pour une utilisation système, donc le budget utilisable de l'application est la valeur de la table moins onze. La conséquence est que vous ne pouvez pas résoudre une tempête de connexions en modifiant un paramètre ; les seules options sont plus de RAM (jusqu'au plafond de 1000 connexions) ou moins de connexions réelles. Pour un ensemble de microservices ou un serveur frontal sans serveur qui ouvre beaucoup plus de connexions logiques que le plafond autorisé, la réponse est le regroupement.

Deuxièmement, le pooler de connexions géré (pgbouncer). Vous pouvez l'activer sur le Cluster ; la seule chose que vous configurez est le mode de pool. Le mode transaction (par défaut) retourne la connexion au pool à la fin de chaque transaction, ce qui multiplexe de nombreuses connexions clientes sur quelques connexions de backend et est le choix approprié pour le trafic web et microservice typique. Le mode session maintient la connexion de backend jusqu'à ce que le client se déconnecte, ce qui n'est nécessaire que lorsque une session repose sur un état à l'échelle de la connexion, tel que des variables de session ou des instructions préparées qui doivent persister. Le pooler écoute sur un port différent : 6432 au lieu du port par défaut de la base de données 5432, donc l'activation est également une modification de configuration du client, et non un commutateur transparent. Les applications doivent être dirigées vers 6432 pour bénéficier du pooler.

La mise à l'échelle des lectures proprement dite est résolue un niveau plus haut, dans le cache. Puisque les secours 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 le niveau relationnel sur le réseau privé, combiné avec le regroupement pour protéger le budget de connexion. Les lectures à chaud sont absorbées par le cache, le principal relationnel gère les écritures et les lectures de non-correspondance de cache, et le regroupement maintient le nombre de connexions en dessous du plafond dérivé de RAM. Cette composition de cache et de regroupement 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 à lecture élevée, et non un extra facultatif.

3. Basculement entre les grappes et accès privé

La promotion In-Cluster (Section 1.1) est le seul basculement géré. Il n'y a pas de produit de basculement géré qui s'étende sur les grappes ou les régions, et surtout, il n'y a pas de réplication de base de données native entre régions ou entre Cluster. Si FinCorp a besoin d'une continuité au-delà d'un seul Cluster, cette continuité est conçue et dirigée, et non répliquée, au niveau de la couche de base de données.

Le modèle natif de Cluster est le basculement de DNS orchestré par le client (construit dans l'Unité 3.7, révisité pour la résilience dans l'Unité 7.1). Deux grappes indépendantes sont mises en place, maintenues à jour par l'application ou par des dumps/restaurations périodiques, et un contrôle de santé externe réachemine un enregistrement Cloud DNS à faible TTL vers le point de terminaison sain. Le Cloud DNS lui-même n'est pas conscient de la santé ; il sert tout enregistrement que vous définissez. Deux propriétés déterminent la conception : le DNS dirige les nouvelles connexions uniquement, de sorte 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 basculement, qui est le levier que vous réglez pour le temps de récupération (RTO). Puisque la deuxième Cluster est une base de données distincte, il s'agit d'un mécanisme de disponibilité avec son propre point de récupération (RPO) régi par la façon dont vous gardez 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 de point de terminaison public IP ; il n'est accessible qu'à partir de l'intérieur du centre de données virtuel via un réseau privé LAN. Lors de la création, vous sélectionnez un centre de données, un LAN, et un point de terminaison privé IP. Les connexions sont protégées par défaut par le TLS : le mode SSL est prefer et ne peut pas être désactivé par le client, avec le certificat serveur émis par une autorité de confiance. Plusieurs plages de réseaux internes CIDR sont réservées par la plateforme et ne peuvent pas être utilisées pour le point de terminaison privé IP du Cluster. L'avantage est que la couche de données se trouve derrière l'équilibreur de charge de couche 4 privé de l'architecture en couches canonique (Unité 1.2), jamais exposée à Internet, accessible uniquement par la couche d'application et le cache.

4. Migration et reprise : Dump/Restore et PITR

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

Le Backup Service ne couvre pas les bases de données gérées. Le Backup Service basé sur Acronis sauvegarde les machines virtuelles et les Block Storage, et non les DBaaS, et les instantanés de Block Storage sont un retour en arrière au niveau VM, et non des sauvegardes cohérentes de base de données. La continuité des bases de données est construite à partir de deux mécanismes natifs uniquement : la reprise gérée en temps réel et la sauvegarde/restauration logique.

La reprise en temps réel est le filet de sécurité en place. Le service géré combine des sauvegardes de base périodiques avec l'archivage continu des journaux d'écriture anticipée, de sorte qu'une sauvegarde représente une plage de temps plutôt qu'un instant unique. Les sauvegardes sont créées lorsqu'un Cluster est créé, lorsque sa version majeure est augmentée, et lorsqu'une opération PITR est exécutée ; elles sont stockées chiffrées dans un seau IONOS Cloud Object Storage dans la même région (les bases de données dans une région sans Object Storage sont sauvegardées sur eu-central-2). La rétention par défaut est de 7 jours et peut être définie de 1 à 365 jours via la v2 API ; la réduction de cette durée supprime 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 plus ancienne, nécessite que le Cluster soit disponible, 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, réduit par la suite). Traitez 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 au moment de la conception, plutôt que de découvrir le manque pendant un incident.

La sauvegarde/restauration est le seul chemin de migration à l'intérieur ou à l'extérieur. Il n'y a pas d'assistant d'importation géré et pas de migration basée sur la réplication dans le service. Le déplacement d'une base de données PostgreSQL existante sur la plateforme, ou hors de celle-ci, utilise les outils logiques standard pg_dump, pg_restore, et psql ; pour MariaDB, l'équivalent est mariadb-dump. Les contraintes découlent de la règle de point de terminaison privé : puisque la cible Cluster est accessible uniquement depuis l'intérieur du VDC, la restauration doit s'exécuter à partir d'un hôte sur le réseau privé LAN de Cluster (par exemple, un saut VM dans le niveau d'application), et la coupure entraîne un temps d'arrêt honnête proportionnel à la taille du jeu de données pendant que la sauvegarde est chargée. Ceci est l'entrée relationnelle dans le plan de migration de l'unité 7.4, où la vague de base de données est la vague de sauvegarde/restauration. Planifiez-la comme une opération planifiée et dimensionnée, et non comme une synchronisation en arrière-plan.

Une mise en garde sur les informations d'identification porte un poids réel : les informations d'identification utilisateur définies au moment de la création de Cluster sont les seules que le chemin de création établit, et elles ne peuvent être définies qu'une seule fois. Capturez-les dans le magasin de secrets au moment de la mise en service, car il n'y a pas de chemin de réinitialisation pratique par la suite.

DCD Marche à suivre pour la mise en œuvre

Vous allez maintenant créer la base de données relationnelle FinCorp Cluster : une base de données privée multi-Node sur le centre de données virtuel (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 l'application LAN. Cela met en œuvre la décision de niveau de données des sections 1 à 3. Le prérequis est un VDC existant avec une application privée LAN que le niveau d'application utilise déjà (la topologie de l'unité 3.1) ; la base de données Cluster sera connectée à cette application LAN avec une adresse privée IP que vous choisissez pour éviter la plage DHCP.

Objectif de construction : Construire une base de données privée multi-Node avec un mode de réplication, une fenêtre de maintenance et des détails de connexion.

Étapes (dans le Data Center Designer) :

1. Ouvrez Menu > Bases de données > PostgreSQL. L'aperçu montre les ressources allouées à votre contrat et combien sont utilisées ; confirmez qu'il y a une marge de manœuvre avant de créer la base de données Cluster.
2. Cliquez sur Créer Cluster. Fournissez un nom de base de données Cluster qui encode l'environnement et le niveau FinCorp, et sélectionnez l'emplacement (région) qui satisfait à la décision de résidence prise à l'unité 1.4. La région est une décision de placement, et non quelque chose à revoir plus tard.
3. Choisissez la version de PostgreSQL parmi l'ensemble pris en charge (actuellement 14, 15 ou 16). La sélection d'une version majeure actuelle conserve la plus longue période de mise à niveau.
4. Sélectionnez le mode de réplication. Pour la charge de travail de ledger de FinCorp, choisissez Strictement Synchronisé et assurez-vous que le nombre d'instances à l'étape suivante est d'au moins trois, afin qu'une perte d'instance de secours unique n'arrête pas les écritures. Pour les services sensibles à la latence et tolérants aux pertes, laissez-le à Asynchrone. N'utilisez pas le mode non strict Synchronisé 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 ; décidez-le contre les exigences d'audit et de résidence plutôt que d'accepter la valeur par défaut aveuglément.
6. Dans la configuration d'instance, définissez les processeurs et la quantité de RAM par instance (n'oubliez pas que le plafond de connexion est dérivé de RAM), choisissez un type de stockage (HDD est la valeur par défaut ; choisissez SSD ou SSD Premium pour la charge de travail de la base de données, puisque SSD en dessous d'environ 100 Go n'est pas recommandé) et entrez la taille de stockage. Définissez le nombre d'instances de telle sorte qu'une base de données Cluster strictement synchronisée ait trois instances ou plus.
7. Dans la configuration réseau, sélectionnez le centre de données, le réseau LAN du centre de données que le niveau d'application utilise, et une adresse privée IP. Il n'y a pas de point de terminaison public. Pour trouver une adresse privée IP sûre, notez que le réseau LAN utilise un /24, donc réutilisez les trois premiers octets du sous-réseau d'application et choisissez une adresse se terminant entre .3 et .10, que DHCP n'attribue jamais, pour éviter une collision.
8. Dans la période de maintenance, choisissez un jour et une heure de début (UTC). Choisissez un véritable créneau de faible trafic, 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 de travail.
9. Dans la création d'utilisateur, définissez le nom d'utilisateur et le mot de passe initiaux. Ce sont les informations d'identification avec lesquelles la base de données Cluster est créée ; capturez-les dans le magasin de secrets immédiatement, puisque le chemin de création est l'endroit prévu pour les définir.
10. Créez la base de données Cluster. Une fois qu'elle est disponible, connectez-vous à partir d'un hôte sur le même réseau privé LAN en utilisant l'adresse privée IP attribuée ou le nom de 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 de transaction, à moins qu'une fonctionnalité à portée de session ne force le mode de session.

Erreurs courantes :

• La mise à disposition d'une base de données Cluster strictement synchronisée avec moins de trois instances. Avec une seule instance de secours, une perte d'instance de secours unique arrête toutes les écritures, car le mode strict refuse d'abandonner la réplication synchronisée. Dimensionnez à trois instances ou plus avant de choisir le mode strict.
• Le choix du mode non strict Synchronisé obsolète pour une nouvelle base de données Cluster. Utilisez Asynchrone ou Strictement Synchronisé ; le mode intermédiaire n'assure pas la durabilité multi-Node dans toutes les circonstances et n'existe que comme un chemin hérité.
• L'attribution d'une adresse privée IP à la base de données Cluster à l'intérieur de la plage DHCP. Les collisions cassent la connectivité de manière intermittente ; réutilisez les trois premiers octets du réseau LAN et choisissez une adresse se terminant entre .3 et .10.
• La définition d'une fenêtre de maintenance pendant les heures de travail, ou la considération 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 véritable créneau de faible trafic.
• L'attente que les instances de secours servent le trafic de lecture ou qu'elles soient un point de terminaison de lecture géré. Il n'y a pas de répliques de lecture ; mettez à l'échelle les lectures avec le cache In-Memory DB plus le pooler pgbouncer, et rappelez-vous que le pooler est sur le port 6432.
• L'hypothèse que le Backup Service ou un Block Storage Snapshot protège la base de données. Ni l'un ni l'autre ne couvre DBaaS. La continuité de la base de données est PITR (rétention par défaut de 7 jours, définie délibérément) plus dump/restore.
• La perte des informations d'identification de base de données initiales. Elles sont définies une seule fois sur le chemin de création avec aucune réinitialisation pratique ; stockez-les au moment de la mise en service.

Une courte illustration côté client des deux faits qui mordent le plus souvent, le point de terminaison 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é

Le niveau relationnel géré concentre les décisions de durabilité de FinCorp : le mode de réplication de PostgreSQL définit le RPO (asynchronous pour un travail à faible latence et tolérant aux pertes ; strictement synchrone avec trois nœuds ou plus pour une perte de données nulle ; jamais le mode non strict déprécié), tandis que MariaDB supprime le choix en étant uniquement asynchrone. La mise à l'échelle des lectures n'est pas effectuée avec des répliques, qui n'existent pas, mais avec un cache In-Memory et le pooler pgbouncer contre un plafond de connexion dérivé de RAM. La bascule automatique est effectuée à l'intérieur d'un Cluster et conçue à travers des grappes avec des vérifications de santé DNS. L'accès est limité aux points de terminaison privés, et la continuité est construite à partir de PITR et de dump/restore car Backup Service ne couvre pas les bases de données. La construction DCD valide ensuite ces choix dans un véritable Cluster.

Points clés :

• Le mode de réplication de PostgreSQL est le réglage du RPO : Asynchrone (par défaut) accepte une fenêtre de perte limitée pour la latence ; Strictement Synchrone ne perd aucune donnée validée mais nécessite un minimum de trois Node et arrête les écritures si aucun standby synchrone n'est disponible. Le mode Synchrone non strict est déprécié ; 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 de transaction par défaut, port 6432) ; le plafond de connexion est dérivé de RAM (jusqu'à 1000, moins 11 réservés) et n'est pas configurable.
• La bascule automatique est effectuée à l'intérieur d'un Cluster (promotion du standby) ; la bascule entre Cluster est conçue avec une réorientation à faible TTL Cloud DNS orchestrée par le client, pilotée par une vérification de santé externe, qui dirige les nouvelles connexions uniquement et dont le plancher TTL pilote le RTO.
• Les grappes sont limitées aux points de terminaison privés, TLS-imposés (prefer, et non désactivables par le client), et doivent être données un point de terminaison privé IP en dehors de la plage DHCP.
• Backup Service ne couvre pas DBaaS. La continuité est PITR (rétention par défaut de 7 jours, réglable de 1 à 365 jours) plus dump/restore (pg_dump/pg_restore/psql, ou mariadb-dump), exécuté à partir d'un hôte sur le réseau privé LAN de Cluster ; ceci est le chemin de migration à l'intérieur et à l'extérieur.

Terminologie importante :

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

Lecture supplémentaire

• Unité 5.5 : Base de données en mémoire (niveau cache) - la moitié de la mise à l'échelle de lecture et de l'externalisation de session du modèle sans répliques de lecture.
• 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 - comment PITR, dump/restore, instantanés et archive Object Storage se composent en un plan de continuité.
• Unité 7.4 : Migration et basculement hybride - où l'onde de base de données est planifiée comme l'onde dump/restore.