Resolução de problemas do Cloud SQL

Esta página inclui sugestões para resolver problemas do Cloud SQL para os motores de base de dados suportados. Algumas destas sugestões aplicam-se apenas a motores de base de dados específicos, enquanto outras são comuns a todos.

Para ver sugestões de resolução de problemas para motores de base de dados específicos, consulte as respetivas páginas individuais:

Verifique se a sua pergunta ou problema já foi abordado numa das seguintes páginas:

Os tópicos desta página incluem:

Cópia de segurança e recuperação

Problema Resolução de problemas
Não pode ver o estado da operação atual. A consola Google Cloud apenas comunica o êxito ou a falha quando a operação estiver concluída. Não foi concebido 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.
Quer saber quem emitiu uma operação de cópia de segurança a pedido. A interface do utilizador não mostra o utilizador que iniciou uma operação.

Procure nos registos e filtre por texto para encontrar o utilizador. Pode ter de usar registos de auditoria para informações privadas. Os ficheiros de registo relevantes incluem:

  • Se os registos de auditoria do Google Cloud estiverem ativados e tiver as autorizações necessárias para os ver, o cloudaudit.googleapis.com/activity também pode estar disponível.
Depois de eliminar uma instância, não pode fazer uma cópia de segurança da mesma.

Se eliminar uma instância sem fazer uma cópia de segurança final dos dados, não é possível recuperar os dados. No entanto, se restaurar a instância, o Cloud SQL também restaura as cópias de segurança. Para mais informações sobre a recuperação de uma instância eliminada, consulte o artigo Mantenha as cópias de segurança após a eliminação da instância.

Se tiver feito uma operação de exportação, crie uma nova instância e, em seguida, faça uma operação de importação para recriar a base de dados. As exportações são escritas no Cloud Storage e as importações são lidas a partir daí.
Uma cópia de segurança automática está bloqueada há muitas horas e não pode ser cancelada. As cópias de segurança podem demorar muito tempo, consoante o tamanho da base de dados.

Se realmente precisar de cancelar a operação, pode pedir ao apoio ao cliente que force restart a instância.
Uma operação de restauro pode falhar quando um ou mais utilizadores referenciados no ficheiro de captura SQL não existem. Antes de restaurar uma captura SQL, todos os utilizadores da base de dados que tenham objetos ou aos quais foram concedidas autorizações relativamente a objetos na base de dados capturada têm de existir na base de dados de destino. Caso contrário, a operação de restauro não consegue recriar os objetos com a propriedade ou as autorizações originais.

Crie os utilizadores da base de dados antes de restaurar o despejo SQL.
Quiser aumentar o número de dias durante os quais pode manter as cópias de segurança automáticas de sete para 30 dias ou mais. Pode configurar o número de cópias de segurança automáticas a reter. As cópias de segurança automáticas são reduzidas regularmente com base no valor de retenção configurado. Infelizmente, isto significa que as cópias de segurança atualmente visíveis são as únicas cópias de segurança automáticas a partir das quais pode fazer o restauro.

Para manter as cópias de segurança indefinidamente, pode criar uma cópia de segurança a pedido, uma vez que não são eliminadas da mesma forma que as cópias de segurança automáticas. As cópias de segurança a pedido permanecem indefinidamente. Ou seja, permanecem até serem eliminadas ou a instância à qual pertencem ser eliminada. Uma vez que esse tipo de cópia de segurança não é eliminado automaticamente, pode afetar a faturação.
Uma cópia de segurança automática falhou e não recebeu uma notificação por email. Para que o Cloud SQL lhe envie uma notificação sobre o estado da cópia de segurança, configure um alerta baseado em registos.
Uma instância está a falhar repetidamente porque está a alternar entre os estados de falha e de restauro da cópia de segurança. As tentativas de ligação e utilização da base de dados após a restauração falham.
  • Pode haver demasiadas ligações abertas. O excesso de ligações pode resultar de erros que ocorrem a meio de uma ligação em que não existem definições autovacuum para limpar ligações inativas.
  • A repetição cíclica pode ocorrer se algum código personalizado estiver a usar uma lógica de repetição que não pare após algumas falhas.
  • Pode haver demasiado tráfego. Use a pool de ligações e outras práticas recomendadas para a conetividade.

Opções que pode testar:

  1. Verifique se a base de dados está configurada para autovacuum.
  2. Verifique se existe alguma lógica de nova tentativa de ligação configurada no código personalizado.
  3. Diminua o tráfego até a base de dados recuperar e, em seguida, aumente lentamente o tráfego novamente.
Verifica que faltam dados quando realiza uma operação de cópia de segurança/restauro. As tabelas foram criadas como não registadas. Por exemplo:

CREATE UNLOGGED TABLE ....

Estas tabelas não estão incluídas num restauro a partir de uma cópia de segurança:

  • O conteúdo das tabelas não registadas não sobrevive à comutação por falha numa instância de HA.
  • As tabelas não registadas não sobrevivem a falhas do postgres.