Mettez à niveau votre PostgreSQL en un clic vers la version 9.5 et 9.6 maintenant disponible !

Scalingo fournit des addons de base de données à jour avec une mise à niveau simple. Nous avons juste activé la possibilité de mettre à niveau vos bases de données PostgreSQL vers les versions 9.5 et 9.6. Dans le processus, nous avons également mis à jour l'onglet "Avancé" du tableau de bord avec la possibilité d'administrer les extensions PostgreSQL. Embarquons pour une visite dans le merveilleux monde de PostgreSQL 9.5 et 9.6.

Processus de mise à niveau

En préambule, jetons un œil à comment mettre à niveau votre base de données sur Scalingo. Comme d'habitude, le processus de mise à niveau sur Scalingo est aussi simple que de cliquer sur un bouton sur le tableau de bord de la base de données. L'image suivante montre le message que vous verrez sur votre tableau de bord de la base de données si vous exécutez la dernière version 9.4 (c'est-à-dire PostgreSQL v9.4.10) :

Cette mise à niveau peut prendre un certain temps pour les plus grandes bases de données. Pendant le processus, votre base de données sera mise hors ligne. Vous devrez d'abord mettre à niveau vers 9.5 avant de pouvoir mettre à niveau vers 9.6.

Nous déployons aujourd'hui les versions 9.5.5 et 9.6.1. Comme d'habitude, vous pouvez trouver les images Docker correspondantes sur notre hub docker dépôt.

Nous vous conseillons fortement de vérifier que votre code fonctionne toujours avec la nouvelle version de la base de données. Pour faciliter cette tâche, vous pouvez tirer la version de PostgreSQL dont vous avez besoin depuis notre hub docker public dépôt et tester localement votre code. Vous pouvez également obtenir le même conteneur que nous avons construit pour votre application et qui fonctionne sur notre infrastructure en utilisant notre Addon d'image Docker.

Une façon plus efficace d'automatiser le processus de mise à niveau

Nous avons toujours pensé à nos addons de base de données comme à une base de données en tant que service (DBaaS). C'est pourquoi il est évident que nous fournissons un processus automatique fluide lorsque vous souhaitez mettre à niveau votre base de données (contrairement à certains de nos concurrents !). Ici à Scalingo, nous vous assistons pleinement avec votre base de données.
Cependant, nous n'étions pas complètement satisfaits de la façon dont nous avons automatisé la mise à niveau de PostgreSQL. C'est pourquoi, pendant notre travail sur PostgreSQL 9.5 et 9.6, notre équipe a repensé la manière dont nous gérons la sauvegarde et la restauration de vos données. Jusqu'à présent, nous arrêtions d'abord la base de données, effectuions une sauvegarde avec pg_dump et une restauration avec psql. Pour les plus grandes bases de données hébergées sur Scalingo (des dizaines de Go !), tout le processus pouvait prendre plusieurs dizaines de minutes pour se terminer. C'est beaucoup de temps d'arrêt pour une base de données de production ! Après quelques modifications dans notre flux de travail, nous sommes maintenant en mesure d'utiliser l'outil pg_upgrade pour gérer ce processus. Le temps d'arrêt est uniquement d'une dizaine de secondes !

Le flux de travail est maintenant :

• Arrêt du conteneur de base de données en cours d'exécution : nous envoyons un signal SIGTERM au processus PostgreSQL pour qu'il arrête gracieusement la transaction et la demande en cours

• Exécution d'un conteneur spécialisé pg_upgrade pour gérer la migration des données : ce conteneur est open source et est disponible sur notre hub docker dépôt. Vous pouvez facilement tester la migration de 9.4 à 9.5 localement avec docker run -v /path/to/data:/var/lib/postgresql scalingo/pgupgrade:94to95 /pg_upgrade.

• Exécution du conteneur de base de données avec la nouvelle version : une fois de plus, l'image Docker est open source et vous pouvez tester localement que tout fonctionne correctement avec un simple docker run -v /path/to/data:/var/lib/postgresql scalingo/postgresql:9.6.1-1.

Gérez vos extensions PostgreSQL depuis le tableau de bord

Le tableau de bord PostgreSQL a également reçu quelques améliorations pour vous donner plus de contrôle sur les extensions. Tout d'abord, l'onglet "Avancé" affiche maintenant dans un bloc la liste des extensions que vous avez installées et leur version.

Deuxièmement, le pg_stat_statements rassemble des statistiques sur les requêtes. Vous pourriez avoir besoin de réinitialiser ces statistiques. Pour ce faire, vous devez interroger la base de données avec des droits administratifs (en utilisant la fonction pg_stat_statements_reset). Comme vous n'avez pas ces droits sur les bases de données Scalingo pour des raisons de sécurité, nous vous donnons maintenant la possibilité de réinitialiser les statistiques avec un bouton sur le tableau de bord. Si vous avez besoin d'effectuer d'autres requêtes avec des droits administratifs, n'hésitez pas à nous demander à support@scalingo.com. Nous pourrions envisager d'ajouter un bouton spécifique dans le tableau de bord.

Enfin, les statistiques de l'onglet "Aperçu" (utilisation de la mémoire et d'échange, connexions de base de données et taille des données) sont désormais mises à jour automatiquement. Plus besoin de recharger la page !

