Resolver problemas

Verifique se a pergunta ou o problema já foi resolvido em uma destas páginas:

Os tópicos desta página incluem:

Backup e recuperação

Problema Solução de problemas
Não é possível ver o status da operação atual. O Console do Google Cloud informa apenas o sucesso ou falha no momento da operação. Ele não foi criado para mostrar avisos ou outras atualizações.

Execute o comando gcloud sql operations list para listar todas as operações da instância do Cloud SQL especificada.
Você quer descobrir quem emitiu uma operação de backup sob demanda. A interface do usuário não mostra o usuário que iniciou uma operação.

Procure nos registros e filtre por texto para encontrar o usuário. Talvez seja necessário usar registros de auditoria para informações particulares. Os arquivos de registro relevantes incluem:

  • cloudsql.googleapis.com/postgres.log
  • Se os registros 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.
Depois que uma instância é excluída, não é possível fazer backup dela.

Depois que uma instância é limpa, não é possível recuperar dados. No entanto, se a instância for restaurada, os backups também serão restaurados. Para mais informações sobre como recuperar uma instância excluída, consulte Backups de recuperação.

Se você tiver feito uma operação de exportação, crie uma nova instância e faça 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á.
O backup automático fica paralisado por muitas horas e não pode ser cancelado. Os backups podem levar muito tempo, dependendo do tamanho do banco de dados.

Se você realmente precisa cancelar a operação, peça ao suporte ao cliente para aplicar force restart à instância.
Uma operação de restauração pode falhar quando um ou mais usuários referenciados no arquivo dump SQL não existem. Antes de restaurar um arquivo dump SQL, todos os usuários do banco de dados com objetos ou que receberam permissões para os objetos do banco de dados despejado precisam existir no banco de dados de destino. Caso contrário, a operação de restauração não recriará os objetos com a propriedade ou as permissões originais.

Crie os usuários do banco de dados antes de restaurar do dump SQL.
Você quer aumentar o número de dias em que pode manter backups automáticos, de sete para 30 dias ou mais. É possível configurar o número de backups automatizados que serão retidos, de 1 a 365. Os backups automatizados são removidos regularmente com base no valor de retenção configurado. Infelizmente, isso significa que os backups visíveis atuais são os únicos backups automatizados que podem ser usados para restaurar.

Para manter os backups indefinidamente, crie um backup sob demanda. Ele não é excluído da mesma forma que backups automáticos. Os backups sob demanda permanecem indefinidamente. Ou seja, eles permanecem até que sejam excluídos ou a instância a que pertencem seja excluída. Como esse tipo de backup não é excluído automaticamente, ele pode afetar o faturamento.
Um backup automático falhou e você não recebeu uma notificação por e-mail. Para que o Cloud SQL notifique você sobre o status do backup, configure um alerta com base em registros.
Uma instância está falhando repetidamente porque está alternando entre os estados de falha e de restauração de backup. As tentativas de conexão e uso do banco de dados após a restauração falham.
  • Pode haver muitas conexões abertas. Conexões em excesso podem resultar de erros que ocorrem no meio de uma conexão em que não há configurações autovacuum para limpar conexões inativas.
  • A alternância pode ocorrer se qualquer código personalizado estiver usando uma lógica de repetição que não pare após algumas falhas.
  • Pode haver muito tráfego. Use o pool de conexões e outras práticas recomendadas para conectividade.

O que tentar

  1. Verifique se o banco de dados está configurado para autovacuum.
  2. Verifique se há alguma lógica de repetição de conexão configurada no código personalizado.
  3. Reduza o tráfego até que o banco de dados seja recuperado e aumente lentamente o tráfego.
Você descobre que está faltando dados ao executar uma operação de backup/restauração. As tabelas foram criadas como não registradas. Exemplo:

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 na instância de alta disponibilidade.
  • Tabelas não registradas não sobrevivem a falhas postgres.
  • As tabelas não registradas não são replicadas para réplicas de leitura.
  • As tabelas não registradas são automaticamente excluídas durante a restauração do backup.

