Problemas conhecidos

Esta página apresenta uma lista de problemas conhecidos com o Cloud SQL para PostgreSQL, juntamente com formas de os evitar ou recuperar.

Se estiver a ter problemas com a sua instância, certifique-se de que também revê as informações em Diagnosticar problemas.

Problemas de ligação à instância

  • Certificados SSL/TLS expirados

    Se a sua instância estiver configurada para usar SSL, aceda à página Instâncias do Cloud SQL na Google Cloud consola e abra a instância. Abra a página Ligações, selecione o separador Segurança e certifique-se de que o certificado do servidor é válido. Se tiver expirado, tem de adicionar um novo certificado e alternar para o mesmo.

  • Versão do proxy Auth do Cloud SQL

    Se estiver a estabelecer ligação através do proxy Auth do Cloud SQL, certifique-se de que está a usar a versão mais recente. Para mais informações, consulte o artigo Manter o proxy Auth do Cloud SQL atualizado.

  • Não tem autorização para estabelecer ligação

    Se tentar estabelecer ligação a uma instância que não existe nesse projeto, a mensagem de erro indica apenas que não tem autorização para aceder a essa instância.

  • Não é possível criar uma instância do Cloud SQL

    Se vir a mensagem de erro Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID], tente criar novamente a instância do Cloud SQL.

  • O seguinte só funciona com o utilizador predefinido ("postgres"): gcloud sql connect --user

    Se tentar estabelecer ligação através deste comando com qualquer outro utilizador, a mensagem de erro indica FATAL: database 'user' does not exist. A solução alternativa é estabelecer ligação através do utilizador predefinido ("postgres") e, em seguida, usar o comando "\c" psql para restabelecer a ligação como o utilizador diferente.

  • As ligações PostgreSQL ficam bloqueadas quando a autenticação do proxy de base de dados da IAM está ativada.

    Quando o proxy Auth do Cloud SQL é iniciado com sockets TCP e com a flag -enable_iam_login, o cliente PostgreSQL fica bloqueado durante a ligação TCP. Uma solução alternativa é usar sslmode=disable na string de ligação do PostgreSQL. Por exemplo:

    psql "host=127.0.0.1 dbname=postgres user=me@google.com sslmode=disable"

    Outra solução alternativa é iniciar o proxy Auth do Cloud SQL através de sockets Unix. Isto desativa a encriptação SSL do PostgreSQL e permite que o proxy Auth do Cloud SQL faça a encriptação SSL.

Problemas administrativos

  • Só pode executar uma operação de importação ou exportação do Cloud SQL de longa duração de cada vez numa instância. Quando iniciar uma operação, certifique-se de que não precisa de realizar outras operações na instância. Além disso, quando inicia a operação, pode cancelá-la.

    O PostgreSQL importa dados numa única transação. Por conseguinte, se cancelar a operação de importação, o Cloud SQL não mantém os dados da importação.

Problemas com a importação e exportação de dados

  • Se a sua instância do Cloud SQL usar o PostgreSQL 17, mas as suas bases de dados usarem o PostgreSQL 16 e versões anteriores, não pode usar o Cloud SQL para importar estas bases de dados para a sua instância. Para o fazer, use o Database Migration Service.

  • Se usar o serviço de migração de bases de dados para importar uma base de dados PostgreSQL 17 para o Cloud SQL, esta é importada como uma base de dados PostgreSQL 16.

  • Para as versões 15 e posteriores do PostgreSQL, se a base de dados de destino for criada a partir do template0, a importação de dados pode falhar e pode ser apresentada uma mensagem de erro permission denied for schema public. Para resolver este problema, conceda privilégios de esquema público ao utilizador cloudsqlsuperuser executando o comando SQL GRANT ALL ON SCHEMA public TO cloudsqlsuperuser.

  • A exportação de muitos objetos grandes faz com que a instância deixe de responder

    Se a sua base de dados contiver muitos objetos grandes (blobs), a exportação da base de dados pode consumir tanta memória que a instância deixa de responder. Isto pode acontecer mesmo que os blobs estejam vazios.

  • O Cloud SQL não suporta tablespaces personalizados, mas suporta a migração de dados de tablespaces personalizados para o tablespace predefinido, pg_default, na instância de destino. Por exemplo, se tiver um tablespace denominado dbspace localizado em /home/data, após a migração, todos os dados em dbspace são migrados para o pg_default. No entanto, o Cloud SQL não cria um tablespace denominado "dbspace" no respetivo disco.

  • Se estiver a tentar importar e exportar dados de uma base de dados grande (por exemplo, uma base de dados com 500 GB de dados ou mais), as operações de importação e exportação podem demorar muito tempo a serem concluídas. Além disso, não pode realizar outras operações (por exemplo, a operação de cópia de segurança) enquanto a importação ou a exportação estiver em curso. Uma potencial opção para melhorar o desempenho do processo de importação e exportação é restaurar uma cópia de segurança anterior através da gcloud ou da API.

  • O Cloud Storage suporta um tamanho máximo de objeto único de cinco terabytes. Se tiver bases de dados com mais de 5 TB, a operação de exportação para o Cloud Storage falha. Neste caso, tem de dividir os ficheiros de exportação em segmentos mais pequenos.

