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. Vous pouvez utiliser une instance dupliquée avec accès en lecture pour effectuer les opérations suivantes :

  • Décharger les requêtes de lecture ou le trafic d'analyse de l'instance principale
  • Effectuer une migration régionale ou basculer vers une autre région à des fins de reprise après sinistre (si l'instance dupliquée est une instance dupliquée interrégionale, c'est-à-dire une instance dupliquée créée dans une région différente de celle de l'instance 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. Accédez à la page "Instances Cloud SQL" dans Google Cloud Console.

    Accéder à la page "Instances Cloud SQL"

  2. Recherchez l'instance pour laquelle vous souhaitez créer une instance dupliquée, puis ouvrez son 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 est déjà une instance dupliquée. Or, vous ne pouvez pas créer une instance dupliquée à partir d'une instance dupliquée.

  4. Si les sauvegardes et la journalisation binaire sont activées sur l'instance, passez à l'étape 6. 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. Sur la page Créer une instance dupliquée avec accès en lecture, mettez à jour l'ID d'instance, si nécessaire, ainsi que les autres options de configuration requises, y compris le nom, la région et la zone.
  6. Cliquez sur Créer.

    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 --enable-bin-log PRIMARY_INSTANCE_NAME
    L'activation des journaux binaires entraîne le redémarrage de l'instance.
  4. Créez l'instance dupliqué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.

    Si l'instance principale ne dispose que d'une adresse IP privée, ajoutez le paramètre --no-assign-ip à la commande.

  • 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 commande gcloud, en utilisant le nom de l'instance dupliquée au lieu du nom de l'instance principale.
    gcloud sql instances patch --enable-bin-log REPLICA_INSTANCE_NAME
        

    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.

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 ci-dessous, effectuez les remplacements suivants :

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

    Méthode HTTP et URL :

    GET https://www.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 ci-dessous, effectuez les remplacements suivants :

    • project-id : ID du projet
    • instance-id : ID d'instance (principale ou dupliquée)
    • start-time : heure au format "HH:MM"
    • enabled : défini sur "true" pour une instance principale, défini sur "false" pour une instance dupliquée

    Méthode HTTP et URL :

    PATCH https://www.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

    Corps JSON de la requête :

    {
      "settings":
      {
        "backupConfiguration":
        {
          "startTime": "start-time",
          "enabled": enabled,
          "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. 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 ci-dessous, effectuez les remplacements suivants :

    • project-id : ID du projet
    • 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 (niveau). Exemple : "db-n1-standard-4"

    Méthode HTTP et URL :

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

    Corps JSON de la requête :

    {
      "masterInstanceName": "primary-instance-name",
      "project": "project-id",
      "name": "replica-name",
      "region": "replica-region",
      "settings":
      {
        "tier": "machine-type",
        "settingsVersion": 0,
      }
    }
    

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

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

Dépannage

Cliquez sur les liens du tableau pour en savoir plus :

Pour ce problème... Le problème peut être... Essayez ce qui suit...
L'instance dupliquée avec accès en lecture n'a pas commencé à se dupliquer lors de la création. Au moins une sauvegarde doit avoir été créée depuis que la journalisation binaire a été activée. Attendez qu'au moins une sauvegarde ait été créée après avoir activé les journaux binaires.
Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue. Il peut y avoir plusieurs causes. Consultez les journaux pour en savoir plus.
Le disque est saturé. Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée. Mettez à niveau l'instance principale en augmentant la taille du disque.
L'instance dupliquée utilise trop de mémoire. Les instances dupliquées peuvent mettre en cache les opérations de lecture souvent demandées. Redémarrez l'instance dupliquée afin de récupérer l'espace de mémoire temporaire.
La duplication s'est arrêtée. L'espace de stockage maximal a été atteint et l'augmentation automatique de l'espace de stockage n'est pas activée. Activez l'augmentation automatique de l'espace de stockage.
Le délai de duplication est systématiquement long. Il peut y avoir de nombreuses causes premières. Voici quelques astuces à essayer.

L'instance dupliquée avec accès en lecture n'a pas commencé à se dupliquer lors de la création

L'instance dupliquée avec accès en lecture n'a pas commencé à se dupliquer lors de la création.

Cause possible

Pour que les instances dupliquées commencent à se dupliquer, l'instance principale doit comporter au moins une semaine de binlogs.

Solutions possibles

Attendez qu'il y ait suffisamment de binlogs.


Impossible de créer l'instance dupliquée avec accès en lecture : erreur inconnue

Impossible de créer l'instance dupliquée avec accès en lecture : unknown error.

Cause possible

Les fichiers journaux indiquent probablement une erreur plus spécifique.

Solutions possibles

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é

Erreur UPDATE_DISK_SIZE ou mysqld: disk is full.

Cause possible

Le disque de l'instance principale peut arriver à saturation lors de la création de l'instance dupliquée.

Solutions possibles

Modifiez l'instance principale en augmentant la taille du disque.


L'instance dupliquée utilise trop de mémoire

L'instance dupliquée utilise trop de mémoire.

Cause possible

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.

Solutions possibles

Redémarrez l'instance dupliquée afin de récupérer l'espace de mémoire temporaire.


Duplication arrêtée

La duplication s'est arrêtée.

Cause possible

La limite maximale de l'espace de stockage a été atteinte et l'augmentation automatique de l'espace de stockage est désactivée (>automatic storage increase is disabled).

Solutions possibles

Modifiez l'instance en activant automatic storage increase.


Délai de duplication systématiquement long

Le délai de duplication est systématiquement long.

Cause possible

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. Vous pouvez les identifier en activant log_slow_slave_statements, puis les corriger.
  • 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.

Solutions possibles

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.
  • Indexez les tables.
  • Identifiez et corrigez les requêtes lentes.
  • Recréez l'instance dupliquée.

Étapes suivantes