A solução é evitar o uso de tabelas não registradas se você quiser restaurar essas tabelas com um backup. Ao restaurar um banco de dados que já tem tabelas não registradas, é possível despejar o banco de dados em um arquivo e recarregar os dados depois de modificar o arquivo despejado para ALTER TABLE para SET LOGGED nessas tabelas.

Cancelar a importação e a exportação

Problema Solução de problemas
Mensagem de erro: You can't cancel operation [operation-ID] because this operation isn't in progress.

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, será possível cancelá-la.
Mensagem de erro: You can't cancel operation [operation-ID] because Cloud SQL doesn't support the cancellation of an [operation-type] operation.

O Cloud SQL não é compatível com o cancelamento da operação porque ela tem um tipo de operação diferente de IMPORT ou EXPORT.
Mensagem de erro: The [operation-type] operation isn't cancelled. Wait and retry in a few seconds.

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

Clonar

Problema Solução de problemas
Ocorreu uma falha na clonagem com um erro constraints/sql.restrictAuthorizedNetworks. A operação de clonagem é bloqueada pela configuração Authorized Networks. Authorized Networks são configurados para endereços IP públicos na seção "Conectividade" do console do Google Cloud, e a clonagem não é permitida devido a considerações de segurança.

Remova todas as entradas Authorized Networks da instância do Cloud SQL, se possível. Caso contrário, crie uma réplica sem nenhuma entrada Authorized Networks.
Mensagem de erro: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

Você está tentando usar o console do Google Cloud para clonar uma instância com um endereço IP particular, mas não especificou o intervalo de IP alocado que pretende 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 o parâmetro
--allocated-ip-range-name. Para mais informações, consulte Como clonar uma instância com um IP particular.

Connect

Problema Solução de problemas
Aborted connection O problema pode ser:
  • Instabilidade de rede.
  • Nenhuma resposta aos comandos de sinal de atividade do TCP (o cliente ou o servidor não é responsivo, possivelmente sobrecarregado)
  • A vida útil da conexão do mecanismo de banco de dados foi excedida e o servidor encerra a conexão.

Os aplicativos devem tolerar falhas de rede e seguir as práticas recomendadas, como a repetição e o pooling de conexões. A maioria dos pools de conexão identifica esses erros sempre que possível. Caso contrário, o aplicativo precisará tentar novamente ou falhar normalmente.

Para novas tentativas de conexão, recomendamos os métodos a seguir:

  1. Espera exponencial. Aumente o intervalo de tempo entre cada nova tentativa, exponencialmente.
  2. Adicione também a espera aleatória.

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

Os certificados do cliente expiraram ou o caminho dos certificados está incorreto.

Para gerar os certificados novamente, recrie-os.
FATAL: database 'user' does not exist gcloud sql connect --user funciona apenas com o usuário postgres padrão.

Conecte-se com o usuário padrão e mude os usuários.
Você quer descobrir quem está conectado. Faça login no banco de dados e execute este comando: 


SELECT datname,
usename,
application_name as appname,
client_addr,
state,
now() - backend_start as conn_age,
now() - state_change as last_activity_age
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY 6 DESC
LIMIT 20

Hostname/IP does not match certificate's altnames: Host: localhost. is not in the cert's altnames

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

Se você estiver usando o Node.js com verify-full ou o 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'
}

Criar instâncias

Problema Solução de problemas
Mensagem de erro: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider Não há mais endereços disponíveis no intervalo de IP alocado. Pode haver vários cenários possíveis:

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

Para resolver esse problema, é possível expandir o intervalo de IP alocado existente ou alocar um intervalo de IP adicional para a conexão de serviço particular. Para mais informações, consulte Alocar um intervalo de endereços IP.

Se você usou a sinalização --allocated-ip-range-name ao criar a instância do Cloud SQL, só vai poder expandir o intervalo de IP especificado.

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

