Solucionar problemas

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Execute o comando gcloud sql operations list para listar todas as operações da instância do Cloud SQL fornecida.

Consulte os logs e filtre por texto para encontrar o usuário. Pode ser necessário usar logs de auditoria para obter informações privadas. Os arquivos de log relevantes incluem:

• cloudsql.googleapis.com/postgres.log
• Se os Logs de Auditoria do Cloud estiverem ativados e você tiver as permissões necessárias para visualizá-los, cloudaudit.googleapis.com/activity também poderá estar disponível.

Se você excluir uma instância sem fazer um backup final dos dados, não será possível recuperá-los. No entanto, se você restaurar a instância, o Cloud SQL também restaurará os backups. Para obter mais informações sobre como recuperar uma instância excluída, consulte Backups de recuperação .

Se você tiver realizado uma operação de exportação, crie uma nova instância e, em seguida, execute uma operação de importação para recriar o banco de dados. As exportações são gravadas no Cloud Storage e as importações são lidas de lá.

Se você realmente precisar cancelar a operação, pode pedir ao suporte ao cliente para force restart da instância.

Crie os usuários do banco de dados antes de restaurar o dump SQL.

Para manter os backups indefinidamente, você pode criar um backup sob demanda , pois eles não são excluídos da mesma forma que os backups automatizados. Os backups sob demanda permanecem indefinidamente. Ou seja, permanecem até serem excluídos ou até que a instância à qual pertencem seja excluída. Como esse tipo de backup não é excluído automaticamente, ele pode afetar a cobrança.

• Pode haver muitas conexões abertas. O excesso de conexões pode resultar de erros que ocorrem no meio de uma conexão, sem configurações autovacuum para limpar conexões inativas.
• O ciclo pode ocorrer se qualquer código personalizado estiver usando uma lógica de repetição que não para após algumas falhas.
• Pode haver muito tráfego. Use o pool de conexões e outras práticas recomendadas para conectividade .

Coisas para tentar:

1. Verifique se o banco de dados está configurado para autovacuum .
2. Verifique se há alguma lógica de nova tentativa de conexão configurada no código personalizado.
3. Reduza o tráfego até que o banco de dados se recupere e então aumente o tráfego lentamente.

CREATE UNLOGGED TABLE ... .

Estas tabelas não estão incluídas em uma restauração de um backup:

• O conteúdo de tabelas não registradas não sobrevive ao failover em uma instância de HA.
• Tabelas não registradas não sobrevivem a falhas do postgres.
• Tabelas não registradas não são replicadas para réplicas de leitura.
• Tabelas não registradas são apagadas automaticamente durante a restauração do backup.

A solução é evitar o uso de tabelas não registradas se você quiser restaurá-las por meio de um backup. Se estiver restaurando a partir de um banco de dados que já possui tabelas não registradas, você pode despejar o banco de dados em um arquivo e recarregar os dados após modificar o arquivo despejado para ALTER TABLE para SET LOGGED nessas tabelas.

Você está tentando cancelar uma operação de importação ou exportação que foi concluída, falhou ou cancelada. Se a operação estiver em execução, você pode cancelá-la.

O Cloud SQL não oferece suporte ao cancelamento da operação porque ela tem um tipo de operação diferente de IMPORT ou EXPORT .

O Cloud SQL não pode cancelar a operação de importação ou exportação neste momento. Tente novamente em alguns segundos. Se o problema persistir, entre em contato com Google Cloud Apoiar .

Remova todas as entradas de Authorized Networks da instância do Cloud SQL, se possível. Caso contrário, crie uma réplica sem nenhuma entrada Authorized Networks .

Você está tentando usar o Google Cloud console para clonar uma instância com um endereço IP privado, mas você não especificou o intervalo de IPs alocado que deseja usar e a instância de origem não foi criada com o intervalo especificado. Como resultado, a instância clonada é criada em um intervalo aleatório.

Use gcloud para clonar a instância e fornecer um valor para
Parâmetro --allocated-ip-range-name . Para obter mais informações, consulte Clonando uma instância com um IP privado .

• Instabilidade de rede.
• Nenhuma resposta aos comandos TCP keep-alive (o cliente ou o servidor não está respondendo, possivelmente sobrecarregado)
• O tempo de vida da conexão do mecanismo de banco de dados foi excedido e o servidor encerra a conexão.

