Solução de problemas do Cloud SQL para MySQL

Os tópicos desta página incluem:

Se você estiver procurando informações sobre mensagens de erro específicas, verifique a página mensagens de erro.

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 um 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.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
  • 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.
Não é possível fazer um backup depois que uma instância é excluída. O período de carência para uma limpeza de instância do Cloud SQL é de quatro dias, com exceção das réplicas de leitura, que são limpas imediatamente. Durante esse período, o suporte ao cliente pode recriar a instância. Depois que as instâncias são removidas, não é possível recuperar dados.

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. Apenas sete backups são mantidos. Os backups são removidos regularmente devido ao custo e ao tamanho da retenção de backups. Infelizmente, isso significa que os backups visíveis atualmente 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 falhou e você vê uma mensagem de Unknown error. A operação de backup pode ter expirado.

Há duas sinalizações que influenciam a criação de backup: checkpoint_timeout e checkpoint_completion_target. No início do backup, um checkpoint slow é executado e usa checkpoint_completion_target multiplicado por checkpoint_timeout.

Por exemplo, 900 sec * 0.9 sec = 810 sec = 13.5 min

Por isso, o tempo limite é atingido. Diminuir o valor de checkpoint_completion_target corrige o problema nesse caso.

Um backup automático falhou e você não recebeu uma notificação por e-mail. As notificações não são compatíveis com falhas no backup.

Quando um backup automático falha, uma mensagem de Operation error é exibida na página Details da instância do Cloud SQL.

É possível encontrar o status de um backup usando a API REST ou os comandos da gcloud. Por exemplo, primeiro liste os backups de uma instância e, em seguida, descreva um backup específico pelo ID:


gcloud sql backups list \
--project=PROJECT_ID \
--instance=INSTANCE_ID
   

gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
    

Clonagem

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.

Conectividade

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.

Combinar esses métodos ajuda a reduzir a limitação.

Como criar instâncias

Problema Solução de problemas
Você receberá a 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.
  • Você está tentando criar instâncias do MySQL ou do SQL Server e do PostgreSQL na mesma conexão de serviço particular no projeto host da VPC. O MySQL e o SQL Server podem compartilhar a mesma conexão de serviço. O PostgreSQL requer uma conexão de serviço própria.
  • Você está tentando criar instâncias na mesma conexão de serviço particular em regiões diferentes, o que não é compatível.

Em cada um dos cenários acima, é possível optar por expandir o intervalo de IP alocado atual ou alocar outro intervalo de IP para a conexão de serviço particular.

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
    

Exportar

Problema Solução de problemas
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.

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.

Principal externo

Clique nos links da tabela para ver detalhes:

Problema Solução de problemas
Lost connection to MySQL server during query when dumping table A origem pode ter ficado indisponível ou o dump continha pacotes muito grandes.

Verifique se a principal externa está disponível para conexão ou use mysqldump com a opção max_allowed_packet.

Para saber mais sobre como usar sinalizações mysqldump para migração de importação gerenciada, consulte Sinalizações de sincronização inicial permitidas e padrão

A migração inicial dos dados foi bem-sucedida, mas nenhum dado está sendo replicado. Uma possível causa raiz pode ser sinalizações de replicação definidas pelo banco de dados de origem, o que faz com que algumas ou todas as alterações do banco de dados não sejam replicadas.

Verifique se as sinalizações de replicação, como binlog-do-db, binlog-ignore-db, replicate-do-db ou replicate-ignore-db não estão definidas de maneira conflitante.

Execute o comando show master status na instância principal para ver as configurações atuais.

A migração inicial de dados foi bem-sucedida, mas a replicação de dados deixa de funcionar após um tempo. O que tentar

  • Verifique as métricas de replicação da instância de réplica na seção Cloud Monitoring do Console do Google Cloud.
  • Os erros da linha de execução de E/S do MySQL ou do SQL podem ser encontrados no Cloud Logging nos arquivos mysql.err log.
  • O erro também pode ser encontrado ao se conectar à instância da réplica. Execute o comando SHOW SLAVE STATUS e verifique os seguintes campos na saída:
    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error
mysqld check failed: data disk is full O disco de dados da instância da réplica está cheio.

Aumente o tamanho do disco da instância de réplica. Aumente o tamanho do disco manualmente ou ative o aumento automático de armazenamento.

Réplica externa

Problema Solução de problemas
Mensagem de erro: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires A instância principal do Cloud SQL tem backups automáticos e registros binários, e a recuperação pontual está ativada. Por isso, ela precisa ter registros suficientes para que a réplica possa acompanhar. No entanto, nesse caso, embora os registros binários existam, a réplica não sabe em qual linha começar a leitura.

Crie um novo arquivo dump usando as configurações de sinalização corretas e configure a réplica externa usando esse arquivo.

  1. Conecte-se ao cliente mysql por uma instância do Compute Engine.
  2. Execute o mysqldump e use as sinalizações --master-data=1 e --flush-privileges.

    Importante: não inclua a sinalização --set-gtid-purged=OFF.

    Saiba mais.

  3. Verifique se o arquivo dump criado contém a linha SET @@GLOBAL.GTID_PURGED='...'.
  4. Faça upload do arquivo dump para um bucket do Cloud Storage e configure a réplica usando o arquivo dump.