Depois de criar um novo intervalo de IP, atualize o peering VPC com o comando a seguir:


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 você estiver expandindo uma alocação atual, só aumente o intervalo de alocação em vez de diminuí-lo. Por exemplo, se a alocação original for 10.0.10.0/24, faça a nova alocação pelo menos 10.0.10.0/23.

Em geral, se começar com uma alocação de /24, diminuir o /mascaramento em 1 para cada condição (grupo de tipo de instância adicional, região adicional) é uma boa regra geral. Por exemplo, se você tentar criar os dois grupos de tipos de instância na mesma alocação, a mudança de /24 para /23 será suficiente.

Depois de expandir um intervalo de IP atual, use o seguinte comando para atualizar o peering VPC:


gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
Mensagem de erro: Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID] Tente criar a instância do Cloud SQL novamente.
Mensagem de erro: Failed to create subnetwork. Required 'compute.projects.get' permission for PROJECT_ID Quando você cria uma instância usando um endereço IP privado, uma conta de serviço é criada no momento certo usando a API Service Networking. Se você ativou recentemente a API Service Networking, a conta de serviço pode não ser criada e a criação da instância falhará. Nesse caso, você precisa esperar a conta de serviço se propagar pelo sistema ou adicioná-la manualmente com as permissões necessárias.

Exportar

Problema Solução de problemas
HTTP Error 409: Operation failed because another operation was already in progress. Já existe uma operação pendente para sua instância. Só é permitida uma operação por vez. Tente fazer o pedido após a conclusão da operação atual.
HTTP Error 403: The service account does not have the required permissions for the bucket. Verifique se o bucket existe e se a conta de serviço da instância do Cloud SQL (que está fazendo a exportação) tem o papel Storage Object Creator (roles/storage.objectCreator) para permitir a exportação para o bucket. Consulte Papéis do IAM para o Cloud Storage.
A exportação de CSV funcionou, mas a exportação de SQL falhou. Os formatos CSV e SQL são exportados de maneira diferente. O formato SQL exporta todo o banco de dados e provavelmente leva mais tempo para ser concluído. O formato CSV permite definir quais elementos do banco de dados serão incluídos na exportação.

Use exportações de CSV para exportar apenas o que você precisa.
A exportação está demorando muito. O Cloud SQL não é compatível com operações síncronas simultâneas.

Use o descarregamento de exportação. Em um alto nível, no descarregamento de exportação, em vez de emitir uma exportação na instância de origem, o Cloud SQL ativa uma instância de descarregamento para realizar a exportação. O descarregamento de exportação tem várias vantagens, incluindo o aumento do 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 pelo tempo necessário para exibir a instância de descarregamento. Geralmente, para exportações de tamanho razoável, a latência não é significativa. No entanto, se a exportação for pequena o suficiente, será possível notar um aumento na latência.
Erro ao criar extensão. O arquivo dump contém referências a extensões não compatíveis.

Edite o arquivo dump para remover as referências.
Erro ao usar pg_dumpall. O uso do utilitário pg_dumpall com a sinalização --global exige o papel de superusuário, mas esse papel não é compatível com o Cloud SQL para PostgreSQL. Para evitar erros ao realizar operações de exportação que incluam nomes de usuários, use também a sinalização --no-role-passwords.
A operação de exportação expira antes de exportar qualquer coisa, e você vê a mensagem de erro Could not receive data from client: Connection reset by peer. Se o Cloud Storage não receber dados em um determinado período, geralmente em torno de sete minutos, a conexão será redefinida. É possível que a consulta de exportação inicial esteja demorando muito para ser executada.

Faça uma exportação manual usando a ferramenta pg_dump.
Você quer que as exportações sejam automatizadas. O Cloud SQL não oferece uma maneira de automatizar exportações.

É possível criar seu próprio sistema de exportação automatizada usando produtos do Google Cloud, como Cloud Scheduler, Pub/Sub e Cloud Functions, semelhante a este artigo sobre como automatizar backups.

Sinalizações

Problema Solução de problemas
Você define o fuso horário de uma sessão, mas ela expira quando você faz logoff.

