Faça uma atualização da base de dados da versão principal no local

Esta página descreve como fazer uma atualização da versão principal no local de uma base de dados de um cluster do AlloyDB for PostgreSQL. Para saber mais acerca dos exemplos de utilização, do fluxo de trabalho e das cópias de segurança automáticas da atualização da versão principal no local da base de dados, consulte o artigo Vista geral da atualização da versão principal no local da base de dados.

Planeie uma atualização importante da versão da base de dados

Siga estes passos para planear uma atualização importante da versão da base de dados:

  1. Encontre a versão principal atual da base de dados.

    Consola

    1. Na Google Cloud consola, aceda à página Clusters.

      Aceda a Clusters

    2. Selecione um cluster na lista. É apresentada a página Vista geral.

    3. Localize a versão principal da base de dados no campo Versão.

    gcloud

    Para obter informações sobre a instalação e o início da CLI gcloud, consulte o artigo Instale a CLI gcloud. Para obter informações sobre como iniciar a Cloud Shell, consulte o artigo Use a Cloud Shell.

    Execute o seguinte comando para obter os detalhes do cluster, incluindo a versão principal atual:

    gcloud alloydb clusters describe CLUSTER_ID --region=REGION

    Faça as seguintes substituições:

    • CLUSTER_ID: o ID do cluster
    • REGION: a localização ou a região do cluster

    REST v1beta

    Execute o seguinte pedido para obter os detalhes do cluster, incluindo a versão principal atual:

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

    Faça as seguintes substituições:

    • CLUSTER_ID: o ID do cluster
    • PROJECT_ID: o ID do projeto
    • REGION: a localização ou a região do cluster

    Para enviar o seu pedido, use uma das seguintes opções:

    curl (Linux, macOS ou Cloud Shell)

    Execute o seguinte comando:

       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)

    Execute o seguinte comando:

       $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. Identifique uma versão principal da base de dados de destino na tabela seguinte. Para ver uma lista completa das versões da base de dados suportadas pelo AlloyDB, consulte o artigo Versões da base de dados e políticas de versões.

    Versão principal de origem Versões principais de destino suportadas
    POSTGRES_14
    • POSTGRES_15
    • POSTGRES_16
    POSTGRES_15
    • POSTGRES_16
  3. Reveja as funcionalidades oferecidas em cada versão principal da base de dados.

  4. Identifique as incompatibilidades que tem de resolver. As novas versões principais podem introduzir alterações incompatíveis que podem exigir que modifique o código da aplicação, o esquema ou as definições da base de dados.

  5. Antes de iniciar a atualização da versão principal no cluster de produção, recomendamos que clone o cluster e teste a atualização da versão principal no cluster clonado.

    Além de verificar se a atualização é concluída com êxito, execute testes para garantir que a aplicação se comporta como esperado no cluster atualizado.

Prepare o cluster para uma atualização da versão principal