Sinalizações

Problema Solução de problemas
Após a ativação de uma sinalização, a instância fica alternando entre pânico e falha. Entre em contato com o suporte ao cliente para solicitar a remoção de uma sinalização, seguida de um hard drain. Isso força a instância a reiniciar em um host diferente com uma nova configuração sem a sinalização ou a configuração não pretendida.
Você verá a mensagem de erro Bad syntax for dict arg ao tentar definir uma sinalização. Valores de parâmetro complexos, como listas separadas por vírgulas, exigem tratamento especial quando usados com comandos gcloud.
O fuso horário não muda automaticamente. As alterações automáticas de fuso horário não estão disponíveis no Cloud SQL para MySQL e precisam ser feitas manualmente, e não por string, mas por valor de ajuste de fuso horário.

Edite a instância para alterar a sinalização default_time_zone. As áreas de nome não são compatíveis. Exemplo:

Europe/LondonLondres está no fuso horário UTC, que seria um valor compatível com +00:00 para a sinalização default_time_zone.

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

Uma operação de importação falha com um erro de que uma tabela não existe. As tabelas podem ter dependências de chave externa em outras tabelas e, dependendo da ordem das operações, pode ser que uma ou mais delas ainda não existam durante a operação de importação.

O que tentar

Adicione a seguinte linha no início do arquivo dump:


SET FOREIGN_KEY_CHECKS=0;
  

Além disso, adicione esta linha ao final do arquivo dump:


SET FOREIGN_KEY_CHECKS=1;
  

Essas configurações desativam as verificações de integridade de dados enquanto a operação de importação está em andamento e as reativam após o carregamento dos dados. Isso não afeta a integridade dos dados no banco de dados porque eles já foram validados durante a criação do arquivo dump.

Logging

Problema Solução de problemas
A geração de registros está usando CPU e memória demais 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 pessoal (PII, na sigla em inglês) e detalhadas sejam registradas.

A geração de registros está usando muito espaço em disco. Há três tipos de arquivos de registros que usam espaço em disco: refazer, gerais e binários.

Conecte-se ao banco de dados e execute estes comandos para ver detalhes sobre cada tipo:


SHOW VARIABLES LIKE 'innodb_log_file%';

SELECT ROUND(SUM(LENGTH(argument)/POW(1024,2),2)
AS GB from mysql.general_log;

SHOW BINARY LOGS;
    
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 text \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
> downloaded-log.txt
   

Como gerenciar instâncias

Problema Solução de problemas
Desempenho lento após a reinicialização do MySQL. 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 ter os dados. Como resultado, as consultas podem ficar mais lentas do que o esperado até que o cache seja preenchido.
Recuperação lenta de falhas. Um general_log grande pode ter se acumulado. É possível reduzir o tempo de recuperação de falhas impedindo que um general_log grande fique 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. Por exemplo, você percebe que seu banco de dados está usando apenas três GB, mas o armazenamento diz que 14 GB estão sendo usados. A maior parte do espaço não usado por tabelas é usada por registros binários e/ou arquivos temporários.

O que 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;
  • Se necessário, também é possível truncar suas tabelas de registros usando a API. Para mais informações, consulte a página de referência instances.truncateLog.
  • Saiba mais sobre como definir e configurar registros de consulta lenta.
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.

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 registros binários manualmente. Os registros binários não podem ser excluídos manualmente. Eles são excluídos automaticamente com o backup automático associado, o que geralmente ocorre após sete dias.
Você quer encontrar informações sobre arquivos temporários. Um arquivo chamado ibtmp1 é usado para armazenar dados temporários. Esse arquivo é redefinido após a reinicialização do banco de dados. Para encontrar informações sobre o uso de arquivos temporários, conecte-se ao banco de dados e execute a seguinte consulta:

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

Você quer saber mais sobre os tamanhos das tabelas. Essas informações estão disponíveis no banco de dados.

Conecte-se ao banco de dados e execute a seguinte 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. A instância provavelmente falhou porque as consultas estão criando conexões em excesso.

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

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. 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 um lote no disco.

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

Este artigo 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:

  • 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"
          

    É possível fazer o download dos registros no formato JSON ou TEXT para processamento local.

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

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

Alterar sinalizações paralelas de replicação resulta em um erro. Um valor incorreto é definido para uma ou mais dessas sinalizações.

Na instância principal exibindo a mensagem de erro, defina as sinalizações de replicação paralela:

  1. Modifique as sinalizações binlog_transaction_dependency_tracking e transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Adicione a sinalização slave_pending_jobs_size_max:

    slave_pending_jobs_size_max=33554432

  3. Modifique a sinalização transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. Modifique a sinalização binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET

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.