Mettre à niveau une instance vers l'édition Cloud SQL Enterprise Plus en utilisant la mise à niveau sur place


Cette page explique comment utiliser la méthode de mise à niveau sur place pour mettre à niveau une instance Cloud SQL Enterprise vers l'édition Cloud SQL Enterprise Plus. En outre, elle décrit également la procédure à suivre pour revenir d'une instance Cloud SQL Enterprise Plus à l'édition Cloud SQL Enterprise.

La mise à niveau vers l'édition Cloud SQL Enterprise Plus vous offre plusieurs avantages et des améliorations de performances. Pour en savoir plus, consultez la page Présentation des éditions Cloud SQL pour MySQL.

Pour activer ces améliorations pour vos instances Cloud SQL Enterprise existantes, vous devez les mettre à niveau vers l'édition Cloud SQL Enterprise Plus. Le processus de déploiement prend quelques minutes. De plus, ce processus ne nécessite pas que vos applications modifient les points de terminaison auxquels elles se connectent.

Avant de commencer

Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis

Toutes les instances de l'édition Cloud SQL Enterprise Plus sont automatiquement activées avec la récupération à un moment précis (PITR). Si l'instance Cloud SQL Enterprise que vous souhaitez mettre à niveau stocke les journaux binaires utilisés pour la récupération PITR sur le disque, le processus de mise à niveau vers l'édition Cloud SQL Enterprise Plus change l'emplacement de stockage des journaux binaires vers Cloud Storage.

Avant de passer à l'édition Cloud SQL Enterprise Plus, vérifiez si votre instance Cloud SQL Enterprise sera soumise au changement d'emplacement de stockage des journaux binaires utilisés pour la récupération à un moment précis. Pour en savoir plus et obtenir des instructions sur la vérification de votre instance, consultez la section Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis.

Pour en savoir plus sur le changement d'emplacement de stockage des journaux de transactions lors du processus de mise à niveau, consultez la section Emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis.

Mettre à niveau une instance vers l'édition Cloud SQL Enterprise Plus

Suivez la procédure décrite dans cette section pour passer d'une instance Cloud SQL Enterprise à l'édition Cloud SQL Enterprise Plus.

Console

  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. Cliquez sur Modifier.
  4. Dans la section Choisir une édition Cloud SQL, cliquez sur Mettre à niveau.
  5. Dans le panneau Passer à l'édition Enterprise Plus, saisissez l'ID de votre instance, puis cliquez sur Mettre à niveau l'édition.

Vous pouvez également mettre à niveau une instance en cliquant sur Mettre à niveau dans la section Configuration de la page Présentation de l'instance.

gcloud

L'exemple de code suivant montre comment mettre à niveau votre instance vers l'édition Cloud SQL Enterprise Plus :

gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise-plus \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID

Remplacez les éléments suivants :

  • PROJECT_ID : ID de projet de l'instance que vous souhaitez mettre à niveau.
  • INSTANCE_ID : nom de l'instance que vous souhaitez mettre à niveau.
  • MACHINE_TYPE : type de machine de l'instance vers laquelle vous souhaitez effectuer la mise à niveau. Pour en savoir plus sur les types de machines pour l'édition Cloud SQL Enterprise Plus, consultez la page Types de machines pour les instances Cloud SQL Enterprise Plus.

REST

La commande suivante met à niveau votre instance vers l'édition Cloud SQL Enterprise et déclenche une opération de redémarrage.

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

  • PROJECT_ID : ID de projet de l'instance que vous souhaitez mettre à niveau.
  • INSTANCE_ID : ID de l'instance que vous souhaitez mettre à niveau.
  • MACHINE_TYPE : type de machine de l'instance vers laquelle vous souhaitez effectuer la mise à niveau. Pour en savoir plus sur les types de machines pour l'édition Cloud SQL Enterprise Plus, consultez la page Types de machines pour les instances Cloud SQL Enterprise Plus.

Méthode HTTP et URL : 

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

Corps JSON de la requête :

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

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/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

