Comment puis-je mettre à niveau de manière transparente la version principale d'une base de données postgres AWS RDS?

Ce matin, j'ai participé à la mise à niveau d'une base de données PostgreSQL sur AWS RDS. Nous voulions passer de la version 9.3.3 à la version 9.4.4. Nous avions "testé" la mise à niveau sur une base de données intermédiaire, mais la base de données intermédiaire est à la fois beaucoup plus petite et n'utilise pas Multi-AZ. Il s'est avéré que ce test était assez insuffisant.

Notre base de données de production utilise Multi-AZ. Nous avons effectué des mises à niveau de versions mineures dans le passé, et dans ces cas, RDS mettra d'abord à niveau le serveur de secours, puis le promouvra en tant que maître. Par conséquent, le seul temps d'arrêt encouru est d'environ 60 secondes lors du basculement.

Nous avons supposé que la même chose se produirait pour la mise à niveau de la version principale, mais oh à quel point nous avions tort.

Quelques détails sur notre configuration:

• db.m3.large
• IOPS provisionnés (SSD)
• 300 Go de stockage, dont 139 Go sont utilisés
• Nous avions des mises à niveau du système d'exploitation RDS en suspens, nous voulions effectuer un lot avec cette mise à niveau pour minimiser les temps d'arrêt

Voici les événements RDS enregistrés lors de la mise à niveau:

Le processeur de la base de données a été maximisé entre environ 08h44 et 10h27. Une grande partie de ce temps semblait être occupée par RDS prenant un instantané avant et après la mise à niveau.

Les documents AWS ne préviennent pas de telles répercussions, bien qu'en les lisant, il est clair qu'une faille évidente dans notre approche est que nous n'avons pas créé une copie de la base de données de production dans la configuration Multi-AZ et que nous essayons de la mettre à niveau comme un essai

En général, c'était très frustrant parce que RDS nous a donné très peu d'informations sur ce qu'il faisait et combien de temps cela prendrait. (Encore une fois, faire un essai aurait aidé ...)

En dehors de cela, nous voulons apprendre de cet incident alors voici nos questions:

• Ce genre de chose est-il normal lors d'une mise à niveau de version majeure sur RDS?
• Si nous voulions faire une mise à niveau de version majeure à l'avenir avec un temps d'arrêt minimal, comment procéderions-nous? Existe-t-il une manière intelligente d'utiliser la réplication pour la rendre plus transparente?

C'est une bonne question,
travailler dans un environnement cloud est parfois délicat.

Vous pouvez utiliser la pg_dumpall -f dump.sqlcommande, qui videra l'intégralité de votre base de données dans un format de fichier SQL, de manière à pouvoir la reconstruire à partir de zéro en pointant vers un autre point de terminaison. Utilisation psql -h endpoint-host.com.br -f dump.sqlpour faire court.

Mais pour ce faire, vous aurez besoin d'une instance EC2 avec un espace raisonnable sur le disque (pour s'adapter à votre vidage de base de données). De plus, vous devrez installer yum install postgresql94.x86_64pour pouvoir exécuter les commandes de vidage et de restauration.

Voir des exemples sur PG Dumpall DOC .

N'oubliez pas que pour conserver l'intégrité de vos données, il est recommandé (dans certains cas, il sera obligatoire) d'arrêter les systèmes qui se connectent à la base de données pendant cette fenêtre de maintenance.

De plus, si vous avez besoin d'accélérer les choses, envisagez d'utiliser à la pg_dumpplace pg_dumpall, en tirant parti du -j njobsparamètre parallelism ( ), lorsque vous déterminez le nombre de processeurs impliqués dans le processus, par exemple -j 8, utilisera jusqu'à 8 processeurs. Par défaut, le comportement de pg_dumpallor pg_dumpest utilisé uniquement 1. Le seul avantage à utiliser à la pg_dumpplace pg_dumpallest que vous devrez exécuter la commande pour chaque base de données que vous avez, et également vider les ROLES (groupes et utilisateurs) séparés.

Voir les exemples sur PG Dump DOC et PG Restore DOC .