Utiliser une importation gérée pour configurer la réplication à partir de bases de données externes

MySQL | PostgreSQL | SQL Server

Cette page explique comment configurer et utiliser une importation gérée pour les données lors de la réplication d'un serveur externe vers Cloud SQL.

Vous devez suivre intégralement la procédure présentée sur cette page. Lorsque vous avez terminé, vous pouvez administrer et surveiller l'instance de représentation source de la même manière que toute autre instance Cloud SQL.

Avant de commencer

Avant de commencer, effectuez les étapes suivantes :

Vérifier les paramètres de réplication

Une fois la configuration terminée, assurez-vous que l'instance dupliquée Cloud SQL peut effectuer la réplication à partir du serveur externe.

Les paramètres de synchronisation externe suivants doivent être corrects.

La connectivité entre l'instance dupliquée Cloud SQL et le serveur externe
Les privilèges de l'utilisateur de réplication
Compatibilité des versions
L'instance dupliquée Cloud SQL n'est pas déjà en cours de réplication

Pour vérifier ces paramètres, ouvrez un terminal Cloud Shell et saisissez les commandes suivantes :

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettings

exemple

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings

Ces appels renvoient une liste de type sql#externalSyncSettingErrorList.

Si la liste est vide, aucune erreur ne s'affiche. Une réponse sans erreur s'affiche comme suit :

  {
    "kind": "sql#externalSyncSettingErrorList"
  }

Propriété	Description
`SYNC_MODE`	Assurez-vous que l'instance répliquée Cloud SQL et le serveur externe sont synchronisés après la configuration de la réplication. Les modes de synchronisation incluent `EXTERNAL_SYNC_MODE_UNSPECIFIED`, `ONLINE` et `OFFLINE`.
`SYNC_PARALLEL_LEVEL`	Vérifiez le paramètre qui contrôle la vitesse à laquelle les données des tables d'une base de données sont transférées. Les valeurs suivantes sont disponibles : `min:` utilise la plus faible quantité de ressources de calcul sur la base de données. Il s'agit de la vitesse la plus lente pour transférer des données. `optimal:` offre des performances équilibrées avec une charge optimale sur la base de données. `max:` fournit la vitesse la plus élevée pour le transfert de données, mais cela peut entraîner une charge accrue sur la base de données. Remarque : La valeur par défaut de ce paramètre est `optimal`, car elle offre une vitesse de transfert des données satisfaisante et a un impact raisonnable sur la base de données. Nous vous recommandons d'utiliser cette valeur.
`PROJECT_ID`	L'ID de votre projet Google Cloud.
`REPLICA_INSTANCE_ID`	ID de votre instance dupliquée Cloud SQL.

Démarrer la réplication sur le serveur externe

Après avoir vérifié que vous pouvez répliquer à partir du serveur externe, démarrez la réplication. La vitesse de réplication pour le processus d'importation initial peut atteindre 500 Go par heure. Cependant, cette vitesse peut varier en fonction du niveau de machine, de la taille du disque de données, du débit du réseau et de la nature de votre base de données.

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "skipVerification": "SKIP_VERIFICATION",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSync

exemple

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

Valeur	Description
`SYNC_MODE`	Vérifiez que l'instance répliquée Cloud SQL et le serveur externe sont synchronisés après la configuration de la réplication.
`SKIP_VERIFICATION`	Indique si l'étape de validation intégrée doit être ignorée avant de synchroniser vos données. Ce paramètre n'est recommandé que si vous avez déjà validé vos paramètres de réplication.
`SYNC_PARALLEL_LEVEL`	Indiquez un paramètre qui contrôle la vitesse à laquelle les données des tables d'une base de données sont transférées. Les valeurs suivantes sont disponibles : `min:` utilise la plus faible quantité de ressources de calcul sur la base de données. Il s'agit de la vitesse la plus lente pour transférer des données. `optimal:` offre des performances équilibrées avec une charge optimale sur la base de données. `max:` fournit la vitesse la plus élevée pour le transfert de données, mais cela peut entraîner une charge accrue sur la base de données. Remarque : La valeur par défaut de ce paramètre est `optimal`, car elle offre une vitesse de transfert des données satisfaisante et a un impact raisonnable sur la base de données. Nous vous recommandons d'utiliser cette valeur.
`PROJECT_ID`	L'ID de votre projet Google Cloud.
`REPLICA_INSTANCE_ID`	ID de votre instance dupliquée Cloud SQL.

Surveillez la migration.

Une fois la réplication lancée à partir du serveur externe, vous devez surveiller la réplication. Pour en savoir plus, consultez la section Surveiller la réplication. Vous pouvez ensuite terminer votre migration.

Résoudre les problèmes

Envisagez les options de dépannage suivantes :