Registos de transações e crescimento do disco

Os registos são eliminados uma vez por dia e não de forma contínua. Quando o número de dias de retenção de registos está configurado para ser igual ao número de cópias de segurança, pode perder um dia de registo, consoante a altura em que a cópia de segurança ocorre. Por exemplo, se definir a retenção de registos para sete dias e a retenção de cópias de segurança para sete cópias de segurança, significa que são retidos entre seis e sete dias de registos.

Recomendamos que defina o número de cópias de segurança para, pelo menos, mais um do que os dias de retenção de registos para garantir um mínimo de dias especificados de retenção de registos.

Problemas relacionados com o Cloud Monitoring ou o Cloud Logging

As instâncias com os seguintes nomes de regiões são apresentadas incorretamente em determinados contextos, da seguinte forma:

  • us-central1 é apresentado como us-central
  • europe-west1 é apresentado como europe
  • asia-east1 é apresentado como asia

Este problema ocorre nos seguintes contextos:

  • Alertas no Cloud Monitoring
  • Metrics Explorer
  • Cloud Logging

Pode mitigar o problema para os alertas no Cloud Monitoring e para o explorador de métricas através de etiquetas de metadados de recursos. Use a etiqueta de metadados do sistema region em vez da etiqueta de recurso monitorizado cloudsql_database region.

Quando elimina uma base de dados criada na Google Cloud consola através do seu clientepsql, pode ocorrer o seguinte erro:

ERROR: must be owner of database [DATABASE_NAME]

Este é um erro de autorização, uma vez que o proprietário de uma base de dados criada através de um cliente psql não tem atributos do Cloud SQL superuser. As bases de dados criadas através da Google Cloud consola são propriedade de cloudsqlsuperuser e as bases de dados criadas através de um cliente psql são propriedade dos utilizadores ligados a essa base de dados. Uma vez que o Cloud SQL é um serviço gerido, os clientes não podem criar nem têm acesso a utilizadores com atributos superuser. Para mais informações, consulte o artigo Restrições e privilégios de superutilizador.

Devido a esta limitação, as bases de dados criadas através da Google Cloud consola só podem ser eliminadas através da Google Cloud consola, e as bases de dados criadas através de um clientepsql só podem ser eliminadas estabelecendo ligação como proprietário da base de dados.

Para encontrar o proprietário de uma base de dados, use o seguinte comando:

SELECT d.datname as Name,
pg_catalog.pg_get_userbyid(d.datdba) as Owner
FROM pg_catalog.pg_database d
WHERE d.datname = 'DATABASE_NAME';

Substitua o seguinte:

  • DATABASE_NAME: o nome da base de dados para a qual quer encontrar informações do proprietário.

Se o proprietário da sua base de dados for cloudsqlsuperuser, use a consola do Google Cloud Google Cloud para eliminar a base de dados. Se o proprietário da base de dados for um psqlutilizador da base de dados de clientes, estabeleça ligação como proprietário da base de dados e execute o comando DROP DATABASE.