La commande suivante met à niveau votre instance vers l'édition Cloud SQL Enterprise et déclenche une opération de redémarrage.

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

  • PROJECT_ID : ID de projet de l'instance que vous souhaitez mettre à niveau.
  • INSTANCE_ID : ID de l'instance que vous souhaitez mettre à niveau.
  • MACHINE_TYPE : type de machine de l'instance vers laquelle vous souhaitez effectuer la mise à niveau. Pour en savoir plus sur les types de machines pour l'édition Cloud SQL Enterprise Plus, consultez la page Types de machines pour les instances Cloud SQL Enterprise Plus.

Méthode HTTP et URL : 

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

Corps JSON de la requête :

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

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/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis

Si votre instance Cloud SQL Enterprise stocke les journaux de transactions pour la récupération PITR sur le disque, le démarrage du processus de mise à niveau vers l'édition Cloud SQL Enterprise Plus change l'emplacement de stockage de ces journaux vers Cloud Storage.

Les conditions suivantes s'appliquent au processus de changement d'emplacement:

  • Le processus prend environ la durée du paramètre de configuration de la récupération PITR transactionLogRetentionDays pour passer à Cloud Storage.
  • Si vous avez défini des valeurs pour l'indicateur expire_logs_days ou binlog_expire_logs_seconds sur votre instance, ces valeurs sont conservées.
  • Pendant le passage à Cloud Storage, vous ne pouvez pas modifier les valeurs des options expire_logs_days ou binlog_expire_logs_seconds sur votre instance.
  • Lors du passage à Cloud Storage, nous vous recommandons de ne pas modifier le paramètre de configuration PITR de transactionLogRetentionDays. Même si vous augmentez la valeur transactionLogRetentionDays, les journaux binaires ne sont pas conservés sur le disque pendant une durée supérieure à la durée par défaut de sept jours pour une instance Cloud SQL Enterprise.
  • Tant que le changement est en cours, Cloud SQL ne conserve les journaux sur le disque que pour la valeur minimale de l'un des éléments suivants:
    • Le paramètre de configuration de la récupération PITR transactionLogRetentionDays avant le basculement (sept jours par défaut)
    • Les options expire_logs_days ou binlog_expire_logs_seconds définies manuellement sur votre instance
  • Après le changement, Cloud SQL conserve sur le disque la même quantité de journaux binaires qu'avant le changement sauf si vous avez défini les options expire_logs_days ou binlog_expire_logs_seconds sur votre instance. Si vous avez défini ces indicateurs, Cloud SQL conserve les journaux binaires sur le disque en fonction de la valeur minimale du paramètre de configuration transactionLogRetentionDays ou de la valeur des indicateurs.

Paramètres par défaut de l'édition Enterprise Plus de Cloud SQL pour la sauvegarde et le stockage des journaux

Une fois que le passage à Cloud Storage est terminé pour une instance, Cloud SQL conserve toujours des copies des journaux binaires sur le disque à des fins de réplication. Le stockage des journaux binaires sur le disque peut être utile si vous souhaitez parcourir des journaux binaires avec l'utilitaire mysqlbinlog.

Si vous avez configuré les options expire_logs_days et binlog_expire_logs_seconds sur votre instance avant la mise à niveau, les valeurs configurées restent intactes.

Après le basculement, étant donné que les journaux binaires utilisés pour effectuer la récupération à un moment précis sont désormais stockés dans Cloud Storage, assurez-vous que les valeurs des options reflètent la conservation des journaux de transactions sur le disque attendu. Cloud SQL ne conserve les journaux sur le disque que pour la valeur minimale de l'un des éléments suivants :

  • Le paramètre de configuration de la récupération PITR transactionLogRetentionDays avant le basculement (sept jours par défaut)
  • Les options expire_logs_days ou binlog_expire_logs_seconds définies manuellement sur votre instance

Si vous souhaitez économiser de l'espace disque, une fois la mise à niveau terminée, définissez la valeur de l'option expire_logs_days ou binlog_expire_logs_seconds sur l'équivalent d'un jour afin de réduire la taille de disque allouée et les coûts de stockage sur disque. Pour en savoir plus sur le stockage des journaux de transactions et la récupération PITR, consultez la section Stockage de journaux pour la récupération à un moment précis.

