Par où commencer ?
Le meilleur endroit que j'ai pu trouver pour commencer n'était autre que la documentation officielle. Il existe également une chaîne Youtube GCP pour ceux qui préfèrent le multimédia. Une fois dans le monde de la documentation Cloud SQL, je me suis tourné vers Concepts, où l'on nous promet de "développer une compréhension approfondie" du produit.
Alors commençons !
Fonctionnalités PostgreSQL de Google Cloud
Google Cloud SQL pour PostgreSQL offre toutes les fonctionnalités standard que nous attendons d'une solution gérée :haute disponibilité avec basculement automatique, sauvegardes automatiques, chiffrement au repos et en transit, journalisation et surveillance avancées, et de bien sûr une API riche pour interagir avec tous les services.
Et pour un peu d'histoire, la prise en charge de PostgreSQL a commencé en mars 2017, jusqu'alors le seul moteur de base de données pris en charge était MySQL.
Cloud SQL exécute PostgreSQL sur la plate-forme informatique de deuxième génération de Google. La liste complète des fonctionnalités est disponible ici et également ici. En examinant le premier, il est évident qu'il n'y a jamais eu de plate-forme de première génération pour PostgreSQL.
Les bases de données exécutées sur la plate-forme de deuxième génération devraient fonctionner à des vitesses 7 fois plus rapides et bénéficier d'une capacité de stockage 20 fois supérieure. Le blog annonçant la plate-forme de deuxième génération entre dans les détails de l'exécution du test sysbench pour comparer Google Cloud SQL avec le principal concurrent AWS de l'époque dans les deux incarnations RDS et Aurora. Les résultats m'ont surpris car ils montrent que Cloud SQL fonctionne mieux alors que les récents tests effectués à l'aide d'AWS Benchmark publiés environ un an plus tard ont conclu le contraire. C'est à peu près au même moment que le support PostgreSQL était disponible. Bien que l'idée d'exécuter moi-même le benchmark me démange, je suppose qu'il y a deux facteurs potentiels qui auraient pu influencer les résultats :le benchmark sysbench de Google a utilisé différents paramètres et AWS a peut-être amélioré ses produits pendant cette période.
Compatibilité GCP PostgreSQL
Comme prévu, Google Cloud SQL pour PostgreSQL remplace quasiment la version communautaire et prend en charge tous les langages procéduraux SQL PL/pgSQL.
Certaines fonctionnalités ne sont pas disponibles pour des raisons de sécurité, par exemple l'accès SUPERUSER. D'autres fonctionnalités ont été supprimées en raison des risques potentiels posés à la stabilité et aux performances du produit. Enfin, certaines options et paramètres ne peuvent pas être modifiés, bien que les demandes de modification de ce comportement puissent être effectuées via le groupe de discussion Cloud SQL.
Cloud SQL est également compatible avec le protocole PostgreSQL.
En ce qui concerne l'isolation des transactions, Cloud SQL suit le comportement par défaut de PostgreSQL, en utilisant par défaut le niveau d'isolation en lecture validée.
Pour certains des paramètres de configuration du serveur, Cloud SQL implémente différentes plages pour des raisons non expliquées dans la documentation, ce qui reste important à retenir.
Mise en réseau
Il existe plusieurs façons de se connecter à la base de données, selon que l'instance se trouve sur un réseau privé ou sur un réseau public (applications se connectant depuis l'extérieur de GCP). Le point commun aux deux cas est le VPC prédéfini géré par Google où résident toutes les instances de base de données Cloud SQL.
IP privée
Les clients se connectant à une adresse IP privée sont acheminés via une connexion de peering entre les VPC hébergeant le client et respectivement l'instance de base de données. Bien que cela ne soit pas spécifique à PostgreSQL, il est important de revoir les exigences du réseau, afin d'éviter les problèmes de connexion. Un piège :une fois activée, la fonctionnalité d'adresse IP privée ne peut pas être supprimée.
Connexion à partir d'applications externes
Les connexions provenant d'applications hébergées en dehors de GCP peuvent et doivent être chiffrées. De plus, afin d'éviter les diverses attaques, les connexions client et l'application doivent installer le certificat client fourni. La procédure de génération et de configuration des certificats est quelque peu compliquée, nécessitant des outils personnalisés pour s'assurer que les certificats sont renouvelés périodiquement. C'est peut-être l'une des raisons pour lesquelles Google offre la possibilité d'utiliser le proxy Cloud SQL.
Se connecter à l'aide du proxy Cloud SQL
La configuration est assez simple, ce qui est en fait le cas pour toutes les instructions de la documentation Google Cloud SQL. Dans le même ordre d'idées, soumettre des commentaires sur la documentation est extrêmement simple et la fonction de capture d'écran était une première pour moi.
Il existe plusieurs façons d'autoriser les connexions proxy et j'ai choisi de configurer un compte de service, comme indiqué dans la documentation Cloud SQL Proxy.
Une fois que tout est en place, il est temps de démarrer le proxy :
~/usr/local/google $ ./cloud_sql_proxy -instances=omiday:us-west1:s9s201907141919=tcp:5432 -credential_file=omiday-427c34fce588.json
2019/07/14 21:22:43 failed to setup file descriptor limits: failed to set rlimit {&{8500 4096}} for max file descriptors: invalid argument
2019/07/14 21:22:43 using credential file for authentication; [email protected]
2019/07/14 21:22:43 Listening on 127.0.0.1:5432 for omiday:us-west1:s9s201907141919
2019/07/14 21:22:43 Ready for new connectionsPour se connecter à l'instance distante, nous utilisons maintenant le proxy en spécifiant localhost au lieu de l'adresse IP publique de l'instance :
~ $ psql "user=postgres dbname=postgres password=postgres hostaddr=127.0.0.1"
Pager usage is off.
psql (11.4, server 9.6.11)
Type "help" for help.Notez qu'il n'y a pas de chiffrement puisque nous nous connectons localement et que le proxy se charge de chiffrer le trafic entrant dans le cloud.
Une tâche DBA courante consiste à afficher les connexions à la base de données en interrogeant pg_stat_activity. La documentation indique que les connexions proxy seront affichées en tant que cloudsqlproxy~1.2.3.4, je voulais donc vérifier cette affirmation. J'ai ouvert deux sessions en tant que postgres, une via proxy et l'autre depuis mon adresse personnelle, donc la requête suivante fera l'affaire :
[email protected]:5432 postgres> select * from pg_stat_activity where usename = 'postgres';
-[ RECORD 1 ]----+-----------------------------------------------------------
datid | 12996
datname | postgres
pid | 924
usesysid | 16389
usename | postgres
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2019-07-15 04:25:37.614205+00
xact_start | 2019-07-15 04:28:43.477681+00
query_start | 2019-07-15 04:28:43.477681+00
state_change | 2019-07-15 04:28:43.477684+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 8229
query | select * from pg_stat_activity where usename = 'postgres';
-[ RECORD 2 ]----+-----------------------------------------------------------
datid | 12996
datname | postgres
pid | 946
usesysid | 16389
usename | postgres
application_name | psql
client_addr | <MY_HOME_IP_ADDRESS>
client_hostname |
client_port | 60796
backend_start | 2019-07-15 04:27:50.378282+00
xact_start |
query_start |
state_change | 2019-07-15 04:27:50.45613+00
wait_event_type |
wait_event |
state | idle
backend_xid |
backend_xmin |
query |Il semble que les connexions proxy soient plutôt identifiées comme client_port ==-1 et un client_addr vide. Cela peut également être confirmé en comparant les horodatages de backend_start et du journal proxy ci-dessous :
2019/07/14 21:25:37 New connection for "omiday:us-west1:s9s201907141919"Haute disponibilité PostgreSQL sur Google Cloud
Google Cloud SQL pour PostgreSQL garantit une haute disponibilité grâce à la synchronisation des données de stockage de bas niveau au moyen de disques persistants régionaux. Le basculement est automatique, avec un intervalle de vérification des pulsations d'une seconde et un basculement déclenché après environ 60 secondes.
Performances et surveillance
La section Performances de la documentation indique les règles générales du cloud :conservez la base de données (réplicas en écriture et en lecture) à proximité de l'application et redimensionnez verticalement l'instance. Ce qui ressort, c'est la recommandation de provisionner une instance avec au moins 60 Go de RAM lorsque les performances sont importantes.
Stackdriver fournit une surveillance et une journalisation, ainsi qu'un accès aux journaux PostgreSQL :
Contrôle d'accès
Ceci est implémenté au niveau du projet, de l'instance et de la base de données.
Contrôle d'accès au projet
Le contrôle d'accès au projet est le contrôle d'accès spécifique au cloud :il utilise le concept de rôles IAM afin de permettre aux membres du projet (utilisateurs, groupes ou comptes de service) d'accéder à diverses ressources Cloud SQL. La liste des rôles est quelque peu explicite. Pour une description détaillée de chaque rôle et des autorisations associées, reportez-vous à l'explorateur d'API ou à l'API d'administration Cloud SQL pour l'un des langages de programmation pris en charge.
Pour démontrer le fonctionnement des rôles IAM, créons un compte de service en lecture seule (lecteur) :
Démarrez une nouvelle instance de proxy sur le port 5433 en utilisant le compte de service associé au rôle de spectateur :
~/usr/local/google $ ./cloud_sql_proxy -instances=omiday:us-west1:s9s201907141919=tcp:5433 -credential_file=omiday-4508243deca9.json
2019/07/14 21:49:56 failed to setup file descriptor limits: failed to set rlimit {&{8500 4096}} for max file descriptors: invalid argument
2019/07/14 21:49:56 using credential file for authentication; [email protected]
2019/07/14 21:49:56 Listening on 127.0.0.1:5433 for omiday:us-west1:s9s201907141919
2019/07/14 21:49:56 Ready for new connectionsOuvrir une connexion psql vers 127.0.0.1:5433 :
~ $ psql "user=postgres dbname=postgres password=postgres hostaddr=127.0.0.1 port=5433"La commande se termine par :
psql: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.Oups ! Vérifions les journaux du proxy :
2019/07/14 21:50:33 New connection for "omiday:us-west1:s9s201907141919"
2019/07/14 21:50:33 couldn't connect to "omiday:us-west1:s9s201907141919": ensure that the account has access to "omiday:us-west1:s9s201907141919" (and make sure there's no typo in that name). Error during createEphemeral for omiday:us-west1:s9s201907141919: googleapi: Error 403: The client is not authorized to make this request., notAuthorizedContrôle d'accès aux instances
L'accès au niveau de l'instance dépend de la source de connexion :
La combinaison de méthodes d'autorisation remplace l'omniprésent pg_hba.conf.
Sauvegarde et restauration
Par défaut, les sauvegardes automatiques sont activées :
Bien que les sauvegardes n'affectent pas les opérations de lecture et d'écriture de la base de données, elles ont un impact sur les performances et par conséquent, il est recommandé de planifier les sauvegardes pendant les périodes de faible activité.
Pour la redondance, les sauvegardes peuvent être stockées dans deux régions (des frais supplémentaires s'appliquent) avec la possibilité de sélectionner des emplacements personnalisés.
Afin d'économiser de l'espace de stockage, utilisez la compression. Les fichiers compressés .gz sont restaurés de manière transparente.
Cloud SQL prend également en charge le clonage d'instance. Pour le plus petit ensemble de données, l'opération a pris environ 3 minutes :
Heure de début du clonage 10:07:10 :
Les journaux PostgreSQL montrent que PostgreSQL est devenu disponible sur l'instance clonée à 10 :10:47 :
C'est toujours un moyen plus simple que la sauvegarde et la restauration, pour créer une copie d'une instance à des fins de test, de développement ou de dépannage.
Bonnes pratiques Google Cloud pour PostgreSQL
- Configurez une règle d'activation pour les instances qui ne sont pas tenues de s'exécuter 24h/24 et 7j/7.
- Placez l'instance de base de données dans la même zone ou région que les instances de moteur de calcul et les applications App Engine afin d'éviter la latence du réseau.
- Créez l'instance de base de données dans la même zone que Compute Engine. Si vous utilisez un autre type de connexion, acceptez la zone par défaut.
- Les utilisateurs créés à l'aide de Cloud SQL sont par défaut des super-utilisateurs du cloud. Utilisez PostgreSQL ALTER ROLE pour modifier leurs autorisations.
- Utilisez la dernière version du proxy Cloud SQL.
- Les noms d'instance doivent inclure un horodatage afin de pouvoir réutiliser le nom lors de la suppression et de la recréation d'instances.
- pg_dump inclut par défaut les gros objets. Si la base de données contient des BLOB, effectuez le vidage pendant les périodes de faible activité pour éviter que l'instance ne réponde plus.
- Utilisez gcloud sql connect pour vous connecter rapidement à partir d'un client externe sans avoir à ajouter l'adresse IP du client à la liste blanche.
- Abonnez-vous au groupe d'annonces afin de recevoir des notifications sur les mises à jour de produits et des alertes telles que des problèmes lors de la création d'instances :
- Assurez-vous que les applications mettent en œuvre des techniques de gestion des connexions à la base de données
- Les instances arrêtées pendant plus de 90 jours seront supprimées, sauf si elles ne sont pas dans un état suspendu.
- Effectuez un basculement manuel afin de tester le comportement de l'application et la durée des temps d'arrêt.
- Utiliser la version du moteur par défaut.
- L'espace de stockage pour les instances configurées pour augmenter automatiquement le stockage augmentera par incréments de 25 Go. Comme l'espace de stockage ne peut pas être récupéré, fixez une limite d'augmentation de la taille estimée de la base de données au cours du prochain cycle budgétaire et surveillez les requêtes incontrôlées,
- Utilisez le calendrier de maintenance "antérieur" pour les instances de test :
- Les applications doivent utiliser des connexions actives et une interruption exponentielle afin de récupérer rapidement après le redémarrage d'une instance.
- Les applications reposant sur des instances dupliquées en lecture doivent envisager d'utiliser trois instances dupliquées afin d'éviter les problèmes causés par la défaillance des disques persistants régionaux entraînant l'indisponibilité des deux instances dupliquées.
- Configurez des instances dupliquées en lecture afin d'améliorer les performances de lecture.
- Le redémarrage de l'instance est requis lors de la mise à jour de la liste des adresses IP autorisées à accéder à une instance publique afin de déconnecter les connexions existantes.
- Consultez le groupe dédié StackOverflow Cloud SQL pour plus d'informations.
Lancer la liste de contrôle pour Cloud SQL
La section Liste de contrôle de la documentation fournit un aperçu des activités recommandées lors de la configuration d'une instance Cloud SQL pour PostgreSQL prête pour la production. En particulier, les applications doivent être conçues pour gérer les redémarrages Cloud SQL. De plus, bien qu'il n'y ait pas de limite de requêtes par seconde, il existe des limites de connexion.
Prise en charge des extensions PostgreSQL GCP
Cloud SQL prend en charge la plupart des extensions PostgreSQL. A ce jour, sur 52 extensions communautaires, il y a 22 extensions non prises en charge et 2 extensions PostGIS non prises en charge.
postgis_raster
postgis_sfcgalPour les extensions PostgreSQL, nous pouvons soit consulter le référentiel contrib PostgreSQL, soit mieux, différencier la sortie de pg_available_extensions :
En amont :
~ $ psql -U postgres -p 54396
Pager usage is off.
psql (11.4, server 9.6.14)
Type "help" for help.
[email protected][local]:54396 postgres# select * from pg_available_extensions order by name;
name | default_version | installed_version | comment
--------------------+-----------------+-------------------+----------------------------------------------------------------------
adminpack | 1.1 | | administrative functions for PostgreSQL
autoinc | 1.0 | | functions for autoincrementing fields
bloom | 1.0 | | bloom access method - signature file based index
btree_gin | 1.0 | | support for indexing common datatypes in GIN
btree_gist | 1.2 | | support for indexing common datatypes in GiST
chkpass | 1.0 | | data type for auto-encrypted passwords
citext | 1.3 | | data type for case-insensitive character strings
cube | 1.2 | | data type for multidimensional cubes
dblink | 1.2 | | connect to other PostgreSQL databases from within a database
dict_int | 1.0 | | text search dictionary template for integers
dict_xsyn | 1.0 | | text search dictionary template for extended synonym processing
earthdistance | 1.1 | | calculate great-circle distances on the surface of the Earth
file_fdw | 1.0 | | foreign-data wrapper for flat file access
fuzzystrmatch | 1.1 | | determine similarities and distance between strings
hstore | 1.4 | | data type for storing sets of (key, value) pairs
hstore_plperl | 1.0 | | transform between hstore and plperl
hstore_plperlu | 1.0 | | transform between hstore and plperlu
hstore_plpython2u | 1.0 | | transform between hstore and plpython2u
hstore_plpythonu | 1.0 | | transform between hstore and plpythonu
insert_username | 1.0 | | functions for tracking who changed a table
intagg | 1.1 | | integer aggregator and enumerator (obsolete)
intarray | 1.2 | | functions, operators, and index support for 1-D arrays of integers
isn | 1.1 | | data types for international product numbering standards
lo | 1.1 | | Large Object maintenance
ltree | 1.1 | | data type for hierarchical tree-like structures
ltree_plpython2u | 1.0 | | transform between ltree and plpython2u
ltree_plpythonu | 1.0 | | transform between ltree and plpythonu
moddatetime | 1.0 | | functions for tracking last modification time
pageinspect | 1.5 | | inspect the contents of database pages at a low level
pg_buffercache | 1.2 | | examine the shared buffer cache
pg_freespacemap | 1.1 | | examine the free space map (FSM)
pg_prewarm | 1.1 | | prewarm relation data
pg_stat_statements | 1.4 | | track execution statistics of all SQL statements executed
pg_trgm | 1.3 | | text similarity measurement and index searching based on trigrams
pg_visibility | 1.1 | | examine the visibility map (VM) and page-level visibility info
pgcrypto | 1.3 | | cryptographic functions
pgrowlocks | 1.2 | | show row-level locking information
pgstattuple | 1.4 | | show tuple-level statistics
plpgsql | 1.0 | 1.0 | PL/pgSQL procedural language
postgres_fdw | 1.0 | | foreign-data wrapper for remote PostgreSQL servers
refint | 1.0 | | functions for implementing referential integrity (obsolete)
seg | 1.1 | | data type for representing line segments or floating-point intervals
sslinfo | 1.2 | | information about SSL certificates
tablefunc | 1.0 | | functions that manipulate whole tables, including crosstab
tcn | 1.0 | | Triggered change notifications
timetravel | 1.0 | | functions for implementing time travel
tsearch2 | 1.0 | | compatibility package for pre-8.3 text search functions
tsm_system_rows | 1.0 | | TABLESAMPLE method which accepts number of rows as a limit
tsm_system_time | 1.0 | | TABLESAMPLE method which accepts time in milliseconds as a limit
unaccent | 1.1 | | text search dictionary that removes accents
uuid-ossp | 1.1 | | generate universally unique identifiers (UUIDs)
xml2 | 1.1 | | XPath querying and XSLTCloud SQL :
[email protected]:5432 postgres> select * from pg_available_extensions where name !~ '^postgis' order by name;
name | default_version | installed_version | comment
--------------------+-----------------+-------------------+--------------------------------------------------------------------
bloom | 1.0 | | bloom access method - signature file based index
btree_gin | 1.0 | | support for indexing common datatypes in GIN
btree_gist | 1.2 | | support for indexing common datatypes in GiST
chkpass | 1.0 | | data type for auto-encrypted passwords
citext | 1.3 | | data type for case-insensitive character strings
cube | 1.2 | | data type for multidimensional cubes
dict_int | 1.0 | | text search dictionary template for integers
dict_xsyn | 1.0 | | text search dictionary template for extended synonym processing
earthdistance | 1.1 | | calculate great-circle distances on the surface of the Earth
fuzzystrmatch | 1.1 | | determine similarities and distance between strings
hstore | 1.4 | | data type for storing sets of (key, value) pairs
intagg | 1.1 | | integer aggregator and enumerator (obsolete)
intarray | 1.2 | | functions, operators, and index support for 1-D arrays of integers
isn | 1.1 | | data types for international product numbering standards
lo | 1.1 | | Large Object maintenance
ltree | 1.1 | | data type for hierarchical tree-like structures
pg_buffercache | 1.2 | | examine the shared buffer cache
pg_prewarm | 1.1 | | prewarm relation data
pg_stat_statements | 1.4 | | track execution statistics of all SQL statements executed
pg_trgm | 1.3 | | text similarity measurement and index searching based on trigrams
pgcrypto | 1.3 | | cryptographic functions
pgrowlocks | 1.2 | | show row-level locking information
pgstattuple | 1.4 | | show tuple-level statistics
plpgsql | 1.0 | 1.0 | PL/pgSQL procedural language
sslinfo | 1.2 | | information about SSL certificates
tablefunc | 1.0 | | functions that manipulate whole tables, including crosstab
tsm_system_rows | 1.0 | | TABLESAMPLE method which accepts number of rows as a limit
tsm_system_time | 1.0 | | TABLESAMPLE method which accepts time in milliseconds as a limit
unaccent | 1.1 | | text search dictionary that removes accents
uuid-ossp | 1.1 | | generate universally unique identifiers (UUIDs)Extensions non compatibles dans Cloud SQL :
adminpack 1.1 administrative functions for PostgreSQL
autoinc 1.0 functions for autoincrementing fields
dblink 1.2 connect to other PostgreSQL databases from within a database
file_fdw 1.0 foreign-data wrapper for flat file access
hstore_plperl 1.0 transform between hstore and plperl
hstore_plperlu 1.0 transform between hstore and plperlu
hstore_plpython2u 1.0 transform between hstore and plpython2u
hstore_plpythonu 1.0 transform between hstore and plpythonu
insert_username 1.0 functions for tracking who changed a table
ltree_plpython2u 1.0 transform between ltree and plpython2u
ltree_plpythonu 1.0 transform between ltree and plpythonu
moddatetime 1.0 functions for tracking last modification time
pageinspect 1.5 inspect the contents of database pages at a low level
pg_freespacemap 1.1 examine the free space map (FSM)
pg_visibility 1.1 examine the visibility map (VM) and page-level visibility info
postgres_fdw 1.0 foreign-data wrapper for remote PostgreSQL servers
refint 1.0 functions for implementing referential integrity (obsolete)
seg 1.1 data type for representing line segments or floating-point intervals
tcn 1.0 Triggered change notifications
timetravel 1.0 functions for implementing time travel
tsearch2 1.0 compatibility package for pre-8.3 text search functions
xml2 1.1 XPath querying and XSLTJournalisation
Les opérations effectuées dans Cloud SQL sont consignées sous l'onglet "Activité" avec tous les détails. Exemple de création d'une instance, montrant tous les détails de l'instance :
Migration PostgreSQL vers GCP
Afin de fournir la migration des installations PostgreSQL sur site, Google tire parti de pgBouncer.
Notez qu'il n'y a pas d'assistant de console GCP pour les migrations PostgreSQL.
Attention administrateur de bases de données !
Haute disponibilité et réplication
Un nœud maître ne peut pas basculer vers un réplica en lecture. La même section décrit d'autres aspects importants des instances dupliquées en lecture :
- peut être mis hors ligne à tout moment pour l'application de correctifs
- ne suivez pas le nœud maître dans une autre zone suite à un basculement :la réplication étant synchrone, cela peut affecter le délai de réplication
- il n'y a pas d'équilibrage de charge entre les répliques, en d'autres termes, aucune application de point de terminaison unique ne peut être dirigée vers
- la taille de l'instance dupliquée doit être au moins égale à la taille du nœud maître
- pas de réplication entre régions
- les répliques ne peuvent pas être sauvegardées
- tous les réplicas doivent être supprimés avant qu'une instance maître puisse être restaurée à partir d'une sauvegarde ou supprimée
- la réplication en cascade n'est pas disponible
Utilisateurs
Par défaut, le "superutilisateur cloud" est postgres qui est membre du rôle cloudsqlsuperuser. À son tour, cloudsqlsuperuser hérite des rôles PostgreSQL par défaut :
[email protected]:5432 postgres> \du+ postgres
List of roles
Role name | Attributes | Member of | Description
-----------+------------------------+---------------------+-------------
postgres | Create role, Create DB | {cloudsqlsuperuser} |
[email protected]:5432 postgres> \du+ cloudsqlsuperuser
List of roles
Role name | Attributes | Member of | Description
-------------------+------------------------+--------------+-------------
cloudsqlsuperuser | Create role, Create DB | {pg_monitor} |Notez que les rôles SUPERUSER et REPLICATION ne sont pas disponibles.
Sauvegarde et restauration
Les sauvegardes ne peuvent pas être exportées.
Les sauvegardes ne peuvent pas être utilisées pour mettre à niveau une instance, c'est-à-dire la restaurer dans un autre moteur PostgreSQL.
Les fonctionnalités telles que PITR, la réplication logique et la compilation JIT ne sont pas disponibles. Les demandes de fonctionnalités peuvent être déposées dans l'outil de suivi des problèmes de Google.
Cryptage
Lors de la création de l'instance, SSL/TLS est activé mais pas appliqué :
Dans ce mode, le chiffrement peut être demandé, mais la validation du certificat n'est pas disponible.
~ $ psql "sslmode=verify-ca user=postgres dbname=postgres password=postgres hostaddr=35.233.149.65"
psql: root certificate file "/home/lelu/.postgresql/root.crt" does not exist
Either provide the file or change sslmode to disable server certificate verification.
~ $ psql "sslmode=require user=postgres dbname=postgres password=postgres hostaddr=35.233.149.65"
Pager usage is off.
psql (11.4, server 9.6.11)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES128-GCM-SHA256, bits: 128, compression: off)
Type "help" for help.Tenter de se connecter en utilisant psql à une instance SSL renverra une erreur explicite :
~ $ psql "sslmode=require user=postgres dbname=postgres password=postgres hostaddr=35.233.149.65"
psql: FATAL: connection requires a valid client certificateStockage
- L'espace de stockage peut être augmenté après la création de l'instance, mais jamais diminué. Faites donc attention aux coûts associés à l'augmentation de l'espace de stockage ou configurez la limite d'augmentation.
- L'espace de stockage est limité à 30 To.
CPU
Les instances peuvent être créées avec moins d'un cœur, cependant, l'option n'est pas disponible dans la console Cloud SQL, car l'instance doit être créée en spécifiant l'un des exemples de types de machines, dans ce cas :niveau :
Exemple de création d'une instance de code partagé à l'aide de gcloud dans Cloud Shell :
Le nombre de CPU est limité à 64, une limite relativement basse pour les gros installations, étant donné qu'à l'époque où la version 9.2 était évaluée, les serveurs haut de gamme commençaient à 32 cœurs.
Emplacements des instances
L'emplacement multirégional n'est disponible que pour les sauvegardes.
Accès via IP publique
Par défaut, l'assistant de console GCP n'autorise que l'accès aux adresses IP publiques, mais l'accès est refusé tant que le réseau du client n'est pas configuré :
Maintenance
Les mises à jour peuvent dépasser la fenêtre de maintenance et les répliques en lecture sont mises à jour à tout moment.
La documentation ne précise pas la durée de la fenêtre de maintenance. Les informations sont fournies lors de la création de l'instance :
Modifications du nombre de CPU, de la taille de la mémoire ou de la zone où se trouve l'instance localisé nécessite que la base de données soit hors ligne pendant plusieurs minutes.
Utilisateurs
Cloud SQL utilise indifféremment les termes "rôle" et "utilisateur".
Haute disponibilité
Le coût d'une configuration hautement disponible est le double de celui d'une instance autonome, et cela inclut le stockage.
Le basculement automatique est lancé environ 60 secondes après l'indisponibilité du nœud principal. Selon le rapport d'Oracle MAA, cela se traduit par une perte de 5 800 $ par minute. Considérant qu'il faut 2 à 3 minutes pour que les applications puissent reconnecter la panne double à triple. De plus, l'intervalle de pulsation de 60 secondes ne semble pas être une option configurable.
Réplication
Les réplicas en lecture ne sont pas accessibles à l'aide d'un seul point de terminaison, chacun recevant une nouvelle adresse IP :
Regional persistent disks provide data redundancy at the cost of write performance.
Cloud SQL will not failover to read replicas, hence readers cannot be considered a high availability solution
External replicas and external masters are currently not supported.
Connecting to Instance
Google does not automatically renew the instance SSL certificates, however, both the initiation and rotation procedures can be automated.
If the application is built on the App Engine platform additional limits apply, such as 60 seconds for a database request to complete, 60 concurrent connections for PHP applications. The “App Engine Limits” section in Quotas and limits provides more details:
IP addresses in the range 172.17.0.0/16 are reserved.
Administration
Once started, operations cannot be canceled. Runaway queries can still be stopped by using the pg_terminate_backend and pg_cancel_backend PostgreSQL built-in functions.
A short demonstration using two psql sessions and starting a long running query in the second session:
[email protected]:5432 postgres> select now(); select pg_sleep(3600); select now();
now
-------------------------------
2019-07-16 02:08:18.739177+00
(1 row)In the first session, cancel the long running query:
[email protected]:5432 postgres> select pid, client_addr, client_port, query, backend_start from pg_stat_activity where usename = 'postgres';
-[ RECORD 1 ]-+-------------------------------------------------------------------------------------------------------------
pid | 2182
client_addr | 173.180.222.170
client_port | 56208
query | select pid, client_addr, client_port, query, backend_start from pg_stat_activity where usename = 'postgres';
backend_start | 2019-07-16 01:57:34.99011+00
-[ RECORD 2 ]-+-------------------------------------------------------------------------------------------------------------
pid | 2263
client_addr | 173.180.222.170
client_port | 56276
query | select pg_sleep(3600);
backend_start | 2019-07-16 02:07:43.860829+00
[email protected]:5432 postgres> select pg_cancel_backend(2263); select now();
-[ RECORD 1 ]-----+--
pg_cancel_backend | t
-[ RECORD 1 ]----------------------
now | 2019-07-16 02:09:09.600399+00Comparing the timestamps between the two sessions:
ERROR: canceling statement due to user request
now
-------------------------------
2019-07-16 02:09:09.602573+00
(1 row)It’s a match!
While restarting an instance is a recommended method when attempting to resolve database instance issues, avoid restarting before the first restart completed.
Data Import and Export
CSV import/export is limited to one database.
Exporting data as an SQL dump that can be imported later, requires a custom pg_dump command.
To quote from the documentation:
pg_dump -U [USERNAME] --format=plain --no-owner --no-acl [DATABASE_NAME] \
| sed -E 's/(DROP|CREATE|COMMENT ON) EXTENSION/-- \1 EXTENSION/g' > [SQL_FILE].sqlPricing
| Charge Type | Instance ON | Instance OFF |
| Storage | Yes | Yes |
| Instance | No | Yes |
Troubleshooting
Logging
All actions are recorded and can be viewed under the Activity tab.
Resources
Review the Diagnosing Issues with Cloud SQL instances and Known issues sections in the documentation.
Conclusion
Although missing some important features the PostgreSQL DBA is used to, namely PITR and Logical Replication, Google Cloud SQL provides out of the box high-availability, replication, encryption, and automatic storage increase, just to name a few, making manage PostgreSQL an appealing solution for organizations looking to quickly deploy their PostgreSQL workloads or even migrating from Oracle.
Developers can take advantage of cheap instances such as shared CPU (less than one CPU).
Google approaches the PostgreSQL engine adoption in a conservative manner, the stable offering lagging behind current upstream by 3 versions.
Just as with any solution provider consider getting support which can come in handy during edge scenarios such as when instances are suspended.
For professional support, Google maintains a list of partners which currently includes one of the PostgreSQL professional services , namely EDB.
