Como diagnosticar problemas nas instâncias do Cloud SQL

Nesta página, mostramos uma lista dos problemas mais frequentes que podem ser encontrados ao trabalhar com instâncias do Cloud SQL, bem como as etapas a serem seguidas para resolvê-los. Veja também a página Problemas conhecidos, a Solução de problemas e a Página de suporte.

Ver registros

Veja informações sobre operações recentes nos registros de operação da instância do Cloud SQL ou nos registros de erro do MySQL.

Instância que não responde

Se a instância parar de responder às conexões ou o desempenho estiver prejudicado, verifique se tudo está em conformidade com as Diretrizes operacionais. Caso contrário, o problema não estará coberto pelo SLA do Cloud SQL.

Problemas de conexão

Verificar se o aplicativo está encerrando as conexões corretamente

Erros contendo "Aborted connection nnnn to db:" costumam indicar que o aplicativo não está interrompendo as conexões corretamente. Problemas de rede também podem causar esse erro. O erro não significa que há problemas com sua instância do Cloud SQL.

Para ver exemplos de práticas recomendadas de gerenciamento de conexões, consulte Como gerenciar conexões.

Verificar se os certificados expiraram

Se a instância estiver configurada para usar SSL, acesse a página "Instâncias" do Cloud SQL no Console do Cloud e abra a instância. Abra a página Conexões correspondente 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. Saiba mais.

Verificar se você está autorizado a se conectar

Caso não esteja conseguindo se conectar, verifique se você tem autorização de conexão:

  • Se estiver com dificuldade para se conectar usando um endereço IP, por exemplo, a partir do seu ambiente local com o cliente mysql, confirme se o endereço IP está autorizado a se conectar à instância do Cloud SQL.

    As conexões com uma instância do Cloud SQL usando um endereço IP privado são autorizadas automaticamente para intervalos de endereços RFC 1918. Dessa forma, todos os clientes particulares podem acessar o banco de dados sem passar pelo proxy. Os intervalos de endereços não RFC 1918 precisam ser configurados como redes autorizadas.

    Por padrão, o Cloud SQL não aprende as rotas de sub-rede não RFC 1918 da sua VPC. É necessário atualizar o peering de rede para o Cloud SQL para exportar rotas que não sejam RFC 1918. Exemplo:

    gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
    
  • Veja aqui o endereço IP atual.

  • Tente usar o comando gcloud sql connect para se conectar à instância. Esse comando autoriza seu endereço IP por um curto período. É possível executar esse comando em um ambiente com o SDK do Cloud e o cliente mysql instalados. Também é possível executar esse comando no Cloud Shell, que está disponível no Console do Google Cloud e tem o SDK do Cloud e o cliente mysql pré-instalados. O Cloud Shell fornece uma instância do Compute Engine para você se conectar ao Cloud SQL.
  • Permita temporariamente que todos os endereços IP se conectem a uma instância. Para IPv4, autorize 0.0.0.0/0. Para IPv6, autorize ::/0.

Verifique como você está se conectando

Se você receber uma mensagem de erro como:

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: NO)

ao se conectar, verifique se você forneceu uma senha.

Se você receber uma mensagem de erro como:

ERROR 1045 (28000): Access denied for user 'root'@'1.2.3.4' (using password: YES)

ao se conectar, verifique se está fornecendo a senha correta e se está utilizando SSL, se exigido pela instância.

Determine como as conexões estão sendo iniciadas

É possível ver informações sobre as conexões atuais executando o seguinte comando:

SHOW PROCESSLIST;

As conexões que mostram um endereço IP, como 1.2.3.4, são estabelecidas com IP. As conexões com cloudsqlproxy~1.2.3.4 usam o Cloud SQL Proxy. Caso contrário, elas são originadas do App Engine. As conexões de localhost podem ser usadas por alguns processos internos do Cloud SQL.

Entenda os limites de conexão

Não há limite de QPS para instâncias do Cloud SQL. No entanto, há limites específicos em relação à conexão, ao tamanho e ao App Engine. Consulte Cotas e limites.

As conexões do banco de dados consomem recursos no servidor e no aplicativo conectado. Sempre use boas práticas de gerenciamento de conexão para minimizar o espaço ocupado pelo seu aplicativo e reduzir a probabilidade de exceder os limites de conexão do Cloud SQL. Para mais informações, consulte Como gerenciar conexões de banco de dados.

Exibir conexões e threads

