Resolver problemas

Execute o comando gcloud sql operations list para listar todas as operações da instância do Cloud SQL especificada.

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

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

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

Se você tiver feito uma operação de exportação, crie uma nova instância e faça uma operação de importação para recriar o banco de dados. As exportações são gravadas no Cloud Storage e as importações são lidas de lá.

Se você realmente precisa cancelar a operação, peça ao suporte ao cliente para aplicar force restart à instância.

Crie os usuários do banco de dados antes de restaurar do dump SQL.

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.

Você está tentando cancelar uma operação de importação ou exportação que foi concluída, falhou ou cancelada. Se a operação estiver em execução, será possível cancelá-la.

O Cloud SQL não é compatível com o cancelamento da operação porque ela tem um tipo de operação diferente de IMPORT ou EXPORT.

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

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.

Você está tentando usar o console do Google Cloud para clonar uma instância com um endereço IP particular, mas não especificou o intervalo de IP alocado que pretende usar e a instância de origem não foi criada com o intervalo especificado. Como resultado, a instância clonada é criada em um intervalo aleatório.

Use gcloud para clonar a instância e fornecer um valor para o parâmetro
--allocated-ip-range-name. Para mais informações, consulte Como clonar uma instância com um IP particular.

• Instabilidade de rede.
• Nenhuma resposta aos comandos de sinal de atividade do TCP (o cliente ou o servidor não é responsivo, possivelmente sobrecarregado)
• A vida útil da conexão do mecanismo de banco de dados foi excedida e o servidor encerra a conexão.

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

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

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

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

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

Para gerar os certificados novamente, recrie-os.

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

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

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

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

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

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=OLD_RESERVED_RANGE_NAME,NEW_RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID \
--force
    

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

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

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

gcloud services vpc-peerings update \
--service=servicenetworking.googleapis.com \
--ranges=RESERVED_RANGE_NAME \
--network=VPC_NETWORK \
--project=PROJECT_ID
    

Use exportações de CSV para exportar apenas o que você precisa.

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.

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

Verifique se a instância principal externa está disponível para conexão. Também é possível modificar os valores das sinalizações net_read_timeout e net_write_timeout na instância de origem para interromper o erro. Para mais informações sobre os valores permitidos para essas sinalizações, consulte Configurar sinalizações do banco de dados.

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

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.

• 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

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.

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.

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

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.

Crie os usuários do banco de dados antes de importar.

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.

Por exemplo, um usuário foi excluído, mas não é possível descobrir quem fez isso. Os registros mostram que a operação foi iniciada, mas não fornecem mais informações. Você precisa ativar o registro de auditoria para que informações de identificação detalhadas e pessoais (PII, na sigla em inglês) sejam registradas.

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;
    

Para fazer o download dos registros como JSON:

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json
    

Para fazer o download dos registros como TEXT:

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt
   

Para descobrir o tamanho dos registros gerais, conecte-se ao banco de dados e execute esta consulta:

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

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.

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

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;

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

1. Verifique o status do endpoint.

   gcloud

   Para verificar o status, use o comando
   gcloud compute forwarding-rules describe.

   gcloud compute forwarding-rules describe ENDPOINT_NAME \
   --project=PROJECT_ID \
   --region=REGION_NAME \
   | grep pscConnectionStatus

   Faça as seguintes substituições:

   • ENDPOINT_NAME: o nome do endpoint.
   • PROJECT_ID: o ID ou número do projeto do Google Cloud que contém o endpoint
   • REGION_NAME: o nome da região do endpoint

   REST

   Antes de usar os dados da solicitação abaixo, faça as substituições a seguir:

   • PROJECT_ID: o ID ou número do projeto do Google Cloud que contém o endpoint do Private Service Connect
   • REGION_NAME: o nome da região.
   • ENDPOINT_NAME: o nome do endpoint.

   Método HTTP e URL:

   GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME

   Para enviar a solicitação, expanda uma destas opções:

   curl (Linux, macOS ou Cloud Shell)

   execute o seguinte comando:

   curl -X GET \
        -H "Authorization: Bearer $(gcloud auth print-access-token)" \
        "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME"

   PowerShell (Windows)

   execute o seguinte comando:

   $cred = gcloud auth print-access-token
   $headers = @{ "Authorization" = "Bearer $cred" }
   
   Invoke-WebRequest `
       -Method GET `
       -Headers $headers `
       -Uri "https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME" | Select-Object -Expand Content

   Você receberá uma resposta JSON semelhante a esta:

   {
     "kind": "compute#forwardingRule",
     "id": "ENDPOINT_ID",
     "creationTimestamp": "2024-05-09T12:03:21.383-07:00",
     "name": "ENDPOINT_NAME",
     "region": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME",
     "IPAddress": "IP_ADDRESS",
     "target": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/serviceAttachments/SERVICE_ATTACHMENT_NAME",
     "selfLink": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME",
     "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
     "serviceDirectoryRegistrations": [
       {
         "namespace": "goog-psc-default"
       }
     ],
     "networkTier": "PREMIUM",
     "labelFingerprint": "LABEL_FINGERPRINT_ID",
     "fingerprint": "FINGERPRINT_ID",
     "pscConnectionId": "CONNECTION_ID",
     "pscConnectionStatus": "ACCEPTED",
     "allowPscGlobalAccess": true
   }
   

2. Verifique se o status do endpoint é ACCEPTED. Se o status for PENDING, a instância não está permitindo o projeto do Google Cloud que contém o endpoint. Verifique se o projeto de rede em que o endpoint foi criado é permitido. Para mais informações, consulte Editar uma instância com o Private Service Connect ativado.

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.

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.

Reinicie a instância da réplica para recuperar o espaço de memória temporário.

Edite a instância para ativar automatic storage increase.

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

• Configure a replicação paralela.
• Defina a sinalização innodb_flush_log_at_trx_commit na réplica de leitura como 2.

  Para mais informações, consulte Dicas para trabalhar com sinalizações.

• Editar a instância para aumentar o tamanho da réplica.
• Reduza a carga no banco de dados.
• Envia o tráfego de leitura para a réplica de leitura.
• Inclua as tabelas em um índice.
• Identifique e corrija consultas de gravação lentas.
• Recrie a réplica.

Para evitar uma transação longa, veja algumas soluções possíveis:

• Dividir a transação em várias transações pequenas
• Divida uma única consulta de gravação grande em lotes menores
• Tente separar consultas de SELECT longas de uma transação combinada com DMLs.

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

Recrie a réplica depois de interromper todas as consultas em execução.