Une fois la mise à niveau vers l'édition Cloud SQL Enterprise Plus terminée, la durée de conservation des journaux de transactions par défaut pour toutes les instances mises à niveau est augmentée à 14 jours. Pour cette augmentation, et toute autre augmentation que vous configurez pour la durée de conservation des journaux de transactions, il faut attendre que la nouvelle valeur soit augmentée pour atteindre la période de conservation complète de la récupération PITR. Par exemple, si l'ancienne valeur des jours de conservation des journaux de transactions est de 7 et que la nouvelle valeur est augmentée à 14, la période de récupération PITR pour les sept premiers jours suivant la mise à niveau n'est que de sept jours. À partir du huitième jours, la période de récupération PITR passe à huit jours, puis le neuvième jour à neuf jours, jusqu'à ce que la période de conservation soit finalement passée à 14 jours le 14e jour.

De plus, le nombre de sauvegardes automatiques par défaut est passé de 8 à 15.

Si vous passez à l'édition Cloud SQL Enterprise Plus après avoir effectué une mise à niveau de version majeure, vous ne pourrez pas effectuer de récupération à un moment précis antérieur à la mise à niveau de la version majeure. Cette limitation s'applique même si votre période de conservation couvre cette période. Vous pouvez restaurer votre instance à un moment précis après le lancement de la mise à niveau de la version majeure.

Passer à l'édition Cloud SQL Enterprise

Console

  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. Cliquez sur Modifier.
  4. Dans la section Choisir une édition Cloud SQL, cliquez sur Passer à l'édition Enterprise.
  5. Dans le panneau Passer à l'édition Enterprise, saisissez l'ID de votre instance, puis cliquez sur Changer d'édition.

Vous pouvez également passer à l'édition Cloud SQL Enterprise en cliquant sur Passer à l'édition Enterprise dans la section Configuration de la page Présentation de l'instance.

gcloud

L'exemple de code suivant montre comment passer votre instance à l'édition Cloud SQL Enterprise :

gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID
Remplacez les éléments suivants :
  • PROJECT_ID : ID de projet de l'instance.
  • INSTANCE_ID : nom de l'instance.
  • MACHINE_TYPE : type de machine de l'instance vers laquelle vous souhaitez basculer. Pour en savoir plus sur les types de machines pour l'édition Cloud SQL Enterprise, consultez la page Types de machines pour les instances Cloud SQL Enterprise.

REST

La commande suivante bascule votre instance vers l'édition Cloud SQL Enterprise et déclenche une opération de redémarrage.

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

  • PROJECT_ID : ID de projet de l'instance.
  • INSTANCE_ID : ID de l'instance.
  • MACHINE_TYPE : type de machine de l'instance vers laquelle vous souhaitez basculer. Pour en savoir plus sur les types de machines pour l'édition Cloud SQL Enterprise, consultez la page Types de machines pour les instances Cloud SQL Enterprise.

Méthode HTTP et URL : 

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

Corps JSON de la requête :

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE"
  }
}

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/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

REST v1beta4

La commande suivante bascule votre instance vers l'édition Cloud SQL Enterprise et déclenche une opération de redémarrage.

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

  • PROJECT_ID : ID de projet de l'instance.
  • INSTANCE_ID : ID de l'instance.
  • MACHINE_TYPE : type de machine de l'instance vers laquelle vous souhaitez basculer. Pour en savoir plus sur les types de machines pour l'édition Cloud SQL Enterprise, consultez la page Types de machines pour les instances Cloud SQL Enterprise.

Méthode HTTP et URL : 

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

Corps JSON de la requête :

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE"
  }
}

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/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Paramètres par défaut de l'édition Cloud SQL Enterprise pour la sauvegarde et le stockage des journaux

Le passage à l'édition Cloud SQL Enterprise ne modifie pas l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis. Si votre instance Cloud SQL Enterprise Plus stocke ses journaux de transactions pour la récupération PITR dans Cloud Storage, les journaux restent dans Cloud Storage. Toutefois, au lieu de stocker par défaut 14 jours de journaux de transactions pour la récupération PITR, la valeur par défaut est remplacée par 7 jours. La configuration de la sauvegarde n'est pas modifiée.

Étapes suivantes