Ce document fait partie d'une série qui fournit des informations et des conseils clés sur la planification et l'exécution des migrations de base de données Oracle® 11g/12c vers Cloud SQL pour PostgreSQL version 12. Outre la section d'introduction à la configuration, la série inclut les éléments suivants :
- Migrer des utilisateurs Oracle vers Cloud SQL pour PostgreSQL : terminologie et fonctionnalités
- Migrer des utilisateurs Oracle vers Cloud SQL pour PostgreSQL : types de données, utilisateurs et tables
- Migrer des utilisateurs Oracle vers Cloud SQL pour PostgreSQL : requêtes, procédures stockées, fonctions et déclencheurs
- Migrer des utilisateurs Oracle vers Cloud SQL pour PostgreSQL : sécurité, opérations, surveillance et journalisation (ce document)
- Migrer des utilisateurs et des schémas de Oracle Database vers Cloud SQL pour PostgreSQL
Sécurité
Cette section fournit des conseils sur le chiffrement, l'audit et le contrôle des accès.
Chiffrement
Oracle et Cloud SQL pour PostgreSQL offrent tous deux des mécanismes de chiffrement des données permettant d'ajouter une couche de protection supplémentaire par-dessus l'authentification de base des utilisateurs et la gestion des droits utilisateur.
Chiffrement au repos
Les données qui ne transitent pas par les réseaux (stockées) sont appelées "données au repos". Oracle propose le mécanisme TDE (Transparent Data Encryption) pour ajouter une couche de chiffrement au niveau du système d'exploitation. Dans Cloud SQL, les données sont chiffrées à l'aide de la norme AES-256 (Advanced Encryption Standard, 256 bits) ou mieux. Ces clés de données sont elles-mêmes chiffrées à l'aide d'une clé principale stockée dans un keystore sécurisé, et elles sont régulièrement modifiées. Pour en savoir plus sur le chiffrement au repos, consultez la page Chiffrement au repos dans Google Cloud.
Chiffrement en transit
Oracle offre une sécurité avancée pour gérer le chiffrement des données sur le réseau. Cloud SQL chiffre et authentifie toutes les données en transit sur une ou plusieurs couches réseau lorsque des données sont transférées en dehors des limites physiques qui ne sont pas contrôlées par ou pour le compte de Google. Les données en transit se trouvant au sein d'une limite physique contrôlée par ou pour le compte de Google sont généralement authentifiées, mais elles peuvent ne pas être chiffrées par défaut. Selon votre modèle de gestion des menaces, vous pouvez choisir d'appliquer des mesures de sécurité supplémentaires. Par exemple, vous pouvez configurer SSL pour les connexions intrazones à Cloud SQL. Pour en savoir plus sur le chiffrement en transit, consultez la page Chiffrement en transit dans Google Cloud.
Audits
Oracle propose plusieurs méthodes d'audit, telles que l'audit standard et l'audit précis. En revanche, l'audit dans Cloud SQL pour PostgreSQL peut être réalisé par les moyens suivants :
- Extension pgAudit. Enregistrez et suivez les opérations SQL effectuées sur une instance de base de données spécifique.
- Cloud Audit Logging Effectuez un audit des opérations d'administration et de maintenance effectuées sur une instance Cloud SQL pour PostgreSQL.
Contrôle des accès
Les utilisateurs peuvent se connecter à l'instance Cloud SQL pour PostgreSQL via un client PostgreSQL avec une adresse IP statique autorisée ou via le proxy Cloud SQL, comme n'importe quelle autre connexion de base de données. Pour les autres sources de connexion, telles que Compute Engine ou App Engine, les utilisateurs disposent de plusieurs options, comme le proxy Cloud SQL. Pour en savoir plus sur ces options, consultez la page Contrôle de l'accès aux instances.
Cloud SQL pour PostgreSQL s'intègre à Identity and Access Management (IAM) et fournit un ensemble de rôles prédéfinis conçus pour vous aider à contrôler l'accès à vos ressources Cloud SQL. Ces rôles permettent aux utilisateurs IAM d'effectuer diverses opérations d'administration, telles que des redémarrages d'instances, des sauvegardes et des basculements. Pour en savoir plus, consultez la page Contrôle de l'accès aux projets.
Opérations
Cette section fournit des conseils sur les opérations d'exportation et d'importation, la sauvegarde et la restauration au niveau de l'instance, ainsi que sur les instances de secours pour les opérations en lecture seule et la mise en œuvre de la reprise après sinistre.
Exporter et importer
La méthode principale d'Oracle pour effectuer des opérations d'exportation et d'importation logiques consiste à exploiter l'utilitaire Data Pump et à recourir aux commandes EXPDP/IMPDP (une ancienne version de la fonctionnalité d'exportation et d'importation d'Oracle incluait les commandes exp/imp). Les utilitaires pg_dump et pg_restore constituent des commandes Cloud SQL pour PostgreSQL équivalentes qui génèrent des fichiers de vidage, puis effectuent l'importation au niveau de la base de données ou de l'objet (y compris l'exportation et l'importation des métadonnées uniquement).
Il n'existe pas de solution Cloud SQL pour PostgreSQL directe équivalente pour l'utilitaire Oracle DBMS_DATAPUMP (méthode Oracle permettant d'appliquer la fonctionnalité EXPDP/IMPDP en interaction directe avec le package DBMS_DATAPUMP). Pour effectuer une conversion à partir du code PL/SQL DBMS_DATAPUMP Oracle, utilisez un autre code (par exemple, Bash ou Python) pour mettre en œuvre des éléments logiques, et employez les utilitaires Cloud SQL pour PostgreSQL pg_dump et pg_restore pour exécuter des opérations d'exportation et d'importation.
Oracle SQL*Loader peut être utilisé pour charger des fichiers externes dans des tables de base de données. SQL*Loader peut utiliser un fichier de configuration (appelé fichier de contrôle), qui contient les métadonnées utilisées par SQL*Loader pour déterminer le mode d'analyse et de chargement des données dans la base de données Oracle. SQL*Loader accepte les fichiers source fixes et variables.
Les utilitaires pg_dump et pg_restore s'exécutent au niveau du client et se connectent à distance à l'instance Cloud SQL pour PostgreSQL. Les fichiers de vidage sont créés côté client. Pour charger des fichiers externes dans Cloud SQL pour PostgreSQL, utilisez la commande COPY à partir de l'interface client psql, ou bien faites appel à Dataflow ou Dataproc. Cette section porte principalement sur la commande Cloud SQL pour PostgreSQL COPY, qui constitue un équivalent plus direct de l'utilitaire SQL*Loader d'Oracle.
Pour le chargement de données plus complexes dans votre base de données Cloud SQL pour PostgreSQL, envisagez d'utiliser Dataflow ou Dataproc, ce qui implique la création d'un processus ETL.
Pour en savoir plus sur Dataflow, consultez la documentation Dataflow. Pour en savoir plus sur Dataproc, consultez la documentation Dataproc.
pg_dump
L'utilitaire client pg_dump effectue des sauvegardes et des sorties cohérentes aux formats de fichier de script ou d'archive. Un vidage par script est un ensemble d'instructions SQL pouvant être exécutées afin de reproduire les définitions des objets de base de données et les données de table d'origine. Ces instructions SQL peuvent être transmises à n'importe quel client PostgreSQL pour restauration. Les sauvegardes dans des formats de fichiers d'archive doivent être utilisées avec pg_restore lors des opérations de restauration, mais ces sauvegardes permettent de restaurer des objets de manière sélective et sont conçues pour être portables sur différentes architectures.
Utilisation :
-- Single database backup & specific tables backup # pg_dump database_name > outputfile.sql # pg_dump -t table_name database_name > outputfile.sql -- Dump all tables in a given schema with a prefix and ignore a given table # pg_dump -t 'schema_name.table_prefixvar>*' -T schema_name.ignore_table database_name > outputfile.sql -- Backup metadata only - Schema only # pg_dump -s database_name > metadata.sql -- Backup in custom-format archive pg_dump -Fc database_name > outputfile.dump
pg_restore
Le programme client pg_restore restaure une base de données PostgreSQL à partir d'une archive créée par pg_dump. Si aucun nom de base de données n'est spécifié, pg_restore génère un script contenant les commandes SQL nécessaires à la recréation de la base de données, comme dans pg_dump.
Utilisation :
-- Connect to an existing database and restore the backup archive
pg_restore -d database_name outputfile.dump
-- Create and restore the database from the backup archive
pg_restore -C -d database_name outputfile.dump
Commande psql COPY
psql est une interface client de ligne de commande pour Cloud SQL pour PostgreSQL. À l'aide de la commande COPY, psql lit le fichier spécifié dans les arguments de commande et achemine les données entre le serveur et le système de fichiers local.
Utilisation :
-- Connect to an existing database and restore the backup archive psql -p 5432 -U username -h cloud_sql_instance_ip -d database_name -c "\copy emps from '/opt/files/inputfile.csv' WITH csv;" -W
Exportation/importation Cloud SQL pour PostgreSQL :
Les liens de documentation suivants montrent comment utiliser l'outil gsutil et la CLI Google Cloud pour interagir avec l'instance Cloud SQL et avec Cloud Storage afin de réaliser les opérations d'exportation et d'importation.
Sauvegarde et restauration au niveau de l'instance
Dans Cloud SQL, les tâches de sauvegarde et de récupération sont gérées via des sauvegardes de bases de données automatiques et à la demande.
Les sauvegardes permettent de restaurer une instance Cloud SQL afin de récupérer des données perdues ou de corriger un problème. Nous vous recommandons d'activer les sauvegardes automatiques pour toute instance contenant des données que vous devez protéger contre toute perte ou dommage.
Vous pouvez créer une sauvegarde à tout moment, ce qui est utile si vous êtes sur le point d'effectuer une opération risquée sur votre base de données, ou si vous avez besoin d'une sauvegarde et ne souhaitez pas attendre l'intervalle de sauvegarde. Vous pouvez créer des sauvegardes à la demande pour n'importe quelle instance, que les sauvegardes automatiques soient activées ou non.
Les sauvegardes à la demande ne sont pas automatiquement supprimées comme le sont les sauvegardes automatiques. Elles persistent jusqu'à ce que vous les supprimiez ou que leur instance soit supprimée. Pour cette raison, les sauvegardes à la demande peuvent affecter vos frais de facturation à long terme si vous ne les supprimez pas.
Lorsque vous activez les sauvegardes automatiques, vous devez spécifier un intervalle de sauvegarde de quatre heures. La sauvegarde commence pendant cet intervalle. Si possible, planifiez les sauvegardes en période de faible activité de l'instance. Si vos données n'ont pas été modifiées depuis la dernière sauvegarde, aucune nouvelle sauvegarde n'est effectuée.
Cloud SQL conserve jusqu'à 7 sauvegardes automatiques pour chaque instance. Le stockage utilisé par les sauvegardes est facturé à un taux réduit en fonction de la région dans laquelle les sauvegardes sont stockées. Pour consulter la liste des tarifs, consultez la page Tarifs de Cloud SQL pour PostgreSQL.
Vous pouvez utiliser la restauration de l'instance de base de données Cloud SQL pour PostgreSQL pour restaurer la même instance, remplacer les données existantes ou restaurer une autre instance. Cloud SQL pour PostgreSQL vous permet également de restaurer une base de données PostgreSQL à un moment précis si l'option de sauvegarde automatique est activée.
Pour plus d'informations sur la création et la gestion de sauvegardes à la demande et automatiques, consultez la section Créer et gérer des sauvegardes à la demande et automatiques.
Le tableau suivant répertorie les opérations de sauvegarde et de restauration courantes dans Oracle, et leur équivalent dans Cloud SQL pour PostgreSQL :
| Description | Oracle (Gestionnaire de récupération – RMAN) |
Cloud SQL pour PostgreSQL |
|---|---|---|
| Sauvegardes automatiques planifiées | Créez une tâche DBMS_SCHEDULER qui exécutera le script RMAN de manière planifiée. |
gcloud sql instances patch INSTANCE_NAME --backup-start-time HH:MM
|
| Sauvegardes manuelles de la base de données complète | BACKUP DATABASE PLUS ARCHIVELOG;
|
gcloud sql backups create --async --instance INSTANCE_NAME
|
| Restaurer la base de données | RUN
|
gcloud sql backups list --instance INSTANCE_NAME
|
| Différentiel incrémentiel | BACKUP INCREMENTAL LEVEL 0 DATABASE;
|
Toutes les sauvegardes sont incrémentielles et n'offrent pas de choix concernant le type incrémentiel. |
| Cumulatif incrémentiel | BACKUP INCREMENTAL LEVEL 0 CUMULATIVE DATABASE;
|
Toutes les sauvegardes sont incrémentielles et n'offrent pas de choix concernant le type incrémentiel. |
| Restaurer la base de données à un moment précis | RUN
|
gcloud sql instances clone SOURCE_INSTANCE_NAME NEW_INSTANCE_NAME \
|
| Sauvegarder les journaux d'archivage de la base de données | BACKUP ARCHIVELOG ALL;
|
Non compatible. |
Instances de secours pour les opérations en lecture seule et mise en œuvre de la reprise après sinistre
Oracle Active Data Guard permet d'utiliser une instance de secours en tant que point de terminaison en lecture seule pendant que les nouvelles données sont appliquées via les journaux de rétablissement et d'archive. Vous pouvez également exploiter Oracle GoldGate pour bénéficier d'une instance supplémentaire pour la lecture pendant que les modifications de données sont appliquées en temps réel. Le service sert ainsi de solution de capture de données modifiées (CDC, Change Data Capture).
Cloud SQL pour PostgreSQL utilise une instance de secours pour la haute disponibilité. Cette instance est synchronisée avec l'instance principale via la réplication au niveau du disque. Contrairement à Active Data Guard, elle n'est pas ouverte aux lectures ou écritures. Si l'instance principale tombe en panne ou ne répond plus pendant environ 60 secondes, l'instance principale bascule automatiquement vers l'instance de secours. En quelques secondes, les rôles sont échangés et la nouvelle instance principale prend le relais.
Cloud SQL pour PostgreSQL propose également des instances dupliquées avec accès en lecture pour s'adapter aux requêtes de lecture. Elles sont conçues pour décharger une part des lectures de l'instance principale et ne sont pas utilisées en tant qu'instance de secours pour la reprise après sinistre. Contrairement à l'instance de secours, les instances dupliquées avec accès en lecture sont synchronisées avec l'instance principale de manière asynchrone. Elles peuvent se trouver dans une zone ou une région différente de l'instance principale. Vous pouvez créer une instance dupliquée avec accès en lecture à l'aide de la console Google Cloud ou de gcloud CLI. Notez que certaines opérations nécessitent un redémarrage de l'instance (par exemple, l'ajout de la haute disponibilité à une instance principale existante).
Journalisation et surveillance
Le fichier journal d'alertes d'Oracle est la principale source permettant d'identifier les événements système généraux et les événements d'erreur afin de comprendre le cycle de vie des instances de base de données Oracle (principalement pour la résolution des problèmes liés aux événements d'échec et d'erreur).
Le journal d'alertes Oracle affiche les informations suivantes :
- Erreurs et avertissements liés aux instances de base de données Oracle (
ORA-et numéro d'erreur) - Événements de démarrage et d'arrêt des instances de base de données Oracle
- Problèmes de réseau et de connexion
- Événements de basculement des journaux de rétablissement de base de données
- Les fichiers de suivi Oracle peuvent être mentionnés avec un lien afin de fournir plus de détails sur un événement de base de données spécifique.
Oracle fournit des fichiers journaux dédiés pour différents services, tels que LISTENER, ASM et Enterprise Manager (OEM), qui n'ont pas de composants équivalents dans Cloud SQL pour PostgreSQL.
Afficher les journaux d'opérations Cloud SQL pour PostgreSQL
Cloud Logging est la plate-forme principale pour afficher toutes les entrées de journal dans postgres.log (équivalent de alert.log dans Oracle). Vous pouvez effectuer un filtrage par niveau d'événement (par exemple, "Critique", "Erreur" ou "Avertissement"). Le filtrage des événements par période et par texte libre est également disponible.
Surveiller l'instance de base de données Cloud SQL pour PostgreSQL
Les principaux tableaux de bord de surveillance d'Oracle font partie des produits OEM et Grid/Cloud Control (par exemple, les graphiques des activités prédominantes) et sont utiles pour la surveillance en temps réel des instances de base de données au niveau de la session ou de l'instruction SQL. Cloud SQL pour PostgreSQL propose des fonctionnalités de surveillance similaires via la console Google Cloud. Vous pouvez afficher des informations récapitulatives sur les instances de base de données Cloud SQL pour PostgreSQL avec plusieurs métriques de surveillance, telles que l'utilisation du processeur, l'utilisation de l'espace de stockage, l'utilisation de la mémoire, les opérations de lecture/écriture, les octets d'entrée/de sortie, les connexions actives, etc.
Cloud Logging accepte des métriques de surveillance supplémentaires pour Cloud SQL pour PostgreSQL. La capture d'écran suivante montre le graphique des requêtes Cloud SQL pour PostgreSQL des 12 dernières heures.
Surveiller l'instance dupliquée avec accès en lecture Cloud SQL pour PostgreSQL
Vous pouvez surveiller les instances dupliquées avec accès en lecture de la même manière que vous surveillez l'instance principale, à l'aide des métriques de surveillance de la console Google Cloud (comme décrit précédemment). En outre, il existe une métrique de surveillance dédiée à la surveillance du délai de duplication, qui détermine le décalage en secondes entre l'instance maîtresse et l'instance dupliquée avec accès en lecture (vous pouvez surveiller cette métrique depuis l'onglet de présentation de l'instance dupliquée avec accès en lecture dans la console Google Cloud).
Vous pouvez récupérer l'état de duplication à l'aide de la CLI gcloud :
gcloud sql instances describe REPLICA_NAME
Vous pouvez également effectuer la surveillance de la réplication à partir d'un client PostgreSQL à l'aide de commandes, ce qui renseigne sur l'état des bases de données principale et de secours.
Vous pouvez employer l'instruction SQL suivante pour vérifier l'état de l'instance dupliquée avec accès en lecture :
postgres=> select * from pg_stat_replication;
Surveiller Cloud SQL pour PostgreSQL
Cette section décrit les méthodes de surveillance Cloud SQL pour PostgreSQL de base qui sont considérées comme des tâches de routine effectuées par un administrateur de base de données (Oracle ou Cloud SQL pour PostgreSQL).
Surveillance des sessions
La surveillance des sessions Oracle s'effectue en interrogeant les vues de performances dynamiques appelées vues "V$". Les vues V$SESSION et V$PROCESS sont couramment utilisées pour obtenir des informations en temps réel sur l'activité actuelle de la base de données, grâce à des instructions SQL. Vous pouvez surveiller l'activité de la session en interrogeant la vue dynamique pg_stat_activity :
postgres=> select * from pg_stat_activity;
Surveillance des transactions de longue durée
Pour identifier les requêtes de longue durée, appliquez les filtres adéquats sur des colonnes telles que query_start et state dans la vue dynamique pg_stat_activity.
Surveillance des verrous
Vous pouvez surveiller les verrous de base de données à l'aide de la vue dynamique pg_locks, qui fournit des informations en temps réel sur les occurrences de verrous pouvant entraîner des problèmes de performances.
Étape suivante
- En savoir plus sur les comptes utilisateur Cloud SQL for PostgreSQL.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.