Como diagnosticar problemas nas instâncias do Cloud SQL

Esta página contém uma lista dos problemas mais frequentes que você encontra ao trabalhar com instâncias do Cloud SQL, bem como as etapas que você pode seguir para resolvê-los. Leia também a página Problemas conhecidos. Consulte a Visão geral do suporte para mais assistência, caso seus problemas não sejam resolvidos.

Como visualizar registros

Para informações sobre operações recentes, consulte os registros de operação da instância do Cloud SQL ou os 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

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

Se você vir erros que contêm "Aborted connection nnnn to db:", isso geralmente indica que seu aplicativo não está encerrando as conexões corretamente. Ele também pode ser causado por problemas de rede. Esse erro não significa que há problemas com sua instância do Cloud SQL.

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

Verifique 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 GCP 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.

No caso das instâncias de primeira geração, também é necessário verificar a data de expiração dos certificados do cliente, exibida na página Conexões. Caso os certificados tenham expirado, crie certificados do cliente novos antes de se conectar à instância usando SSL.

Verificar se você está autorizado a se conectar

Caso não esteja conseguindo se conectar, verifique sua autorização:

  • Se você estiver se conectando pelo ambiente padrão do App Engine a uma instância de primeira geração, verifique se o aplicativo do App Engine está autorizado a se conectar à instância do Cloud SQL.
  • 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. Aqui está seu endereço IP atual.
  • Use gcloud sql connect para se conectar à instância. Com ele, o endereço IP é autorizado por um curto período de tempo. Você pode executá-lo em um ambiente com o Cloud SDK e o cliente mysql instalados. Você também pode executar esse comando no Cloud Shell, disponível no console do Google Cloud Platform e que tem o Cloud SDK 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. Dessa forma, o seu cliente pode se conectar.

Verificar 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.

Determinar como as conexões estão sendo iniciadas

Você pode ver informações sobre as conexões atuais executando o comando abaixo:

SHOW PROCESSLIST;

As conexões que mostram um endereço IP, como 1.2.3.4, conectam-se usando IP, já aquelas com cloudsqlproxy~1.2.3.4 usam o Cloud SQL Proxy ou foram originadas do App Engine. As conexões de localhost geralmente são feitas a uma instância de primeira geração do App Engine, embora esse caminho também seja usado por alguns processos internos do Cloud SQL.

Entender 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 ver mais informações, consulte Como gerenciar conexões de banco de dados.

Exibir conexões e threads

Se você receber a mensagem de erro "too many connections" ou quiser saber o que está acontecendo em uma instância, é possível exibir o número de conexões e threads com o comando SHOW PROCESSLIST.

Em um cliente MySQL, execute:

mysql> SHOW PROCESSLIST;
+----+-----------+--------------+-----------+---------+------+-------+----------------------+
| 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)

Para informações sobre como interpretar as colunas retornadas pelo comando PROCESSLIST, consulte a referência do MySQL.

Para receber uma contagem rápida de threads use:

mysql> SHOW STATUS WHERE Variable_name = 'Threads_connected';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 7     |
+-------------------+-------+
1 row in set (0.08 sec)

Conexões pelo Compute Engine

Se você espera que as conexões entre as instâncias do Compute Engine e do Cloud SQL incluam conexões com inatividade de longa duração, saiba que as conexões com uma instância do Compute Engine expiram após 10 minutos de inatividade. Para mais informações, consulte Rede e firewalls na documentação do Compute Engine.

Para manter ativas as conexões com inatividade de longa duração, configure o TCP keepalive. Os comandos a seguir definem o valor TCP keepalive para um minuto e tornam a configuração permanente em reinicializações de instância.

# Display the current tcp_keepalive_time value.
cat /proc/sys/net/ipv4/tcp_keepalive_time

# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

# Apply the change.
sudo /sbin/sysctl --load=/etc/sysctl.conf

