Créer des instances dupliquées avec accès en lecture

Cette page vous explique comment créer une instance dupliquée avec accès en lecture pour une instance Cloud SQL.

Une instance dupliquée avec accès en lecture est une copie de l'instance principale qui reflète quasiment en temps réel les modifications apportées à l'instance principale, dans des circonstances normales. Vous pouvez utiliser une instance dupliquée avec accès en lecture pour décharger l'instance principale des requêtes de lecture ou du trafic d'analyse.

En outre, pour la reprise après sinistre, vous pouvez procéder à une migration régionale. Si une instance dupliquée est une Instance dupliquée interrégionale, vous pouvez effectuer un basculement vers une autre région. Plus précisément, vous pouvez promouvoir une instance dupliquée en instance autonome (dans ce cas, les instances dupliquées existantes ne considéreront pas cette instance comme principale).

Pour en savoir plus sur le fonctionnement de la réplication, consultez la page Réplication dans Cloud SQL.

Avant de commencer

Si vous créez la première instance dupliquée pour cette instance, assurez-vous qu'elle répond aux exigences des instances principales. En savoir plus

Créer une instance dupliquée avec accès en lecture

La procédure de création d'une instance dupliquée avec accès en lecture est décrite ci-dessous.

Console

  1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

    Accéder à la page Instances Cloud SQL

  2. Recherchez l'instance pour laquelle vous souhaitez créer une instance dupliquée, puis ouvrez le menu more actions tout à droite de la liste.
  3. Sélectionnez Créer une instance dupliquée avec accès en lecture.

    Si cette option ne s'affiche pas, cela signifie que l'instance a déjà été dupliquée. vous ne pouvez pas dupliquer une instance dupliquée.

  4. Si les sauvegardes et la journalisation binaire sont activées sur l'instance, passez à l'étape suivante. Sinon, sélectionnez Automatiser les sauvegardes et Activer la journalisation binaire, cliquez sur Continuer, puis sur Enregistrer et redémarrer pour redémarrer l'instance.

    L'activation de la journalisation binaire entraîne le redémarrage de l'instance.

  5. Dans la section Personnaliser votre instance de la page, mettez à jour les paramètres de votre instance dupliquée. Commencez par cliquer sur Afficher les options de configuration pour afficher les groupes de paramètres. Développez ensuite les groupes souhaités pour examiner et personnaliser les paramètres. Un résumé de toutes les options sélectionnées s'affiche à droite. La personnalisation de ces paramètres est facultative. Des valeurs par défaut sont attribuées chaque fois qu'aucune personnalisation n'est effectuée.

    Pour en savoir plus sur chaque paramètre, consultez la page Paramètres des instances.

    Par exemple, pour autoriser d'autres services Google Cloud, tels que BigQuery, à accéder aux données dans Cloud SQL et à exécuter des requêtes sur ces données via une connexion interne, développez le groupe Connexions. puis décochez la case Adresse IP publique.

  6. Cliquez sur Créer une instance répliquée.

    Cloud SQL crée une sauvegarde si nécessaire et génère l'instance dupliquée. Vous revenez à la page de l'instance principale.

gcloud

  1. Vérifiez l'état de l'instance principale : 
    gcloud sql instances describe PRIMARY_INSTANCE_NAME

    Si la propriété databaseReplicationEnabled est définie sur true, l'instance est déjà une instance dupliquée. Or, vous ne pouvez pas créer une instance dupliquée à partir d'une instance dupliquée.

  2. Si la propriété enabled sous backupConfiguration est définie sur false, activez les sauvegardes pour l'instance principale : 
    gcloud sql instances patch PRIMARY_INSTANCE_NAME \
--backup-start-time=>HH:MM
    Le paramètre backup-start-time est indiqué au format 24 heures dans le fuseau horaire UTC±00 et spécifie le début d'un intervalle de sauvegarde de quatre heures. Les sauvegardes peuvent commencer à tout moment pendant l'intervalle de sauvegarde.
  3. Si la propriété binaryLogEnabled est définie sur false, activez les journaux binaires sur l'instance principale : 
    gcloud sql instances patch PRIMARY_INSTANCE_NAME \