Os aplicativos devem tolerar falhas de rede e seguir as melhores práticas, como pool de conexões e novas tentativas. A maioria dos poolers de conexões detecta esses erros sempre que possível. Caso contrário, o aplicativo deve tentar novamente ou falhar normalmente.

Para nova tentativa de conexão, recomendamos os seguintes métodos:

1. Backoff exponencial . Aumenta o intervalo de tempo entre cada nova tentativa, exponencialmente.
2. Adicione também o recuo aleatório.

A combinação desses métodos ajuda a reduzir a limitação.

Os certificados do cliente expiraram ou o caminho para os certificados não está correto.

Regenere os certificados recriando-os .

Conecte-se com o usuário padrão e depois altere os usuários.

O endereço do host não corresponde ao endereço nos nomes alternativos do certificado do servidor.

Se você estiver usando Node.js com verify-full ou equivalente, use o nome DNS para o parâmetro servername . O nome DNS pode ser encontrado no certificado do servidor usando openssl . Por exemplo, openssl x509 -in server-cert.pem -noout -text |grep 'DNS:' .

 ssl: {
  rejectUnauthorized: true,
  ca: fs.readFileSync("/path/to/server/CA"),
  servername: 'N-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx.us-central1.sql.goog'
}

• O tamanho do intervalo IP alocado para a conexão de serviço privado é menor que /24.
• O tamanho do intervalo de IP alocado para a conexão de serviço privado é muito pequeno para o número de instâncias do Cloud SQL.
• O requisito sobre o tamanho do intervalo de IPs alocado será maior se as instâncias forem criadas em várias regiões. Consulte o tamanho do intervalo alocado.

Para resolver esse problema, você pode expandir o intervalo de IP alocado existente ou alocar um intervalo de IP adicional para a conexão de serviço privada. Para obter mais informações, consulte Alocar um intervalo de endereços IP .

Se você usou o sinalizador --allocated-ip-range-name ao criar a instância do Cloud SQL, poderá expandir somente o intervalo de IP especificado.

Se você estiver alocando um novo intervalo, tome cuidado para que a alocação não se sobreponha a nenhuma alocação existente.

Após criar um novo intervalo de IP, atualize o peering do VPC com o seguinte comando:

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID \
--force
    

Se estiver expandindo uma alocação existente, tome cuidado para aumentar apenas o intervalo de alocação e não diminuí-lo. Por exemplo, se a alocação original era 10.0.10.0/24, torne a nova alocação pelo menos 10.0.10.0/23.

Em geral, ao começar com uma alocação /24, decrementar a /mask em 1 para cada condição (grupo de tipos de instância adicional, região adicional) é uma boa regra prática. Por exemplo, ao tentar criar ambos os grupos de tipos de instância na mesma alocação, ir de /24 a /23 é suficiente.

Após expandir um intervalo de IP existente, atualize o peering do VPC com o seguinte comando:

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
    

Habilite a API de rede de serviços usando o seguinte comando e tente criar a instância do Cloud SQL novamente.

gcloud services enable servicenetworking.googleapis.com \
--project=PROJECT_ID
    

Verifique se os nomes DNS que você deseja adicionar ao certificado do servidor de uma instância do Cloud SQL atendem aos seguintes critérios:

• Eles não têm caracteres curinga.
• Eles não têm pontos finais.
• Eles atendem às especificações RFC 1034 .

Use exportações CSV para exportar apenas o que você precisa.

Use o descarregamento de exportação . Em um nível mais alto, no descarregamento de exportação, em vez de emitir uma exportação na instância de origem, o Cloud SQL inicia uma instância de descarregamento para executar a exportação. O descarregamento de exportação tem várias vantagens, incluindo maior desempenho na instância de origem e o desbloqueio de operações administrativas enquanto a exportação está em execução. Com o descarregamento de exportação, a latência total pode aumentar de acordo com o tempo necessário para ativar a instância de descarregamento. Geralmente, para exportações de tamanho razoável, a latência não é significativa. No entanto, se a sua exportação for pequena o suficiente, você poderá notar um aumento na latência.

Edite o arquivo de despejo para remover as referências .

Faça uma exportação manual usando a ferramenta pg_dump .

Você pode construir seu próprio sistema de exportação automatizado usando Google Cloudprodutos como Cloud Scheduler, Pub/Sub e funções do Cloud Run, semelhantes a este artigo sobre automação de backups .

