Effectuer une mise à niveau sur place de la version majeure de la base de données

Cette page explique comment effectuer une mise à niveau sur place de la version majeure d'une base de données d'un cluster AlloyDB pour PostgreSQL. Pour en savoir plus sur les cas d'utilisation, le workflow et les sauvegardes automatiques de la mise à niveau sur place de la version majeure de la base de données, consultez Présentation de la mise à niveau sur place de la version majeure de la base de données.

Planifier une mise à niveau de version majeure de la base de données

Pour planifier la mise à niveau d'une version majeure de la base de données, procédez comme suit :

  1. Recherchez la version majeure actuelle de votre base de données.

    Console

    1. Dans la console Google Cloud , accédez à la page Clusters.

      accéder aux clusters

    2. Sélectionnez un cluster dans la liste. La page Vue d'ensemble s'affiche.

    3. Recherchez la version majeure de la base de données dans le champ Version.

    gcloud

    Pour en savoir plus sur l'installation et le démarrage avec la gcloud CLI, consultez Installer la gcloud CLI. Pour en savoir plus sur le démarrage de Cloud Shell, consultez Utiliser Cloud Shell.

    Exécutez la commande suivante pour obtenir les détails du cluster, y compris la version majeure actuelle :

    gcloud alloydb clusters describe CLUSTER_ID --region=REGION

    Effectuez les remplacements suivants :

    • CLUSTER_ID : ID du cluster
    • REGION : emplacement ou région du cluster

    REST v1beta

    Exécutez la requête suivante pour obtenir les détails du cluster, y compris la version majeure actuelle :

    GET https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID

    Effectuez les remplacements suivants :

    • CLUSTER_ID : ID du cluster
    • PROJECT_ID : ID du projet
    • REGION : emplacement ou région du cluster

    Pour envoyer votre demande, utilisez l'une des options suivantes :

    curl (Linux, macOS ou Cloud Shell)

    Exécutez la commande suivante : 

       curl -X GET \
         -H "Authorization: Bearer $(gcloud auth print-access-token)" \
         -H "Content-Type: application/json; charset=utf-8" \
         "https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID"

    PowerShell (Windows)

    Exécutez la commande suivante : 

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

   Invoke-WebRequest `
     -Method GET `
     -Headers $headers `
     -Uri "https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID| Select-Object -Expand Content

  2. Identifiez une version majeure de base de données cible dans le tableau suivant. Pour obtenir la liste complète des versions de bases de données compatibles avec AlloyDB, consultez Versions de bases de données et règles concernant les versions.

    Version majeure de la source Version(s) majeure(s) cible(s) acceptée(s)
    POSTGRES_14
    • POSTGRES_15
    • POSTGRES_16
    POSTGRES_15
    • POSTGRES_16

  3. Examinez les fonctionnalités proposées dans chaque version majeure de la base de données.

  4. Identifiez les éventuelles incompatibilités à résoudre. Les nouvelles versions majeures peuvent présenter des modifications incompatibles qui peuvent vous obliger à modifier le code de l'application, le schéma ou les paramètres de la base de données.

  5. Avant de commencer la mise à niveau de la version majeure sur votre cluster de production, nous vous recommandons de cloner votre cluster et de tester la mise à niveau de la version majeure sur le cluster cloné.

    En plus de vérifier que la mise à niveau a abouti, exécutez des tests pour vous assurer que l'application se comporte comme prévu sur le cluster mis à niveau.

Préparer le cluster pour une mise à niveau de version majeure

Pour vous connecter à la base de données, utilisez l'une des options suivantes :

  1. Supprimez ou promouvez vos instances dupliquées interrégionales. Les mises à niveau sur place des versions majeures de bases de données ne sont pas compatibles avec les répliques interrégionales. Pour en savoir plus, consultez Réplication interrégionale.

  2. Si votre cluster AlloyDB est une source de réplication logique, désactivez les abonnements en aval et supprimez tous les emplacements de réplication logique. Vous pourrez réactiver les abonnements et recréer les emplacements de réplication logique après la mise à niveau. Si l'instance AlloyDB n'est qu'une cible de réplication logique, ces étapes ne sont pas obligatoires. Pour désactiver les abonnements et supprimer les emplacements de réplication logique, procédez comme suit :

    1. Désactivez chaque abonnement en aval sur l'abonné ou la cible de réplication en aval. Ne désactivez pas les abonnements en aval sur l'instance AlloyDB en cours de mise à niveau :

      • Si vous utilisez pglogical, exécutez la commande suivante :

        SELECT * FROM
pglogical.alter_subscription_disable(SUBSCRIPTION_NAME, immediate);

        Remplacez SUBSCRIPTION_NAME dans la requête par le nom de l'abonnement existant. Si l'abonnement doit être désactivé immédiatement, définissez la valeur du paramètre immediate sur true. Par défaut, la valeur est false et l'abonnement n'est désactivé qu'à la fin de la transaction en cours.

        Exemple :

        postgres=> SELECT * FROM pglogical.alter_subscription_disable('test_sub',true);
alter_subscription_disable
----------------------------
t
(1 row)

      • Si vous utilisez une extension autre que pglogical, exécutez la commande suivante :

        ALTER SUBSCRIPTION SUBSCRIPTION_NAME DISABLE;

    2. Supprimez tous les emplacements de réplication logique sur l'instance principale AlloyDB en exécutant la commande suivante :

      SELECT pg_drop_replication_slot(REPLICATION_SLOT_NAME) FROM pg_replication_slots WHERE slot_type = 'logical';

      Remplacez REPLICATION_SLOT_NAME dans la requête par le nom de l'emplacement de réplication.

  3. Gérez vos extensions PostgreSQL. Pour en savoir plus, consultez Configurer des extensions de base de données.

    Les vérifications préalables à la mise à niveau détectent les incompatibilités d'extension et signalent ces violations dans les journaux, ainsi que les actions suggérées. Pour en savoir plus, consultez Afficher les échecs de la vérification préalable à la mise à niveau.

    Vous devrez peut-être procéder comme suit :

    1. Supprimez toutes les extensions qui ne sont plus compatibles dans la version cible.

    2. Mettez à niveau PostGIS et les extensions associées (address_standardizer, address_standardizer_data_us, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder et postgis_topology) vers une version compatible dans la version PostgreSQL cible. Pour en savoir plus, consultez Extensions PostGIS. Le tableau suivant répertorie les versions minimales de l'extension PostGIS compatibles avec chaque version majeure de PostgreSQL :

      Version de PostgreSQL Version minimale de PostGIS compatible
      PG14 3.1
      PG15 3.2
      PG16 3.4

      Par exemple, si votre version de PostGIS est 3.1.x et que vous souhaitez passer de POSTGRES 14 à POSTGRES 16, utilisez la commande suivante pour mettre à niveau l'extension PostGIS :

      ALTER EXTENSION postgis UPDATE TO '3.4.0';
SELECT PostGIS_Version();

  4. Vérifiez que les connexions sont autorisées pour chaque base de données, à l'exception de template0, en exécutant la requête suivante et en vérifiant le champ datallowconn pour chaque base de données :

    SELECT datname,datallowconn from pg_database;

    Une valeur t dans le champ datallowconn signifie que la connexion est autorisée. Une valeur f indique qu'une connexion ne peut pas être établie. La base de données template0 ne doit pas autoriser les connexions.

    Pour autoriser les connexions à une base de données, exécutez la commande suivante :

    ALTER DATABASE DATABASE_NAME WITH ALLOW_CONNECTIONS = true;

  5. Vérifiez que template1 est une base de données de modèle en exécutant la commande suivante :

    SELECT datname, datistemplate FROM pg_database WHERE datname = 'template1';

    Si datistemplate est défini sur f, définissez-le sur true en exécutant la commande suivante :

    ALTER DATABASE template1 WITH IS_TEMPLATE true;

Mettre à niveau la version majeure du cluster sur place

La mise à niveau sur place de la version majeure de la base de données peut prendre entre 40 minutes et 48 heures, selon des facteurs tels que la taille de la base de données, la taille du schéma et le nombre d'instances de pool de lecture dans le cluster. Le temps d'arrêt de l'instance principale est généralement de 20 minutes à une heure, et dépend principalement du schéma de votre base de données.

Lorsque vous placez une demande de mise à niveau de version majeure sur place, AlloyDB commence par effectuer des vérifications préalables à la mise à niveau. Si AlloyDB détermine que votre cluster n'est pas prêt pour une mise à niveau de version majeure, la requête échoue. Pour en savoir plus, consultez Résoudre les problèmes liés à la mise à niveau d'une version majeure sur place.

Pour mettre à niveau la version majeure de la base de données sur place, procédez comme suit :

Console

  1. Dans la console Google Cloud , accédez à la page Clusters.

    accéder aux clusters

  2. Sélectionnez un cluster dans la liste. La page Vue d'ensemble s'affiche.

  3. Cliquez sur Mettre à niveau pour lancer le processus de mise à niveau de la version majeure de la base de données.

  4. À l'étape Choisir une version de base de données, sélectionnez l'une des versions majeures de base de données disponibles comme version majeure cible.

  5. Cliquez sur Continuer.

  6. À l'étape Mettre à niveau le cluster, dans le champ ID du cluster, saisissez le nom du cluster.

  7. Cliquez sur Lancer la mise à niveau. Vous êtes redirigé vers l'étape État de la mise à niveau, où vous pouvez vérifier l'état de la mise à niveau. Pour en savoir plus, consultez Surveiller la mise à niveau de la version majeure de la base de données.

gcloud

Démarrez la mise à niveau de version majeure sur place en exécutant la commande suivante :

gcloud alloydb clusters upgrade CLUSTER_ID --region=REGION --version=DATABASE_VERSION --async

Voici un exemple de commande :

gcloud alloydb clusters upgrade my-cluster --region=us-central1 --version=POSTGRES_16 --async

REST v1beta

Démarrez la mise à niveau de version majeure sur place en exécutant la commande suivante :

PATCH https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID:upgrade

Corps JSON de la requête :

{
  "version": "DATABASE_VERSION"
}

Remplacez par l'énumération de la version majeure de la base de données cible, qui doit être postérieure à la version actuelle.

Exemple de corps de requête JSON :

{
"version": "POSTGRES_16"
}

Terraform

Pour mettre à niveau une instance de votre cluster de bases de données vers une version PostgreSQL, utilisez une ressource Terraform et définissez database_version sur une version majeure cible compatible.

resource "google_alloydb_instance" "default" {
cluster       = google_alloydb_cluster.default.name
instance_id   = "alloydb-instance"
instance_type = "PRIMARY"

machine_config {
  cpu_count = 2
}

depends_on = [google_service_networking_connection.vpc_connection]
}

resource "google_alloydb_cluster" "default" {
  cluster_id = "alloydb-cluster"
  location   = "us-central1"
  network_config {
    network = google_compute_network.default.id
  }
  database_version = "POSTGRES_16"

  initial_user {
    password = "alloydb-cluster"
  }
}

data "google_project" "project" {}

resource "google_compute_network" "default" {
  name = "alloydb-network"
}

resource "google_compute_global_address" "private_ip_alloc" {
  name          =  "alloydb-cluster"
  address_type  = "INTERNAL"
  purpose       = "VPC_PEERING"
  prefix_length = 16
  network       = google_compute_network.default.id
}

resource "google_service_networking_connection" "vpc_connection" {
  network                 = google_compute_network.default.id
  service                 = "servicenetworking.googleapis.com"
  reserved_peering_ranges = [google_compute_global_address.private_ip_alloc.name]
}

Pour savoir comment appliquer ou supprimer une configuration Terraform, consultez Commandes Terraform de base.

Surveiller la mise à niveau de la version majeure du cluster

Une fois la mise à niveau sur place de la version majeure de la base de données lancée, vous pouvez surveiller son état à l'aide de la console Google Cloud , de la gcloud CLI ou de l'API REST.

Console

Pour vérifier l'état de la mise à niveau dans la console Google Cloud  :

  1. Dans la console Google Cloud , accédez à la page Clusters.

    accéder aux clusters

  2. Sélectionnez le cluster en cours de mise à niveau. La page Vue d'ensemble s'affiche.

  3. Ouvrez la page Vue d'ensemble.

  4. Cliquez sur État de la mise à niveau. La page État de la mise à niveau s'affiche. Vous pouvez y vérifier l'état de la mise à niveau.

gcloud

Pour vérifier l'état de la mise à niveau dans gcloud CLI, procédez comme suit :

  1. Obtenez l'ID d'opération de mise à niveau en exécutant la commande suivante. Avant d'exécuter la commande, remplacez la variable CLUSTER_ID par le nom du cluster :

    gcloud alloydb operations list --cluster=CLUSTER_ID --region=REGION_ID --filter=metadata.verb:upgrade

    Appel gcloud CLI utilisé pour déclencher une mise à niveau de version majeure. alloydb beta clusters upgrade renvoie l'ID de l'opération en tant que réponse synchrone. Vous pouvez également utiliser la commande gcloud alloydb operations list avec l'option --cluster.

    Voici un exemple de commande :

    gcloud alloydb operations list --cluster=my-cluster --region=us-central1 --filter=metadata.verb:upgrade

  2. Surveillez l'état de la mise à niveau en exécutant la commande gcloud alloydb operations describe :

    gcloud alloydb operations describe OPERATION_ID
--region=REGION

REST v1beta

Pour vérifier l'état de la mise à niveau dans l'API REST, procédez comme suit :

  1. Obtenez l'ID d'opération de la mise à niveau.

    Utilisez la requête GET suivante avec la méthode operations.list pour lister toutes les opérations de mise à niveau et trouver celle correspondant au cluster cible :

    GET https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/operations/filter=metadata.verb:upgrade

    L'appel d'API REST renvoie l'ID de l'opération en tant que réponse synchrone.

  2. Surveillez l'état de la mise à niveau.

    Exécutez une requête GET avec la méthode operations.get :

      GET https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID

    Effectuez les remplacements suivants :

    • PROJECT_ID : ID du projet
    • REGION : emplacement ou région du cluster
    • OPERATION_ID : ID de l'opération de mise à niveau récupéré à l'étape précédente.

    Voici un exemple de réponse lorsque l'opération est en cours :

    {
"name": "projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID",
"metadata": {
"@type": "type.googleapis.com/google.cloud.alloydb.v1.OperationMetadata",
"createTime": "2024-09-16T23:17:39.727319438Z",
"target": "projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID",
"verb": "upgrade",
"requestedCancellation": false,
"apiVersion": "v1",
"upgradeClusterStatus": {
   "state": "IN_PROGRESS",
   "cancellable": true,
   "stages": [
    {
      "stage": "ALLOYDB_PRECHECK",
      "state": "IN_PROGRESS"
    },
    {
      "stage": "PG_UPGRADE_CHECK",
      "state": "IN_PROGRESS"
    },
    {
      "stage": "PREPARE_FOR_UPGRADE",
      "state": "NOT_STARTED"
    },
    {
      "stage": "PRIMARY_INSTANCE_UPGRADE",
      "state": "NOT_STARTED"
    },
    {
      "stage": "CLEANUP",
      "state": "NOT_STARTED"
    }
   ]
 }
},
"done":false
}

    Voici un exemple de réponse lorsque l'opération est terminée :

    {
"operations": [
{
 "metadata": {
 "@type": "type.googleapis.com/google.cloud.alloydb.v1betaalpha.OperationMetadata",
 "createTime": "2024-09-16T21:52:17.303861317Z",
 "endTime": "2024-09-16T22:29:13.947527949Z",
 "target": "projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_ID",
 "verb": "upgrade",
 "requestedCancellation": false,
 "apiVersion": "v1beta",
 "upgradeClusterStatus": {
  "state": "SUCCESS",
  "stages": [
    {
      "stage": "ALLOYDB_PRECHECK",
      "state": "SUCCESS"
    },
    {
      "stage": "PG_UPGRADE_CHECK",
      "state": "SUCCESS"
    },
    {
      "stage": "PREPARE_FOR_UPGRADE",
      "state": "SUCCESS"
    },
    {
      "stage": "PRIMARY_INSTANCE_UPGRADE",
      "state": "SUCCESS"
    },
    {
      "stage": "CLEANUP",
      "state": SUCCESS"
    }
   ]
 }
},
"response": {
     …
},
"name":  "projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID",
"done": true
}
]
}

    Pour en savoir plus sur la structure response, consultez Réponse de l'opération de mise à niveau.

Réponse de l'opération de mise à niveau

La réponse de l'opération UpgradeCluster inclut les éléments suivants :

  • status : état de l'opération de mise à niveau globale. Les valeurs possibles sont SUCCESS, FAILED et PARTIAL_SUCCESS..
  • message : fournit un bref résumé du résultat de l'opération de mise à niveau.
  • clusterUpgradeDetails : détails de la mise à niveau pour les clusters en cours de mise à niveau. Ce champ est un tableau. AlloyDB n'autorise qu'une seule mise à niveau de cluster. Il ne comporte donc qu'une seule entrée.
    • name : nom complet du cluster.
    • upgradeStatus : état de la mise à niveau du cluster. Les valeurs possibles sont SUCCESS, FAILED et PARTIAL_SUCCESS. PARTIAL_SUCCESS signifie qu'une ou plusieurs instances de pool de lecture ne peuvent pas être mises à niveau.
    • clusterType : type de cluster. AlloyDB ne vous permet de mettre à niveau qu'un seul cluster PRIMARY. Ce type doit toujours être PRIMARY.
    • databaseVersion : version actuelle de la base de données du cluster.
    • stageInfo : informations sur les étapes de mise à niveau du cœur.
      • status : SUCCESS ou FAILED
      • logs_url : lien vers les journaux générés par l'étape. Vide pour les étapes qui ne génèrent pas de journaux.
    • instanceUpgradeDetails : informations sur la mise à niveau pour toutes les instances du cluster.
      • name : nom complet de l'instance
      • upgradeStatus : SUCCESS ou FAILED
      • instanceType : PRIMARY ou READ_POOL

Voici un exemple de réponse à une opération de mise à niveau :

"response": {
  "@type": "type.googleapis.com/google.cloud.alloydb.v1alpha.UpgradeClusterResponse",
  "status": "SUCCESS",
  "message": "Cluster upgraded successfully.",
  "clusterUpgradeDetails": [
    {
      "name": "projects/1234/locations/us-central1/clusters/abc",
      "upgradeStatus": "SUCCESS",
      "clusterType": "PRIMARY",
      "databaseVersion": "POSTGRES_16",
      "stageInfo": [
        {
          "stage": "ALLOYDB_PRECHECK",
          "status": "SUCCESS",
          "logsUrl": "https://console.cloud.google.com/logs/query..."
        },
        {
          "stage": "PG_UPGRADE_CHECK",
          "status": "SUCCESS",
          "logsUrl": "https://console.cloud.google.com/logs/query..."
        },
        {
          "stage": "PRIMARY_INSTANCE_UPGRADE",
          "status": "SUCCESS",
          "logsUrl": "https://console.cloud.google.com/logs/query..."
        },
        {
          "stage": "READ_POOL_INSTANCES_UPGRADE",
          "status": "SUCCESS",
        }
      ],
      "instanceUpgradeDetails": [
        {
          "name": "projects/1234/locations/us-central1/clusters/abc/instances/primary",
          "upgradeStatus": "SUCCESS",
          "instanceType": "PRIMARY",
        },
        {
          "name": "projects/1234/locations/us-central1/clusters/abc/instances/read1",
          "upgradeStatus": "SUCCESS",
          "instanceType": "READ_POOL",
        },
        {
          "name": "projects/1234/locations/us-central1/clusters/abc/instances/read2",
          "upgradeStatus": "SUCCESS",
          "instanceType": "READ_POOL",
        }
      ]
    }
  ]
}

Afficher les journaux de mise à niveau AlloyDB

AlloyDB publie tous les journaux de mise à niveau dans le nom de journal postgres_upgrade.

Pour afficher les journaux liés à la mise à niveau, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

  2. Sélectionnez alloydb.googleapis.com/postgres_upgrade comme nom de journal. Cela se traduit par la requête "logName="projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres_upgrade".

  3. Utilisez les libellés suivants pour filtrer les journaux :

    Label Description

    LOG_TYPE

    		 Étape de mise à niveau ayant généré le journal. Les valeurs possibles sont ALLOYDB_PRECHECK, PG_UPGRADE_CHECK et PG_UPGRADE.

    OPERATION_NAME

    		 Nom complet de l'opération de mise à niveau.

    FILE_NAME

    		 Renseigné uniquement pour les journaux pg_upgrade_check et pg_upgrade, et correspond aux fichiers journaux générés par l'utilitaire pg_upgrade.

Voici un exemple de requête qui renvoie les journaux de prévérification de la mise à niveau d'AlloyDB pour une opération donnée :

logName="projects/project1234/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
labels.LOG_TYPE="ALLOYDB_PRECHECK"
labels.OPERATION_NAME="projects/PROJECT_ID/locations/REGION/operations/OPERATION_ID"

Pour en savoir plus sur les vérifications de mise à niveau, consultez Présentation de la mise à niveau sur place de la version majeure de la base de données.

Afficher les journaux de mise à niveau d'un cluster

Pour afficher les journaux de mise à niveau d'un cluster lorsque vous ne connaissez pas l'ID de l'opération et que l'opération a expiré, procédez comme suit :

  1. Dans la console Google Cloud , accédez à la page Explorateur de journaux.

    Accéder à l'explorateur de journaux

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Logging.

  2. Interrogez les journaux de vérification préalable AlloyDB pour votre cluster.

    logName="projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
labels.LOG_TYPE="ALLOYDB_PRECHECK"
resource.labels.cluster_id=CLUSTER_ID

  3. Recherchez le Operation_ID à partir du libellé de journal OPERATION_NAME.

    Dans l'exemple suivant, Operation_ID de OPERATION_NAME est operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013.

    labels.OPERATION_NAME="projects/myproject/locations/us-central1/operations/operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013"

  4. Interrogez tous les journaux postgres_upgrade pour une opération spécifique.

    logName="projects/production-1/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
labels.OPERATION_NAME="operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013"

Annuler la mise à niveau de version majeure sur place de la base de données

Vous pouvez annuler une opération de mise à niveau de version majeure en cours depuis la console Google Cloud , la gcloud CLI ou l'API REST.

Trouver l'ID de l'opération

Pour annuler l'opération de mise à niveau de la version majeure à l'aide de la gcloud CLI ou de l'API REST, vous avez besoin de l'ID de l'opération. Vous devez spécifier cet ID dans la commande gcloud CLI ou de l'API REST afin qu'AlloyDB sache quelle opération annuler.

Vous ne pouvez pas annuler la mise à niveau une fois qu'elle a atteint un certain point.

Lorsque vous démarrez la mise à niveau de version majeure sur place, l'ID d'opération est renvoyé dans le champ name de la réponse. Consultez l'exemple de réponse.

Vous pouvez également trouver l'ID d'opération en effectuant un appel operations.list sur le cluster AlloyDB.

Annuler la mise à niveau

Pour annuler une mise à niveau de version majeure sur place, procédez comme suit :

Console

  1. Dans la console Google Cloud , accédez à la page Clusters.

    accéder aux clusters

  2. Sélectionnez un cluster dans la liste. La page Vue d'ensemble s'affiche.

  3. Cliquez sur État de la mise à niveau.

  4. Cliquez sur Annuler la mise à niveau. Si la mise à niveau ne peut pas être annulée, ce bouton est grisé.

gcloud

Utilisez la commande gcloud alloydb operations cancel pour annuler l'opération :

gcloud alloydb operations cancel OPERATION_ID

Remplacez la variable OPERATION_ID par l'ID de l'opération.

Si UpgradeClusterStatus affiche cancellable comme false dans le résultat de la commande gcloud alloydb operations cancel, AlloyDB ignore la demande d'annulation et poursuit la mise à niveau. Dans ce cas, l'API ne génère pas d'erreur et renvoie une réponse vide. Pour en savoir plus sur l'état de la mise à niveau, consultez Surveiller la mise à niveau de la version majeure du cluster.

REST v1beta

Exécutez la commande suivante :

POST https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/operations/OPERATION_ID:cancel

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

  • PROJECT_ID : ID du projet.
  • OPERATION_ID : ID de l'opération d'importation ou d'exportation.

Si cancellable dans UpgradeClusterStatus est défini sur false, vous ne pouvez pas annuler la mise à niveau.

Pour envoyer votre demande, utilisez l'une des options suivantes :

curl (Linux, macOS ou Cloud Shell)

Exécutez la commande suivante :

       curl -X POST \
             -H "Authorization: Bearer $(gcloud auth print-access-token)" \
             -H "Content-Type: application/json; charset=utf-8" \
             -d "" \
            "https://alloydb.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID:cancel"

PowerShell (Windows)

Exécutez la commande suivante :

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

       Invoke-WebRequest `
         -Method POST `
         -Headers $headers `
         -Uri "https://alloydb.googleapis.com/v1beta/projects/PROJECT_ID/operations/OPERATION_ID:cancel"| Select-Object -Expand Content

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

