Problemas conhecidos

MySQL   |  PostgreSQL   |  SQL Server

Nesta página, você verá uma lista problemas conhecidos do Cloud SQL para PostgreSQL, além de maneiras de evitar ou remediar esses problemas.

Se você estiver tendo problemas com sua instância, verifique as informações em Como diagnosticar problemas.

Problemas de conexão da instância

• Certificados SSL/TLS expirados

  Se a instância estiver configurada para usar SSL, acesse a página Instâncias do Cloud SQL no Google Cloud console e abra a instância. Abra a página Conexões, selecione a guia Segurança e verifique se o certificado do servidor é válido. Se ele tiver expirado, você precisará adicionar um novo e fazer a rotação dos certificados.

• Versão do proxy do Cloud SQL Auth

  Se estiver se conectando usando o proxy do Cloud SQL Auth, verifique se está usando a versão mais recente. Para mais informações, consulte Como manter o proxy do Cloud SQL Auth atualizado.

• Conexão não autorizada

  Se você tentar se conectar a uma instância que não existe no projeto, a mensagem de erro informará apenas que você não está autorizado a acessar essa instância.

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

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

• O seguinte funciona apenas com o usuário padrão ('postgres'): gcloud sql connect --user

  Se você tentar se conectar usando esse comando com qualquer outro usuário, a mensagem de erro será FATAL: database 'user' does not exist. A solução alternativa é se conectar usando o usuário padrão ('postgres') e, em seguida, usar o comando "\c" psql para se reconectar como o usuário diferente.

• As conexões do PostgreSQL travam quando a autenticação do proxy db do IAM está ativada.

  Quando o proxy de autenticação do Cloud SQL é iniciado com soquetes TCP e com a flag -enable_iam_login, um cliente PostgreSQL trava durante a conexão TCP. Uma solução é usar sslmode=disable na string de conexão do PostgreSQL. Exemplo:

  psql "host=127.0.0.1 dbname=postgres user=[e-mail] sslmode=disable"

  Outra solução é iniciar o proxy de autenticação do Cloud SQL com soquetes Unix. Isso desativa a criptografia SSL do PostgreSQL e permite que o proxy de autenticação do Cloud SQL faça essa criptografia.

Problemas administrativos

• Apenas uma operação de importação ou exportação do Cloud SQL de longa duração pode ser executada por vez em uma instância. Ao iniciar uma operação, verifique se não é necessário executar outras operações na instância. Além disso, ao iniciar uma operação, é possível cancelá-la.

  O PostgreSQL importa dados em uma única transação. Portanto, se você cancelar a operação de importação, o Cloud SQL não manterá os dados da importação.

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

• Se a instância do Cloud SQL usar o PostgreSQL 17, mas os bancos de dados usarem o PostgreSQL 16 e versões anteriores, não será possível usar o Cloud SQL para importar esses bancos de dados para a instância. Para fazer isso, use o Database Migration Service.

• Se você usar o Database Migration Service para importar um banco de dados do PostgreSQL 17 para o Cloud SQL, ele será importado como um banco de dados do PostgreSQL 16.

• Para as versões 15 e posteriores do PostgreSQL, se o banco de dados de destino for criado a partir de template0, a importação de dados poderá falhar e você poderá ver uma mensagem de erro permission denied for schema public. Para resolver esse problema, forneça privilégios de esquema públicos ao usuário cloudsqlsuperuser executando o comando SQL GRANT ALL ON SCHEMA public TO cloudsqlsuperuser.

• Exportar vários objetos grandes faz com que a instância pare de responder

  Se o banco de dados tiver vários objetos grandes (blobs), sua exportação poderá consumir tanta memória que a instância não responderá. Isso pode acontecer mesmo se os blobs estiverem vazios.

• O Cloud SQL não é compatível com espaços de tabela personalizados, mas é compatível com a migração de dados de espaços de tabela personalizados para o padrão, pg_default, na instância de destino. Por exemplo, se você tem um espaço de tabela chamado dbspace está localizado em /home/data, após a migração todos os dados de dbspace são migrados para o pg_default. Mas o Cloud SQL não vai criar um espaço de tabela chamado "dbspace" no disco.

• Se você estiver tentando importar e exportar dados de um banco de dados grande (por exemplo, um banco de dados que tenha 500 GB de dados ou mais), as operações de importação e exportação poderão levar muito tempo para serem concluídas. Além disso, outras operações (por exemplo, a de backup) não estarão disponíveis para serem realizadas enquanto ocorre a importação ou exportação. Uma opção possível para melhorar o desempenho do processo de importação e exportação é restaurar um backup anterior usando gcloud ou a API.

