Mise à niveau sur place

Cette page explique comment effectuer des mises à niveau et des rétrogradations sur place de vos instances Cloud SQL.

Apporter des modifications sur place à une instance Cloud SQL

Vous pouvez utiliser des modifications sur place pour mettre à niveau ou rétrograder l'édition, le type de machine ou le type de stockage de votre instance Cloud SQL, ou pour mettre à niveau sa version de base de données. Apporter des modifications sur place est le moyen le plus simple et le moins sujet aux erreurs de reconfigurer une instance.

Avant de commencer

Avant d'apporter des modifications sur place à votre instance, procédez comme suit :

  • Assurez-vous que votre instance exécute la dernière version de maintenance.

    Si votre instance utilise une version de maintenance plus ancienne, vous devez la mettre à jour vers la dernière version de maintenance avant de la mettre à niveau vers l'édition Cloud SQL Enterprise Plus. Pour en savoir plus sur la vérification et la mise à jour de la version de maintenance, consultez Effectuer une maintenance en libre-service.

Les différentes éditions sont compatibles avec différents types de machines qui utilisent différentes options de stockage. Les types de machines hautes performances C4, C4A et C4D utilisent le stockage Google Cloud Hyperdisk Balanced plutôt que l'une des options de disque persistant utilisées par les types de machines plus anciens.

Lorsque vous modifiez l'édition ou le type de machine que vous utilisez, votre type de stockage peut également changer, ce qui peut entraîner un temps d'arrêt et une modification des coûts de stockage. Lorsque vous passez à Google Cloud Hyperdisk Balanced, vous pouvez spécifier des options de configuration supplémentaires. Pour en savoir plus, consultez Modifications du stockage.

Prendre connaissance des modifications apportées au stockage des journaux de transactions pour la récupération PITR

Si vous mettez à niveau une instance Cloud SQL Enterprise qui stocke les journaux binaires utilisés pour la récupération PITR sur disque, sachez que le processus de mise à niveau vers l'édition Cloud SQL Enterprise Plus déplace l'emplacement de stockage de ces journaux du disque vers Cloud Storage. Pour déterminer l'emplacement actuel des journaux binaires PITR pour votre instance, consultez 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 l'impact des mises à niveau sur place sur l'emplacement des journaux binaires, consultez Modifications de l'emplacement de stockage des journaux binaires pour la récupération PITR.

Modifier l'édition d'une instance sur place

Cette section explique comment modifier l'édition de votre instance Cloud SQL sur place vers ou depuis l'édition Cloud SQL Enterprise Plus. L'édition Cloud SQL Enterprise Plus offre des avantages et des améliorations de performances que l'édition Cloud SQL Enterprise ne propose pas. Pour en savoir plus sur les éditions Cloud SQL, consultez Présentation des éditions Cloud SQL.

La mise à niveau vers l'édition Cloud SQL Enterprise Plus prend quelques minutes et n'entraîne que très peu de temps d'arrêt. Le retour à l'édition Cloud SQL Enterprise entraînera une indisponibilité plus longue. Aucun de ces processus ne nécessite de modifier les points de terminaison auxquels vos applications se connectent.

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

Console

  1. Dans la console Google Cloud , 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 si votre instance utilise l'édition Cloud SQL Enterprise, ou sur Passer à l'édition Enterprise si votre instance utilise l'édition Cloud SQL Enterprise Plus.
  5. Utilisez le panneau qui s'ouvre pour spécifier la configuration de votre instance à l'aide de la nouvelle édition. Consultez la section [Options pour effectuer des modifications sur place](#change-options).
  6. Saisissez l'ID de votre instance pour confirmer ces choix, puis cliquez sur Mettre à niveau l'édition ou Changer d'édition selon que vous passez à une édition supérieure ou inférieure.

Vous pouvez également modifier l'édition sur la page Instances en sélectionnant Modifier dans la colonne Actions de l'instance.

De plus, si votre instance utilise l'édition Cloud SQL Enterprise, vous pouvez lancer une mise à niveau en cliquant sur le lien Mettre à niveau à côté du champ de l'édition dans la section Configuration de la page de l'instance.

gcloud

L'exemple de code [`gcloud sql instance patch`](/sdk/gcloud/reference/sql/instances/patch) 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 Types de machines pour les instances Cloud SQL Enterprise Plus.

REST

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

Avant d'utiliser les données de requête, 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 Plus et déclenche une opération de redémarrage.

Avant d'utiliser les données de requête, 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"
}

Options pour les modifications sur place

La modification de l'édition de votre instance Cloud SQL peut nécessiter de modifier sa série de machines, ce qui affecte son type de stockage.

Modifications de la machine

Lorsque vous changez d'édition, vous devez également modifier le type de machine. Pour en savoir plus sur les séries de machines compatibles avec Cloud SQL, consultez Choisir une série de machines.

Lorsque vous passez de l'édition Cloud SQL Enterprise à l'édition Cloud SQL Enterprise Plus, vous pouvez choisir entre les séries de machines N2, C4A, C4 et C4D.

Lorsque vous passez de l'édition Cloud SQL Enterprise Plus à l'édition Cloud SQL Enterprise, vous pouvez choisir entre un cœur dédié à usage général et une série de machines N4.

Vous pouvez également modifier le type de machine sans changer d'édition. Après avoir choisi de modifier votre instance, accédez à la sous-section Machine de Configuration de la machine dans la zone Personnaliser votre instance. Vous pouvez sélectionner un autre type de machine dans le menu déroulant. Vous pouvez également choisir un nombre différent de vCPU, et activer ou désactiver le cache de données, le cas échéant.

Pour plus d'informations générales, consultez également la documentation Compute Engine pour les séries de machines N2, C4A, C4, C4D et N4.

Modifications du stockage

Si vous passez d'une série de machines à usage général ou N2 à une série de machines N4, C4A, C4 ou C4D, votre stockage est migré d'un disque SSD vers un stockage Google Cloud Hyperdisk Balanced. Cette mise à niveau ne nécessite généralement qu'un temps d'arrêt minimal.

Le stockage Google Cloud Hyperdisk Balanced peut être personnalisé pour votre cas d'utilisation en définissant les éléments suivants :

  • Capacité de stockage
  • IOPS provisionnées
  • Débit provisionné

Google Cloud Hyperdisk Balanced définit les valeurs et les limites par défaut des IOPS et du débit en fonction de la configuration de votre instance, qui inclut le type de machine et la capacité de stockage. La capacité de stockage limite la valeur par défaut, et le type de machine définit la valeur maximale pour les IOPS et le débit. Pour en savoir plus, consultez Choisir une option de stockage.

Modifications de l'emplacement des journaux binaires pour la récupération PITR

Si votre instance Cloud SQL Enterprise stocke les journaux de transactions pour la récupération PITR sur disque, le 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 changement de zone géographique :

  • 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'option expire_logs_days ou binlog_expire_logs_seconds sur votre instance, ces valeurs sont conservées.
  • Lors du 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 transactionLogRetentionDays, les journaux binaires ne seront pas conservés sur le disque plus longtemps que la durée par défaut de sept jours pour une instance de l'édition 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 options, 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 options.

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

Une fois le basculement vers Cloud Storage terminé pour une instance, Cloud SQL conserve des copies des journaux binaires sur le disque à des fins de réplication. Le stockage des journaux binaires sur disque peut être utile si vous souhaitez parcourir les 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.