--enable-bin-log
    L'activation des journaux binaires entraîne le redémarrage de l'instance.
  4. Créez l'instance répliquée : 
    gcloud sql instances create REPLICA_NAME \
--master-instance-name=PRIMARY_INSTANCE_NAME

    Si nécessaire, vous pouvez spécifier un niveau différent à l'aide du paramètre --tier.

    Vous pouvez spécifier une autre région à l'aide du paramètre --region.

    Vous pouvez ajouter d'autres paramètres d'instance. Pour en savoir plus, consultez la documentation sur la commande gcloud sql instances create.

    Si l'instance principale ne dispose que d'une adresse IP interne et que vous souhaitez autoriser d'autres services Google Cloud, tels que BigQuery, à accéder aux données dans Cloud SQL et à effectuer des requêtes sur ces données via une connexion interne, ajoutez le paramètre --enable-google-private-path à la commande.

    Vous devez créer l'instance dupliquée sur le même réseau VPC que l'instance principale. Vous pouvez également spécifier une plage allocated-ip-range-name dans ce réseau VPC. Si aucune plage n'est spécifiée, l'instance dupliquée est créée dans une plage aléatoire.

  • La journalisation binaire est compatible avec les instances dupliquées avec accès en lecture (MySQL 5.7 et 8.0 uniquement. Non compatible avec les anciennes instances dupliquées de basculement à haute disponibilité). Activez la journalisation binaire sur une instance dupliquée avec la même commande gcloud CLI, en utilisant le nom de l'instance dupliquée au lieu du nom de l'instance principale. 
    gcloud sql instances patch REPLICA_INSTANCE_NAME \
--enable-bin-log

    La durabilité de la journalisation binaire sur l'instance dupliquée (mais pas sur l'instance principale) peut être définie avec l'option sync_binlog qui contrôle la fréquence à laquelle le serveur MySQL synchronise le journal binaire sur le disque.

    Les sauvegardes ne peuvent pas être activées sur les instances dupliquées, mais la journalisation binaire peut l'être sur une instance dupliquée même si les sauvegardes sont désactivées, ce qui n'est pas le cas pour l'instance principale.

    La durée de conservation des binlogs des instances dupliquées est automatiquement définie sur une journée, contrairement aux instances principales qui bénéficient de sept jours.

Terraform

Pour créer une instance dupliquée avec accès en lecture, utilisez une ressource Terraform. 