Conecte-se ao banco de dados e defina o fuso horário do banco de dados como você desejar, por usuário ou por banco de dados.

No Cloud SQL para PostgreSQL, você pode especificar o seguinte. Estas configurações permanecem após o encerramento de uma sessão, imitando uma configuração .conf :

ALTER DATABASE dbname SET TIMEZONE TO 'timezone';
ALTER USER username SET TIMEZONE TO 'timezone';

Essas configurações se aplicam apenas a novas conexões com o banco de dados. Para ver a alteração no fuso horário, desconecte-se da instância e reconecte-se a ela.

Edite a instância para atualizar para um tamanho de máquina maior e obter mais CPUs e memória.

Feche as operações não utilizadas. Verifique o uso de CPU e memória da sua instância do Cloud SQL para garantir que haja recursos suficientes disponíveis. A melhor maneira de garantir o máximo de recursos para a importação é reiniciar a instância antes de iniciar a operação.

Um reinício:

• Fecha todas as conexões.
• Encerra quaisquer tarefas que possam estar consumindo recursos.

Crie os usuários do banco de dados antes de importar.

Pode haver um uso inesperado do disco após a importação de dados. Esse uso pode ser devido ao uso da recuperação pontual .

Para resolver isso, após importar os dados, desative a recuperação pontual se desejar excluir logs e recuperar o armazenamento. Lembre-se de que diminuir o armazenamento usado não reduz o tamanho do armazenamento provisionado para a instância.

Essa mensagem de erro aparece se você tentar importar um arquivo de despejo SQL carregado no Cloud Storage para um banco de dados Cloud SQL e o trabalho de importação tiver sido executado por cerca de quatro dias.

ROLE_NAME é uma função de banco de dados personalizada definida no banco de dados PostgreSQL de origem. O usuário padrão cloudsqlsuperuser importa o arquivo de despejo SQL. No entanto, esse usuário pode não pertencer à função ROLE_NAME .

Para resolver esse problema, siga estas etapas:

1. Crie a função ROLE_NAME no banco de dados de destino para onde você está importando o arquivo de despejo SQL.

2. Não use o usuário cloudsqlsuperuser para importar o arquivo. Em vez disso, no banco de dados de destino, especifique um usuário que seja membro da função ROLE_NAME . Para especificar o usuário, execute o seguinte comando:

   gcloud sql import sql INSTANCE URI [--async]
[--database=DATABASE, -d DATABASE] [--user=USER] [GCLOUD_WIDE_FLAG …]

O sinalizador log_statement pode ser definido como none e o sinalizador logging_collector pode ser definido como off. Se o registro ainda estiver em andamento, pode haver outros sinalizadores relacionados ao registro que podem ser ajustados. Você pode editar a instância para modificar esses sinalizadores.

Por exemplo, um usuário foi excluído, mas você não consegue descobrir quem fez isso. Os logs mostram que a operação foi iniciada, mas não fornecem mais informações. Você deve habilitar o registro de auditoria para que informações detalhadas e de identificação pessoal (PII) como essas sejam registradas.

Para baixar os logs como JSON:

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json
    

Para baixar os logs como TEXTO:

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt
   

1. Em um terminal, conecte-se ao seu banco de dados:

   gcloud sql connect INSTANCE_NAME
         

2. Execute este comando para criar a extensão:

   CREATE EXTENSION pgaudit;
         

3. Saia do banco de dados e, em um terminal, execute o seguinte comando:

   gcloud sql instances patch INSTANCE_NAME \
   --database-flags=cloudsql.enable_pgaudit=on,pgaudit.log=all
        

SELECT datname, usename, application_name as appname, client_addr, state, now() - backend_start as conn_age, now() - xact_start as xact_age, now() - query_start as query_age, now() - state_change as last_activity_age, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY 8 DESC LIMIT 20;

SELECT name, setting, unit FROM pg_settings WHERE name = ' FIELD_NAME ' .

SHOW SETTING_NAME ;

Execute SHOW ALL; para ver todas as configurações.

Execute os seguintes comandos:

1.       GRANT pg_signal_backend TO USERNAME;
         

2. Encontre o ID do processo bloqueado ou travado:

         SELECT pid, usename, state, query FROM pg_stat_activity;
         