Para estabelecer ligação à base de dados, use uma das seguintes opções:

  1. Elimine ou promova as suas réplicas entre regiões. As atualizações da versão principal no local da base de dados não suportam réplicas entre regiões. Para mais informações, consulte o artigo Replicação entre regiões.

  2. Se o seu cluster do AlloyDB for uma origem de replicação lógica, desative as subscrições a jusante e elimine todos os espaços de replicação lógica. Pode reativar as subscrições e recriar as ranhuras de replicação lógica após a atualização. Se a instância do AlloyDB for apenas um destino de replicação lógica, estes passos não são necessários. Para desativar as subscrições e eliminar as posições de replicação lógica, siga estes passos:

    1. Desative cada subscrição a jusante no subscritor ou no destino de replicação a jusante. Não desative as subscrições a jusante na instância do AlloyDB que está a ser atualizada:

      • Se estiver a usar o pglogical, execute o seguinte comando:

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

        Substitua SUBSCRIPTION_NAME na consulta pelo nome da subscrição existente. Se a subscrição tiver de ser desativada imediatamente, defina o valor do parâmetro immediate como true. Por predefinição, o valor é false e a subscrição é desativada apenas após o fim da transação atual.

        Por exemplo:

        postgres=> SELECT * FROM pglogical.alter_subscription_disable('test_sub',true);
        alter_subscription_disable
        ----------------------------
        t
        (1 row)
        
      • Se estiver a usar uma extensão diferente de pglogical, execute o seguinte comando:

        ALTER SUBSCRIPTION SUBSCRIPTION_NAME DISABLE;
        
    2. Elimine todas as ranhuras de replicação lógica na instância principal do AlloyDB executando o seguinte comando:

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

      Substitua REPLICATION_SLOT_NAME na consulta pelo nome do espaço de replicação.

  3. Faça a gestão das suas extensões do PostgreSQL. Para mais informações, consulte o artigo Configure extensões de base de dados.

    As verificações pré-atualização detetam incompatibilidades de extensões e apresentam essas violações nos registos, juntamente com ações sugeridas. Para mais informações, consulte o artigo Veja as falhas da verificação pré-atualização.

    Pode ter de fazer o seguinte:

    1. Remova todas as extensões que já não são suportadas na versão de destino.
    2. Atualize o PostGIS e as extensões relacionadas (address_standardizer, address_standardizer_data_us, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder e postgis_topology) para uma versão suportada na versão do PostgreSQL de destino. Para mais informações, consulte o artigo Extensões PostGIS. A tabela seguinte apresenta as versões mínimas suportadas da extensão PostGIS para cada versão principal do PostgreSQL:

      Versão do PostgreSQL Versão mínima suportada do PostGIS
      PG14 3.1
      PG15 3.2
      PG16 3.4

      Por exemplo, se a sua versão do PostGIS for 3.1.x e quiser atualizar do POSTGRES 14 para o POSTGRES 16, use o seguinte comando para atualizar a extensão do PostGIS:

      ALTER EXTENSION postgis UPDATE TO '3.4.0';
      SELECT PostGIS_Version();
      
  4. Verifique se as ligações são permitidas para cada base de dados, exceto para template0, executando a seguinte consulta e verificando o campo datallowconn para cada base de dados:

    SELECT datname,datallowconn from pg_database;
    

    Um valor t no campo datallowconn significa que a associação é permitida. Um valor f indica que não é possível estabelecer uma ligação. A base de dados template0 não pode permitir ligações.

    Para permitir ligações a uma base de dados, execute o seguinte comando:

    ALTER DATABASE DATABASE_NAME WITH ALLOW_CONNECTIONS = true;
    
  5. Verifique se template1 é uma base de dados de modelos executando o seguinte comando:

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

    Se datistemplate for f, defina-o como true executando o seguinte comando:

    ALTER DATABASE template1 WITH IS_TEMPLATE true;
    

Atualize a versão principal do cluster no local

A atualização da versão principal no local da base de dados pode demorar entre 40 minutos e 48 horas a ser concluída, consoante fatores como o tamanho da base de dados, o tamanho do esquema e o número de instâncias do conjunto de leitura no cluster. Normalmente, o tempo de inatividade da instância principal é de 20 minutos a 1 hora e depende principalmente do esquema da base de dados.

Quando faz um pedido de atualização da versão principal no local, o AlloyDB executa primeiro verificações pré-atualização. Se o AlloyDB determinar que o cluster não está pronto para uma atualização da versão principal, o pedido falha. Para mais informações, consulte o artigo Resolva problemas de uma atualização no local de uma versão principal.

Para atualizar a versão principal da base de dados no local, siga estes passos:

Consola

  1. Na Google Cloud consola, aceda à página Clusters.

    Aceda a Clusters

  2. Selecione um cluster na lista. É apresentada a página Vista geral.

  3. Clique em Atualizar para iniciar o processo de atualização da versão principal da base de dados.

  4. No passo Escolher versão da base de dados, selecione uma das versões principais da base de dados disponíveis como a versão principal de destino.

  5. Clique em Continuar.

  6. No passo Atualizar cluster, no campo ID do cluster, introduza o nome do cluster.

  7. Clique em Iniciar atualização. É direcionado para o passo Estado da atualização, onde pode verificar o estado da atualização. Para mais informações, consulte o artigo Monitorize a atualização da versão principal da base de dados.

gcloud

Inicie a atualização da versão principal no local executando o seguinte comando:

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

Segue-se um exemplo de comando:

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

REST v1beta

Inicie a atualização da versão principal no local executando o seguinte comando:

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

Corpo JSON do pedido:

{
  "version": "DATABASE_VERSION"
}

Substitua pelo enum da versão principal da base de dados de destino, que tem de ser posterior à versão atual.

Exemplo de corpo JSON do pedido:

{
"version": "POSTGRES_16"
}

Terraform

