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 de votre instance Cloud SQL, son type de machine, son type de stockage ou 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

Assurez-vous que votre instance exécute MySQL version 8.0.31 ou ultérieure.

Si votre instance exécute une version antérieure de MySQL, vous devez passer à MySQL 8.0.31 ou version ultérieure. Pour en savoir plus, consultez les pages Mettre à niveau la version majeure de la base de données sur place et Mettre à niveau la version mineure de la base de données.

Tenir compte des modifications potentielles du stockage liées au type de machine

Différentes éditions sont compatibles avec différents types de machines qui utilisent différentes options de stockage. Les types de machines C4 et C4A hautes performances utilisent Hyperdisk Balanced stockage 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 une certaine indisponibilité 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 la section Modifications du stockage.

Tenir compte 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 le 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 de récupération PITR 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 obtenir une explication complète de l'impact des mises à niveau sur place sur l'emplacement des journaux binaires, consultez la section 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 certains avantages et améliorations de performances que l'édition Cloud SQL Enterprise ne propose pas. Pour en savoir plus sur les éditions Cloud SQL, consultez la page Présentation des éditions Cloud SQL.

La mise à niveau vers l'édition Cloud SQL Enterprise Plus prend quelques minutes et entraîne un temps d'arrêt quasi nul. 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 rétrograder une instance Cloud SQL Enterprise Plus vers l'édition Cloud SQL Enterprise.

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

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

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

curl -X PATCH \
     -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/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "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"
}

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

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

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "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 la modification de sa série de machines, ce qui affecte à son tour son type de stockage.

Modifications de la machine

Lorsque vous modifiez les éditions, vous devez également modifier le type de machine. Pour en savoir plus sur les séries de machines compatibles avec Cloud SQL, consultez la section 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 et C4.

Lorsque vous passez de l'édition Cloud SQL Enterprise Plus à l'édition Cloud SQL Enterprise, vous pouvez choisir entre une série de machines à 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. Dans le menu déroulant, vous pouvez sélectionner un autre type de machine. Vous pouvez également choisir un nombre différent de processeurs virtuels et activer ou désactiver le cache de données, le cas échéant.

Pour obtenir des informations plus générales, consultez également la documentation Compute Engine pour les séries de machines N2, C4A, C4 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 ou C4, votre stockage sera migré d' un disque SSD vers un stockage Google Cloud Hyperdisk Balanced. Cette mise à niveau nécessite généralement 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 par défaut des IOPS et du débit, ainsi que les limites 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 la section 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 à la modification de l'emplacement :

• Le processus prend environ la durée du transactionLogRetentionDays paramètre de configuration de la récupération PITR 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.

• Pendant le basculement, 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 le 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.