3. Pare um processo em execução ou ocioso usando estes comandos:

         SELECT pg_cancel_backend(pid)
               FROM pg_stat_activity
               WHERE usename = 'USERNAME';
         
         

         SELECT pg_terminate_backend(pid)
               FROM pg_stat_activity
               WHERE usename = 'USERNAME';
         
         

O trabalho de autovacuum pode estar bloqueado ou pode não estar recuperando os IDs de transação rápido o suficiente para acompanhar a carga de trabalho.

Para evitar interrupções devido a problemas de wraparound de transação, você pode revisar estas dicas de autoatendimento para lidar com o wraparound de TXID.

Para obter conselhos gerais sobre ajuste, consulte Otimizando, monitorando e solucionando problemas de operações de vácuo no PostgreSQL .

Reiniciar exclui os arquivos temporários, mas não reduz o espaço de armazenamento. Somente o suporte ao cliente pode redefinir o tamanho da instância.

Verifique os logs no momento da exclusão e veja se há um script malicioso em execução em um painel ou outro processo automatizado.

Algumas explicações possíveis incluem:

• Outra operação está em andamento. As operações do Cloud SQL não são executadas simultaneamente. Aguarde a conclusão da outra operação.
• O aviso INSTANCE_RISKY_FLAG_CONFIG é acionado sempre que pelo menos um sinalizador beta estiver sendo usado. Remova as configurações do sinalizador de risco e reinicie a instância.

Infelizmente, você não pode reduzir o arquivo ibtmp1 por nenhum método além de reiniciar o serviço.

Uma opção de mitigação é criar a tabela temporária com ROW_FORMAT=COMPRESSED , para que ela seja armazenada em tablespaces de arquivo por tabela no diretório de arquivos temporários. No entanto, a desvantagem são os custos de desempenho associados à criação e remoção de um tablespace de arquivo por tabela para cada tabela temporária.

Se a sua instância ficar sem espaço de armazenamento e o recurso de aumento automático de armazenamento não estiver habilitado, ela ficará offline. Para evitar esse problema, você pode editar a instância para habilitar o aumento automático de armazenamento.

Ao manter conexões que duram menos de 60 segundos, a maioria dos desligamentos impróprios pode ser evitada, incluindo conexões a partir do prompt de comando do banco de dados. Se você mantiver essas conexões abertas por horas ou dias, os desligamentos podem ser impróprios.

Descubra quais objetos dependem do usuário e, em seguida, descarte ou reatribua esses objetos a um usuário diferente.

Consulte especialmente dicas gerais de desempenho .

Para inserções, atualizações ou exclusões lentas do banco de dados, considere as seguintes ações:

• Verifique a localização do gravador e do banco de dados; enviar dados a longas distâncias gera latência.
• Verifique a localização do leitor e do banco de dados; a latência afeta o desempenho de leitura ainda mais do que o desempenho de gravação

Para reduzir a latência, a recomendação é localizar os recursos de origem e destino na mesma região.

Além da carga de trabalho, há outros fatores que podem impactar o uso de memória, como o número de conexões ativas e processos internos de sobrecarga. Esses fatores nem sempre são refletidos nos gráficos de monitoramento.

Certifique-se de que a instância tenha sobrecarga suficiente para dar conta da sua carga de trabalho, além de alguma sobrecarga adicional.

Para preservar seus dados, exporte-os para o Cloud Storage antes de excluir uma instância .

A função de administrador do Cloud SQL inclui a permissão para excluir a instância. Para evitar exclusões acidentais, conceda essa função somente quando necessário.

Há outras maneiras de atingir o objetivo criando uma nova instância.

• Você pode clonar a instância que deseja renomear e definir um novo nome para a instância clonada. Isso permite criar a nova instância sem precisar importar dados manualmente. Assim como ao criar uma nova instância, a instância clonada terá um novo endereço IP.
• Você pode exportar dados da sua instância para um bucket do Cloud Storage, criar uma nova instância com o novo nome desejado e, em seguida, importar os dados para a nova instância.

Em ambos os casos, você pode excluir sua instância antiga após a conclusão da operação. Recomendamos a clonagem, pois ela não afeta o desempenho e não exige que você refaça nenhuma configuração da instância, como sinalizadores, tipo de máquina, tamanho do armazenamento e memória.