# Display the tcp_keepalive_time value to verify the change was applied.
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. Visite o site ipv6.google.com para verificar se o IPv6 está funcionando na estação de trabalho. Se o site não carregar, isso será sinal de que o IPv6 não está disponível. Para corrigir isso, 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. Conexões de qualquer IP dentro do intervalo 172.17.0.0/16 para instâncias do Cloud SQL usando um IP particular falharão. Da mesma forma, as instâncias do Cloud SQL criadas com um IP nesse intervalo serão inacessíveis. Esse intervalo é reservado para a rede de ponte do docker.

Problemas da instância

Backup

Os backups para instâncias de Primeira geração podem falhar se houver mais de 10.000 tabelas de banco de dados. Para garantir o melhor desempenho, mantenha um número razoável de tabelas.

Importar e exportar

As importações e exportações no Cloud SQL são as mesmas de quando se usa o utilitário mysqldump. Porém, com o recurso de importação e exportação do Cloud SQL, você transfere dados usando um intervalo do Cloud Storage. É possível importar e exportar um banco de dados, todos os bancos de dados de instância ou dados selecionados no formato CSV.

As importações e as exportações para o Cloud SQL usando-se a funcionalidade de importação (por meio de um intervalo do Cloud Storage) podem demorar para serem concluídas, dependendo do tamanho do banco de dados. Isso pode ter os seguintes impactos:

  • Em instâncias de primeira geração, as operações estão limitadas a 24 horas.
  • Não é possível interromper uma operação de longa duração.

Além disso, é possível executar somente uma operação de importação ou exportação por vez para cada instância.

É possível diminuir o tempo exigido para cada operação utilizando uma das seguintes estratégias:

  • Use a funcionalidade de importação ou exportação do Cloud SQL com lotes de dados menores, que levarão menos de 24 horas para serem concluídos.

  • Em vez de usar a funcionalidade de importação ou exportação do Cloud SQL, reproduza de novo um arquivo de despejo diretamente no Cloud SQL. Por exemplo, é possível usar a ferramenta cloudsql-import, que faz a importação reproduzindo novamente um arquivo mysqldump em uma conexão MySQL. O cloudsql-import é resiliente em caso de falhas na conexão e reinicializações de instâncias.

Outros fatores a considerar durante a importação:

  • Se a importação estiver falhando, isso poderá ser por causa de um erro de falta de memória (OOM, na sigla em inglês). Se esse for o caso, você poderá tentar adicionar os parâmetros --extended-insert=FALSE --complete- insert. Isso reduz a velocidade da importação, mas também a quantidade de memória obrigatória.

Espaço em disco

Se a sua instância atingir o armazenamento máximo permitido, as gravações no banco de dados não serão feitas. Se você excluir dados, por exemplo, eliminando uma tabela, o espaço liberado não será refletido no Armazenamento usado relatado da instância. Confira a perguntas frequente Como recuperar o espaço de uma tabela eliminada? para ver uma explicação sobre esse comportamento.

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 eliminadas. O tempo fornecido ao mysqld para o encerramento é limitado a um minuto. Se o encerramento não for concluído nesse período, o processo mysqld será finalizado 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 de segunda geração, já que é mais resistente à corrupção de dados do que outros mecanismos de armazenamento do 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 diferente do InnoDB, por exemplo, ENGINE = MyISAM, a tabela não será criada. Além disso, você verá uma mensagem de erro como o exemplo a seguir:

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

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

O InnoDB é altamente recomendável para instâncias de primeira geração, pois garante uma maior consistência de dados.

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 do mysql. Por exemplo, mysql.user e mysql.db. Essas tabelas são vulneráveis a encerramentos "não limpos". Por isso, você deve emitir o comando FLUSH CHANGES depois de fazer qualquer alteração nelas. Em caso de corrupção de dados do MyISAM, os comandos CHECK TABLE e REPAIR TABLE podem ser usados para retornar ao estado anterior sem salvar os dados.

Identificadores de Transações Globais (GTID)

Todas as instâncias de segunda geração têm GTID habilitado 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 com um servidor MySQL habilitado para GTID:

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