Conecte-se ao banco de dados e defina o fuso horário que você quiser para ele, por usuário ou banco de dados.

No Cloud SQL para PostgreSQL, é possível especificar o seguinte. Essas configurações permanecem depois que a sessão é fechada, imitando uma configuração .conf:


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

Essas configurações são válidas apenas para 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.

Alta disponibilidade

Problema Solução de problemas
Não é possível encontrar as métricas de um failover manual. Somente failovers automáticos entram nas métricas.
Os recursos da instância do Cloud SQL (CPU e RAM) estão quase com 100% de uso, fazendo com que a instância de alta disponibilidade fique inativa. O tamanho da máquina da instância é pequeno demais para a carga.

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

Importar

Problema Solução de problemas
Mensagem de erro: permission denied for schema public 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. 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.
HTTP Error 409: Operation failed because another operation was already in progress Já existe uma operação pendente para sua instância. Só é permitida uma operação por vez. Tente fazer o pedido após a conclusão da operação atual.
A operação de importação está demorando muito. Muitas conexões ativas podem interferir nas operações de importação.

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

Uma reinicialização:

  • fecha todas as conexões;
  • encerra todas as tarefas que possam estar consumindo recursos.
Uma operação de importação pode falhar quando um ou mais usuários referenciados no arquivo dump não existem. Antes de importar um arquivo dump, todos os usuários do banco de dados que têm objetos ou receberam permissões nos objetos no banco de dados despejado precisam existir no banco de dados de destino. Caso contrário, a operação de importação não recriará os objetos com a propriedade ou as permissões originais.

Crie os usuários do banco de dados antes de importar.
Após a importação de dados, o tamanho do uso do disco de dados é muito maior.

Talvez haja um uso inesperado do disco após a importação de dados. Esse uso pode ser por causa da recuperação pontual.

Para resolver isso, depois de importar dados, desative a recuperação pontual se quiser excluir registros e recuperar armazenamento. Lembre-se de que diminuir o armazenamento usado não reduz o tamanho do armazenamento provisionado para a instância.
Mensagem de erro: GRANT stderr: ERROR: must be member of role ROLE_NAME

Essa mensagem de erro será exibida se você tentar importar um arquivo dump SQL enviado no Cloud Storage para um banco de dados do Cloud SQL e o job de importação tiver sido executado por cerca de quatro dias.

ROLE_NAME é um papel de banco de dados personalizado definido no banco de dados PostgreSQL de origem. O usuário cloudsqlsuperuser padrão importa o arquivo dump SQL. No entanto, esse usuário pode não pertencer ao papel ROLE_NAME.

Para resolver esse problema, siga estas etapas:

  1. Crie o papel ROLE_NAME no banco de dados de destino para onde você está importando o arquivo dump 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 do papel 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 …]

Integrar com a Vertex AI

Problema Solução de problemas
Mensagem de erro: Google ML integration API is supported only on Postgres version 12 or above. Para ativar a integração da Vertex AI no Cloud SQL, você precisa ter um banco de dados do Cloud SQL para PostgreSQL versão 12 ou mais recente. Para fazer upgrade do banco de dados para esta versão, consulte Fazer upgrade da versão principal do banco de dados no local.
Mensagem de erro: Google ML Integration API is not supported on shared core instance. Please upsize your machine type. Se você selecionou um núcleo compartilhado para o tipo de máquina da sua instância, não vai ser possível ativar a integração da Vertex AI no Cloud SQL. Faça upgrade do seu tipo de máquina para o núcleo dedicado. Para mais informações, consulte Tipo de máquina.
Mensagem de erro: Google ML Integration is unsupported for this maintenance version. Please follow https://cloud.google.com/sql/docs/postgres/self-service-maintenance to update the maintenance version of the instance. Para ativar a integração da Vertex AI no Cloud SQL, a versão de manutenção da instância precisa ser R20240130 ou posterior. Se quiser fazer upgrade da instância para esta versão, consulte Manutenção de autoatendimento.
Mensagem de erro: Cannot invoke ml_predict_row if 'cloudsql.enable_google_ml_integration' is off. A flag do banco de dados cloudsql.enable_google_ml_integration está desativada. Não é possível integrar o Cloud SQL à Vertex AI.