Vous pouvez maintenant parler des nouvelles fonctionnalités introduites dans PG 9.5 et PG 9.6.

Quoi de neuf dans PostgreSQL 9.5

PostgreSQL 9.4 a été initialement publié en décembre 2014. La version 9.5 étant publiée au début de 2016, cela a été une longue année de travail pour le groupe de développement mondial de PostgreSQL pour libérer cette version.

Le très attendu PostgreSQL 9.5 livre la requête UPSERT tant attendue. UPSERT est l'abréviation de INSERT, ON CONFLICT UPDATE. Elle permet de traiter les nouvelles lignes et les lignes mises à jour de la même manière.

Une grande nouvelle fonctionnalité de sécurité est le sécurité au niveau des lignes. C'est le fruit de 5 années de travail pour fournir la possibilité de filtrer les lignes que des utilisateurs particuliers sont autorisés à mettre à jour ou à visualiser. Étant donné une table log, dans laquelle chaque ligne est une entrée de journal :

CREATE TABLE log (
   id serial primary key,
   username text,
   log_event text);

CREATE TABLE log (
   id serial primary key,
   username text,
   log_event text);

CREATE TABLE log (
   id serial primary key,
   username text,
   log_event text);

CREATE TABLE log (
   id serial primary key,
   username text,
   log_event text);

Grâce à la sécurité au niveau des lignes, vous pouvez spécifier qu'une entrée de journal n'est visible que par l'utilisateur qui l'a créée :

CREATE POLICY policy_user_log ON log
 FOR ALL
 TO PUBLIC
 USING (username = current_user)

CREATE POLICY policy_user_log ON log
 FOR ALL
 TO PUBLIC
 USING (username = current_user)

CREATE POLICY policy_user_log ON log
 FOR ALL
 TO PUBLIC
 USING (username = current_user)

CREATE POLICY policy_user_log ON log
 FOR ALL
 TO PUBLIC
 USING (username = current_user)

Et enfin, nous activons la sécurité au niveau des lignes sur la table :

Une requête SELECT sur cette table ne renverra que les lignes insérées par l'utilisateur actuel. Par exemple, en tant qu'utilisateur "report" :

# SELECT * FROM log;
id | username |   log_event
----+----------+----------------
 1 | report   | DELETE issued
 4 | report   | Reset accounts
(2 rows)

# SELECT * FROM log;
id | username |   log_event
----+----------+----------------
 1 | report   | DELETE issued
 4 | report   | Reset accounts
(2 rows)

# SELECT * FROM log;
id | username |   log_event
----+----------+----------------
 1 | report   | DELETE issued
 4 | report   | Reset accounts
(2 rows)

# SELECT * FROM log;
id | username |   log_event
----+----------+----------------
 1 | report   | DELETE issued
 4 | report   | Reset accounts
(2 rows)

Exemple tiré du wiki PostgreSQL.

Cette version fournit également de meilleures performances pour le tri des champs varchar, text, numeric.

Pour une liste complète de ce qui est nouveau dans cette version, veuillez consulter ce billet de blog du site officiel.

Quoi de neuf dans PostgreSQL 9.6

Avec une gestation plus courte, cette version a tout de même des fonctionnalités vraiment intéressantes. La plus importante étant le support pour la parallélisation de certaines opérations de requêtes, afin de renvoyer les résultats des requêtes plus rapidement. L'augmentation de vitesse dépend des cœurs disponibles.

Deuxièmement, la recherche en texte intégral de PostgreSQL soutient maintenant la "recherche de phrases". Les anciennes versions de PostgreSQL autorisaient une recherche booléenne de base sur un ensemble de mots, mais il n'était pas possible d'avoir une sorte de relation entre ces mots. Par exemple, une recherche de mot sur "Scalingo Nouvelles Fonctionnalités" renvoie des documents où ces trois documents sont séparés par des pages de texte ou liés ensemble.

En utilisant le nouveau tie-fighter <->, vous pourriez rechercher cette phrase exacte en utilisant l'un des phrases suivantes :

> phraseto_tsquery('scalingo new features')
> to_tsquery('scalingo <-> new <-> features')

> phraseto_tsquery('scalingo new features')
> to_tsquery('scalingo <-> new <-> features')

> phraseto_tsquery('scalingo new features')
> to_tsquery('scalingo <-> new <-> features')

> phraseto_tsquery('scalingo new features')
> to_tsquery('scalingo <-> new <-> features')

Si nous voulons également permettre "Scalingo Grandes Nouvelles Fonctionnalités de Base de Données", nous pourrions utiliser la recherche ci-dessous, permettant aux mots d'avoir un mot entre :

> to_tsquery('scalingo <2> new <2> features')

> to_tsquery('scalingo <2> new <2> features')

> to_tsquery('scalingo <2> new <2> features')

> to_tsquery('scalingo <2> new <2> features')

Le travail sur les performances de telles recherches est toujours actif. Attendez-vous à plus dans la prochaine version 10.0 !

Pour une liste complète de ce qui est nouveau dans cette version, veuillez consulter ce billet de blog du site officiel.