Para atualizar uma instância no cluster de base de dados para uma versão do PostgreSQL, use um recurso do Terraform e defina o database_version para uma versão principal de destino suportada.

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]
}

Para saber como aplicar ou remover uma configuração do Terraform, consulte o artigo Comandos básicos do Terraform.

Monitorize a atualização da versão principal do cluster

Após o início da atualização da versão principal da base de dados no local, pode monitorizar o estado da atualização através da consola, da CLI gcloud ou da API REST. Google Cloud

Consola

Siga estes passos para verificar o estado da atualização na Google Cloud consola:

  1. Na Google Cloud consola, aceda à página Clusters.

    Aceda a Clusters

  2. Selecione o cluster que está a ser atualizado. É apresentada a página Vista geral.

  3. Abra a página Vista geral.

  4. Clique em Estado da atualização. É apresentada a página Estado da atualização, onde pode verificar o estado da atualização.

gcloud

Siga estes passos para verificar o estado da atualização na CLI gcloud:

  1. Execute o seguinte comando para obter o ID da operação de atualização. Antes de executar o comando, substitua a variável CLUSTER_ID pelo nome do cluster:

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

    A chamada da CLI gcloud usada para acionar uma atualização da versão principal. alloydb beta clusters upgrade, devolve o ID da operação como uma resposta síncrona. Em alternativa, use o comando gcloud alloydb operations list com a flag --cluster.

    Segue-se um exemplo de comando:

    gcloud alloydb operations list --cluster=my-cluster --region=us-central1 --filter=metadata.verb:upgrade
  2. Monitorize o estado da atualização executando o comando gcloud alloydb operations describe:

    gcloud alloydb operations describe OPERATION_ID
    --region=REGION

REST v1beta

Siga estes passos para verificar o estado da atualização na API REST:

  1. Obtenha o ID da operação de atualização.

    Use o seguinte pedido GET com o método operations.list para listar todas as operações de atualização e encontrar a que corresponde ao cluster de destino:

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

    A chamada da API REST devolve o ID da operação como uma resposta síncrona.

  2. Monitorize o estado da atualização.

    Use um pedido GET com o método operations.get:

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

    Faça as seguintes substituições:

    • PROJECT_ID: o ID do projeto
    • REGION: a localização ou a região do cluster
    • OPERATION_ID: o ID da operação de atualização, que foi obtido no passo anterior.

    Segue-se um exemplo de resposta quando a operação está em curso:

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

    Segue-se um exemplo de resposta quando a operação estiver concluída:

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

    Para mais informações sobre a estrutura response, consulte a secção Resposta da operação de atualização.

Resposta da operação de atualização

A resposta da operação UpgradeCluster inclui o seguinte:

  • status: estado da operação de atualização geral. Os valores possíveis são SUCCESS, FAILED e PARTIAL_SUCCESS.
  • message: fornece um breve resumo do resultado da operação de atualização.
  • clusterUpgradeDetails: detalhes da atualização para os clusters que estão a ser atualizados. Este campo é uma matriz. O AlloyDB só permite uma atualização de cluster único, pelo que inclui apenas uma entrada.
    • name: nome totalmente qualificado do cluster.
    • upgradeStatus: o estado da atualização do cluster. Os valores possíveis são SUCCESS, FAILED e PARTIAL_SUCCESS. PARTIAL_SUCCESS significa que não é possível atualizar uma ou mais instâncias do conjunto de leitura.
    • clusterType: o tipo de cluster. O AlloyDB só permite atualizar um único cluster PRIMARY. Este tipo tem de ser sempre PRIMARY.
    • databaseVersion: a versão atual da base de dados do cluster.
    • stageInfo: informações sobre as fases principais da atualização.
      • status: SUCCESS ou FAILED
      • logs_url: link para os registos gerados pela fase. Vazio para estágios que não geram registos.
    • instanceUpgradeDetails: informações de atualização para todas as instâncias no cluster.
      • name: nome totalmente qualificado da instância
      • upgradeStatus: SUCCESS ou FAILED
      • instanceType: PRIMARY ou READ_POOL

Segue-se um exemplo de resposta da operação de atualização:

"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",
        }
      ]
    }
  ]
}

Veja os registos de atualização do AlloyDB

O AlloyDB publica todos os registos de atualizações no nome do registo postgres_upgrade.

