Présentation des offres Amazon RDS et Aurora pour PostgreSQL

Les services AWS PostgreSQL relèvent de l'égide RDS, qui est l'offre DaaS d'Amazon pour tous les moteurs de base de données connus.

Les services de bases de données gérées offrent certains avantages attrayants pour le client qui recherche l'indépendance vis-à-vis de la maintenance de l'infrastructure et des configurations hautement disponibles. Comme toujours, il n'y a pas de solution unique. Les options actuellement disponibles sont mises en évidence ci-dessous :

Aurora PostgreSQL

La page FAQ Amazon Aurora fournit des détails importants qui doivent être pris en compte avant de plonger dans le produit. Par exemple, nous apprenons que la couche de stockage est virtualisée et repose sur un système de stockage virtualisé propriétaire sauvegardé par SSD.

Prix

En termes de tarification, il convient de noter qu'Aurora PostgreSQL n'est pas disponible dans l'offre gratuite d'AWS.

Compatibilité

La même page FAQ indique clairement qu'Amazon ne revendique pas une compatibilité à 100 % avec PostgreSQL. La plupart (mon emphase) des applications ira bien, par ex. la version AWS PostgreSQL est wire-compatible avec PostgreSQL 9.6. Par conséquent, le dissecteur Wireshark PostgreSQL fonctionnera parfaitement.

Performances

Les performances sont également liées au type d'instance, par exemple le nombre maximum de connexions est configuré par défaut en fonction de la taille de l'instance.

La taille de la page qui a été maintenue à 8 Ko, qui est la taille de page par défaut de PostgreSQL, est également importante en matière de compatibilité. En parlant de pages, il vaut la peine de citer la FAQ :"Contrairement aux moteurs de base de données traditionnels, Amazon Aurora ne pousse jamais les pages de base de données modifiées vers la couche de stockage, ce qui permet d'économiser davantage sur la consommation d'E/S. « Cela est rendu possible car Amazon a changé la façon dont le cache de la page est géré, lui permettant de rester en mémoire en cas de défaillance de la base de données. Cette fonctionnalité profite également au redémarrage de la base de données après un crash, permettant à la récupération de se produire beaucoup plus rapidement que dans la méthode traditionnelle de relecture des journaux.

Selon la FAQ référencée ci-dessus, Aurora PostgreSQL offre trois fois les performances de PostgreSQL sur les opérations SELECT et UPDATE. Selon le livre blanc PostgreSQL Benchmark d'Amazon, les outils utilisés pour mesurer les performances étaient pgbench et sysbench. Il convient de noter la dépendance des performances sur le type d'instance, la sélection de la région et les performances du réseau. Vous vous demandez pourquoi INSERT n'est pas mentionné ? C'est parce que la conformité PostgreSQL ACID (le "C") exige qu'un enregistrement mis à jour soit créé en utilisant une suppression suivie d'une insertion.

Afin de tirer pleinement parti des améliorations de performances, Amazon recommande que les applications soient conçues pour interagir avec la base de données en utilisant un grand nombre de requêtes et de transactions simultanées . Ce facteur important est souvent négligé, ce qui entraîne de mauvaises performances imputées à la mise en œuvre.

Limites

Certaines limitations doivent être prises en compte lors de la planification de la migration :

Les énormes_pages ne peuvent pas être modifiées, mais elles sont activées par défaut :

template1=> select aurora_version();
 aurora_version
----------------
 1.0.11
(1 row)

template1=> show huge_pages ;
 huge_pages
------------
 on
(1 row)

pg_hba ne peut pas être utilisé car il nécessite un redémarrage du serveur. En passant, cela doit être une faute de frappe dans la documentation d'Amazon, car PostgreSQL n'a besoin que d'être rechargé. Au lieu de s'appuyer sur pg_hba, les administrateurs devront utiliser les groupes de sécurité AWS et PostgreSQL GRANT.
La granularité PITR est de 5 minutes.
La réplication entre régions n'est actuellement pas disponible pour PostgreSQL.
La taille maximale des tableaux est de 64 Tio
Jusqu'à 15 instances dupliquées en lecture

Évolutivité

La mise à l'échelle vers le haut et vers le bas de l'instance de base de données est actuellement un processus manuel, qui peut être effectué via la console AWS ou l'interface de ligne de commande, bien que la mise à l'échelle automatique soit en cours, cependant, selon la FAQ d'Amazon Aurora, elle ne sera disponible que pour MySQL.

Event log scaling ressources informatiques

Afin d'évoluer horizontalement, les applications doivent tirer parti des API AWS SDK, par exemple afin d'obtenir un basculement rapide.

Haute disponibilité

Passant à la haute disponibilité, en cas de défaillance du nœud principal, Aurora PostgreSQL fournit un point de terminaison de cluster en tant qu'enregistrement DNS A, qui est automatiquement mis à jour en interne pour pointer vers le réplica sélectionné pour devenir maître.

Sauvegardes