Réponse

Cet appel d'API REST ne renvoie aucune réponse.

Terminer la mise à niveau de version majeure sur place

Pour effectuer la mise à niveau de la version majeure, connectez-vous à une instance AlloyDB à l'aide d'AlloyDB Studio, de psql ou d'autres méthodes de connexion.

Si vous utilisez un système autre qu'AlloyDB, consultez la documentation de votre système pour obtenir des instructions de connexion.

Une fois votre cluster mis à niveau, procédez comme suit :

  1. Si vous avez précédemment désactivé pglogical, réactivez la réplication pglogical. L'activation de la réplication pglogical crée automatiquement l'emplacement de réplication requis.

    1. Supprimez l'abonnement pglogical sur l'instance répliquée de destination à l'aide de la commande suivante :

        select pglogical.drop_subscription(subscription_name name);

      Remplacez name par le nom de l'abonnement existant. Exemple :

      postgres=> select pglogical.drop_subscription(subscription_name:= 'test_sub');
-[ RECORD 1 ]-----+--
drop_subscription |1

1.  Recreate the `pglogical` subscription on the destination or
  replica by providing the following connection information to the
  AlloyDB primary instance:

  ```sql
  SELECT pglogical.create_subscription(
  subscription_name :='test_sub',<br>
  provider_dsn := 'host=primary-ip port=5432 dbname=postgres user=replication_user password=replicapassword'
  );
  ```

