Jusqu'où devrions-nous aller avec cela? Je commencerai par dire qu'au moment d'écrire ces lignes, je n'ai pu trouver que 3 livres sur Amazon à propos de PostgreSQL dans le cloud et 117 discussions sur les listes de diffusion PostgreSQL à propos d'Aurora PostgreSQL. Cela ne ressemble pas à beaucoup, et cela me laisse, l'utilisateur final curieux de PostgreSQL, avec la documentation officielle comme le seul endroit où je pourrais vraiment en apprendre davantage. Comme je n'ai pas la capacité ni les connaissances pour m'aventurer beaucoup plus profondément, il y a AWS re:Invent 2018 pour ceux qui recherchent ce genre de sensations fortes. Je peux me contenter de l'article de Werner sur les quorums.
Pour m'échauffer, je suis parti de la page d'accueil d'Aurora PostgreSQL où j'ai noté que le benchmark montrant qu'Aurora PostgreSQL est trois fois plus rapide qu'un PostgreSQL standard fonctionnant sur le même matériel remonte à PostgreSQL 9.6. Comme je l'ai appris plus tard, 9.6.9 est actuellement l'option par défaut lors de la configuration d'un nouveau cluster. C'est une très bonne nouvelle pour ceux qui ne veulent pas ou ne peuvent pas mettre à niveau tout de suite. Et pourquoi seulement 99,99 % de disponibilité ? Une explication peut être trouvée dans l'article de Bruce Momjian.
Compatibilité
Selon AWS, Aurora PostgreSQL est un remplacement direct de PostgreSQL, et la documentation indique :
Le code, les outils et les applications que vous utilisez aujourd'hui avec vos bases de données MySQL et PostgreSQL existantes peuvent être utilisés avec Aurora.
Ceci est renforcé par la FAQ d'Aurora :
Cela signifie que la plupart du code, des applications, des pilotes et des outils que vous utilisez déjà aujourd'hui avec vos bases de données PostgreSQL peuvent être utilisés avec Aurora avec peu ou pas de changement. Le moteur de base de données Amazon Aurora est conçu pour être compatible avec PostgreSQL 9.6 et 10, et prend en charge le même ensemble d'extensions PostgreSQL qui sont prises en charge avec RDS pour PostgreSQL 9.6 et 10, ce qui facilite le déplacement des applications entre les deux moteurs.
"la plupart" dans le texte ci-dessus suggère qu'il n'y a pas de garantie à 100 %, auquel cas ceux qui recherchent la certitude devraient envisager d'acheter une assistance technique auprès des services professionnels AWS ou des partenaires Aamazon Aurora. En passant, j'ai remarqué qu'aucun des fournisseurs d'hébergement professionnels PostgreSQL employant des contributeurs principaux de la communauté ne figure sur cette liste.
Sur la page FAQ d'Aurora, nous apprenons également qu'Aurora PostgreSQL prend en charge les mêmes extensions que RDS, qui répertorie à son tour la plupart des extensions de la communauté et quelques extras.
Concepts
Dans le cadre d'Amazon RDS, Aurora PostgreSQL est livré avec sa propre terminologie :
- Cluster :une instance de base de données principale en mode lecture/écriture et zéro ou plusieurs réplicas Aurora. La base de données principale est souvent appelée Master dans les `diagrammes AWS`_ ou Writer dans la console AWS. Sur la base du schéma de référence, nous pouvons faire une observation intéressante :Aurora écrit trois fois. Comme la latence entre les AZ est généralement plus élevée qu'au sein d'une même AZ, la transaction est considérée comme validée dès qu'elle est écrite sur la copie de données dans la même AZ, sinon la latence et les pannes potentielles entre les AZ.
- Volume de cluster :volume de stockage de base de données virtuelle couvrant plusieurs AZ.
- URL Aurora :une paire `hôte:port`.
- Point de terminaison du cluster :URL Aurora pour la base de données principale. Il existe un point de terminaison de cluster.
- Reader Endpoint :URL Aurora pour le jeu de répliques. Pour faire une analogie avec le DNS, c'est un alias (CNAME). Les demandes de lecture sont réparties entre les instances dupliquées disponibles.
- Point de terminaison personnalisé :URL Aurora vers un groupe composé d'une ou de plusieurs instances de base de données.
- Point de terminaison d'instance :URL Aurora vers une instance de base de données spécifique.
- Version Aurora :version du produit renvoyée par `SELECT AURORA_VERSION();`.
Performances et surveillance PostgreSQL sur AWS Aurora
Dimensionnement
Aurora PostgreSQL applique une configuration basée sur la meilleure estimation basée sur la taille de l'instance de base de données et la capacité de stockage, laissant un réglage supplémentaire au DBA grâce à l'utilisation de groupes de paramètres de base de données.
Lors de la sélection de l'instance de base de données, basez votre sélection sur la valeur souhaitée pour max_connections.
Mise à l'échelle
Aurora PostgreSQL propose une mise à l'échelle automatique et manuelle. La mise à l'échelle horizontale des réplicas en lecture est automatisée grâce à l'utilisation de mesures de performances. La mise à l'échelle verticale peut être automatisée via des API.
La mise à l'échelle horizontale met hors ligne pendant quelques minutes lors du remplacement du moteur de calcul et de l'exécution des opérations de maintenance (mises à niveau, correctifs). Par conséquent, AWS recommande d'effectuer ces opérations pendant les fenêtres de maintenance.
La mise à l'échelle dans les deux sens est un jeu d'enfant :
Mise à l'échelle verticale :modification de la classe d'instance 
Mise à l'échelle horizontale :ajout d'un réplica de lecteur. Au niveau du stockage, l'espace est ajouté par incréments de 10G. L'espace de stockage alloué n'est jamais récupéré, voir ci-dessous pour savoir comment résoudre cette limitation.
Stockage
Comme mentionné ci-dessus, Aurora PostgreSQL a été conçu pour tirer parti des quorums afin d'améliorer la cohérence des performances.
Étant donné que le stockage sous-jacent est partagé par toutes les instances de base de données au sein du même cluster, aucune écriture supplémentaire sur les nœuds de secours n'est requise. De plus, l'ajout ou la suppression d'instances de base de données ne modifie pas les données sous-jacentes.
Je me demande ce que ces IOs unités signifient-elles sur la facture mensuelle ? La FAQ d'Aurora vient à nouveau à la rescousse pour expliquer ce qu'est un IO c'est-à-dire dans le cadre du suivi et de la facturation. Une E/S de lecture équivaut à une lecture de page de base de données de 8 Kio et une E/S d'écriture équivaut à 4 Ko d'écriture sur la couche de stockage.
Concurrence élevée
Afin de tirer pleinement parti de la conception à haute simultanéité d'Aurora, il est recommandé de configurer les applications pour gérer un grand nombre de requêtes et de transactions simultanées.
Les applications conçues pour diriger les requêtes de lecture et d'écriture vers les nœuds de base de données de secours et principal, respectivement, bénéficieront du point de terminaison du réplica de lecteur Aurora PostgreSQL.
Les connexions sont équilibrées en charge entre les instances dupliquées en lecture.
L'utilisation d'instances de base de données de points de terminaison personnalisées avec plus de capacité peut être regroupée afin d'exécuter une charge de travail intensive telle que l'analyse.
Les points de terminaison d'instance DB peuvent être utilisés pour un équilibrage de charge précis ou un basculement rapide.
Notez que pour que les points de terminaison du lecteur équilibrent la charge des requêtes individuelles, chaque requête doit être envoyée en tant que nouvelle connexion.
Mise en cache
Aurora PostgreSQL utilise une technique de Survivable Cache Warming qui garantit que la date dans le tampon cache est préservée, éliminant ainsi le besoin de repeupler ou de réchauffer le cache après un redémarrage de la base de données.
Réplication
Le temps de latence de réplication entre les répliques est maintenu à un chiffre de la milliseconde. Bien qu'il ne soit pas disponible pour PostgreSQL, il est bon de savoir que le décalage de réplication entre régions est maintenu à moins de 10 s de millisecondes.
Selon la documentation, le décalage du réplica augmente pendant les périodes de fortes demandes d'écriture.
Plans d'exécution des requêtes
En partant de l'hypothèse que les performances des requêtes se dégradent avec le temps en raison de diverses modifications de la base de données, le rôle de ce composant Aurora PostgreSQL est de maintenir une liste des plans d'exécution des requêtes approuvés ou rejetés.
Les plans sont approuvés ou rejetés à l'aide de méthodes proactives ou réactives.
Lorsqu'un plan d'exécution est marqué comme rejeté, le plan d'exécution de la requête remplace les décisions de l'optimiseur PostgreSQL et empêche l'exécution du "mauvais" plan.
Cette fonctionnalité nécessite Aurora 2.1.0 ou version ultérieure.
Haute disponibilité et réplication PostgreSQL sur AWS Aurora
Au niveau de la couche de stockage, Aurora PostgreSQL garantit la durabilité en répliquant chaque 10 Go de volume de stockage, six fois sur 3 AZ (chaque région se compose généralement de 3 AZ) à l'aide de la réplication physique synchrone. Cela permet aux écritures de base de données de continuer à fonctionner même lorsque 2 copies de données sont perdues. La disponibilité en lecture survit à la perte de 3 copies de données.
Les réplicas en lecture garantissent qu'une instance principale défaillante peut être rapidement remplacée en promouvant l'un des 15 réplicas disponibles. Lors de la sélection d'un déploiement multi-AZ, un réplica en lecture est automatiquement créé. Le basculement ne nécessite aucune intervention de l'utilisateur et les opérations de base de données reprennent en moins de 30 secondes.
Pour les déploiements mono-AZ, la procédure de récupération inclut une restauration à partir de la dernière bonne sauvegarde connue. Selon les FAQ d'Aurora, le processus se termine en moins de 15 minutes si la base de données doit être restaurée dans une autre AZ. La documentation n'est pas si spécifique, affirmant qu'il faut moins de 10 minutes pour terminer le processus de restauration.
Aucune modification n'est requise du côté de l'application pour se connecter à la nouvelle instance de base de données, car le point de terminaison du cluster ne change pas lors d'une promotion de réplica ou d'une restauration d'instance.
Étape 1 :supprimez l'instance principale pour forcer un basculement :
Basculement automatique Étape 1 :supprimer le fichier principal Étape 2 :basculement automatique terminé
Basculement automatique Étape 2 :basculement terminé. Pour les bases de données occupées, le temps de récupération après un redémarrage ou une panne est considérablement réduit car Aurora PostgreSQL n'a pas besoin de relire les journaux de transactions.
Dans le cadre du service entièrement géré, les blocs de données et les disques défectueux sont automatiquement remplacés.
Le basculement lorsque des répliques existent prend jusqu'à 120 secondes, souvent en moins de 60 secondes. Des temps de récupération plus rapides peuvent être obtenus lorsque les conditions de basculement sont prédéterminées, auquel cas les répliques peuvent se voir attribuer des priorités de basculement.
Aurora PostgreSQL fonctionne bien avec Amazon RDS - une instance Aurora peut agir comme un réplica en lecture pour une instance RDS principale.
Aurora PostgreSQL prend en charge la réplication logique qui, tout comme dans la version communautaire, peut être utilisée pour surmonter les limitations de réplication intégrées. Il n'y a pas d'automatisation ni d'interface de console AWS.
Sécurité pour PostgreSQL sur AWS Aurora
Au niveau du réseau, Aurora PostgreSQL exploite les composants principaux d'AWS, le VPC pour l'isolation du réseau cloud et les groupes de sécurité pour le contrôle d'accès au réseau.
Il n'y a pas d'accès superutilisateur. Lors de la création d'un cluster, Aurora PostgreSQL crée un compte principal avec un sous-ensemble d'autorisations de superutilisateur :
[email protected]:5432 postgres> \du+ postgres
List of roles
Role name | Attributes | Member of | Description
-----------+-------------------------------+-----------------+-------------
postgres | Create role, Create DB +| {rds_superuser} |
| Password valid until infinity | |Pour sécuriser les données en transit, Aurora PostgreSQL fournit une prise en charge SSL/TLS native qui peut être configurée par instance de base de données.
Toutes les données au repos peuvent être chiffrées avec un impact minimal sur les performances. Cela s'applique également aux sauvegardes, aux instantanés et aux répliques.
Chiffrement au repos. L'authentification est contrôlée par les stratégies IAM, et le balisage permet de contrôler davantage ce que les utilisateurs sont autorisés à faire et sur quelles ressources.
Les appels d'API utilisés par tous les services cloud sont enregistrés dans CloudTrail.
La gestion des mots de passe restreints côté client est disponible via le paramètre rds.restrict_password_commands.
Sauvegarde et restauration PostgreSQL sur AWS Aurora
Les sauvegardes sont activées par défaut et ne peuvent pas être désactivées. Ils fournissent une récupération ponctuelle en utilisant un instantané quotidien complet comme sauvegarde de base.
La restauration à partir d'une sauvegarde automatisée présente quelques inconvénients :le temps de restauration peut être de plusieurs heures et la perte de données peut aller jusqu'à 5 minutes avant la panne. Les déploiements multi-AZ d'Amazon RDS résolvent ce problème en promouvant un réplica en lecture comme principal, sans perte de données.
Les instantanés de base de données sont rapides et n'affectent pas les performances du cluster. Ils peuvent être copiés ou partagés avec d'autres utilisateurs.
Prendre un instantané est presque instantané :
Heure de l'instantané. La restauration d'un instantané est également rapide. Comparez avec PITR :
Les sauvegardes et les instantanés sont stockés dans S3 qui offre onze 9 de durabilité.
Outre les sauvegardes et les instantanés, Aurora PostgreSQL permet de cloner des bases de données. Il s'agit d'une méthode efficace pour créer des copies d'ensembles de données volumineux. Par exemple, le clonage de plusieurs téraoctets de données ne prend que quelques minutes et n'a aucun impact sur les performances.
Aurora PostgreSQL – Démonstration de récupération ponctuelle
Connexion au cluster :
~ $ export PGUSER=postgres PGPASSWORD=postgres PGHOST=s9s-us-east-1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
~ $ psql
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.Remplir un tableau avec des données :
[email protected]:5432 postgres> create table s9s (id serial not null, msg text, created timestamptz not null default now());
CREATE TABLE
[email protected]:5432 postgres> select * from s9s;
id | msg | created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
7 | test | 2019-06-25 07:59:59.5233+00
8 | test | 2019-06-25 08:00:00.318474+00
9 | test | 2019-06-25 08:00:11.153298+00
10 | test | 2019-06-25 08:00:12.287245+00
(10 rows)Lancez la restauration :
Récupération ponctuelle :lancer la restauration. 
Une fois la restauration terminée, connectez-vous et vérifiez :
~ $ psql -h pg107-dbt3medium-restored-cluster.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
Pager usage is off.
psql (11.3, server 10.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
[email protected]:5432 postgres> select * from s9s;
id | msg | created
----+------+-------------------------------
1 | test | 2019-06-25 07:57:40.022125+00
2 | test | 2019-06-25 07:57:57.666222+00
3 | test | 2019-06-25 07:58:05.593214+00
4 | test | 2019-06-25 07:58:08.212324+00
5 | test | 2019-06-25 07:58:10.156834+00
6 | test | 2019-06-25 07:59:58.573371+00
(6 rows)Meilleures pratiques
Surveillance et audit
- Intégrez les flux d'activité de la base de données avec une surveillance tierce afin de surveiller l'activité de la base de données pour la conformité et les exigences réglementaires.
- Un service de base de données entièrement géré ne signifie pas un manque de responsabilité :définissez des métriques pour surveiller le processeur, la RAM, l'espace disque, le réseau et les connexions à la base de données.
- Aurora PostgreSQL s'intègre à l'outil de surveillance standard AWS CloudWatch, et fournit des moniteurs supplémentaires pour Aurora Metrics, Aurora Enhanced Metrics, Performance Insight Counters, Aurora PostgreSQL Replication, ainsi que pour les métriques RDS qui peuvent être regroupées par dimensions RDS.
- Surveillez la charge moyenne de la base de données des sessions actives en attendant les signes de surcharge des connexions, les requêtes SQL nécessitant un réglage, les conflits de ressources ou une classe d'instance de base de données sous-dimensionnée.
- Configurer les notifications d'événements.
- Configurer les paramètres du journal des erreurs.
- Surveillez les modifications de configuration apportées aux composants du cluster de base de données :instances, groupes de sous-réseaux, instantanés, groupes de sécurité.
Réplication
- Utilisez le partitionnement de table natif pour les charges de travail qui dépassent la classe d'instance de base de données et la capacité de stockage maximales
Cryptage
- La base de données chiffrée doit avoir des sauvegardes activées pour garantir que les données peuvent être restaurées en cas de révocation de la clé de chiffrement.
Compte principal
- N'utilisez pas psql pour modifier le mot de passe de l'utilisateur principal.
Dimensionnement
- Envisagez d'utiliser différentes classes d'instance dans un cluster afin de réduire les coûts.
Groupes de paramètres
- Régler avec précision à l'aide des groupes de paramètres afin d'économiser $$$.
Démonstration des groupes de paramètres
Paramètres actuels :
[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
10112136kB
(1 row)Créez un nouveau groupe de paramètres et définissez la nouvelle valeur à l'échelle du cluster :
Mise à jour du cluster shared_buffers. Associez le groupe de paramètres personnalisés au cluster :
Redémarrez le graveur et vérifiez la valeur :
[email protected]:5432 postgres> show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)- Définir le fuseau horaire local
Par défaut, le fuseau horaire est en UTC :
[email protected]:5432 postgres> show timezone;
TimeZone
----------
UTC
(1 row)Définition du nouveau fuseau horaire :
Configuration du fuseau horaire Et puis vérifiez :
[email protected]:5432 postgres> show timezone;
TimeZone
------------
US/Pacific
(1 row)Notez que la liste des valeurs de fuseau horaire acceptées par Amazon Aurora ne correspond pas aux ensembles de fuseaux horaires trouvés dans PostgreSQL en amont.
- Examiner les paramètres d'instance qui sont remplacés par les paramètres de cluster
- Utilisez l'outil de comparaison de groupes de paramètres.
Instantanés
- Évitez les frais de stockage supplémentaires en partageant les instantanés avec d'autres comptes pour permettre la restauration dans leurs environnements respectifs.
Entretien
- Modifiez la fenêtre de maintenance par défaut en fonction du calendrier de l'organisation.
Basculement
- Améliorez le temps de récupération en configurant la gestion du cache du cluster.
- Réduisez les valeurs TCP keepalive du noyau sur le client et configurez le cache DNS et la durée de vie de l'application, ainsi que les chaînes de connexion PostgreSQL.
Attention administrateur de bases de données !
En plus des limitations connues, évitez ou soyez conscient de ce qui suit :
Cryptage
- Une fois qu'une base de données a été créée, l'état de chiffrement ne peut plus être modifié.
Aurora sans serveur
- Pour le moment, la version PostgreSQL d'Aurora Serverless n'est disponible qu'en version préliminaire limitée.
Requête parallèle
- Amazon Parallel Query n'est pas disponible, bien que la fonctionnalité portant le même nom soit disponible depuis PostgreSQL 9.6.
Points de terminaison
À partir de la gestion des connexions Amazon :
- 5 points de terminaison personnalisés par cluster
- Les noms de points de terminaison personnalisés ne peuvent pas dépasser 63 caractères
- Les noms des points de terminaison de cluster sont uniques au sein d'une même région
- Comme indiqué dans la capture d'écran ci-dessus (aurora-custom-endpoint-details), READER et AUCUN type de point de terminaison personnalisé ne sont disponibles, utilisez la CLI
- Les points de terminaison personnalisés ne sont pas au courant des répliques qui deviennent temporairement indisponibles
Réplication
- Lors de la promotion d'un réplica en principal, les connexions via le point de terminaison du lecteur peuvent continuer à être dirigées pendant une courte période vers le réplica promu.
- Les répliques interrégionales ne sont pas prises en charge
- Bien qu'il soit sorti fin novembre 2017, l'aperçu Amazon Aurora Multi-Master n'est toujours pas disponible pour PostgreSQL
- Surveillez la dégradation des performances lorsque la réplication logique est activée sur le cluster.
- La réplication logique nécessite un moteur PostgreSQL 10.6 ou ultérieur publié.
Stockage
- L'espace de stockage alloué maximal ne diminue pas lorsque les données sont supprimées, et l'espace n'est pas non plus récupéré par la restauration à partir d'instantanés. Le seul moyen de récupérer de l'espace consiste à effectuer un vidage logique dans un nouveau cluster.
Sauvegarde et restauration
- La conservation des sauvegardes n'est pas prolongée lorsque le cluster est arrêté.
- La période de conservation maximale est de 35 jours :utilisez des instantanés manuels pour une période de conservation plus longue.
- Restaurations de récupération ponctuelles vers un nouveau cluster de bases de données.
- brève interruption des lectures pendant le basculement vers les répliques.
- Les scénarios de reprise après sinistre ne sont pas disponibles dans plusieurs régions.
Instantanés
- La restauration à partir d'un instantané crée un nouveau point de terminaison (les instantanés ne peuvent être restaurés que sur un nouveau cluster).
- Après une restauration d'instantané, les points de terminaison personnalisés doivent être recréés.
- La restauration à partir d'instantanés réinitialise le fuseau horaire local sur UTC.
- La restauration à partir d'instantanés ne préserve pas les groupes de sécurité personnalisés.
- Les instantanés peuvent être partagés avec un maximum de 20 ID de compte AWS.
- Les instantanés ne peuvent pas être partagés entre les régions.
- Les instantanés incrémentiels sont toujours copiés en tant qu'instantanés complets, entre les régions et au sein de la même région.
- La copie d'instantanés d'une région à l'autre ne conserve pas les groupes de paramètres autres que ceux par défaut.
Facturation
- La facturation des 10 minutes s'applique aux nouvelles instances, ainsi qu'à la suite d'un changement de capacité (calcul ou stockage).
Authentification
- L'utilisation de l'authentification de base de données IAM impose une limite au nombre de connexions par seconde.
- Le compte principal a certains privilèges de superutilisateur révoqués.
Démarrage et arrêt
À partir de la vue d'ensemble de l'arrêt et du démarrage d'un cluster de bases de données Aurora :
- Les clusters ne peuvent pas être arrêtés indéfiniment, car ils démarrent automatiquement au bout de 7 jours.
- Les instances de base de données individuelles ne peuvent pas être arrêtées.
Mises à jour
- Les mises à niveau de version majeure sur place ne sont pas prises en charge.
- Les modifications de groupe de paramètres pour l'instance de base de données et le cluster de base de données prennent au moins 5 minutes pour se propager.
Clonage
- 15 clones par base de données (original ou copie).
- Les clones ne sont pas supprimés lors de la suppression de la base de données source.
Mise à l'échelle
- Auto-Scaling nécessite que tous les réplicas soient disponibles.
- Il ne peut y avoir qu'une seule règle d'autoscaling par métrique et par cluster.
- La mise à l'échelle horizontale de l'instance de base de données principale (classe d'instance) n'est pas entièrement automatique. Avant la mise à l'échelle, le cluster déclenche un basculement automatique vers l'un des réplicas. Une fois la mise à l'échelle terminée, la nouvelle instance doit être promue manuellement du lecteur au rédacteur :
Nouvelle instance laissée en mode lecteur après le changement de classe d'instance de base de données.
Surveillance
- La publication de journaux PostgreSQL sur CloudWatch nécessite une version minimale du moteur de base de données 9.6.6 et 10.4.
- Seules certaines métriques Aurora sont disponibles dans la console RDS et d'autres métriques ont des noms et des unités de mesure différents.
- Par défaut, les journaux de surveillance améliorée sont conservés dans CloudWatch pendant 30 jours.
- Les métriques Cloudwatch et Enhanced Monitoring seront différentes, car elles collectent des données de l'hyperviseur et respectivement de l'agent s'exécutant sur l'instance.
- Performance Insights_ regroupe les métriques de toutes les bases de données au sein d'une instance DB.
- Les instructions SQL sont limitées à 500 caractères lorsqu'elles sont affichées avec l'interface de ligne de commande et l'API AWS Performance Insights.
Migration
- Seuls les instantanés de base de données RDS non chiffrés peuvent être chiffrés au repos.
- Les migrations utilisant la technique Aurora Read Replica prennent plusieurs heures par Tio.
Dimensionnement
- La plus petite classe d'instance disponible est db.t3.medium et la plus grande db.r5.24xlarge. À titre de comparaison, le moteur MySQL propose db.t2.small et db.t2.medium, mais pas db.r5.24xlarge dans la plage supérieure.
- la limite supérieure de max_connections est de 262 143.
Gestion des plans de requête
- Les déclarations à l'intérieur des fonctions PL/pgSQL ne sont pas prises en charge.
Migration
Aurora PostgreSQL ne fournit pas de services de migration directe, la tâche est plutôt déchargée vers un produit AWS spécialisé, à savoir AWS DMS.
Conclusion
En tant que remplacement direct entièrement géré du PostgreSQL en amont, Amazon Aurora PostgreSQL tire parti des technologies qui alimentent le cloud AWS pour supprimer la complexité requise pour configurer des services tels que la mise à l'échelle automatique, l'équilibrage de charge des requêtes, les données de bas niveau. réplication, sauvegardes incrémentielles et chiffrement.
L'architecture et une approche conservatrice pour la mise à niveau du moteur PostgreSQL offrent les performances et la stabilité que recherchent les organisations, qu'elles soient petites ou grandes.
Les limitations inhérentes ne sont qu'une preuve que la création d'une base de données à grande échelle en tant que service est une tâche complexe, laissant aux fournisseurs d'hébergement PostgreSQL hautement spécialisés un marché de niche dans lequel ils peuvent exploiter.