Il convient de mentionner que si la base de données est supprimée, tous les instantanés de sauvegarde manuelle seront conservés, tandis que les instantanés automatiques seront supprimés.

Réplication

Étant donné que les répliques partagent le même stockage sous-jacent que l'instance principale, le décalage de réplication est, en théorie, de l'ordre de quelques millisecondes.

Amazon recommande des répliques en lecture afin de réduire la durée de basculement. Avec un réplica en lecture en veille, le processus de basculement prend environ 30 secondes, tandis que sans réplica, attendez jusqu'à 15 minutes.

Une autre bonne nouvelle est que la réplication logique est également prise en charge, comme indiqué à la page 22.

Bien que la FAQ d'Amazon Aurora ne fournisse pas de détails sur la réplication comme c'est le cas pour MySQL, les bonnes pratiques d'Aurora PostgreSQL fournissent une requête utile pour vérifier l'état de la réplication :

select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp from
aurora_replica_status();

La requête ci-dessus donne :

-[ RECORD 1 ]--------------+-------------------------------------
server_id                  | testdb
session_id                 | 9e268c62-9392-11e8-87fc-a926fa8340fe
highest_lsn_rcvd           | 46640889
cur_replay_latency_in_usec | 8830
now                        | 2018-07-29 20:14:55.434701-07
last_update_timestamp      | 2018-07-29 20:14:54-07
-[ RECORD 2 ]--------------+-------------------------------------
server_id                  | testdb-us-east-1b
session_id                 | MASTER_SESSION_ID
highest_lsn_rcvd           |
cur_replay_latency_in_usec |
now                        | 2018-07-29 20:14:55.434701-07
last_update_timestamp      | 2018-07-29 20:14:55-07

Étant donné que la réplication est un sujet si important, il valait la peine de configurer le test pgbench comme indiqué dans le livre blanc de référence référencé ci-dessus :

[[email protected] ~]$ whoami
ec2-user

[[email protected] ~]$ tail -n 2 .bashrc
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
export PATH=$PATH:/usr/local/pgsql/bin/

[[email protected] ~]$ which pgbench
/usr/local/pgsql/bin/pgbench
[[email protected] ~]$ pgbench --version
pgbench (PostgreSQL) 9.6.8

Astuce : Évitez les saisies inutiles en créant un fichier pgpass et en exportant l'hôte, la base de données et les variables d'environnement utilisateur, par exemple :

[[email protected] ~]#  tail -n 3 ~/.bashrc export
PGUSER=dbadmin
export PGHOST=c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
export PGDATABASE=template1

[[email protected] ~]# cat ~/.pgpass
*:*:*:dbadmin:password

Exécutez la commande d'initialisation des données :

[[email protected] ~]$ pgbench -i --fillfactor=90 --scale=10000 postgres

Pendant l'initialisation des données, capturez le décalage de réplication à l'aide du SQL ci-dessus appelé à partir du script suivant :

while : ; do
   psql -t -q \
      -c 'select server_id, session_id, highest_lsn_rcvd,
                 cur_replay_latency_in_usec, now(), last_update_timestamp
                 from aurora_replica_status();' postgres
   sleep 1
done

Filtrage de la sortie du journal d'écran via la commande suivante :

[[email protected] ~]# awk -F '|' '{print $4,$5,$6}' screenlog.2 | sort -k1,1 -n | tail
                     513116   2018-07-30 04:30:44.394729+00   2018-07-30 04:30:43+00
                     529294   2018-07-30 04:20:54.261741+00   2018-07-30 04:20:53+00
                     544139   2018-07-30 04:41:57.538566+00   2018-07-30 04:41:57+00
                    1001902   2018-07-30 04:42:54.80136+00   2018-07-30 04:42:53+00
                    2376951   2018-07-30 04:38:06.621681+00   2018-07-30 04:38:06+00
                    2376951   2018-07-30 04:38:07.672919+00   2018-07-30 04:38:07+00
                    5365719   2018-07-30 04:36:51.608983+00   2018-07-30 04:36:50+00
                    5365719   2018-07-30 04:36:52.912731+00   2018-07-30 04:36:51+00
                    6308586   2018-07-30 04:45:22.951966+00   2018-07-30 04:45:21+00
                    8210986   2018-07-30 04:46:14.575385+00   2018-07-30 04:46:13+00

Il s'avère que la réplication a pris jusqu'à 8 secondes !

Sur une note connexe, la métrique AWS CloudWatch AuroraReplicaLagMaximum n'est pas d'accord avec les résultats de la commande SQL ci-dessus. J'aimerais savoir pourquoi, donc les commentaires sont très appréciés.

Graphique de décalage maximal de réplica RDS CloudWatch

Sécurité

Le cryptage est disponible et doit être activé lors de la création de la base de données, car il ne peut pas être modifié par la suite.

Dépannage

Cette courte section est un élément important Assurez-vous que le work_mem de PostgreSQL est réglé de manière appropriée afin que les opérations de tri n'écrivent pas de données sur le disque.