1.  Check the status of the subscription by using the following command:

  ```sql
  SELECT * FROM pglogical.show_subscription_status('test_sub');
  ```

1.  Test the replication by performing write transactions and
  verifying that the changes are visible on the destination.

  2. Actualisez les statistiques de la base de données.

    Une fois la mise à niveau terminée, exécutez ANALYZE sur votre cluster principal pour mettre à jour les statistiques système. Les statistiques précises garantissent que le planificateur de requêtes PostgreSQL traite les requêtes de manière optimale. Des statistiques manquantes peuvent entraîner des plans de requête inexacts, ce qui peut dégrader les performances et entraîner une utilisation excessive de mémoire.

  3. Exécutez des tests de validation pour vous assurer que le système mis à niveau fonctionne comme prévu.

  4. Vérifiez que la version majeure de la base de données mise à niveau sur place apparaît sur la page Présentation du cluster dans la console Google Cloud .

Restaurer la version majeure précédente

Si votre système de base de données mis à niveau ne fonctionne pas comme prévu, vous devrez peut-être revenir à l'état antérieur à la mise à niveau. Pour ce faire, restaurez une sauvegarde préalable à la mise à niveau (celle qu'AlloyDB crée automatiquement pendant le processus de mise à niveau ou une sauvegarde préalable à la mise à niveau existante) afin de créer un cluster avec l'état préalable à la mise à niveau.

