Mise à niveau sur place

Cette page explique comment mettre à niveau ou rétrograder vos instances Cloud SQL sur place.

Apporter des modifications sur place à une instance Cloud SQL

Vous pouvez utiliser les 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

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

Si votre instance utilise une version antérieure de MySQL, vous devez la mettre à niveau vers MySQL 8.0.31 ou une 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.

Tenez compte des éventuels changements de stockage liés au type de machine.

Les 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 le stockage Hyperdisk Balanced plutôt que l'une des options de disque persistant utilisées par les anciens types de machines.

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 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 Modifications apportées au stockage.

Être informé des modifications apportées au stockage des journaux de transactions pour la récupération à un moment précis

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 de 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 obtenir une explication complète de 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 à un moment précis.

Modifier l'édition d'une instance sur place

Cette section explique comment modifier l'édition de votre instance Cloud SQL sur place pour passer à l'édition Cloud SQL Enterprise Plus ou en revenir. L'édition Cloud SQL Enterprise Plus offre certains avantages et améliorations de performances qui ne sont pas disponibles dans l'édition Cloud SQL Enterprise. Pour en savoir plus sur les éditions Cloud SQL, consultez la 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. Si vous repassez à l'édition Cloud SQL Enterprise, l'indisponibilité sera 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.

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 des machines

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 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 à usage général avec cœur dédié 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 section Personnaliser votre instance. Vous pouvez sélectionner un autre type de machine dans le menu déroulant. Vous pouvez également choisir un autre nombre de vCPU et activer ou désactiver le cache de données si nécessaire.

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 apportées au 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é de Solid-state drive (SSD) vers le stockage Google Cloud Hyperdisk balanced. Cette mise à niveau nécessite généralement un temps d'arrêt minimal.

Vous pouvez personnaliser le stockage Google Cloud Hyperdisk Balanced 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 des valeurs et des limites par défaut pour les IOPS et le 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 les options 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 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 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 période 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.