resource "google_sql_database_instance" "read_replica" {
  name                 = "mysql-replica-instance-name"
  master_instance_name = google_sql_database_instance.primary.name
  region               = "europe-west4"
  database_version     = "MYSQL_8_0"

  replica_configuration {
    failover_target = false
  }

  settings {
    tier              = "db-n1-standard-2"
    availability_type = "ZONAL"
    disk_size         = "100"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Appliquer les modifications

Pour appliquer votre configuration Terraform dans un projet Google Cloud, suivez les procédures des sections suivantes.

Préparer Cloud Shell

  1. Lancez Cloud Shell.

  2. Définissez le projet Google Cloud par défaut dans lequel vous souhaitez appliquer vos configurations Terraform.

    Vous n'avez besoin d'exécuter cette commande qu'une seule fois par projet et vous pouvez l'exécuter dans n'importe quel répertoire.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Les variables d'environnement sont remplacées si vous définissez des valeurs explicites dans le fichier de configuration Terraform.

Préparer le répertoire

Chaque fichier de configuration Terraform doit avoir son propre répertoire (également appelé module racine).

  1. Dans Cloud Shell, créez un répertoire et un nouveau fichier dans ce répertoire. Le nom du fichier doit comporter l'extension .tf, par exemple main.tf. Dans ce tutoriel, le fichier est appelé main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Si vous suivez un tutoriel, vous pouvez copier l'exemple de code dans chaque section ou étape.

    Copiez l'exemple de code dans le fichier main.tf que vous venez de créer.

    Vous pouvez également copier le code depuis GitHub. Cela est recommandé lorsque l'extrait Terraform fait partie d'une solution de bout en bout.

  3. Examinez et modifiez les exemples de paramètres à appliquer à votre environnement.
  4. Enregistrez les modifications.
  5. Initialisez Terraform. Cette opération n'est à effectuer qu'une seule fois par répertoire. 
    terraform init

    Vous pouvez également utiliser la dernière version du fournisseur Google en incluant l'option -upgrade : 

    terraform init -upgrade

Appliquer les modifications

  1. Examinez la configuration et vérifiez que les ressources que Terraform va créer ou mettre à jour correspondent à vos attentes : 
    terraform plan

    Corrigez les modifications de la configuration si nécessaire.

  2. Appliquez la configuration Terraform en exécutant la commande suivante et en saisissant yes lorsque vous y êtes invité : 
    terraform apply

    Attendez que Terraform affiche le message "Apply completed!" (Application terminée).

  3. Ouvrez votre projet Google Cloud pour afficher les résultats. Dans la console Google Cloud, accédez à vos ressources dans l'interface utilisateur pour vous assurer que Terraform les a créées ou mises à jour.

Supprimer les modifications

Pour supprimer vos modifications, procédez comme suit :

  1. Pour désactiver la protection contre la suppression, définissez l'argument deletion_protection sur false dans le fichier de configuration Terraform. 
    deletion_protection =  "false"
  2. Appliquez la configuration Terraform mise à jour en exécutant la commande suivante et en saisissant yes lorsque vous y êtes invité : 
    terraform apply

  1. Supprimez les ressources précédemment appliquées à votre configuration Terraform en exécutant la commande suivante et en saisissant yes à la requête :

    terraform destroy

REST v1

  1. Obtenir la configuration de sauvegarde actuelle

    Utilisez la méthode get de la ressource des instances pour renvoyer la version de la base de données et la configuration de sauvegarde actuelle de l'instance principale.

    Avant d'utiliser les données de requête, effectuez les remplacements suivants :

    • project-id : ID du projet
    • primary-instance-name : nom de l'instance principale

    Méthode HTTP et URL :

    GET https://sqladmin.googleapis.com/v1/projects/project-id/instances/primary-instance-name

    Pour envoyer votre requête, développez l'une des options suivantes :

    Vous devriez recevoir une réponse JSON de ce type :

  2. Vérifier que les champs de duplication sont définis

    Si l'élément enabled ou pointInTimeEnabled est défini sur false, utilisez la méthode patch de la ressource des instances pour les activer tous les deux. Dans la requête, spécifiez les propriétés de la configuration de sauvegarde que vous souhaitez modifier.

    Pour activer les sauvegardes, définissez enabled sur true et startTime sur une heure de la journée au format HH:MM. Le paramètre startTime est indiqué au format 24 heures dans le fuseau horaire UTC ± 00 et spécifie le début d'un intervalle de sauvegarde de quatre heures. Les sauvegardes peuvent commencer à tout moment pendant l'intervalle de sauvegarde.

    Pour activer la récupération à un moment précis, définissez pointInTimeEnabled sur true.

    Avant d'utiliser les données de requête, effectuez les remplacements suivants :

    • PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
    • INSTANCE_NAME : nom de l'instance principale ou de l'instance répliquée avec accès en lecture que vous configurez pour la haute disponibilité.
    • START_TIME : heure (en heures et en minutes).

    Méthode HTTP et URL :

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Corps JSON de la requête :

    {
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

    Pour envoyer votre requête, développez l'une des options suivantes :

    Vous devriez recevoir une réponse JSON de ce type :

  3. Créer l'instance dupliquée avec accès en lecture

    Utilisez la méthode insert de la ressource des instances pour créer l'instance dupliquée avec accès en lecture. La propriété databaseVersion doit être identique à celle de l'instance principale. Si l'instance principale utilise une adresse IP interne, vous pouvez spécifier une plage allocatedIpRange de la même manière que lorsque vous créez une instance principale. Si aucune plage n'est spécifiée, l'instance dupliquée est créée dans une plage aléatoire. Pour une instance dupliquée interrégionale avec accès en lecture, spécifiez une région autre que celle de l'instance principale.

    Avant d'utiliser les données de requête, effectuez les remplacements suivants :

    • project-id : ID du projet
    • database-version : chaîne de version Emum (par exemple, MYSQL_8_0)
    • primary-instance-name : nom de l'instance principale
    • primary-instance-region : région de l'instance principale
    • replica-region : région de l'instance dupliquée
    • replica-name : nom de l'instance dupliquée
    • machine-type : chaîne d'énumération du type de machine Exemple : "db-custom-1-3840"
    • private-network : réseau autorisé que vous ajoutez ou sélectionnez pour créer une connexion privée.

    Méthode HTTP et URL : 

    POST https://sqladmin.googleapis.com/v1/projects/project-id/instances

    Corps JSON de la requête :

    {
  "masterInstanceName": "primary-instance-name",
  "project": "project-id",
  "databaseVersion": "database-version",
  "name": "replica-name",
  "region": "replica-region",
  "settings":
  {
    "tier": "machine-type",
    "settingsVersion": 0,
    "ipConfiguration": {
    object (IpConfiguration)
  },
  {
  "ipv4Enabled": false,
  "privateNetwork": private-network,
  "requireSsl": boolean,
  "authorizedNetworks": [
    {
      object (AclEntry)
    }
  ],
  "allocatedIpRange": string
    }
  }
}

    Pour envoyer votre requête, développez l'une des options suivantes :

    Vous devriez recevoir une réponse JSON de ce type :

REST v1beta4

  1. Obtenir la configuration de sauvegarde actuelle

    Utilisez la méthode get de la ressource des instances pour renvoyer la version de la base de données et la configuration de sauvegarde actuelle de l'instance principale.

    Avant d'utiliser les données de requête, effectuez les remplacements suivants :

    • project-id : ID du projet
    • primary-instance-name : nom de l'instance principale

    Méthode HTTP et URL :

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/primary-instance-name

    Pour envoyer votre requête, développez l'une des options suivantes :

    Vous devriez recevoir une réponse JSON de ce type :

  2. Vérifier que les champs de duplication sont définis

    Si enabled et/ou binaryLogEnabled sont définis sur false sur l'instance principale, utilisez la méthode patch de la ressource des instances pour les activer tous les deux. Dans la requête, spécifiez les propriétés de la configuration de sauvegarde que vous souhaitez modifier.

    Pour activer les sauvegardes, définissez enabled sur true et startTime sur une heure de la journée au format HH:MM. Le paramètre startTime est indiqué au format 24 heures dans le fuseau horaire UTC ± 00 et spécifie le début d'un intervalle de sauvegarde de quatre heures. Les sauvegardes peuvent commencer à tout moment pendant l'intervalle de sauvegarde.

    Pour activer la récupération à un moment précis, définissez binaryLogEnabled sur true sur l'instance principale.

    La journalisation binaire est compatible avec les instances dupliquées avec accès en lecture (MySQL 5.7 et 8.0 uniquement). Activez la journalisation binaire sur une instance dupliquée avec la même API, en utilisant l'ID d'instance de l'instance dupliquée plutôt que l'ID de l'instance principale.

    La durabilité de la journalisation binaire sur l'instance dupliquée (mais pas sur l'instance principale) peut être définie avec l'option sync_binlog qui contrôle la fréquence à laquelle le serveur MySQL synchronise le journal binaire sur le disque.

    Les sauvegardes ne peuvent pas être activées sur les instances dupliquées, mais la journalisation binaire peut l'être sur une instance dupliquée même si les sauvegardes sont désactivées, ce qui n'est pas le cas pour l'instance principale.

    Avant d'utiliser les données de requête, effectuez les remplacements suivants :

    • PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
    • INSTANCE_NAME : nom de l'instance principale ou de l'instance répliquée avec accès en lecture que vous configurez pour la haute disponibilité.
    • START_TIME : heure (en heures et en minutes).

    Méthode HTTP et URL :

    PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

    Corps JSON de la requête :

    {
  "settings":
  {
    "backupConfiguration":
    {
      "startTime": "START_TIME",
      "enabled": true,
      "binaryLogEnabled": true
    }
  }
}

    Pour envoyer votre requête, développez l'une des options suivantes :

    Vous devriez recevoir une réponse JSON de ce type :

  3. Créer l'instance dupliquée avec accès en lecture

    Utilisez la méthode insert de la ressource des instances pour créer l'instance dupliquée avec accès en lecture. La propriété databaseVersion doit être identique à celle de l'instance principale. Si l'instance principale utilise une adresse IP interne, vous pouvez spécifier une plage allocatedIpRange de la même manière que lorsque vous créez une instance principale. Pour une instance dupliquée interrégionale avec accès en lecture, spécifiez une région autre que celle de l'instance principale.

    Avant d'utiliser les données de requête, effectuez les remplacements suivants :

    • project-id : ID du projet
    • database-version : chaîne de version Emum (par exemple, MYSQL_8_0)
    • primary-instance-name : nom de l'instance principale
    • primary-instance-region : région de l'instance principale
    • replica-region : région de l'instance dupliquée
    • replica-name : nom de l'instance dupliquée
    • machine-type : chaîne d'énumération du type de machine Exemple : "db-custom-1-3840"
    • private-network : réseau autorisé que vous ajoutez ou sélectionnez pour créer une connexion privée.

    Méthode HTTP et URL : 

    POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances

    Corps JSON de la requête :

    {
  "masterInstanceName": "primary-instance-name",
  "project": "project-id",
  "databaseVersion": "database-version",
  "name": "replica-name",
  "region": "replica-region",
  "settings":
  {
    "tier": "machine-type",
    "settingsVersion": 0,
    
    "ipConfiguration": {
    object (IpConfiguration)
  },
  {
  "ipv4Enabled": false,
  "privateNetwork": private-network,
  "requireSsl": boolean,
  "authorizedNetworks": [
    {
      object (AclEntry)
    }
  ],
  "allocatedIpRange": string
    }
    
  }
}

    Pour envoyer votre requête, développez l'une des options suivantes :

    Vous devriez recevoir une réponse JSON de ce type :

Créer une instance répliquée avec accès en lecture pour une instance avec Private Service Connect activé

gcloud CLI ou l'API. Vous pouvez créer cette instance répliquée dans la même région ou dans une région différente de celle de l'instance principale (instance répliquée interrégionale avec accès en lecture).

L'instance répliquée avec accès en lecture ne peut pas être répliquée à partir d'une instance avec un type de connectivité différent. Par exemple, une instance pour laquelle Private Service Connect est activé ne peut être répliquée qu'à partir d'une autre instance Private Service Connect. Elle ne peut pas non plus être répliquée à partir d'une instance compatible avec les connexions IP externes, ou à partir d'une instance configurée avec l'accès aux services privés.

gcloud

Pour créer une instance répliquée avec accès en lecture pour une instance, utilisez la commande gcloud sql instances create :

gcloud sql instances create REPLICA_INSTANCE_NAME \
--master-instance-name=PRIMARY_INSTANCE_NAME \
--project=PROJECT_ID \
--region=REGION_NAME \
--enable-private-service-connect \
--allowed-psc-projects=ALLOWED_PROJECTS \
--availability-type=AVAILABILITY_TYPE \
--no-assign-ip

Effectuez les remplacements suivants :

  • REPLICA_INSTANCE_NAME : nom de l'instance répliquée.
  • PRIMARY_INSTANCE_NAME : nom de l'instance principale.
  • PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
  • REGION_NAME : nom de la région pour l'instance répliquée.

  • ALLOWED_PROJECTS : liste d'ID ou de numéros de projet autorisés, séparés par une virgule. Si un projet ne figure pas dans cette liste, vous ne pouvez pas l'utiliser pour créer une instance sur laquelle activer Private Service Connect.

    Cloud SQL ne copie pas les projets autorisés pour l'instance principale sur l'instance répliquée. Pour chaque instance répliquée, vous devez créer un point de terminaison Private Service Connect. Si vous utilisez le proxy d'authentification Cloud SQL ou les connecteurs de langage Cloud SQL, vous devez créer une zone DNS et un enregistrement DNS pour les instances répliquées.

  • AVAILABILITY_TYPE : permet d'activer la haute disponibilité pour l'instance. Pour ce paramètre, spécifiez l'une des valeurs suivantes :
    • REGIONAL : permet d'activer la haute disponibilité (recommandé pour les instances de production). L'instance bascule vers une autre zone dans la région sélectionnée.
    • ZONAL : n'offre aucune fonctionnalité de basculement. Il s'agit de la valeur par défaut.

    Pour en savoir plus sur la définition et la suppression de la haute disponibilité pour les instances, consultez les sections Configurer la haute disponibilité d'une instance existante et Désactiver la haute disponibilité pour une instance.

REST v1

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • PRIMARY_INSTANCE_NAME : nom de l'instance principale.
  • PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
  • REPLICA_INSTANCE_NAME : nom de l'instance répliquée.
  • REGION_NAME : nom de la région pour l'instance répliquée.
  • MACHINE_TYPE : type de machine de l'instance.
  • AVAILABILITY_TYPE : permet d'activer la haute disponibilité pour l'instance. Pour ce paramètre, spécifiez l'une des valeurs suivantes :
    • REGIONAL : permet d'activer la haute disponibilité (recommandé pour les instances de production). L'instance bascule vers une autre zone dans la région sélectionnée.
    • ZONAL : n'offre aucune fonctionnalité de basculement. Il s'agit de la valeur par défaut.

    Pour en savoir plus sur la définition et la suppression de la haute disponibilité pour les instances, consultez les sections Configurer la haute disponibilité d'une instance existante et Désactiver la haute disponibilité pour une instance.

  • ALLOWED_PROJECTS : liste d'ID ou de numéros de projet autorisés, séparés par une virgule. Si un projet ne figure pas dans cette liste, vous ne pouvez pas l'utiliser pour créer une instance sur laquelle activer Private Service Connect.

    Cloud SQL ne copie pas les projets autorisés pour l'instance principale sur l'instance répliquée. Pour chaque instance répliquée, vous devez créer un point de terminaison Private Service Connect. Si vous utilisez le proxy d'authentification Cloud SQL ou les connecteurs de langage Cloud SQL, vous devez créer une zone DNS et un enregistrement DNS pour les instances répliquées.

Méthode HTTP et URL :

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances

Corps JSON de la requête :

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "MYSQL_8_0",
  "name": "REPLICA_INSTANCE_NAME",
  "region": "REGION_NAME",
  "kind": "sql#instance",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "ipConfiguration": {
      "ipv4Enabled": false,
      "pscConfig": {
        "allowedConsumerProjects": [ALLOWED_PROJECTS],
        "pscEnabled": true
      }
    },
    "kind": "sql#settings",
    "pricingPlan": "PER_USE",
    "replicationType": "ASYNCHRONOUS",
    "tier": "MACHINE_TYPE"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "CREATE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

Avant d'utiliser les données de requête, effectuez les remplacements suivants :

  • PRIMARY_INSTANCE_NAME : nom de l'instance principale.
  • PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
  • REPLICA_INSTANCE_NAME : nom de l'instance répliquée.
  • REGION_NAME : nom de la région pour l'instance répliquée.
  • MACHINE_TYPE : type de machine de l'instance.
  • AVAILABILITY_TYPE : permet d'activer la haute disponibilité pour l'instance. Pour ce paramètre, spécifiez l'une des valeurs suivantes :
    • REGIONAL : permet d'activer la haute disponibilité (recommandé pour les instances de production). L'instance bascule vers une autre zone dans la région sélectionnée.
    • ZONAL : n'offre aucune fonctionnalité de basculement. Il s'agit de la valeur par défaut.

    Pour en savoir plus sur la définition et la suppression de la haute disponibilité pour les instances, consultez les sections Configurer la haute disponibilité d'une instance existante et Désactiver la haute disponibilité pour une instance.

  • ALLOWED_PROJECTS : liste d'ID ou de numéros de projet autorisés, séparés par une virgule. Si un projet ne figure pas dans cette liste, vous ne pouvez pas l'utiliser pour créer une instance sur laquelle activer Private Service Connect.

    Cloud SQL ne copie pas les projets autorisés pour l'instance principale sur l'instance répliquée. Pour chaque instance répliquée, vous devez créer un point de terminaison Private Service Connect. Si vous utilisez le proxy d'authentification Cloud SQL ou les connecteurs de langage Cloud SQL, vous devez créer une zone DNS et un enregistrement DNS pour les instances répliquées.

Méthode HTTP et URL :

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances

Corps JSON de la requête :

{
  "masterInstanceName": "PRIMARY_INSTANCE_NAME",
  "project": "PROJECT_ID",
  "databaseVersion": "MYSQL_8_0",
  "name": "REPLICA_INSTANCE_NAME",
  "region": "REGION_NAME",
  "kind": "sql#instance",
  "settings":
  {
    "tier": "MACHINE_TYPE",
    "availabilityType": "AVAILABILITY_TYPE",
    "settingsVersion": 0,
    "ipConfiguration": {
      "ipv4Enabled": false,
      "pscConfig": {
        "allowedConsumerProjects": [ALLOWED_PROJECTS],  
        "pscEnabled": true
      }
    },
    "kind": "sql#settings",
    "pricingPlan": "PER_USE",
    "replicationType": "ASYNCHRONOUS",
    "tier": "MACHINE_TYPE"
  }
}

Pour envoyer votre requête, développez l'une des options suivantes :

Vous devriez recevoir une réponse JSON de ce type :

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "CREATE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_INSTANCE_NAME",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Configurer des instances dupliquées avec accès en lecture pour l'authentification IAM pour les bases de données

L'indicateur cloudsql_iam_authentication n'est pas activé automatiquement sur les instances dupliquées avec accès en lecture, lorsqu'il est activé sur l'instance principale.

Pour configurer l'instance dupliquée avec accès en lecture pour l'authentification IAM pour les bases de données :

  1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

    Accéder à la page Instances Cloud SQL

  2. Pour ouvrir la page Présentation d'une instance, cliquez sur son nom.
  3. Dans la tuile Configuration, recherchez l'option cloudsql_iam_authentication. Si l'option ne figure pas dans la liste, il n'est pas nécessaire de l'activer dans l'instance dupliquée avec accès en lecture. Si l'option figure dans la liste, vous devez l'activer sur l'instance dupliquée avec accès en lecture. Si vous devez activer l'option sur l'instance dupliquée avec accès en lecture, passez à l'étape suivante.
  4. Dans le menu de navigation SQL, sélectionnez Instances dupliquées.
  5. Cliquez sur le nom de l'instance dupliquée que vous souhaitez modifier.
  6. Cliquez sur Modifier.
  7. Dans la section Options de configuration, développez Options.
  8. Sélectionnez + Ajouter un élément.
  9. Saisissez cloudsql_iam_authentication comme nom de l'option. Assurez-vous que l'option Activé est sélectionnée pour cette option.
  10. Cliquez sur Enregistrer.

Créer des instances répliquées en cascade

Cette section explique comment créer et gérer des instances répliquées en cascade. Pour en savoir plus sur le fonctionnement des instances répliquées en cascade, consultez la section Instances répliquées en cascade.

Avant de commencer

L'instance principale doit disposer d'une instance répliquée avec accès en lecture. Pour en savoir plus sur la création d'instances principales, consultez la section Créer une instance répliquée avec accès en lecture.

Étapes de création d'une instance répliquée en cascade

Console

  1. Dans Google Cloud Console, accédez à la page Instances Cloud SQL.

    Accéder à la page Instances Cloud SQL

  2. Pour MySQL version 5.7 ou ultérieure, activez la réplication.
  3. Cliquez sur l'onglet Instances dupliquées de l'instance répliquée qui va servir de parent pour l'instance répliquée que vous souhaitez créer.
  4. Cliquez sur Créer une instance répliquée.
  5. Sur la page Créer une instance répliquée avec accès en lecture, mettez à jour l'ID d'instance et toutes les autres options de configuration, y compris le nom, la région et la zone.
  6. Cliquez sur Créer.

    Cloud SQL crée une instance répliquée. Vous êtes redirigé vers la page de l'instance répliquée parente.

  7. Suivez les étapes 4 à 6 pour chaque nouvelle instance répliquée en cascade que vous souhaitez créer.

gcloud

  1. Si vous utilisez MySQL version 5.7 ou ultérieure, activez les binlogs pour l'instance principale de la nouvelle instance répliquée :
    gcloud sql instances patch --enable-bin-log PARENT_REPLICA_NAME
    Remplacez PARENT_REPLICA_NAME par le nom de l'instance répliquée parente.

  2. Créez l'instance répliquée en spécifiant votre instance répliquée principale en tant qu'instance principale à l'aide de l'option --master-instance-name :

    gcloud sql instances create REPLICA_NAME \
      --master-instance-name=PARENT_REPLICA_NAME \
    Remplacez les éléments suivants :
    • REPLICA_NAME : ID unique de l'instance répliquée que vous créez.
    • PARENT_REPLICA_NAME : nom de l'instance répliquée parente.

  3. Une fois l'instance répliquée créée, vous pouvez constater que les modifications apportées à l'instance principale sont répliquées via toutes les instances répliquées présentes dans la chaîne d'instances répliquées en cascade.

curl

  1. Si vous utilisez MySQL version 5.7 ou ultérieure, activez la journalisation binaire :

    Pour activer la journalisation binaire, enregistrez le code JSON suivant dans un fichier nommé request.JSON, puis appelez la commande curl pour activer la journalisation binaire. 
    {
  "settings":
  {
    "backupConfiguration":
    {
      "enabled": false,
      "binaryLogEnabled": true
    }
  }
}

  2. Pour créer une instance répliquée qui soit hiérarchiquement inférieure à l'instance répliquée parente, modifiez l'exemple de code JSON suivant et enregistrez-le dans un fichier nommé request.json : 

    {
  "masterInstanceName": "PARENT_REPLICA_NAME",
  "project": "PROJECT_ID",
  "name": "REPLICA_NAME",
  "region": "REPLICA_REGION",
  "settings":
    {
      "tier": "MACHINE_TYPE",
    }
}
  3. Exécutez la commande suivante : 
    curl -X POST
-H "Authorization: Bearer "$(gcloud auth print-access-token)
-H "Content-Type: application/json; charset=utf-8"
-d @request.json
"https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances"

Résoudre les problèmes

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'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 répliqué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 :
Le délai de réplication augmente soudainement. Ce problème est causé par des transactions de longue durée. Lorsqu'une transaction (une ou plusieurs instructions) est validée sur l'instance source, l'heure de début de la transaction est enregistrée dans le journal binaire. Lorsque l'instance répliquée reçoit cet événement binlog, elle compare ce code temporel au code temporel actuel pour calculer le délai de réplication. Par conséquent, une transaction de longue durée sur la source entraîne un délai de réplication important immédiat sur l'instance dupliquée. Si la quantité de modifications de ligne dans la transaction est importante, l'instance dupliquée prendra également beaucoup de temps à l'exécuter. Pendant ce temps, le délai de réplication augmente. Une fois que l'instance dupliquée a terminé cette transaction, la période de rattrapage dépend de la charge de travail d'écriture sur la source et de la vitesse de traitement de l'instance dupliquée.

Voici quelques solutions possibles pour éviter une longue transaction :

  • Diviser la transaction en plusieurs petites transactions
  • Fragmenter une seule requête d'écriture volumineuse en lots plus petits
  • Tenter de séparer les longues requêtes SELECT d'une transaction associée à des LMD
La modification des options de réplication parallèle génère une erreur. Une valeur incorrecte est définie pour une ou plusieurs de ces options.

Sur l'instance principale qui affiche le message d'erreur, définissez les options de réplication parallèle comme suit :

  1. Modifiez les options binlog_transaction_dependency_tracking et transaction_write_set_extraction :
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Ajoutez l'option slave_pending_jobs_size_max :

    slave_pending_jobs_size_max=33554432

  3. Modifiez l'option transaction_write_set_extraction :

    transaction_write_set_extraction=XXHASH64

  4. Modifiez l'option binlog_transaction_dependency_tracking :

    binlog_transaction_dependency_tracking=WRITESET
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.

Étape suivante