1. Verifique o status do ponto de extremidade.

   gcloud

   Para verificar o status, use o
   gcloud compute forwarding-rules describe .

   gcloud compute forwarding-rules describe ENDPOINT_NAME \
   --project=PROJECT_ID \
   --region=REGION_NAME \
   | grep pscConnectionStatus

   Faça as seguintes substituições:

   • ENDPOINT_NAME : o nome do ponto final
   • PROJECT_ID : o ID ou número do projeto do Google Cloud projeto que contém o ponto final
   • REGION_NAME : o nome da região para o ponto de extremidade

   DESCANSAR

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

   • PROJECT_ID : o ID ou número do projeto do Google Cloud projeto que contém o ponto de extremidade do Private Service Connect
   • REGION_NAME : o nome da região
   • ENDPOINT_NAME : o nome do ponto final

   Método HTTP e URL:

   GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME

   Para enviar sua solicitação, expanda uma destas opções:

   curl (Linux, macOS ou Cloud Shell)

   Execute o seguinte comando:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME"

   PowerShell (Windows)

   Execute o seguinte comando:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME" | Select-Object -Expand Content

   Você deve receber uma resposta JSON semelhante à seguinte:

   {
     "kind": "compute#forwardingRule",
     "id": "ENDPOINT_ID",
     "creationTimestamp": "2024-05-09T12:03:21.383-07:00",
     "name": "ENDPOINT_NAME",
     "region": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME",
     "IPAddress": "IP_ADDRESS",
     "target": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/serviceAttachments/SERVICE_ATTACHMENT_NAME",
     "selfLink": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME",
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
     "serviceDirectoryRegistrations": [
       {
         "namespace": "goog-psc-default"
       }
     ],
     "networkTier": "PREMIUM",
     "labelFingerprint": "LABEL_FINGERPRINT_ID",
     "fingerprint": "FINGERPRINT_ID",
     "pscConnectionId": "CONNECTION_ID",
     "pscConnectionStatus": "ACCEPTED",
     "allowPscGlobalAccess": true
   }
   

2. Verifique se o status do endpoint é ACCEPTED . Se o status for PENDING , a instância não está permitindo o Google Cloud Projeto que contém o endpoint. Certifique-se de que o projeto de rede no qual o endpoint foi criado seja permitido. Para obter mais informações, consulte Editar uma instância com o Private Service Connect habilitado .

Primeiro, verifique se o valor do sinalizador max_connections é maior ou igual ao valor no primário.

Se o sinalizador max_connections estiver definido corretamente, inspecione os logs no Cloud Logging para encontrar o erro real.

Se o erro for: set Service Networking service account as servicenetworking.serviceAgent role on consumer project , desative e reative a Service Networking API . Esta ação cria a conta de serviço necessária para continuar o processo.

Reinicie a instância de réplica para recuperar o espaço de memória temporário.

Edite a instância para habilitar automatic storage increase .

• Consultas lentas na réplica. Encontre e corrija-as.
• Todas as tabelas devem ter uma chave única/primária. Cada atualização em uma tabela sem uma chave única/primária causa varreduras completas na réplica.
• Consultas como DELETE ... WHERE field < 50000000 causam atraso na replicação com replicação baseada em linha, pois um grande número de atualizações são acumuladas na réplica.

Algumas soluções possíveis incluem:

• Edite a instância para aumentar o tamanho da réplica.
• Reduza a carga no banco de dados.
• Enviar tráfego de leitura para a réplica de leitura.
• Indexe as tabelas.
• Identifique e corrija consultas de gravação lenta.
• Recrie a réplica.

Se você precisar usar índices de hash, atualize para o PostgreSQL 10+. Caso contrário, se também quiser usar réplicas, não use índices de hash no PostgreSQL 9.6.

Recrie a réplica após interromper todas as consultas em execução.

Para resolver esse problema, siga estas etapas:

1. Ative o sinalizador log_duration e defina o parâmetro log_statement como ddl . Isso fornece as consultas e o tempo de execução no banco de dados. No entanto, dependendo da sua carga de trabalho, isso pode causar problemas de desempenho.
2. Tanto na instância primária quanto na réplica de leitura, execute explain analyze para as consultas.
3. Compare o plano de consulta e verifique se há diferenças.

Se for uma consulta específica, modifique-a. Por exemplo, você pode alterar a ordem das junções para ver se obtém melhor desempenho.