Para ativar essa sinalização, use o comando gcloud sql instances patch:

gcloud sql instances patch INSTANCE_NAME --database-flags cloudsql.enable_google_ml_integration=on

Substitua INSTANCE_NAME pelo nome da instância principal do Cloud SQL.
Mensagem de erro: Failed to connect to remote host: Connection refused. A integração entre o Cloud SQL e a Vertex AI não está ativada. Para ativar essa integração, use ogcloud sql instances patch comando:

gcloud sql instances patch INSTANCE_NAME
--enable-google-ml-integration

Substituir INSTANCE_NAME pelo nome da instância principal do Cloud SQL.
Mensagem de erro: Vertex AI API has not been used in project PROJECT_ID before or it is disabled. Enable it by visiting /apis/api/aiplatform.googleapis.com/overview?project=PROJECT_ID then retry. A API Vertex AI não está ativada. Para mais informações sobre como ativar essa API, consulte Ativar a integração do banco de dados com a Vertex AI.
Mensagem de erro: Permission 'aiplatform.endpoints.predict' denied on resource. As permissões da Vertex AI não são adicionadas à conta de serviço do Cloud SQL para o projeto em que a instância do Cloud SQL está localizada. Para mais informações sobre como adicionar essas permissões à conta de serviço, consulte Ativar a integração do banco de dados com a Vertex AI.
Mensagem de erro: Publisher Model `projects/PROJECT_ID/locations/REGION_NAME/publishers/google/models/MODEL_NAME` not found. O modelo de machine learning ou o LLM não existe na Vertex AI.
Mensagem de erro: Resource exhausted: grpc: received message larger than max. O tamanho da solicitação que o Cloud SQL transmite para a Vertex AI excede o limite gRPC de 4 MB por solicitação.
Mensagem de erro: Cloud SQL attempts to send a request to Vertex AI. However, the instance is in the %s region, but the Vertex AI endpoint is in the %s region. Make sure the instance and endpoint are in the same region. O Cloud SQL tenta enviar uma solicitação para a Vertex AI. No entanto, a instância está em uma região, mas o endpoint da Vertex AI está em outra região. Para resolver esse problema, a instância e o endpoint precisam estar na mesma região.
Mensagem de erro: The Vertex AI endpoint isn't formatted properly. O endpoint da Vertex AI não está formatado corretamente. Para mais informações, consulte Usar endpoints particulares para previsão on-line.
Mensagem de erro: Quota exceeded for aiplatform.googleapis.com/online_prediction_requests_per_base_model with base model: textembedding-gecko. O número de solicitações que o Cloud SQL transmite para a Vertex AI excede o limite de 1.500 solicitações por minuto, região, modelo e projeto.

Geração de registros

Problema Solução de problemas
A geração de registros usa muita CPU e memória na instância do Cloud SQL. A geração de registros precisa ser ajustada.

A sinalização log_statement pode ser definida como nenhuma e a sinalização logging_collector pode ser desativada. Se a geração de registros ainda estiver ocorrendo, talvez haja outras sinalizações relacionadas a registros que podem ser ajustadas. É possível editar a instância para modificar essas sinalizações.
Registros de auditoria não encontrados. Os registros de acesso a dados só são gravados se a operação for uma chamada de API autenticada pelo usuário que cria, modifica ou lê dados criados pelo usuário ou se a operação acessar arquivos de configuração ou metadados de recursos.
Informações de operações não encontradas nos registros. Você quer encontrar mais informações sobre uma operação.

Por exemplo, um usuário foi excluído, mas não é possível descobrir quem fez isso. Os registros mostram que a operação foi iniciada, mas não fornecem mais informações. Você precisa ativar o registro de auditoria para que informações de identificação detalhadas e pessoais (PII, na sigla em inglês) sejam registradas.
Os arquivos de registros são difíceis de ler. Você preferiria ver os registros como json ou texto. É possível usar o comando gcloud logging read junto com os comandos de pós-processamento do Linux para fazer o download dos registros.