Para ver os registos relacionados com a atualização, siga estes passos:

  1. Na Google Cloud consola, aceda à página Explorador de registos:

    Aceda ao Explorador de registos

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

  2. Selecione alloydb.googleapis.com/postgres_upgrade como nome do registo. Isto traduz-se na consulta "logName="projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres_upgrade".

  3. Use as seguintes etiquetas para filtrar os registos:

    Etiqueta Descrição

    LOG_TYPE

    Fase de atualização que gerou o registo. Os valores possíveis são ALLOYDB_PRECHECK, PG_UPGRADE_CHECK e PG_UPGRADE.

    OPERATION_NAME

    Nome completo da operação de atualização.

    FILE_NAME

    Preenchido apenas para registos pg_upgrade_check e pg_upgrade e corresponde aos ficheiros de registo gerados pela utilidade pg_upgrade.

Segue-se um exemplo de consulta que devolve os registos de pré-verificação de atualização do AlloyDB para uma determinada operação:

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"

Para mais informações sobre as verificações de atualização, consulte o artigo Vista geral da atualização da versão principal no local da base de dados.

Veja os registos de atualizações de um cluster

Para ver os registos de atualização de um cluster quando não conhece o ID da operação e a operação expirou, siga estes passos:

  1. Na Google Cloud consola, aceda à página Explorador de registos:

    Aceda ao Explorador de registos

    Se usar a barra de pesquisa para encontrar esta página, selecione o resultado cuja legenda é Registo.

  2. Consulte os registos de pré-verificação do AlloyDB para o seu cluster.

    logName="projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres_upgrade"
    labels.LOG_TYPE="ALLOYDB_PRECHECK"
    resource.labels.cluster_id=CLUSTER_ID
    
  3. Encontre o Operation_ID na etiqueta de registo OPERATION_NAME.

    No exemplo seguinte, Operation_ID de OPERATION_NAME é operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013.

    labels.OPERATION_NAME="projects/myproject/locations/us-central1/operations/operation-1728225968201-623cff6ed1e02-e34b7191-3cd92013"
    
  4. Consultar todos os registos postgres_upgrade para uma operação específica.

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

Cancele a atualização da versão principal no local da base de dados

Pode cancelar uma operação de atualização da versão principal em curso a partir da consola Google Cloud , da CLI gcloud ou da API REST.

Encontre o ID da operação

Para cancelar a operação de atualização da versão principal através da CLI gcloud ou da API REST, precisa do ID da operação. Tem de especificar este ID no comando da CLI gcloud ou da API REST para que o AlloyDB saiba que operação cancelar.

Não pode cancelar a atualização depois de a instância principal atingir um determinado ponto.

Quando inicia a atualização da versão principal no local, o ID da operação é devolvido no campo name da resposta. Consulte o exemplo de resposta.

Também pode encontrar o ID da operação fazendo uma chamada operations.list no cluster do AlloyDB.

Cancele a atualização

Para cancelar uma atualização da versão principal no local, siga estes passos:

Consola

  1. Na Google Cloud consola, aceda à página Clusters.

    Aceda a Clusters

  2. Selecione um cluster na lista. É apresentada a página Vista geral.

  3. Clique em Atualizar estado.

  4. Clique em Cancelar atualização. Se não for possível cancelar a atualização, este botão está assinalado a cinzento.

gcloud

Use o comando gcloud alloydb operations cancel para cancelar a operação:

gcloud alloydb operations cancel OPERATION_ID

Substitua a variável OPERATION_ID pelo ID da operação.

Se o UpgradeClusterStatus mostrar cancellable como false na saída do comando gcloud alloydb operations cancel, o AlloyDB ignora o pedido de cancelamento e continua com a atualização. Neste caso, a API não gera um erro e devolve uma resposta vazia. Para mais informações sobre o estado da atualização, consulte o artigo Monitorize a atualização da versão principal do cluster.

REST v1beta

Execute o seguinte comando:

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

Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

  • PROJECT_ID: o ID do projeto.
  • OPERATION_ID: o ID da operação de importação ou exportação.

Se o valor de cancellable em UpgradeClusterStatus for false, não pode cancelar a atualização.

Para enviar o seu pedido, use uma das seguintes opções:

curl (Linux, macOS ou Cloud Shell)

Execute o seguinte comando:

       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)

Execute o seguinte comando:

       $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
    

Deve receber uma resposta JSON semelhante à seguinte:

Resposta

Esta chamada API REST não devolve nenhuma resposta.