• O Cloud Storage é compatível com um tamanho máximo de objeto único de até cinco tebibytes (5 TiB). Como o Cloud SQL compacta os dados antes de fazer o upload para o Cloud Storage, uma operação de exportação falha somente se o tamanho compactado de um arquivo de exportação exceder 5 TiB.

  A taxa de compactação depende dos tipos de dados no banco de dados. Por exemplo, o texto é compactado melhor do que dados binários, como BLOBs. Portanto, um banco de dados ou tabela com tamanho maior que 5 TiB pode não causar falha na exportação se os dados forem altamente compactáveis, enquanto dados não compactados que se aproximam de 5 TiB podem falhar.

  Se você realizar uma operação de exportação padrão, o Cloud SQL normalmente criará um único arquivo de exportação. Se você usar a exportação paralela, o Cloud SQL criará vários arquivos de exportação, geralmente um para cada tabela. Com esse tipo de exportação, a operação falha se alguma tabela for grande o suficiente para que o arquivo de exportação compactado exceda 5 TiB.

  Se a exportação falhar devido ao limite de 5 TiB, será necessário dividir a exportação em segmentos menores. Se você estiver usando uma exportação padrão e encontrar esse limite, considere mudar para a exportação paralela.

  Se você já estiver usando a exportação paralela e atingir o limite de 5 TiB, uma das tabelas será muito grande para exportar, mesmo sozinha. Nesse caso, como alternativa, você pode se conectar a partir de uma instância do Compute Engine e usar o utilitário pg_dump para exportar a tabela.

Registros de transações e crescimento do disco

Os registros são limpados uma vez por dia, e não continuamente. Quando o número de dias de retenção de registros é configurado para ser o mesmo que o número de backups, um dia de registro pode ser perdido, dependendo de quando o backup ocorre. Por exemplo, definir a retenção de registros para 7 dias e a retenção de backup para 7 backups significa que entre 6 e 7 dias de registros serão retidos.

Recomendamos que você defina o número de backups para, pelo menos, um dia a mais de dias de retenção de registros. Dessa forma, é possível garantir um mínimo de dias especificados para a retenção de registros.

Observação: as instâncias de réplica apresentam um aumento de armazenamento quando a replicação é suspensa e retomada posteriormente. O aumento é causado quando a instância primária envia a réplica dos registros de transações para o período de tempo em que a replicação foi suspensa. Os registros de transações atualizam a réplica para o estado atual da instância principal.

Problemas relacionados ao Cloud Monitoring ou ao Cloud Logging

As instâncias com os seguintes nomes de região são exibidas incorretamente em determinados contextos, da seguinte maneira:

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

Esse problema ocorre nos seguintes contextos:

• Alertas no Cloud Monitoring
• Metrics Explorer
• Cloud Logging

Reduza o problema dos alertas no Cloud Monitoring e no Metrics Explorer usando os rótulos de metadados de recursos. Use o rótulo de metadados do sistema region em vez do cloudsql_database rótulo de recurso monitorado region.

Problema relacionado à exclusão de um banco de dados do PostgreSQL

Ao excluir um banco de dados criado no Google Cloud console usando o psql cliente, você pode encontrar o seguinte erro:

ERROR: must be owner of database [DATABASE_NAME]

Esse é um erro de permissão, já que o proprietário de um banco de dados criado usando um cliente psql não tem atributos superuser do Cloud SQL. Os bancos de dados criados usando o Google Cloud console são de propriedade de cloudsqlsuperuser e os bancos de dados criados usando um psql cliente são de propriedade de usuários conectados a esse banco de dados. Como o Cloud SQL é um serviço gerenciado, os clientes não podem criar ou ter acesso a usuários com atributos superuser. Para mais informações, consulte Restrições e privilégios do superusuário.

Devido a essa limitação, os bancos de dados criados usando o Google Cloud console só podem ser excluídos usando o Google Cloud console, e os bancos de dados criados usando um psql cliente só podem ser excluídos conectando-se como o proprietário do banco de dados.

Para encontrar o proprietário de um banco 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:

• DATABASE_NAME: o nome do banco de dados para o qual você quer encontrar informações do proprietário.

Se o proprietário do banco de dados for cloudsqlsuperuser, use Google Cloud o console para excluir o banco de dados. Se o proprietário do banco de dados for um usuário do banco de dados do cliente psql, conecte-se como o proprietário do banco de dados e execute o comando DROP DATABASE.