Para fazer o download dos registros 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 fazer o download dos registros como TEXT:


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
Os registros de consulta não são encontrados nos registros do PostgreSQL. Você precisa ativar os sinalizadores pgaudit.
  1. Em um terminal, conecte-se ao 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 execute este comando em um terminal: 
    
gcloud sql instances patch INSTANCE_NAME \
--database-flags=cloudsql.enable_pgaudit=on,pgaudit.log=all

Gerenciar instâncias

Problema Solução de problemas
Você quer descobrir quais consultas estão sendo executadas agora. Conecte-se ao banco de dados e execute a seguinte consulta:

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;

Você quer descobrir quais unidades estão sendo usadas para um campo específico. Conecte-se ao banco de dados e execute a seguinte consulta (usando seu próprio FIELD_NAME):

SELECT name, setting, unit FROM pg_settings WHERE name = 'FIELD_NAME'
Você quer encontrar o valor atual de uma configuração de banco de dados. Conecte-se ao banco de dados e execute a seguinte consulta (usando seu próprio SETTING_NAME):

SHOW SETTING_NAME;

Execute SHOW ALL; para ver todas as configurações.
Você quer interromper um processo em segundo plano que está bloqueado. O usuário precisa ter o papel pg_signal_backend.

Execute os comandos a seguir:

  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. Interrompa 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';
A instância está se aproximando de 100% de consumo de IDs da transação. O monitoramento interno avisa que a instância está se aproximando de 100% do consumo de IDs de transação. Evite o encapsulamento de transações, que pode bloquear gravações.

O job do autovacuum pode estar bloqueado ou 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 um problema de encapsulamento de transações, você pode revisar estas dicas de autoatendimento para lidar com o encapsulamento de TXID.

Para dicas gerais de ajuste, consulte Como otimizar, monitorar e solucionar problemas de operações de vacuum no PostgreSQL.
O armazenamento temporário aumentou o armazenamento automático. O armazenamento automático está ativado.

A reinicialização exclui os arquivos temporários, mas não reduz o armazenamento. Somente o suporte ao cliente pode redefinir o tamanho da instância.
Os dados estão sendo excluídos automaticamente. Provavelmente, um script está sendo executado em algum lugar no seu ambiente.

Procure nos registros próximos o momento da exclusão e veja se há um script não autorizado em execução em um painel ou outro processo automatizado.
A instância não pode ser excluída. Você verá a mensagem de erro ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request ou a instância apresentará um status de sinalização INSTANCE_RISKY_FLAG_CONFIG.

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 uma sinalização beta é usada. Remova as configurações de sinalização arriscadas e reinicie a instância.
A instância está travada devido ao grande tamanho dos dados temporários. O sistema pode criar muitas tabelas temporárias de uma só vez, dependendo das consultas e da carga.

Infelizmente, não é possível reduzir o arquivo ibtmp1 por nenhum método que não seja 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.
Erro fatal durante o upgrade. Os registros podem revelar mais. Mas, em qualquer caso, o suporte ao cliente pode ser necessário para forçar a recriação da instância.
A instância trava na reinicialização quando acaba o espaço em disco. O recurso de aumento automático de armazenamento não está ativado.

Se a instância ficar sem espaço de armazenamento e o recurso de aumento automático de armazenamento não estiver ativado, a instância ficará off-line. Para evitar esse problema, edite a instância para ativar o aumento automático de armazenamento.
A instância principal local está paralisada. O Google Cloud não pode ajudar com instâncias que não estão no Cloud SQL.
Desligamento lento na reinicialização. Quando uma instância é encerrada, todas as conexões pendentes que não são encerradas em até 60 segundos produzem erros no desligamento.