Problème	Dépannage
L'instance répliquée avec accès en lecture n'a pas commencé à se répliquer lors de la création.	Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question.
Impossible de créer l'instance dupliquée avec accès en lecture : erreur invalidFlagValue.	L'un des indicateurs de la requête n'est pas valide. Il peut s'agir d'une option que vous avez explicitement définie ou d'une option définie sur une valeur par défaut. Tout d'abord, vérifiez que la valeur de l'option `max_connections` est supérieure ou égale à la valeur principale. Si l'option `max_connections` est définie correctement, inspectez les journaux dans Cloud Logging pour rechercher l'erreur réelle.
Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue.	Les fichiers journaux indiquent probablement une erreur plus spécifique. Inspectez les journaux dans Cloud Logging pour rechercher l'erreur en question. Si l'erreur est : `set Service Networking service account as servicenetworking.serviceAgent role on consumer project`, désactivez et réactivez `Service Networking API`. Cette action crée le compte de service nécessaire pour poursuivre le processus.
Le disque est saturé.	Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée. Modifiez l'instance principale en augmentant la taille du disque.
L'espace disque augmente considérablement.	Un emplacement qui n'est pas activement utilisé pour suivre les données oblige PostgreSQL à conserver les segments WAL indéfiniment, ce qui entraîne une augmentation permanente de l'espace disque. Si vous utilisez les fonctionnalités de réplication logique et de décodage logique de Cloud SQL, les emplacements de réplication sont créés et supprimés automatiquement. Vous pouvez détecter les emplacements de réplication inutilisés en interrogeant la vue système `pg_replication_slots` et en filtrant suivant la colonne `active`. La suppression des emplacements inutilisés, en vue d'éliminer des segments WAL, s'effectue à l'aide de la commande `pg_drop_replication_slot`.
L'instance dupliquée utilise trop de mémoire.	L'instance dupliquée met en cache les opérations de lecture souvent demandées dans une mémoire temporaire, ce qui peut l'amener à utiliser plus de mémoire que l'instance principale. Redémarrez l'instance dupliquée afin de récupérer l'espace de mémoire temporaire.
La duplication s'est arrêtée.	La limite de stockage maximale a été atteinte et l'augmentation automatique de l'espace de stockage n'est pas activée. Modifiez l'instance pour activer `automatic storage increase`.
Le délai de duplication est systématiquement long.	La charge d'écriture est trop élevée pour que l'instance dupliquée puisse la traiter. Le délai de duplication s'allonge lorsque le thread SQL d'une instance dupliquée ne parvient pas à suivre le thread d'E/S. Certains types de requêtes ou de charges de travail peuvent allonger le délai de duplication de manière temporaire ou permanente pour un schéma donné. Voici quelques causes typiques affectant le délai de duplication : Requêtes lentes sur l'instance dupliquée. Recherchez-les et corrigez-les. Toutes les tables doivent avoir une clé unique/primaire. Chaque mise à jour d'une table sans clé unique/primaire entraîne une analyse complète des tables de l'instance dupliquée. Les requêtes telles que `DELETE ... WHERE field < 50000000` allongent le délai de duplication, dans le cas des duplications basées sur les lignes, car un grand nombre de mises à jour s'accumulent sur l'instance dupliquée. Voici quelques solutions possibles : Modifiez l'instance pour augmenter la taille de l'instance dupliquée. Réduisez la charge sur la base de données. Envoyez du trafic en lecture à l'instance dupliquée avec accès en lecture. Indexez les tables. Identifiez et corrigez les requêtes d'écriture lentes. Recréez l'instance dupliquée.
Erreurs lors de la reconstruction d'index dans PostgreSQL 9.6.	Une erreur de PostgreSQL vous indique que vous devez reconstruire un index particulier. Cette opération n'est possible que sur l'instance principale. Si vous créez une nouvelle instance dupliquée, vous obtiendrez rapidement la même erreur. Les index de hachage ne sont pas propagés aux instances dupliquées dans les versions de PostgreSQL antérieures à la version 10. Si vous devez absolument utiliser des index de hachage, effectuez une mise à niveau vers PostgreSQL 10 ou une version ultérieure. Sinon, si vous souhaitez également utiliser des instances dupliquées, n'utilisez pas d'index de hachage dans PostgreSQL 9.6.
La requête sur l'instance principale est toujours en cours d'exécution.	Après avoir créé une instance répliquée, la requête `SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica'` doit s'exécuter en continu sur votre instance principale.
La création d'une instance dupliquée échoue avec un délai d'expiration.	Les transactions non validées de longue durée sur l'instance principale peuvent entraîner l'échec de la création d'une instance dupliquée avec accès en lecture. Recréez l'instance dupliquée après avoir arrêté toutes les requêtes en cours d'exécution.
Si l'instance principale et l'instance dupliquée disposent de tailles de processeurs virtuels différentes, des problèmes de performances des requêtes peuvent survenir, car l'optimiseur de requêtes prend en compte les tailles de processeurs virtuels.	Pour résoudre ce problème, procédez comme suit : Activez l'option log_duration et définissez le paramètre `log_statement` sur `ddl`. Vous obtenez ainsi à la fois les requêtes et le temps d'exécution sur la base de données. Toutefois, en fonction de votre charge de travail, cela peut entraîner des problèmes de performances. Sur l'instance principale et sur l'instance dupliquée avec accès en lecture, exécutez `explain analyze` pour les requêtes. Comparez le plan de requête et recherchez les différences. S'il s'agit d'une requête spécifique, modifiez-la. Par exemple, vous pouvez modifier l'ordre des jointures pour voir si vous obtenez de meilleures performances.

Examiner vos journaux de réplication

Lorsque vous vérifiez les paramètres de réplication, des journaux sont générés.

Pour afficher ces journaux, procédez comme suit :

Accédez à la visionneuse de journaux dans Google Cloud Console.

Accéder à la visionneuse de journaux
Sélectionnez l'instance dupliquée Cloud SQL dans la liste déroulante Instance.
Sélectionnez le fichier journal replication-setup.log.

Si l'instance dupliquée Cloud SQL ne parvient pas à se connecter au serveur externe, vérifiez les points suivants :

Tous les pare-feu du serveur externe sont configurés pour autoriser les connexions à partir de l'adresse IP sortante de l'instance dupliquée Cloud SQL.
Votre configuration SSL/TLS est correcte.
Votre utilisateur de réplication, hôte et mot de passe sont corrects.

Étape suivante

Apprenez-en plus sur la mise à jour des instances.
Apprenez-en plus sur la gestion des instances dupliquées.
Apprenez-en plus sur la surveillance des instances.
Découvrez comment promouvoir votre instance dupliquée Cloud SQL.