Se você receber a mensagem de erro "muitas conexões" ou quiser descobrir o que está acontecendo em uma instância, poderá exibir o número de conexões e linhas de execução com SHOW PROCESSLIST.

Em um cliente MySQL, execute:

mysql> SHOW PROCESSLIST;

Você verá um resultado parecido com este:

+----+-----------+--------------+-----------+---------+------+-------+----------------------+
| Id | User      | Host         | db        | Command | Time | State | Info                 |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
|  3 | user-name | client-IP    | NULL      | Query   |    0 | NULL  | SHOW processlist     |
|  5 | user-name | client-IP    | guestbook | Sleep   |    1 |       | SELECT * from titles |
| 17 | user-name | client-IP    | employees | Query   |    0 | NULL  | SHOW processlist     |
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
3 rows in set (0.09 sec)

Veja informações sobre como interpretar as colunas retornadas pelo comando PROCESSLIST na referência do MySQL (em inglês).

Para receber uma contagem de linhas de execução, use:

mysql> SHOW STATUS WHERE Variable_name = 'Threads_connected';

Você verá um resultado parecido com este:

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 7     |
+-------------------+-------+
1 row in set (0.08 sec)

Conexões do Compute Engine

As conexões com uma instância do Compute Engine expiram após dez minutos de inatividade, o que pode afetar conexões de longa duração não usadas entre a instância do Compute Engine e a instância do Cloud SQL. Para mais informações, consulte Rede e firewalls na documentação do Compute Engine.

Para manter ativas as conexões de longa duração não usadas, configure o sinal de atividade TCP (em inglês). Os comandos a seguir definem o valor TCP keepalive para um minuto e tornam a configuração permanente em reinicializações de instância.

Exiba o valor tcp_keepalive_time atual.

cat /proc/sys/net/ipv4/tcp_keepalive_time

Defina tcp_keepalive_time como 60 segundos e torne-o permanente durante as reinicializações.

echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

Aplique a alteração.

sudo /sbin/sysctl --load=/etc/sysctl.conf

Exiba o valor tcp_keepalive_time para verificar se a alteração foi aplicada.

cat /proc/sys/net/ipv4/tcp_keepalive_time

Conexão com IPv6

Se você receber uma destas mensagens de erro:

Can't connect to MySQL server on '2001:1234::4321' (10051)
Can't connect to MySQL server on '2001:1234::4321' (101)

ao se conectar, é provável que esteja tentando conectar-se ao endereço IPv6 da instância, mas a estação de trabalho não tenha IPv6 disponível. Acesse o site ipv6.google.com para verificar se o IPv6 está funcionando na estação de trabalho. Se o site não carregar, isso significa que o IPv6 não está disponível. Como solução, conecte-se ao endereço IPv4 ou à instância do Cloud SQL. Talvez seja necessário adicionar um endereço IPv4 à instância primeiro.

Tempo limite da conexão

Se um cliente não puder se conectar à instância do Cloud SQL usando um IP particular, verifique se o IP utilizado está no intervalo 172.17.0.0/16. Ocorre falha nas conexões de qualquer IP no intervalo 172.17.0.0/16 para instâncias do Cloud SQL usando IP particular. Da mesma forma, as instâncias do Cloud SQL criadas com um IP nesse intervalo são inacessíveis. Esse intervalo é reservado para a rede de ponte do docker.

Falhas de conexão de vez em quando

Quando o Cloud SQL reinicia uma instância devido a eventos de manutenção, as conexões podem ser roteadas para a réplica de failover. Quando você se conecta à réplica de failover:

  • As solicitações de leitura de clientes que usam conexões não criptografadas têm êxito normalmente. No entanto, as solicitações de gravação falham e retornam uma mensagem de erro, como "Erro 1290: o servidor MySQL está em execução com a opção --read-only, portanto, não pode executar esta instrução."

  • As solicitações de leitura e gravação de clientes que usam conexões criptografadas falham e retornam uma mensagem de erro, como "x509: o certificado é válido para instância mestre, não para a instância de failover".

Depois que o evento terminar, o Cloud SQL redefinirá a conexão. Tente estabelecer conexão novamente. Recomendamos que os aplicativos sejam desenvolvidos implementando uma estratégia de tratamento de erros, como a espera exponencial, para manipular falhas de conexão de vez em quando. Consulte Implementação do aplicativo para mais informações.

Problemas da instância

Backups

Para ter o melhor desempenho com backups, mantenha a quantidade de tabelas em um número razoável.

Importar e exportar