Pour restaurer un état antérieur à la mise à niveau, procédez comme suit :

  1. Identifiez une sauvegarde préalable à la mise à niveau à partir de laquelle effectuer la restauration. Lors de la mise à niveau, AlloyDB crée automatiquement une sauvegarde préalable avec le préfixe pre-upgrade-bkp. Pour en savoir plus, consultez Afficher la liste des sauvegardes.

  2. Lancez une restauration à partir de la sauvegarde préalable à la mise à niveau, ce qui crée un cluster avec la version précédente de PostgreSQL. Pour en savoir plus, consultez Restaurer un cluster à partir d'une sauvegarde stockée.

  3. Connectez votre application. Mettez à jour votre application avec les détails du cluster restauré et de ses instances répliquées avec accès en lecture. Vous pouvez reprendre la diffusion du trafic sur le cluster restauré.

Vous pouvez également effectuer une récupération à un moment précis antérieur à la mise à niveau. Pour en savoir plus, consultez Utiliser la récupération à un moment précis (PITR).

Limites

Les limites suivantes affectent les mises à niveau de versions majeures sur place pour AlloyDB :

  • Vous ne pouvez pas effectuer de mise à niveau de version majeure sur place sur un cluster secondaire.
  • La mise à niveau d'instances comportant plus de 1 000 bases de données d'une version à une autre peut prendre beaucoup de temps et expirer.
  • AlloyDB n'est pas compatible avec la mise à niveau des clusters qui utilisent pg_largeobject_metadata. Si select count(*) from pg_largeobject_metadata; est différent de zéro, la mise à niveau échoue.
  • L'opération de mise à niveau de la version majeure sur place peut se terminer avant la sauvegarde avant mise à niveau ou avant la fin des sauvegardes après mise à niveau, en particulier lorsque vous disposez d'une grande base de données avec moins d'objets de schéma.
  • Un court délai peut s'écouler entre le moment où les écritures reprennent sur l'instance mise à niveau et celui où la sauvegarde post-migration est créée. Cela signifie que le contenu des sauvegardes après la mise à niveau peut ne pas correspondre au contenu de la base de données avant la mise à niveau de la version majeure.
  • Des sauvegardes avant mise à niveau peuvent toujours être créées en cas d'échec d'une mise à niveau sur place d'une version majeure.
  • Étant donné que les sauvegardes automatiques de mise à niveau sont continues, vous ne pouvez pas les supprimer tant qu'elles n'ont pas atteint la durée de conservation maximale des sauvegardes et de la récupération continues. Lorsque la durée de conservation maximale est atteinte, les sauvegardes sont supprimées. Vous pouvez également utiliser la gcloud CLI pour supprimer manuellement les sauvegardes. Pour en savoir plus, consultez Restrictions concernant la suppression des sauvegardes.

Étapes suivantes