Conclua a atualização da versão principal no local

Para concluir a atualização da versão principal, estabeleça ligação a uma instância do AlloyDB através do AlloyDB Studio, psql ou outros métodos de ligação.

Se estiver a usar um sistema que não seja o AlloyDB, consulte a documentação do sistema para obter instruções de ligação.

Depois de atualizar o cluster, siga estes passos para concluir a atualização:

  1. Se tiver desativado anteriormente a replicação pglogical, reative-a.pglogical A ativação da replicação pglogical cria automaticamente o espaço de replicação necessário.

    1. Elimine a subscrição pglogical na réplica de destino através do seguinte comando:

        select pglogical.drop_subscription(subscription_name name);
      

      Substitua name pelo nome da subscrição existente. Por exemplo:

      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. Atualizar as estatísticas da base de dados.

    Após a conclusão da atualização, execute ANALYZE no cluster principal para atualizar as estatísticas do sistema. As estatísticas precisas garantem que o planeador de consultas do PostgreSQL processa as consultas de forma otimizada. A falta de estatísticas pode resultar em planos de consultas imprecisos, o que pode degradar o desempenho e ocupar memória excessiva.

  3. Execute testes de aceitação para garantir que o sistema atualizado funciona como esperado.

  4. Verifique se a versão principal atualizada da base de dados no local aparece na página Vista geral do cluster na Google Cloud consola.

Restaure a versão principal anterior

Se o sistema de base de dados atualizado não tiver o desempenho esperado, pode ter de reverter para o estado anterior à atualização. Pode fazê-lo restaurando a partir de uma cópia de segurança anterior à atualização, quer seja a que o AlloyDB cria automaticamente durante o processo de atualização ou uma cópia de segurança anterior à atualização existente, para criar um novo cluster com o estado anterior à atualização.

Para restaurar um estado anterior à atualização, siga estes passos:

  1. Identifique uma cópia de segurança pré-atualização a partir da qual restaurar. Durante o processo de atualização, o AlloyDB cria automaticamente uma cópia de segurança pré-atualização com o prefixo pre-upgrade-bkp. Para mais informações, consulte o artigo Veja uma lista de cópias de segurança.

  2. Inicie um restauro a partir da cópia de segurança anterior à atualização, que cria um novo cluster com a versão anterior do PostgreSQL. Para mais informações, consulte o artigo Restaure um cluster a partir de uma cópia de segurança armazenada.

  3. Associe a sua aplicação. Atualize a sua aplicação com detalhes sobre o cluster restaurado e as respetivas réplicas de leitura. Pode retomar a publicação de tráfego no cluster restaurado.

Também pode fazer uma recuperação pontual para um momento anterior à atualização. Para mais informações, consulte o artigo Use a recuperação num ponto específico no tempo (PITR).

Limitações

As seguintes limitações afetam as atualizações da versão principal no local para o AlloyDB:

  • Não pode fazer uma atualização da versão principal no local num cluster secundário.
  • A atualização de instâncias com mais de 1000 bases de dados de uma versão para outra pode demorar muito tempo e o processo pode exceder o limite de tempo.
  • O AlloyDB não suporta a atualização de clusters que usam o pg_largeobject_metadata. Se select count(*) from pg_largeobject_metadata; for diferente de zero, a atualização falha.
  • A operação de atualização da versão principal no local pode ser concluída antes da cópia de segurança pré-atualização ou antes da conclusão das cópias de segurança pós-atualização, especialmente quando tem uma base de dados grande com menos objetos de esquema.
  • Pode haver um pequeno atraso entre o momento em que as gravações são retomadas na instância atualizada e o momento em que a cópia de segurança pós-atualização é criada. Isto significa que o conteúdo da cópia de segurança após a atualização pode não corresponder ao conteúdo da base de dados antes da atualização da versão principal.
  • As cópias de segurança pré-atualização podem continuar a ser criadas quando uma atualização da versão principal no local falha.
  • Uma vez que as cópias de segurança da atualização automática são contínuas, não pode eliminá-las até atingirem a retenção máxima das cópias de segurança e recuperação contínuas. Quando a retenção máxima é atingida, as cópias de segurança são recolhidas como lixo; em alternativa, pode usar a CLI gcloud para eliminar manualmente as cópias de segurança. Para mais informações, consulte o artigo Restrições à eliminação de cópias de segurança.

O que se segue?