As importações e exportações no Cloud SQL são as mesmas de quando se usa o utilitário mysqldump. No entanto, com o recurso de importação e exportação do Cloud SQL, você transfere dados usando um bucket do Cloud Storage.

As importações e exportações para o Cloud SQL que usam a função de importação (por meio de um bucket do Cloud Storage) podem demorar muito para serem concluídas, dependendo do tamanho do banco de dados. Esse processo pode ter os seguintes impactos:

  • Não é possível interromper uma operação de longa duração.
  • Apenas uma operação de importação ou exportação pode ser executada por vez para cada instância.

É possível diminuir o tempo necessário para concluir cada operação usando a função de importação ou exportação do Cloud SQL com lotes menores de dados.

Para exportações, use a opção sem servidor para minimizar o impacto no desempenho do banco de dados e permitir que outras operações sejam executadas na sua instância enquanto a exportação é feita.

Outros fatores a considerar durante a importação:

  • Se a importação estiver falhando, talvez seja por causa de um erro de falta de memória (OOM, na sigla em inglês). Se esse for o caso, tente usar comandos do MySQL diretamente para adicionar os parâmetros --extended-insert=FALSE --complete-insert. Esses parâmetros reduzem a velocidade da importação, mas também reduzem a quantidade de memória necessária.

Espaço em disco

Se sua instância atingir o volume de armazenamento máximo permitido, as gravações no banco de dados falharão. Se você excluir dados, por exemplo, eliminando uma tabela, o espaço liberado não será refletido no Armazenamento usado relatado da instância. Veja uma explicação desse comportamento nas "Perguntas frequentes" Como recuperar o espaço de uma tabela eliminada?.

Atingir o limite máximo de armazenamento também pode fazer com que a instância fique travada na reinicialização.

Evitar a corrupção de dados

Evite colunas geradas

Devido a um problema no MySQL, o uso de colunas geradas pode causar corrupção de dados. Para mais informações, consulte o bug nº 82736 do MySQL.

Encerramentos limpos

Quando o Cloud SQL encerra uma instância, por exemplo, para manutenção, novas conexões não são enviadas à instância. Além disso, as conexões existentes são encerradas. O tempo fornecido ao mysqld para o encerramento é limitado a 1 minuto. Se o encerramento não for concluído nesse período, o processo mysqld será interrompido de modo forçado. Isso pode fazer com que gravações de disco sejam abortadas antes da conclusão.

Mecanismos de banco de dados

O InnoDB é o único mecanismo de armazenamento compatível com instâncias do MySQL porque ele é mais resistente ao corrompimento de tabelas do que outros mecanismos de armazenamento MySQL, como o MyISAM.

Por padrão, as tabelas de banco de dados do Cloud SQL são criadas com o mecanismo de armazenamento InnoDB. Se a sintaxe CREATE TABLE incluir uma opção ENGINE especificando um mecanismo de armazenamento que não seja o InnoDB, por exemplo, ENGINE = MyISAM, a tabela não será criada e você verá mensagens de erro como:

ERROR 3161 (HY000): Storage engine MyISAM is disabled (Table creation is disallowed).

Para evitar esse erro, remova a opção ENGINE = MyISAM do comando CREATE TABLE. Assim, a tabela será criada com o mecanismo de armazenamento InnoDB.

O InnoDB é recomendado para instâncias de primeira geração porque garante uma consistência de dados maior.

Alterações nas tabelas do sistema

As tabelas do sistema do MySQL usam o mecanismo de armazenamento MyISAM, incluindo todas as tabelas do banco de dados mysql, por exemplo, mysql.user e mysql.db. Essas tabelas são vulneráveis a encerramentos com erros. Emita o comando FLUSH CHANGES depois de fazer alterações nessas tabelas. Em caso de corrompimento do MyISAM, CHECK TABLE e REPAIR TABLE podem fazer o retorno para um ponto de bom estado, mas sem salvar dados.

Identificadores de transações globais (GTID, na sigla em inglês)

Todas as instâncias do MySQL têm o GTID ativado automaticamente. O GTID oferece proteção contra perda de dados durante a criação de réplicas e failover e torna a replicação mais robusta. No entanto, ele apresenta algumas limitações impostas pelo MySQL, conforme documentado no manual do MySQL. As operações transacionais não seguras a seguir não podem ser usadas em um servidor MySQL com GTID ativado:

  • Instruções CREATE TABLE ... SELECT
  • Instruções CREATE TEMPORARY TABLE dentro de transações
  • Transações ou instruções que afetam tabelas transacionais e não transacionais