Com apenas conexões que duram menos de 60 segundos, a maioria dos desligamentos com erros pode ser evitada, incluindo conexões pelo prompt de comando do banco de dados. Se você mantiver essas conexões abertas por horas ou dias, é possível que haja erros nos desligamentos.
Não é possível excluir um usuário. O usuário provavelmente tem objetos no banco de dados que dependem dele. É necessário descartar esses objetos ou reatribuí-los a outro usuário.

Descubra quais objetos dependem do usuário e, em seguida, disponibilize ou reatribua esses objetos a outro usuário.

Esta linha de execução no Stack Exchange discute como encontrar os objetos de propriedade do usuário.
As consultas específicas estão lentas. As consultas podem ser lentas por vários motivos, principalmente devido a aspectos específicos do banco de dados. Um motivo que pode envolver o Cloud SQL é a latência da rede, quando o recurso de origem (gravador ou leitor) e o recurso de destino (Cloud SQL) estão em regiões diferentes.

Consulte as dicas gerais de desempenho, especialmente:

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

  • Verifique os locais do gravador e do banco de dados. O envio de dados por uma longa distância gera latência.
  • Verifique o local 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, recomenda-se que os recursos de origem e de destino estejam na mesma região.
A falta de memória é indicada, mas os gráficos de monitoramento não mostram isso. Uma instância pode falhar e informar Out of memory, mas os gráficos do Console do Google Cloud ou do Cloud Monitoring parecem mostrar que ainda há memória.

Há outros fatores, além da carga de trabalho, que podem afetar o uso de memória, como o número de conexões ativas e processos de sobrecarga interna. Eles nem sempre aparecem nos gráficos de monitoramento.

Verifique se a instância tem sobrecarga suficiente para suportar sua carga de trabalho e uma possível sobrecarga.
Como recuperar uma instância excluída. Ao excluir uma instância, todos os dados contidos nela são perdidos permanentemente, inclusive backups.

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

O papel de administrador do Cloud SQL inclui a permissão para excluir a instância. Para evitar exclusões acidentais, conceda esse papel somente quando necessário.
Você quer renomear uma instância do Cloud SQL. Não é possível renomear uma instância atual.

Há outras maneiras de atingir a meta criando uma nova instância.

  • É possível clonar a instância que você quer renomear e definir um novo nome para ela. Isso permite que você crie a nova instância sem precisar importar dados manualmente. Assim como ao criar uma nova instância, a instância clonada tem um novo endereço IP.
  • É possível exportar dados da instância para um bucket do Cloud Storage, criar uma nova instância com o novo nome e importar os dados para a nova instância.

Nos dois casos, é possível excluir a instância antiga depois que a operação for concluída. Recomendamos seguir a rota de clonagem porque ela não afeta o desempenho e não exige que você refaça nenhuma das definições da configuração da instância, como sinalizações, tipo de máquina, tamanho do armazenamento e memória.
Erro ao excluir uma instância. Se a proteção contra exclusão estiver ativada em uma instância, confirme seus planos para excluir a instância. Em seguida, desative a proteção contra exclusão antes de excluir a instância.

Replicação

Problema Solução de problemas
A réplica de leitura não começou a ser replicada na criação. Provavelmente há um erro mais específico nos arquivos de registro. Inspecione os registros no Cloud Logging para encontrar o erro real.
Não foi possível criar a réplica de leitura: erro invalidFlagValue. Uma das sinalizações na solicitação é inválida. Pode ser uma sinalização fornecida explicitamente ou uma que foi definida como um valor padrão.

Primeiro, verifique se o valor da sinalização max_connections é maior ou igual ao valor na instância principal.