Se você usar uma operação transacional não segura, verá uma mensagem de erro como o exemplo a seguir:

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

Como trabalhar com acionadores e funções armazenadas

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

Estado suspenso

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

  • 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 um projeto acessando a página de faturamento no Console do Google Cloud Platform, selecionando o projeto e vendo as informações da conta de faturamento. Depois de resolver o problema de faturamento, a instância retornará ao status executável dentro de algumas horas.

  • problemas jurídicos

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

  • problemas operacionais

    Por exemplo, se uma instância ficar presa em um ciclo de falha, ou seja, falhar na inicialização ou assim que for inicializada, o Cloud SQL poderá suspendê-la.

Enquanto uma instância estiver suspensa, você poderá continuar a visualizar informações sobre ela ou excluí-la se a suspensão tiver sido acionada por problemas de cobrança.

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 seguir a orientação acima e visitar o fórum google-cloud-sql.

Desempenho

Ativar registros de consulta

Para ajustar o desempenho das suas consultas, configure o Cloud SQL para registrar consultas lentas com a inclusão das sinalizações de bancos de dados --log_output='FILE' e --slow_query_log=on para a instância. Isso disponibiliza a saída de registro pelo visualizador de registros no Console do Google Cloud Platform. Observe que cobranças do Stackdriver Logging são aplicáveis.

Não defina log_output como TABLE. Isso pode causar problemas de conexão, conforme descrito 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 MySQL Client para receber os resultados da monitoração 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.

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

As tabelas de banco de dados consomem recursos do sistema. Um número muito elevado pode afetar o desempenho e a disponibilidade da instância, bem como resultar na perda da cobertura do SLA. Saiba mais.

Dicas de desempenho geral

  • As instâncias de primeira geração limitam o espaço temporário usado pelas operações do SQL a 10 GB. Algumas operações, por exemplo, grandes agregações com GROUP BY, podem ser afetadas por esse limite. Em alguns casos, você pode evitar atingir o limite de espaço temporário escrevendo a consulta de forma diferente ou usando outra sintaxe SQL. Instâncias de segunda geração não impõem esse limite.
  • Confirme que o tipo de máquina usado é suficientemente grande para a carga de trabalho.

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

  • Em instâncias de primeira geração, a replicação do sistema de arquivos é muito mais rápida no modo assíncrono, que é uma configuração da instância, do que no modo síncrono. Se estiver usando o modo síncrono, e seu aplicativo puder suportar alguns riscos de dados, você precisa alternar para o modo assíncrono.
  • 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 cache é extremamente importante para o desempenho da leitura. Compare o tamanho do conjunto de dados com a capacidade RAM da instância. Idealmente, todo o conjunto de dados precisa caber em 70% da capacidade RAM da instância. Nesse caso, as consultas não serão restritas ao desempenho de E/S. Se esse não for o caso, considere aumentar o tamanho do nível da sua instância.
  • Se a carga de trabalho consiste em consultas que usam intensamente a CPU como funções de classificação, regexes e outras funções complexas, a instância fica limitada. Aumente o nível.
  • Verifique o local do leitor e banco de dados. A latência afeta o desempenho de leitura mais do que o desempenho de gravação.
  • Investigue melhorias específicas de desempenho não relacionadas ao Cloud SQL, por exemplo, adicionar indexação apropriada, reduzir dados digitalizados e evitar ciclos extras.

Caso você observe um baixo desempenho na execução de consultas, use EXPLAIN para identificar onde é possível:

  • adicionar índices a tabelas e melhorar o desempenho da consulta. Por exemplo, certifique-se de que todos os campos usados como uma chave JOIN tenham um índice em ambas as tabelas;

  • melhorar as operações ORDER BY. Se EXPLAIN exibir "Using temporary; Using filesort" na coluna Extra da saída, os resultados intermediários serão armazenados em um arquivo que será classificado depois, o que geralmente resulta em desempenho ruim. 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.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Cloud SQL para MySQL