Se usar uma transação não segura, você verá uma mensagem de erro como:

 Exception: SQLSTATE[HY000]: General error: 1786
 CREATE TABLE ... SELECT is forbidden when @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1.

Como trabalhar com gatilhos e funções armazenadas

Se a instância tiver a geração de registros binária ativada e você precisar trabalhar com gatilhos ou funções armazenadas, verifique se a instância tem a sinalização log_bin_trust_function_creators definida como on.

Estado suspenso

Há vários motivos pelos quais o Cloud SQL pode suspender uma instância, entre os quais:

  • Problemas de faturamento

    Por exemplo, se o cartão de crédito da conta de faturamento do projeto tiver expirado, a instância poderá ser suspensa. Verifique as informações de faturamento de um projeto acessando a página de faturamento do Console do Google Cloud, basta selecionar o projeto e visualizar as informações da conta de faturamento usada no projeto. Depois de resolver o problema de faturamento, a instância retorna ao status executável em algumas horas.

  • Problemas de chave do KMS

    Por exemplo, se a versão da chave do KMS usada para criptografar os dados do usuário na instância do Cloud SQL não estiver presente ou se tiver sido desativada ou destruída. Consulte Como usar chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês).

  • Problemas jurídicos

    Por exemplo, uma violação da política de uso aceitável do Google Cloud pode causar a suspensão da instância. Para mais informações, consulte "Suspensões e remoções" nos Termos de Serviço do Google Cloud.

  • Problemas operacionais

    Por exemplo, se uma instância estiver presa em um ciclo de falha (ela falha durante ou logo após a inicialização), o Cloud SQL poderá suspendê-la.

Durante a suspensão de uma instância, é possível continuar visualizando informações sobre ela ou excluí-la, caso a suspensão tenha sido acionada por problemas de faturamento.

Os usuários do Cloud SQL com pacotes de suporte Platinum, Gold ou Silver podem contatar a equipe de suporte diretamente sobre instâncias suspensas. Todos os usuários podem usar a orientação anterior com o fórum google-cloud-sql (em inglês).

Desempenho

Ativar registros de consulta

Para ajustar o desempenho das consultas, configure o Cloud SQL para registrar consultas lentas adicionando as sinalizações do banco de dados --log_output='FILE' e --slow_query_log=on à instância. Isso disponibiliza a saída de registro usando o visualizador de registros no Console do Google Cloud. As cobranças de registro do pacote de operações do Google Cloud são aplicáveis.

Não defina log_output como TABLE. Isso pode causar problemas de conexão descritos em Dicas para trabalhar com sinalizações.

Ativar o monitoramento de bloqueio

Os monitores do InnoDB fornecem informações sobre o estado interno do mecanismo de armazenamento InnoDB, que você pode usar no ajuste de desempenho.

Acesse a instância usando o cliente MySQL para receber a saída do monitor sob demanda:

SHOW ENGINE INNODB STATUS\G

Para ver explicações sobre as seções dos resultados de monitoramento, consulte Saída do monitor padrão e do monitor de bloqueio do InnoDB.

É possível ativar monitores do InnoDB para que a saída seja gerada periodicamente em um arquivo ou tabela, com degradação no desempenho. Para conferir mais informações, veja Ativar monitores do InnoDB.

Usar esquema de desempenho

O MySQL Performance Schema é um recurso para monitorar a execução do MySQL Server em um nível baixo. A maneira mais acessível de consumir as estatísticas geradas em performance_schema é pela funcionalidade Relatórios de desempenho do MySQL Workbench.

Mantenha um número razoável de tabelas de banco de dados

As tabelas de banco de dados consomem recursos do sistema. Um grande número pode afetar o desempenho e a disponibilidade da instância e fazer com que a instância perca a cobertura do SLA. Saiba mais

Dicas de desempenho geral

  • Verifique se o tipo de máquina é grande o suficiente para a carga de trabalho.

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

  • Verifique as localizações do gravador e do banco de dados. O envio de dados de longa distância introduz latência.

