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 des instances Cloud SQL pour MySQL de deuxième génération, version 5.7. La série comprend les parties suivantes :
- Migrer des utilisateurs Oracle vers Cloud SQL pour MySQL : terminologie et fonctionnalités
- Migrer des utilisateurs Oracle vers Cloud SQL pour MySQL : types de données, utilisateurs et tables
- Migrer des utilisateurs Oracle vers Cloud SQL pour MySQL : requêtes, procédures stockées, fonctions et déclencheurs
- Migrer des utilisateurs Oracle vers Cloud SQL pour MySQL : sécurité, opérations, surveillance et journalisation (ce document)
Sécurité
Cette section explique les différences de chiffrement de données entre Oracle et Cloud SQL pour MySQL, et aborde l'audit du contrôle des accès Cloud SQL pour MySQL.
Chiffrement des données Oracle
Au-delà de la gestion de l'authentification et des droits des utilisateurs, Oracle propose le mécanisme de chiffrement transparent des données (TDE, Transparent Data Encryption), qui ajoute une couche de chiffrement supplémentaire pour la sécurité des données au repos au niveau du système d'exploitation. Une fois configuré, le mécanisme TDE Oracle est mis en œuvre automatiquement par le système et ne nécessite aucune interaction manuelle de la part des utilisateurs. Afin de mettre en œuvre le mécanisme TDE, nous vous recommandons de le configurer explicitement (par commande) sur les objets de base de données requis et compatibles qui peuvent accepter ce type de chiffrement (espace de table, table ou colonne, par exemple). Pour gérer la sécurité des données en transit, nous vous conseillons de mettre en œuvre une solution de sécurité réseau.
Chiffrement des données Cloud SQL pour MySQL
Google Cloud fournit plusieurs niveaux de chiffrement pour protéger les données client au repos dans ses produits, y compris Cloud SQL. Cloud SQL utilise le chiffrement AES-128 ou AES-256. Pour en savoir plus, consultez l'article sur le chiffrement au repos. Contrairement au chiffrement Oracle (qui doit être mis en œuvre via des actions de configuration), Google Cloud chiffre les données client au repos, sans qu'aucune action ne soit requise. Du point de vue de la conversion de schéma, aucune intervention n'est nécessaire, et le chiffrement reste transparent pour l'utilisateur.
Pour mieux comprendre la façon dont Google Cloud gère le chiffrement des données en transit, consultez la section Comment le chiffrement est-il géré pour les données en transit.
Audits
Oracle propose plusieurs méthodes d'audit, telles que l'audit standard et l'audit précis. En revanche, MySQL ne fournit pas de solutions d'audit équivalentes par défaut. Pour contourner cette limitation, vous pouvez exploiter les tableaux de bord et la surveillance Google Cloud. Toutefois, afin de capturer les opérations LMD/LDD de base de données, vous pouvez utiliser les journaux généraux, d'erreurs et de requêtes lentes comme solution d'audit plus fiable.
Pour mettre en œuvre cette solution, nous vous recommandons d'activer le journal des requêtes lentes et le journal général à l'aide de l'instance FLAGS. En outre, vous devez gérer les règles de conservation de ces journaux en fonction des besoins de votre entreprise.
Vous pouvez collecter des informations d'audit à l'aide des journaux d'audit Google Cloud. Ces journaux couvrent trois niveaux principaux :
- Journaux d'audit pour les activités d'administration (activés par défaut)
- Journaux d'audit pour l'accès aux données (désactivés par défaut)
- Découvrez comment configurer les journaux d'accès aux données.
- Sachez que ces journaux n'enregistrent pas les opérations d'accès aux données sur les ressources accessibles sans connexion à Google Cloud.
- Journaux d'audit pour les événements système (activés par défaut)
Afficher les journaux d'audit Google Cloud
Pour afficher les journaux d'audit, accédez à console Google Cloud > Accueil > Activité.
Vous pouvez filtrer la précision des informations entre les niveaux d'audit. La capture d'écran suivante montre un audit d'activité d'administration.
Page Cloud Logging
Pour consulter la page de journalisation, accédez à console Google Cloud > Cloud Logging.
Vous pouvez filtrer la précision des informations entre les types de journaux. La capture d'écran suivante montre un audit de journal général (données d'audit pour l'utilisateur, l'hôte et l'instruction SQL).
Contrôle des accès Cloud SQL pour MySQL
Les utilisateurs peuvent se connecter à l'instance Cloud SQL pour MySQL via un client MySQL 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. Ces options sont décrites plus en détail sur la page Contrôle de l'accès aux instances.
Opérations
Cette section aborde l'exportation et l'importation, la sauvegarde et la restauration au niveau de l'instance, le planificateur d'événements MySQL (pour les tâches de base de données), ainsi que les instances de secours pour les opérations en lecture seule et 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 et imp). Les utilitaires mysqldump et mysqlimport constituent des commandes SQL é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 MySQL 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 MySQL mysqldump et mysqlimport pour exécuter des opérations d'exportation et d'importation.
Les utilitaires MySQL mysqldump et mysqlimport s'exécutent au niveau du client (dans le cadre des programmes clients MySQL), et se connectent à distance à l'instance Cloud SQL pour MySQL. Les fichiers de vidage sont créés côté client.
mysqldump:
Un utilitaire client effectue des sauvegardes logiques et des importations de données (au format sql). Cela produit un ensemble d'instructions SQL qui peuvent être exécutées pour reproduire les définitions d'objets et les données de table de la base de données d'origine. L'utilitaire mysqldump peut également générer un résultat au format CSV, au format XML ou dans un autre format de texte délimité. L'avantage principal de ce format de sortie est qu'il vous permet d'afficher ou de modifier le résultat d'exportation avant la restauration, car il s'agit d'un fichier texte. Le principal désavantage est qu'il n'est pas conçu comme une solution rapide ou évolutive permettant de sauvegarder d'importantes quantités de données.
Utilisation de mysqldump :
-- Single database backup & specific tables backup # mysqldump database_name > outpitfile.sql # mysqldump database_name tbl1 tbl2 > outpitfile.sql -- Back up all databases # mysqldump --all-databases > all_databases.sql -- Ignore a given table # mysqldump --databases db1 --ignore-table db1.tbl > outpitfile.sql -- Back up metadata only - Schema only # mysqldump --no-data db1 > bck.sql -- Include stored procedures and functions (routines) # mysqldump db1 --routines > db1.sql -- Back up only rows by a given WHERE condition # mysqldump db1 tbl1 --where="col1=1" > bck.sql -- Include triggers for each dumped table (default) # mysqldump db1 tbl1 —triggers > bck.sql
mysqlimport:
Il s'agit d'un programme client qui fournit une interface de ligne de commande à l'instruction SQL LOAD
DATA INFILE. mysqlimport est fréquemment utilisé pour l'importation de données à partir de fichiers texte ou CSV dans une table MySQL avec une structure correspondante.
Oracle SQL*Loader peut être converti au format mysqlimport, car ces deux éléments partagent la même fonctionnalité de chargement de données à partir d'un fichier externe.
Utilisation de mysqlimport :
-- Example of loading data from a CSV file into a table:
-- Create a table named csv_file
mysql> create table file(col1 int, col2 varchar(10));
-- Create a CSV file (delimited by tab)
# echo 1 A > file.csv
# echo 2 B >> file.csv
# echo 3 C >> file.csv
-- Import the CSV file into the csv_file table
-- Note that the file and table name must be named identically
# mysqlimport -u USER -p -h HOSTNAME/IP DB_NAME --local file.csv
csv_file: Records: 3 Deleted: 0 Skipped: 0 Warnings: 0
-- Verify
# mysql -u USER -p -h HOSTNAME/IP DB_NAME -e "SELECT * FROM file"
+------+------+
| col1 | col2 |
+------+------+
| 1 | A |
| 2 | B |
| 3 | C |
+------+------+
-- Example of using LOAD DATA INFILE to load a CSV file (using the same
table from the previous example, with the CSV delimiter defined by
comma)
mysql> LOAD DATA LOCAL INFILE 'file.csv' INTO TABLE file
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n' (col1, col2);
mysql> SELECT * FROM file;
+------+------+
| col1 | col2 |
+------+------+
| 1 | A |
| 2 | B |
| 3 | C |
+------+------+
Exportation/Importation Cloud SQL pour MySQL :
Les liens de documentation suivants montrent comment employer gcloud CLI pour interagir avec l'instance Cloud SQL et avec Cloud Storage afin d'appliquer des opérations d'exportation et d'importation.
Sauvegarde et restauration au niveau de l'instance
Il s'agit d'une opération simple qui permet de migrer depuis Oracle RMAN ou Data Pump et qui comprend des options de sauvegarde et de restauration supplémentaires (par exemple, des instantanés de VM, des sauvegardes à froid ou des outils tiers) vers Cloud SQL pour MySQL. Aucun code ni aucunes connaissances supplémentaires ne sont nécessaires. Vous pouvez gérer ce processus à l'aide de la console Google Cloud ou de la Google Cloud CLI. (Les exemples précédents ont été compilés avec des instances Cloud SQL de deuxième génération.)
Les types de méthodes de sauvegarde de base de données MySQL incluent les sauvegardes à la demande et les sauvegardes automatiques.
Vous pouvez utiliser la fonctionnalité de restauration d'instance de base de données Cloud SQL pour MySQL afin de restaurer une instance, d'écraser ses données existantes ou d'effectuer une restauration sur une autre instance. Cloud SQL pour MySQL vous permet également de restaurer une base de données MySQL à un moment précis à l'aide de la journalisation binaire avec l'option de sauvegarde automatique activée.
Cloud SQL pour MySQL permet de cloner une version indépendante de la base de données source. Cette fonctionnalité ne s'applique qu'à la base de données principale (maître) ou à un autre clone, et ne peut pas être extraite d'une instance dupliquée avec accès en lecture. Vous pouvez également exploiter cette fonctionnalité pour restaurer une instance MySQL à un moment précis, en autorisant la récupération de données si nécessaire. Vous pouvez restaurer une base de données Cloud SQL pour MySQL à l'aide de la console Google Cloud ou de la gcloud CLI.
Planificateur d'événements MySQL (tâches de base de données)
Pour initier des procédures de base de données prédéfinies, les fonctionnalités du planificateur d'événements MySQL sont équivalentes à celles fournies par les packages Oracle DBMS_JOBS et DBMS_SCHEDULER. Par défaut, le paramètre de base de données event_scheduler est défini sur OFF. Si nécessaire, il doit être remplacé par ON à l'aide des options Cloud SQL.
Vous pouvez utiliser le planificateur d'événements MySQL pour exécuter une commande LMD/LDD explicite ou pour programmer une fonction ou une procédure stockée à un moment spécifique et avec une certaine logique.
Points à prendre en compte pour la conversion des packages Oracle DBMS_JOBS et DBMS_SCHEDULER :
Toutes les tâches Oracle doivent être converties en syntaxe MySQL manuellement ou à l'aide d'outils de conversion PL/SQL disponibles sur le marché.
Utilisez l'instruction suivante pour vérifier la valeur actuelle du paramètre event_scheduler à partir d'une exécution cliente :
mysql> SHOW VARIABLES LIKE '%event_s%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| event_scheduler | ON |
+-----------------+-------+
Exemples de planificateurs d'événements :
Oracle DBMS_SCHEDULER :
SQL> BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'job_sessions_1d_del', job_type => 'PLSQL_BLOCK', job_action => 'BEGIN DELETE FROM sessions WHERE session_date < SYSDATE - 1; END;', start_date => SYSTIMESTAMP, repeat_interval => 'FREQ=DAILY', end_date => NULL, enabled => TRUE, comments => 'Deletes last day data from the sessions table'); END; /Conversion MySQL EVENT :
mysql> CREATE EVENT job_sessions_1d_del ON SCHEDULE EVERY 1 DAY COMMENT 'Deletes last day data from the sessions table' DO DELETE FROM sessions WHERE session_date < DATE_SUB(SYSDATE(), INTERVAL 1 DAY);Métadonnées du planificateur d'événements MySQL :
mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS \G; -- OR mysql> SHOW EVENTS FROM HR;
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 MySQL permet de séparer les lectures et les écritures à l'aide d'read-replicas, afin de diriger les lectures ou les charges de travail analytiques de l'instance principale vers une source dupliquée alternative quasiment en temps réel. Vous pouvez appliquer des paramètres sur les instances dupliquées avec accès en lecture Cloud SQL pour MySQL à l'aide de la console Google Cloud ou de gcloud CLI.
Cloud SQL pour MySQL accepte des options de réplication supplémentaires : la réplication vers une instance MySQL externe et la réplication depuis une instance MySQL externe.
Vous pouvez mettre en œuvre Oracle Active Data Guard and Oracle GoldenGate en tant que solution de reprise après sinistre en ajoutant une instance de secours déjà synchronisée avec l'instance principale.
Les instances répliquées avec accès en lecture Cloud SQL pour MySQL ne sont pas destinées à servir d'instances de secours pour les scénarios de reprise après sinistre. À cette fin, Cloud SQL permet de configurer une instance MySQL pour la haute disponibilité (à l'aide de la console Google Cloud ou de gcloud CLI).
Certaines opérations peuvent nécessiter un redémarrage d'instance (par exemple, l'ajout de haute disponibilité à une instance principale existante). Du point de vue du contrat de niveau de service haute disponibilité, si l'instance principale ne répond pas pendant environ 60 secondes, l'instance de secours haute disponibilité sera disponible lors de la reconnexion. Pour activer la haute disponibilité pour Cloud SQL pour MySQL, consultez ces instructions.
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.
En outre, 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 MySQL.
Types de journaux Cloud SQL pour MySQL :
| Type de journal MySQL | Description | Remarques |
|---|---|---|
| Journal d'activité | Contient des données sur les appels d'API ou d'autres opérations d'administration qui modifient la configuration ou les métadonnées d'une instance Cloud SQL pour MySQL. | Ce journal est l'un des trois journaux inclus dans Cloud Audit Logging. |
| Journal d'accès aux données | Contient des données sur les appels d'API qui lisent la configuration ou les métadonnées des ressources, ainsi que sur les appels d'API pilotés par l'utilisateur qui créent, modifient ou lisent des données de ressources fournies par l'utilisateur. | Ce journal est l'un des trois journaux inclus dans Cloud Audit Logging. Notez qu'il ne consigne que les opérations d'accès aux données sur les instances MySQL pour les événements accessibles sans connexion à Google Cloud. |
mysql.err |
Il s'agit du fichier journal principal MySQL, qui peut être comparé au journal d'alertes d'Oracle. Les deux journaux contiennent les événements des instances de base de données, tels que les événements de démarrage et d'arrêt, ainsi que les événements d'erreur et d'avertissement. | Guide pour le message d'erreur MySQL 5.7. |
mysql-slow.log |
Le journal des requêtes lentes MySQL collecte des données sur les requêtes qui dépassent la configuration prédéfinie, telles que celles dont la durée d'exécution est supérieure à deux secondes (la valeur par défaut est 10 secondes). | Désactivé par défaut. Pour activer ce journal, définissez les variables suivantes (paramètres de base de données) :
|
mysql-general.log |
Ce journal collecte des données sur les connexions et les déconnexions des clients, ainsi que sur les instructions SQL exécutées sur l'instance de base de données MySQL. Ce journal est utile pour le dépannage et est généralement désactivé (défini sur OFF) lorsque l'opération est terminée. |
Désactivé par défaut. Pour activer le journal, définissez les variables general_log sur ON. |
| Journal binaire | Le serveur MySQL emploie la journalisation binaire pour consigner toutes les instructions ayant modifié des données. Ce journal est principalement utilisé pour la sauvegarde et la duplication. | Par défaut, le paramètre de journalisation binaire est activé dans Cloud SQL pour MySQL pour permettre la récupération et le déploiement d'instances dupliquées avec accès en lecture.
Pour activer la journalisation binaire, définissez le paramètre de configuration log_bin sur ON. |
| Journal de relais | Contient les instructions reçues des journaux binaires principaux afin de mettre en œuvre toutes les modifications de données dans l'instance subordonnée (instance dupliquée avec accès en lecture). | Ne s'applique qu'aux instances secondaires (esclaves) et aux instances dupliquées avec accès en lecture. |
Afficher les journaux des opérations Cloud SQL pour MySQL
Cloud Logging est la plate-forme principale permettant d'afficher tous les détails des journaux. Vous pouvez sélectionner différents journaux et les filtrer 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.
Exemple
La capture d'écran suivante montre comment rechercher une requête spécifique dans le fichier mysql-slow.log en utilisant une période personnalisée comme critère de filtre.
Surveillance des instances de base de données MySQL
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 MySQL 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 MySQL 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 MySQL. La capture d'écran suivante montre le graphique des requêtes MySQL des 12 dernières heures.
Surveillance des instances dupliquées avec accès en lecture MySQL
Vous pouvez surveiller les instances dupliquées avec accès en lecture de la même manière qu'une instance maîtresse, à 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 principale 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 réplication à l'aide de gcloud CLI :
gcloud sql instances describe REPLICA_NAME
Vous pouvez également effectuer la surveillance de la réplication à l'aide des commandes d'un client MySQL, qui fournit un état pour les bases de données principale et subordonnée, ainsi que pour le journal binaire et le journal de relais.
Vous pouvez employer l'instruction SQL suivante pour vérifier l'état de l'instance dupliquée avec accès en lecture :
mysql> SHOW SLAVE STATUS;
Surveillance MySQL
Cette section décrit les méthodes de surveillance MySQL 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 MySQL).
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é des sessions dans MySQL à l'aide de commandes et d'instructions SQL. Par exemple, la commande MySQL SHOW PROCESSLIST fournit les détails suivants sur l'activité de session :
mysql> SHOW PROCESSLIST;
Vous pouvez également interroger et filtrer les résultats SHOW PROCESSLIST à l'aide d'une instruction SELECT :
mysql> SELECT * FROM information_schema.processlist;
Surveillance des transactions de longue durée
Pour identifier en temps réel les transactions de longue durée qui peuvent entraîner des problèmes de performances, vous pouvez interroger la vue dynamique information_schema.innodb_trx. Cette vue n'affiche que les enregistrements des transactions ouvertes exécutées dans l'instance de base de données MySQL.
Surveillance des verrous
Vous pouvez surveiller les verrous de base de données à l'aide de la vue dynamique information_schema.innodb_locks, qui fournit des informations en temps réel sur les occurrences de verrous pouvant entraîner des problèmes de performances.