Configuration

Suivez simplement l'assistant de configuration dans la console AWS :

Ouvrez Amazon RDS console de gestion.
Console de gestion RDS
Sélectionnez Amazon Aurora et PostgreSQL édition.
Assistant Aurora PostgreSQL
Spécifiez les détails de la base de données et notez les limitations du mot de passe Aurora PostgreSQL :
```
Master Password must be at least eight characters long, as in
"mypassword". Can be any printable ASCII character except "/", """, or "@".
```
Détails de la base de données de l'assistant Aurora PostgreSQL
Configurez les options de la base de données :
- Au moment d'écrire ces lignes, seul PostgreSQL 9.6 est disponible. Utilisez PostgreSQL sur Amazon RDS si vous avez besoin d'assistance pour les versions plus récentes, y compris les aperçus bêta.
Configurez la priorité de basculement et sélectionnez le nombre de répliques.
Description de la photo
Définissez la durée de conservation des sauvegardes (le maximum est de 35 jours).
Rétention de sauvegarde de l'assistant Aurora PostgreSQL
Sélectionnez le programme d'entretien. Des mises à niveau automatiques des versions mineures sont disponibles, mais il est important de vérifier auprès du support AWS si leur calendrier de correctifs peut ou non être accéléré au cas où le projet PostgreSQL publierait des mises à jour urgentes. Par exemple, il a fallu plus de deux mois à AWS pour publier les mises à jour du 10/05/2018.
Calendrier de maintenance de l'assistant Aurora PostgreSQL
Si la base de données a été créée avec succès, un lien vers les instructions pour s'y connecter s'affichera :
Configuration de l'assistant Aurora PostgreSQL terminée

Connexion à la base de données

Consultez les instructions détaillées pour les options de connexion disponibles, en fonction de la configuration de l'infrastructure. Dans le scénario le plus simple, la connexion se fait via une instance EC2 publique.

Remarque :Le client doit être compatible avec PostgreSQL 9.6.3 ou supérieur.

[[email protected] ~]# psql -U dbadmin -h c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com template1
Password for user dbadmin:
psql (9.6.8, server 9.6.3)
SSL connection (protocol: TLSv1.2, cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Surveillance

Amazon fournit diverses métriques pour surveiller la base de données, un exemple ci-dessous montrant les métriques d'instance :

Métriques d'instance RDSTélécharger le livre blanc aujourd'hui Gestion et automatisation de PostgreSQL avec ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blanc

RDS pour PostgreSQL

Il s'agit d'une offre permettant plus de granularité en termes de choix de configuration. Par exemple, contrairement à Aurora qui utilise un système de stockage propriétaire, RDS offre un stockage configurable à l'aide de volumes EBS qui peuvent être soit des SSD à usage général (GP2), soit des IOPS provisionnés, soit magnétiques (non recommandé).

Afin d'aider les grandes installations, nécessitant une personnalisation non disponible dans l'offre Aurora, Amazon a récemment publié les recommandations des meilleures pratiques, uniquement disponibles pour RDS.

La haute disponibilité doit être configurée manuellement (ou automatisée à l'aide de l'un des outils AWS connus) et il est recommandé de configurer un déploiement multi-AZ.

La réplication est implémentée à l'aide de la réplication native PostgreSQL.

Il existe certaines limites pour les instances de base de données PostgreSQL qui doivent être prises en compte.

Avec les notes ci-dessus à l'esprit, voici une procédure pas à pas pour configurer un environnement RDS PostgreSQL Multi-AZ :

À partir de la console de gestion RDS lancer l'assistant
Assistant RDS PostgreSQL
Choisissez entre une configuration de production et une configuration de développement.
Sélection des cas d'utilisation de la base de données de l'assistant RDS PostgreSQL
Entrez les détails de votre nouveau cluster de bases de données.
Détails de la base de données de l'assistant RDS PostgreSQL Paramètres de base de données de l'assistant RDS PostgreSQL
Sur la page suivante, configurez le réseau, la sécurité et le calendrier de maintenance :
Paramètres avancés de l'assistant RDS PostgreSQL Sécurité et maintenance de l'assistant RDS PostgreSQL

Conclusion

Les services Amazon RDS pour PostgreSQL incluent RDS PostgreSQL et Aurora PostgreSQL, tous deux étant des offres DaaS gérées. Dotés de nombreuses fonctionnalités et d'un stockage backend solide, ils présentent certaines limites par rapport à la configuration traditionnelle, cependant, avec une planification minutieuse, ces offres peuvent fournir un rapport coût-fonctionnalité bien équilibré. Amazon RDS pour PostgreSQL est destiné aux utilisateurs nécessitant plus d'options pour configurer leurs environnements et est généralement plus coûteux. La majorité des utilisateurs bénéficieront d'un démarrage avec Aurora PostgreSQL et évolueront vers des configurations plus complexes.