Para seleções lentas do banco de dados, considere o seguinte:

  • O armazenamento em cache é importante para o desempenho de leitura. Compare o tamanho do conjunto de dados com a capacidade de RAM da instância. O ideal é que todo o conjunto de dados se ajuste a 70% da RAM da instância. Nesse caso, as consultas não são limitadas ao desempenho de E/S. Caso contrário, aumente o tamanho do nível da instância.
  • Se a carga de trabalho consistir em consultas com uso intensivo de CPU (classificação, expressões regulares, outras funções complexas), a instância poderá ser limitada. Aumente o nível.
  • 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.
  • Investigue as melhorias de desempenho específicas não relacionadas ao Cloud SQL, como adicionar indexação apropriada, reduzir dados digitalizados e evitar ciclos extras.

Caso você perceba um desempenho ruim na execução de consultas, use EXPLAIN. EXPLAIN é uma instrução adicionada a outras, como SELECT, e retorna informações sobre como o MySQL executa a instrução. Ela funciona com SELECT, DELETE, INSERT, REPLACE e UPDATE. Por exemplo, EXPLAIN SELECT * FROM myTable;.

Use EXPLAIN para identificar onde você pode:

  • adicionar índices a tabelas e melhorar o desempenho da consulta. Por exemplo, garanta que todos os campos usados como chave JOIN tenham um índice nas duas tabelas.

  • melhorar as operações ORDER BY. Se EXPLAIN mostrar "Using temporary; Using filesort" na coluna Extra da saída, os resultados intermediários serão armazenados em um arquivo que será classificado, o que geralmente resulta em baixo desempenho. Nesse caso, execute uma das seguintes etapas:

    • Se possível, use índices em vez de classificar. Veja Otimização do comando ORDER BY para saber mais informações.

    • Aumente o tamanho da variável sort_buffer_size para a sessão de consulta.

    • Use menos memória RAM por linha, declarando colunas somente com o tamanho necessário.

Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês)

As operações de administrador do Cloud SQL (como criação, clonagem ou atualização) podem falhar devido a erros do Cloud KMS e ausência de papéis ou permissões. Motivos comuns de falha incluem uma versão ausente da chave do Cloud KMS, uma versão da chave do Cloud KMS desativada ou destruída, permissões de IAM insuficientes para acessar a versão da chave do Cloud KMS ou a versão da chave do Cloud KMS está em uma região diferente da instância do Cloud SQL. Use a seguinte tabela de solução de problemas para diagnosticar e resolver problemas comuns.

Tabela de solução de problemas de chaves de criptografia gerenciadas pelo cliente

Para este erro... O problema pode ser... Tente o seguinte...
Conta de serviço por produto, por projeto não encontrada O nome da conta de serviço está incorreto. Certifique-se de ter criado uma conta de serviço para o projeto de usuário correto.

ACESSAR A PÁGINA "CONTAS DE SERVIÇO"

Não é possível conceder acesso à conta de serviço A conta de usuário não tem permissão para conceder acesso a esta versão de chave. Adicione o papel Administrador da organização à sua conta de usuário ou serviço.

ACESSAR A PÁGINA "CONTAS DE IAM"

A versão da chave do Cloud KMS foi destruída A versão da chave foi destruída. Se a versão da chave for destruída, você não poderá usá-la para criptografar ou descriptografar dados.
A versão da chave do Cloud KMS está desativada A versão da chave está desativada. Reative a versão da chave do Cloud KMS.

ACESSAR A PÁGINA "CHAVES DE CRIPTOGRAFIA"

Permissão insuficiente para usar a chave do Cloud KMS O papel cloudkms.cryptoKeyEncrypterDecrypter está ausente na conta de usuário ou serviço que você está usando para executar operações em instâncias do Cloud SQL ou a versão da chave do Cloud KMS não existe. Adicione o papel cloudkms.cryptoKeyEncrypterDecrypter à conta de usuário ou serviço.

ACESSAR A PÁGINA "CONTAS DE IAM"


Se o papel já estiver na sua conta, consulte Como criar uma chave para saber como criar uma nova versão de chave. Consulte a observação.
A chave do Cloud KMS não foi encontrada A versão da chave não existe. Crie uma nova versão de chave. Consulte Como criar uma chave. Consulte a observação.
A instância do Cloud SQL e a versão da chave do Cloud KMS estão em diferentes regiões A versão da chave do Cloud KMS e a instância do Cloud SQL precisam estar na mesma região. Ela não funcionará se a versão da chave do Cloud KMS estiver em uma região global ou em várias regiões. Crie uma versão de chave na mesma região em que você quer criar instâncias. Consulte Como criar uma chave. Consulte a observação.