Se a sinalização max_connections estiver definida corretamente, inspecione os registros no Cloud Logging para encontrar o erro real.
Não foi possível criar a réplica de leitura: erro desconhecido. Provavelmente há um erro mais específico nos arquivos de registro. Inspecione os registros 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 o Service Networking API. Essa ação cria a conta de serviço necessária para continuar com o processo.
O disco está cheio. O tamanho do disco da instância principal pode ficar cheio durante a criação da réplica. Edite a instância principal com upgrade para um tamanho de disco maior.
O espaço em disco aumenta significativamente. Um slot que não está sendo usado ativamente para rastrear dados faz com que o PostgreSQL mantenha os segmentos de WAL indefinidamente, fazendo com que o espaço em disco aumente indefinidamente. Se você usar os recursos de replicação e decodificação lógica no Cloud SQL, os slots de replicação serão criados e descartados automaticamente. Os slots de replicação não utilizados podem ser detectados consultando a visualização do sistema pg_replication_slots e filtrando a coluna active. Os slots não utilizados podem ser descartados para remover segmentos WAL usando o comando pg_drop_replication_slot.
A instância da réplica está usando memória demais. A réplica usa memória temporária para armazenar em cache as operações de leitura solicitadas com frequência, o que pode fazer com que ela use mais memória do que a instância principal.

Reinicie a instância da réplica para recuperar o espaço de memória temporário.
Replicação interrompida. O limite máximo de armazenamento foi atingido e o aumento automático de armazenamento não está ativado.

Edite a instância para ativar automatic storage increase.
O atraso da replicação é consistentemente alto. A carga de gravação é alta demais para a réplica processar. O atraso de replicação ocorre quando a linha de execução SQL em uma réplica não consegue acompanhar a linha de execução de E/S. Alguns tipos de consultas ou cargas de trabalho podem causar um atraso de replicação temporário ou permanente para um determinado esquema. Estas são algumas das causas comuns do atraso de replicação:
  • Consultas lentas na réplica. Encontre e corrija esses problemas.
  • Todas as tabelas precisam ter uma chave primária/exclusiva. Cada atualização em uma tabela sem uma chave exclusiva/principal resulta em varreduras completas na tabela da réplica.
  • Consultas como DELETE ... WHERE field < 50000000 causam atraso de replicação com base em linha, já que um grande número de atualizações é acumulado na réplica.

Algumas soluções possíveis incluem:

  • Editar a instância para aumentar o tamanho da réplica.
  • Reduza a carga no banco de dados.
  • Envia o tráfego de leitura para a réplica de leitura.
  • Inclua as tabelas em um índice.
  • Identifique e corrija consultas de gravação lentas.
  • Recrie a réplica.
Erros ao recriar índices no PostgreSQL 9.6. Você recebe um erro do PostgreSQL informando que é necessário recriar um índice específico. Isso só pode ser feito na instância principal. Se você criar uma nova instância de réplica, em breve receberá o mesmo erro novamente. Os índices de hash não são propagados para réplicas nas versões do PostgreSQL abaixo de 10.

Se você precisar usar índices de hash, faça upgrade para o PostgreSQL 10+. Caso contrário, se você também quiser usar réplicas, não use índices de hash no PostgreSQL 9.6.
A consulta na instância principal está sempre em execução. Após a criação de uma réplica, a consulta SELECT * from pg_stat_activity where state = 'active' and pid = XXXX and username = 'cloudsqlreplica' deve ser executada continuamente em sua instância principal.
A criação da réplica falha com o tempo limite. Transações não confirmadas de longa duração na instância primária podem causar falha na criação da réplica de leitura.

Recrie a réplica depois de interromper todas as consultas em execução.
Se a instância principal e a réplica tiverem tamanhos de vCPU diferentes, poderá haver problemas de desempenho de consultas porque o otimizador de consultas considera os tamanhos de vCPU.

Para resolver esse problema, siga estas etapas:

  1. Ative a flag log_duration e defina o parâmetro log_statement como ddl. Assim, você terá acesso às consultas e ao ambiente de execução no banco de dados. No entanto, dependendo da carga de trabalho, isso pode causar problemas de desempenho.
  2. Na instância principal e na réplica de leitura, execute explain analyze para as consultas.
  3. Compare o plano de consulta e verifique as diferenças.

Se for uma consulta específica, modifique a consulta. Por exemplo, é possível mudar a ordem das mesclagens para ver se o desempenho melhora.