Solução de problemas de instâncias do Cloud SQL

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Desempenho lento após a reinicialização. O cache do InnoDB fica vazio após a reinicialização. Portanto, todas as leituras exigem um retorno ao back-end para receber dados. Aguarde a conclusão de todos os dados.
Recuperação lenta de falhas. Um general_log grande pode ter se acumulado. Gerencie a geração de registros geral. Saiba mais
Você quer descobrir o que está consumindo armazenamento. A maior parte do uso são tabelas de banco de dados, registros binários ou arquivos temporários. Veja estas dicas sobre como verificar.
As consultas estão bloqueadas. Um processo é bloquear todo o restante. Encontre e interrompa o processo de bloqueio. Saiba mais.
Não é possível excluir registros binários manualmente. Os registros binários não podem ser excluídos manualmente. Os registros binários são excluídos automaticamente com o backup automático associado, o que costuma ocorrer cerca de sete dias depois.
Você quer encontrar informações sobre arquivos temporários. O nome do arquivo temporário é ibtmp1. Tente esta consulta ao banco de dados para saber mais.
Você quer saber mais sobre os tamanhos das tabelas. Essas informações estão disponíveis no banco de dados. Tente estas consultas ao banco de dados para saber mais.
O mysqld recebeu um sinal 11. A instância falhou porque as consultas estão criando um excesso de conexões. Refatore as consultas para evitar isso.
InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal. O limpador de página não consegue acompanhar a velocidade de mudanças na instância. Fragmentar a instância pode ajudar.
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. Saiba mais.
Os dados estão sendo excluídos automaticamente. Há um script em execução em algum lugar que está fazendo isso. Tente encontrar o script.
A instância não pode ser excluída. mais de uma causa possível. mais de uma solução possível.
A instância está travada devido ao grande tamanho dos dados temporários. Muitas tabelas temporárias foram criadas ao mesmo tempo. Reinicie a instância e teste esta opção de mitigação.
Erro fatal durante o upgrade. Há muitas causas possíveis. Os registros podem revelar mais. Talvez seja necessário entrar em contato com o suporte ao cliente para forçar uma reinicialização.
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. Ative o aumento automático de armazenamento.
A instância principal local está paralisada. N/A O suporte ao cliente do Cloud SQL não pode ajudar com instâncias que não estão no Cloud SQL.
Desligamento lento na reinicialização. Conexões pendentes que não são encerradas após 60 segundos podem causar erros no desligamento. Tenha apenas conexões que durem menos de 60 segundos.
Access denied for user. É possível que a autenticação do usuário ou certificados SSL/TLS tenham expirado. Verifique os status de usuário e certificado.
Não é possível excluir um usuário. Pode ser que o usuário seja proprietário de objetos no banco de dados. Talvez seja necessário descartar ou reatribuir objetos.
Não é possível atribuir um endereço IP particular a uma instância atual em uma VPC compartilhada. Os endereços das instâncias são vinculados aos projetos no momento da criação. Crie uma nova instância do Cloud SQL para substituir a atual.
As consultas específicas estão lentas. Problemas específicos do banco de dados ou latência de rede. Confira estas sugestões.
A falta de memória é indicada, mas os gráficos de monitoramento não mostram isso. Talvez parte da RAM esteja sendo usada por processos de sobrecarga interna. Garanta que a instância terá sobrecarga suficiente para a carga de trabalho.
Como recuperar uma instância excluída. Ao excluir uma instância, todos os dados contidos nela são perdidos permanentemente, inclusive backups. Impeça a perda de dados exportando para o Cloud Storage.

Desempenho lento após a reinicialização

Desempenho lento após a reinicialização.

O problema pode ser

O Cloud SQL permite o armazenamento em cache de dados no pool de buffer do InnoDB. No entanto, após uma reinicialização, esse cache fica sempre vazio, e todas as leituras exigem um retorno ao back-end para receber dados. Como resultado, as consultas podem ficar mais lentas do que o esperado até que o cache seja preenchido.

O que você precisa tentar

N/A


Recuperação lenta de falhas

Recuperação lenta de falhas.

O problema pode ser

Um general_log grande pode ter se acumulado.

O que você precisa tentar

É possível reduzir o tempo de recuperação de falhas impedindo que um general_log grande seja acumulado. Se o general_log estiver ativado, trunque a tabela e ative general_log apenas por períodos curtos.

Para descobrir o tamanho dos registros gerais, conecte-se ao banco de dados e execute esta consulta: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) from mysql.general_log;


Você quer descobrir o que está consumindo armazenamento

Você quer descobrir o que está consumindo armazenamento. Por exemplo, você percebe que seu banco de dados está usando apenas 3 Gb, mas o armazenamento diz que 14 GB estão sendo usados.

O problema pode ser

A maior parte do espaço não usado por tabelas é usada por registros binários e/ou arquivos temporários.

O que você precisa tentar

  • Verifique o armazenamento ocupado por registros binários usando o seguinte comando na interface de linha de comando do MySQL: SHOW BINARY LOGS;
  • As tabelas temporárias também podem estar ocupando uma quantidade significativa de espaço de armazenamento. Para verificar o uso temporário de espaço, use o seguinte comando: SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G.
  • O comando a seguir permite verificar o tamanho do registro redo: SHOW VARIABLES LIKE 'innodb_log_file%';
  • É possível verificar o tamanho do general_log, se estiver ativado, com a ajuda deste comando: SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2)),2) AS GB from mysql.general_log;

As consultas estão bloqueadas

É possível que as consultas bloqueiem o banco de dados MySQL, fazendo com que todas as consultas subsequentes sejam bloqueadas/expirem.

O problema pode ser

Um processo está bloqueando os demais.

O que você precisa tentar

Conecte-se ao banco de dados e execute esta consulta: SHOW PROCESSLIST. O primeiro item da lista pode ser aquele que contém o cadeado, que os itens subsequentes estão esperando.

A consulta SHOW INNODB STATUS também pode ser útil.


Não é possível excluir manualmente os registros binários

Você não consegue excluir manualmente os registros binários.

O problema pode ser

Os registros binários não podem ser excluídos manualmente.

O que você precisa tentar

Os registros binários são excluídos automaticamente com o backup automático associado, o que costuma ocorrer cerca de sete dias depois.


Você quer encontrar informações sobre arquivos temporários

Você quer encontrar informações sobre arquivos temporários.

O problema pode ser

Um arquivo chamado ibtmp1 é usado para armazenar dados temporários. Esse arquivo é redefinido após a reinicialização do banco de dados.

O que você precisa tentar

Para encontrar informações sobre o uso de arquivos temporários, conecte-se ao banco de dados e execute esta consulta:

SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G


Você quer saber mais sobre os tamanhos das tabelas

Você quer descobrir os tamanhos das tabelas no seu banco de dados.

O problema pode ser

Essas informações estão disponíveis no banco de dados.

O que você precisa tentar

Conecte-se ao banco de dados e execute esta consulta:

SELECT TABLE_SCHEMA, TABLE_NAME, sum(DATA_LENGTH+INDEX_LENGTH)/pow(1024,2) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA NOT IN ('PERFORMANCE_SCHEMA','INFORMATION_SCHEMA','SYS','MYSQL') GROUP BY TABLE_SCHEMA, TABLE_NAME;


O mysqld recebeu um sinal 11

O seguinte erro ocorre:

mysqld got signal 11

O problema pode ser

A instância provavelmente falhou porque as consultas estão criando um excesso de conexões.

O que você precisa tentar

Refatore as consultas para que elas não criem tantas conexões.


InnoDB: page_cleaner

O servidor fica parado, e você recebe um erro como este: InnoDB: page_cleaner: 1000ms intended loop took 5215ms. The settings might not be optimal.

O problema pode ser

O limpador de página não consegue acompanhar a velocidade de mudanças na instância. Uma vez por segundo, o limpador de página verifica o pool de buffer para que páginas sujas sejam removidas do pool de buffer do disco. O alerta exibido mostra que há muitas páginas sujas a serem limpas, e que está demorando mais de um segundo para limpar o lote no disco.

O que você precisa tentar

Fragmente a instância, se possível. Usar muitas instâncias menores do Cloud SQL é melhor do que uma instância grande.


O armazenamento temporário aumentou o armazenamento automático

Tabelas temporárias aumentaram o uso do armazenamento, e o armazenamento automático foi aumentado.

O problema pode ser

O armazenamento automático está ativado.

O que você precisa tentar

Reiniciar para excluir tabelas temporárias não reduz o tamanho do armazenamento automaticamente.


Os dados estão sendo excluídos automaticamente

Você percebe que os dados estão sendo excluídos automaticamente em intervalos regulares.

O problema pode ser

Provavelmente, um script está sendo executado em algum lugar no seu ambiente.

O que você precisa tentar

Procure nos registros próximos ao 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.

O problema pode ser

  1. Outra operação está em andamento.
  2. O aviso INSTANCE_RISKY_FLAG_CONFIG é acionado sempre que pelo menos uma sinalização beta é usada.

O que você deve tentar

  1. As operações do Cloud SQL não são executadas simultaneamente. Aguarde a conclusão da outra operação.
  2. Remova as configurações de sinalização arriscadas e reinicie a instância.

O sistema está travado devido ao grande tamanho dos dados temporários

O sistema está travado devido ao grande tamanho dos dados temporários.

O problema pode ser

O sistema pode criar muitas tabelas temporárias de uma só vez, dependendo das consultas e da carga.

O que você precisa tentar

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

Você verá a mensagem de erro ERROR_INTERNAL_FATAL ao fazer upgrade dos recursos na instância.

O problema pode ser

Há muitas causas possíveis.

O que você deve tentar

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

A instância trava na reinicialização quando acaba o espaço em disco

O problema pode ser

O recurso de aumento automático de armazenamento não está ativado.

O que você precisa tentar

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

Você quer saber se o suporte ao cliente do Cloud SQL pode ajudar quando uma instância principal local está paralisada.

O problema pode ser

A instância não está no Cloud SQL.

O que você precisa tentar

O suporte ao cliente do Cloud SQL não pode ajudar com instâncias que não estão no Cloud SQL.


Desligamento lento na reinicialização

Desligamento lento na reinicialização.

O problema pode ser

Quando uma instância é encerrada, todas as conexões pendentes que não são encerradas em até 60 segundos produzirão erros no desligamento.

O que você precisa tentar

Com apenas conexões que duram menos de 60 segundos, a maioria dos desligamentos com erros pode ser evitada, incluindo conexões do 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.


Acesso negado para o usuário

Você vê a mensagem de erro Access denied for user 'XXX'@'XXX' (using password: XXX).

O problema pode ser

Há várias causas possíveis, incluindo:

  • o nome de usuário (ou senha) está incorreto;
  • o usuário está se conectando de algo diferente de @XXX;
  • o usuário não tem os privilégios corretos para o banco de dados a que está tentando se conectar.

O que você precisa tentar

  • Verifique o nome de usuário e a senha correspondente
  • Verifique a origem da conexão para ver se ela corresponde a onde o usuário recebeu privilégios de acesso.
  • Verifique os privilégios de concessão do usuário no banco de dados.

Não é possível excluir o usuário

Não é possível excluir um usuário do banco de dados.

O problema pode ser

O usuário tem objetos no banco de dados que dependem dele. Primeiro, você precisa descartar esses objetos ou reatribuí-los a outro usuário.

O que você precisa tentar

Descubra quais objetos dependem do usuário e, em seguida, deixe ou reatribua esses objetos para outro usuário. Este artigo discute como encontrar os objetos de propriedade do usuário.


Não é possível atribuir um endereço IP particular a uma instância atual em uma VPC compartilhada

Não é possível atribuir um endereço IP privado a uma instância atual em uma VPC compartilhada.

O problema pode ser

Isso acontece porque, quando uma instância do Cloud SQL é criada, ela é automaticamente anexada a um projeto de locatário, assim como todas as instâncias do Cloud SQL nesse mesmo projeto. No entanto, quando a instância criada usa IP particular em uma VPC compartilhada, ela é anexada ao projeto de locatário associado ao projeto host da VPC compartilhada.

O que você precisa tentar

Crie uma nova instância do Cloud SQL para substituir a atual.


Consultas específicas lentas

O uso da CPU está consistentemente alto.

O problema pode ser

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.

O que você precisa tentar

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:

  • Se você ativar a sinalização long_query_time, será possível verificar os registros de consultas lentas. Acesse a página do Explorador de registros do projeto e execute uma consulta como esta:
    resource.type="cloudsql_database"
    resource.labels.database_id="INSTANCE-ID"
    log_name="projects/PROJECT-ID/logs/cloudsql.googleapis.com%2Fmysql-slow.log"
        
  • 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 falha e informa Out of memory, mas os gráficos do Console ou do Cloud Monitoring parecem mostrar que ainda há memória.

O problema pode ser

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.

O que você precisa tentar

Garanta que a instância terá sobrecarga suficiente para suportar a carga de trabalho e uma possível sobrecarga extra.


Como recuperar uma instância excluída

Não é possível cancelar a exclusão de uma instância, seja ela proposital ou acidental.

O problema pode ser

Ao excluir uma instância, todos os dados contidos nela são perdidos permanentemente, inclusive backups.

O que você deve tentar

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.