Solução de problemas do Cloud SQL para MySQL

Os tópicos desta página incluem:

Backup e recuperação

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Não é possível ver o status atual da operação. A interface do usuário mostra apenas sucesso ou falha. Use estes comandos do banco de dados para saber mais.
Não é possível encontrar o criador da operação. A interface do usuário não mostra quem iniciou uma operação. Use o registro de auditoria para descobrir.
Sem espaço em disco durante o backup automatizado. A instância atingiu os limites de espaço do disco rígido. Verifique o tamanho e a cota do sistema de arquivos.
Não é possível fazer backup após a instância ser excluída. A instância foi excluída. Recrie de uma exportação ou entre em contato com o suporte ao cliente se estiver dentro do período de carência.
O backup automatizado parece travado. O tempo de backup está correlacionado ao tamanho do banco de dados. Entre em contato com o suporte ao cliente se você realmente precisar cancelar a operação.
Falha na restauração. O arquivo dump pode conter usuários de banco de dados que ainda não existem. Crie os usuários do banco de dados antes de restaurar.
A operação não é válida para esta instância. O tamanho da instância de destino é menor que a origem. Aumente o tamanho da instância de destino.
Aumente o número de dias que backups automáticos precisam ser mantidos. Apenas sete backups automáticos são mantidos. Gerencie seus próprios backups manuais.
Erro desconhecido de falha do backup É possível que o backup tenha expirado. Marque estas sinalizações.
Nenhuma notificação sobre falha no backup. As notificações não são compatíveis com falhas no backup. Use a API REST ou os comandos da gcloud para verificar o status de um backup.

Não é possível ver o status atual da operação

Não é possível ver o status de uma operação no Console do Google Cloud.

O problema pode ser

O Console do Google Cloud informa apenas o sucesso ou falha no momento da conclusão e não foi projetado para retornar avisos.

O que você pode tentar

Conecte-se ao banco de dados e execute SHOW WARNINGS.


Não é possível encontrar o criador da operação

Você quer descobrir quem emitiu uma operação de backup sob demanda.

O problema pode ser

A página de operações da instância no Console do Google Cloud não mostra quem iniciou uma operação.

O que você pode tentar

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 registros relevantes são os seguintes:

  • cloudsql.googlapis.com/mysql-general.log
  • cloudsql.googleapis.com/mysql.err
  • cloudaudit.googleapis.com/activity também pode estar disponível, caso os Cloud Audit Logs estejam ativados.


Sem espaço em disco durante o backup automatizado

Você vê a mensagem de erro [ERROR] InnoDB: Write to file ./ibtmp1 failed at offset XXXX, YYYY bytes should have been written, only 0 were written..

Possível problema

A instância atingiu um limite absoluto durante um backup automatizado. Os arquivos temporários podem se expandir além do espaço em disco disponível durante um backup.

O que você pode tentar

Verifique se o disco não está cheio ou com cota de disco insuficiente. Aumente o tamanho do disco manualmente ou ative o aumento automático de armazenamento.


Não é possível fazer backup após a instância ser excluída

Não é possível fazer um backup depois de excluir a instância.

O problema pode ser

A instância foi excluída.

O que você pode tentar

  • O período de carência para uma limpeza de instância do Cloud SQL é de quatro dias. 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 exportação, crie uma nova instância e faça uma 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 está paralisado

O backup automático fica paralisado por muitas horas e não pode ser cancelado.

O problema pode ser

Os backups podem levar muito tempo, dependendo do tamanho do banco de dados.

O que você pode tentar

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


Falha na restauração do backup

Uma operação de restauração pode falhar quando um ou mais usuários referenciados no arquivo dump SQL não existem.

O problema pode ser

Antes de restaurar um despejo 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. Caso contrário, a restauração não recriará os objetos com a propriedade e/ou as permissões originais.

O que você pode tentar

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


A operação não é válida para esta instância

Você vê a mensagem de erro HTTP Error 400: This operation isn't valid for this instance de uma chamada de API para instances.restoreBackup.

O problema pode ser

Não é possível restaurar de um backup de uma instância com um tamanho de armazenamento (XX GB) menor que o tamanho de backup (YY GB).

O que você pode tentar

Edite a instância de destino para aumentar o tamanho de armazenamento dela.


Aumentar o número de dias que backups automáticos precisam ser mantidos

Você quer aumentar o número de dias em que pode manter backups automáticos, de sete para 30 dias ou mais.

O problema pode ser

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.

O que você pode tentar

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.


Erro desconhecido de falha do backup

O backup falhou e você vê Unknown error.

Possível problema

A criação do backup atingindo o tempo limite.

O que você pode tentar

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.

Nenhuma notificação sobre falha no backup

Um backup automático falhou e você não recebeu uma notificação por e-mail.

Possível problema

As notificações não são compatíveis com falhas no backup.

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

O que você pode tentar

É 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 --project=PROJECT_ID backups list --instance=INSTANCE_ID
gcloud sql --project=PROJECT_ID backups describe BACKUP-ID --instance=INSTANCE_ID

Clonagem

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Ocorreu uma falha na clonagem com um erro constraints/sql.restrictAuthorizedNetworks. Bloqueado pela configuração de redes autorizadas. Tente uma destas opções.

Ocorreu uma falha na clonagem com um erro constraints/sql.restrictAuthorizedNetworks

Ocorreu uma falha na clonagem com um erro constraints/sql.restrictAuthorizedNetworks.

Possível problema

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.

O que você pode tentar

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

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Aborted connection. Erro ao ler pacotes ou conexão cancelada. Veja aqui o que você pode tentar.
Erros Unauthorized to connect. Há muitas causas possíveis. Veja aqui o que você pode tentar.
Falha na associação de rede. Service Networking API não está ativado no projeto. Ative o Service Networking API no projeto.
Remaining connection slots are reserved. O número máximo de conexões foi atingido. Aumente a sinalização max_connections.
Set Service Networking service account as servicenetworking.serviceAgent role on consumer project A conta de serviço da Service Networking não está vinculada ao papel servicenetworking.serviceAgent. Vincule a conta de serviço da Service Networking ao papel servicenetworking.serviceAgent.
error x509: certificate is not valid for any names, but wanted to match project-name:db-name Problema conhecido: no momento, o Cloud SQL Proxy Dialer não é compatível com o Go 1.15. Até que o problema seja resolvido, confira esta discussão no GitHub, que inclui uma solução alternativa.
Não é possível analisar certificados em alguns sistemas operacionais. Os clientes que usam bibliotecas x509 do mac OS 11.0 (Big Sur) podem não analisar alguns certificados de instâncias mysql. Isso pode ser exibido ao cliente como um erro genérico, como "cancelado". A solução alternativa é alternar o certificado do servidor e criar novamente os certificados do cliente.
Cannot modify allocated ranges in CreateConnection. Please use UpdateConnection Os peerings de VPC não são atualizados depois que um intervalo alocado é modificado ou removido. Consulte O que fazer e veja mais detalhes sobre a atualização de peering de VPC.
Allocated IP range not found in network Os peerings de VPC não são atualizados depois que um intervalo alocado é modificado ou removido. Consulte O que fazer e veja mais detalhes sobre a atualização de peering de VPC.
ERROR: (gcloud.sql.connect) It seems your client does not have ipv6 connectivity and the database instance does not have an ipv4 address. Please request an ipv4 address for this database instance. Você está tentando se conectar à sua instância de IP particular usando o Cloud Shell. A conexão do Cloud Shell a uma instância com apenas um endereço IP particular não é aceita atualmente.

Conexão cancelada

Você verá a mensagem de erro Got an error reading communication packets ou Aborted connection xxx to db: DB_NAME.

O problema pode ser

  • Instabilidade de rede.
  • Nenhuma resposta aos comandos de sinal de atividade 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 encerrou a conexão.

O que você pode tentar

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.


Sem autorização para se conectar

Você vê a mensagem de erro Unauthorized to connect.

O problema pode ser

Pode haver muitas causas, já que a autorização ocorre em muitos níveis.

  • No nível do banco de dados, o usuário do banco de dados precisa existir e a senha precisa corresponder.
  • No nível do projeto, é possível que o usuário não tenha as permissões corretas do IAM.
  • No nível do Cloud SQL, a causa pode depender de como você se conecta à instância. Se você estiver se conectando diretamente a uma instância pelo IP público, o IP de origem da conexão precisará estar na rede autorizada da instância.

    A conectividade IP particular é permitida por padrão, exceto quando você está se conectando a partir de um endereço não RFC 1918. Os endereços de clientes que não são RFC 1918 precisam ser configurados como redes autorizadas.

    Por padrão, o Cloud SQL não grava 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
    

    Se estiver se conectando pelo proxy do Cloud SQL Auth, verifique se as permissões do IAM estão configuradas corretamente.

  • No nível da rede, se a instância do Cloud SQL estiver usando IP público, o IP de origem da conexão precisa estar em uma rede autorizada.

O que você pode tentar

  • Confirme o nome de usuário e a senha.
  • Verifique os papéis e as permissões do IAM do usuário.
  • Se estiver usando IP público, verifique se a origem está nas redes autorizadas.

Falha na associação de rede

Você verá a mensagem de erro Error: Network association failed due to the following error: conceda o papel servicenetworking.serviceAgent à conta de serviço do Service Networking no projeto do consumidor.

O problema pode ser

A Service Networking API não está ativada no projeto.

O que você pode tentar

Ative a Service Networking API no seu projeto. Se você vir esse erro ao tentar atribuir um endereço IP particular a uma instância do Cloud SQL e estiver usando uma VPC compartilhada, também será necessário ativar a Service Networking API para o projeto host.


Os slots de conexão restantes estão reservados

Você vê a mensagem de erro FATAL: remaining connection slots are reserved for non-replication superuser connections.

O problema pode ser

O número máximo de conexões foi atingido.

O que você pode tentar

Edite o valor da sinalização max_connections.


Defina a conta de serviço do Service Networking com o papel servicenetworking.serviceAgent no projeto do consumidor

Você vê a mensagem de erro set Service Networking service account as servicenetworking.serviceAgent role on consumer project..

Possível problema

A conta de serviço da Service Networking não está vinculada ao papel servicenetworking.serviceAgent.

O que você pode tentar

Para atenuar esse problema, use estes comandos da gcloud para vincular a conta de serviço da Service Networking ao papel servicenetworking.serviceAgent.

gcloud beta services identity create --service=servicenetworking.googleapis.com --project=PROJECT_ID
gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:service-PROJECT_NUMBER@service-networking.iam.gserviceaccount.com" --role="roles/servicenetworking.serviceAgent"

Erro x509: o certificado não é válido para nenhum nome

Você vê a mensagem de erro error x509: certificate is not valid for any names, but wanted to match project-name:db-name.

O problema pode ser…

Problema conhecido: no momento, o Cloud SQL Proxy Dialer não é compatível com o Go 1.15.

O que você pode tentar

Até que o bug seja corrigido, consulte esta discussão no GitHub, que inclui uma solução alternativa.


Não é possível analisar certificados em alguns sistemas operacionais

Quando você usa bibliotecas x509 do mac OS 11.0 (Big Sur), pode falhar em analisar os certificados de instâncias mysql. Isso pode ser um erro genérico, como "cancelado".

O que você pode tentar

O bug foi corrigido e as novas instâncias não enfrentarão esse problema. Para instâncias antigas que enfrentarem esse problema, rotacione o certificado do servidor e recrie os certificados do cliente.


Não é possível modificar intervalos alocados em CreateConnection. Use UpdateConnection

Você verá a mensagem de erro Cannot modify allocated ranges in CreateConnection. Please use UpdateConnection ou The operation "operations/1234" resulted in a failure "Allocated IP range 'xyz' not found in network.

O problema pode ser…

Você recebe o primeiro erro quando tenta fazer uma conexão novamente usando um intervalo reservado diferente.

Você verá o segundo erro quando o intervalo alocado for modificado, mas vpc-peerings não tiver sido atualizado.

O que você pode tentar

É necessário modificar a conexão particular. Use o seguinte comando e certifique-se de usar o argumento --force:

gcloud services vpc-peerings update --network=VPC_NETWORK --ranges=ALLOCATED_RANGES --service=servicenetworking.googleapis.com --force

Como criar instâncias

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Internal error. Não há conta de serviço da rede de serviço. Desative e reative o Service Networking API.
Falha na criação da instância do Terraform. Erro de configuração do Terraform. Inspecione e repare o arquivo de configuração do Terraform.
HTTP Error 409 no script do Terraform. Outra operação já está em andamento. Corrija o script do Terraform para aguardar a conclusão de cada operação.
Unknown error

A API Service Networking pode não estar ativada.

Talvez você esteja tentando criar uma instância com o mesmo nome de outra excluída recentemente.

Talvez você esteja tentando criar várias instâncias simultaneamente.

A criação da sub-rede pode ter falhado porque não havia mais endereços disponíveis no intervalo de IP.

Ative a API Service Networking.

Use um nome diferente para a instância ou aguarde uma semana após a instância ser excluída.

Crie instâncias consecutivas.

Veja outras mensagens de Erro desconhecido caso esta não corresponda ao seu caso.

Alocar novos intervalos.

Failed to create subnetwork Não há mais endereços disponíveis no intervalo de IP. Alocar novos intervalos.

Erro interno

Você vê a mensagem de erro {"ResourceType":"sqladmin.v1beta4.instance", "ResourceErrorCode":"INTERNAL_ERROR","ResourceErrorMessage":null}.

O problema pode ser

O projeto de serviço provavelmente não tem a conta de serviço da rede de serviço necessária para esse recurso.

O que você pode tentar

Para corrigir as permissões do serviço, desative o Service Networking API, aguarde cinco minutos e reative-o.


Falha na criação da instância do Terraform

Falha na criação da instância do Terraform.

O problema pode ser

Isso geralmente é um problema no próprio script do Terraform.

O que você pode tentar

Inspecione e repare o arquivo de configuração do Terraform.


Erro 409 no script do Terraform

Você verá a mensagem de erro HTTP Error 409 nos scripts do Terraform.

O problema pode ser

Operation failed because another operation was already in progress

O que você pode tentar

Revise o script para interromper a execução até que cada operação da instância seja concluída. Antes de continuar para a próxima etapa, faça uma pesquisa com o script e aguarde até que um 200 seja retornado para o ID da operação anterior.


Erro desconhecido

Ao tentar criar uma instância, você vê uma mensagem de erro como Cloud SQL creation failed, error UNKNOWN.

Possível problema

  • A API Service Networking pode não estar ativada.
  • Talvez você esteja tentando reutilizar o nome de uma instância excluída recentemente. Os nomes das instâncias não podem ser reutilizados por uma semana após a exclusão.
  • Talvez você esteja tentando criar várias instâncias simultaneamente. Nesse caso, apenas a primeira instância é criada e a outra falha com Unknown error. Só é possível executar uma operação de criação por vez
  • A criação da sub-rede pode ter falhado porque não havia mais endereços disponíveis no intervalo de IP.

O que você pode tentar

  • Ative a API Service Networking.
  • Use um nome diferente para a instância ou aguarde uma semana para criar uma nova com esse nome.
  • Crie várias instâncias consecutivamente, em vez de simultaneamente.
  • Consulte a seção Falha ao criar uma sub-rede abaixo.

Falha ao criar sub-rede

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.

Possível problema

Não há mais endereços disponíveis no intervalo de IP alocado.

Se você encontrar esse erro ao tentar criar uma instância do Cloud SQL com IP privado em uma rede VPC compartilhada usando conexões de serviço particular, há cinco 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.

O que você pode tentar

Para cada um dos cenários acima, é possível expandir a opção atual ou alocar um intervalo de IP adicional para a conexão de serviço particular.

Se você estiver alocando um novo intervalo, tome cuidado para não criar uma alocação que se sobreponha a uma alocação existente.

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 a /mascaramento por 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]

Principal externo

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Specified key was too long; max key length is 767 bytes. A instância principal externa pode ter a variável innodb_large_prefix definida. Defina a sinalização innodb_large_prefix como ON ao criar a réplica ou atualize a réplica atual com a sinalização.
Table definition has changed. Houve alterações na linguagem de definição de dados (DDL, na sigla em inglês) durante o processo de despejo. Evite mudanças em DDL durante o processo de despejo.
Mensagem de erro: Access denied; you need (at least one of) the SUPER privilege(s) for this operation Pode haver uma visualização, uma função ou um procedimento no banco de dados de origem que referencie DEFINER de uma maneira que não é compatível com o Cloud SQL. Veja mais informações sobre o uso do DEFINER no Cloud SQL.
Mensagem de erro: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost Há um DEFINER no banco de dados de origem que não existe na réplica. Veja mais informações sobre o uso de DEFINER no Cloud SQL.
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.
Got packet bigger than 'max_allowed_packet' bytes when dumping table O pacote era maior do que o permitido pelas configurações. Use mysqldump com a opção max_allowed_packet.
A migração inicial dos dados foi bem-sucedida, mas nenhum dado está sendo replicado. Pode haver sinalizações de replicação conflitantes. Verifique estas configurações de sinalização.
A migração inicial de dados foi bem-sucedida, mas a replicação de dados deixa de funcionar após um tempo. Há muitas causas possíveis. Tente estas sugestões:
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 da réplica. Aumente o tamanho do disco manualmente ou ative o aumento automático de armazenamento.

A chave especificada era muito longa. O comprimento máximo da chave é 767 bytes

Você verá o erro Specified key was too long; max key length is 767 bytes.

Possível problema

A instância principal externa pode ter a variável innodb_large_prefix definida. Isso permite prefixos de chave de índice com mais de 767 bytes. O valor padrão é OFF para MySQL 5.6.

O que você deve tentar

Defina a sinalização innodb_large_prefix como ON ao criar a réplica ou atualize a réplica atual com a sinalização.


A definição da tabela foi alterada

Você verá o erro Table definition has changed.

Possível problema

Houve alterações de DDL durante o processo de despejo.

O que você deve tentar

Não modifique tabelas nem faça outras alterações de DDL durante o processo de despejo.


Acesso negado. Você precisa de (pelo menos um dos) privilégios de SUPER para esta operação

Você verá o erro Access denied; you need (at least one of) the SUPER privilege(s) for this operation.

Possível problema

A causa raiz pode ser o cliente VIEW/FUNCTION/PROCEDURE com DEFINER usando superusuario@localhost (como root@localhost). Isso não é compatível com o Cloud SQL.

O que você pode tentar

A solução é atualizar o definidor nos bancos de dados externos, por exemplo, de root@localhost para root@% ou não um superusuário. Consulte Controle de acesso ao objeto armazenado para mais informações.


ERRO 1045 (28000) na linha xxx: acesso negado para o usuário 'cloudsqlimport'@'localhost

Você verá o erro ERROR 1045 (28000) at line xxx: Access denied for user 'cloudsqlimport'@'localhost

Possível problema

Um usuário no banco de dados de origem com a cláusula DEFINER não existe no banco de dados de réplica, e ele é referenciado nas definições de objetos no banco de dados de origem.

O que você pode tentar

Os usuários não são migrados com os dados. Crie os usuários do banco de dados de origem no banco de dados de réplica antes de iniciar a replicação.


Perda de conexão com o servidor MySQL durante a consulta ao despejar tabela

Você verá o erro Lost connection to MySQL server during query when dumping table.

Possível problema

  • A origem pode ter ficado indisponível para se conectar pela réplica.

  • O banco de dados de origem pode ter tabelas com blobs grandes ou strings longas que exigem a configuração de max_allowed_packet como um número maior no banco de dados de origem.

O que você deve tentar

  • Reinicie e verifique se a instância principal externa está disponível para conexão.

  • Use mysqldump com a opção max_allowed_packet para despejar dados e migrar com o arquivo dump.


Pacote maior com bytes "max_allowed_packet" ao despejar tabela

Você verá o erro Got packet bigger than 'max_allowed_packet' bytes when dumping table.

Possível problema

O pacote era maior do que o permitido pelas configurações.

O que você deve tentar

Use mysqldump com a opção max_allowed_packet para despejar dados e migrar com o arquivo dump.


Nenhum dado está sendo replicado.

A migração inicial dos dados foi bem-sucedida, mas nenhum dado está sendo replicado.

Possível problema

Uma possível causa raiz pode ser a sinalização do seu banco de dados de origem, o que faz com que algumas ou todas as alterações do banco de dados não sejam replicadas.

O que você deve tentar

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 concluída, mas a replicação de dados deixará de funcionar após um tempo

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

Possível problema

Pode haver muitas causas raiz para esse problema.

O que você pode tentar

  • Verifique as métricas de replicação para sua instância de réplica na IU do Cloud Monitoring.

  • Os erros da linha de execução de E/S do MySQL ou do SQL podem ser encontrados no Cloud Logging nos arquivos de registros mysql.err.

  • O erro também pode ser encontrado ao se conectar à instância da réplica. Execute o comando SHOW SLAVE STATUS e verifique estes campos na saída:

    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

Falha na verificação do mysqld: o disco de dados está cheio

Você verá o erro mysqld check failed: data disk is full.

Possível problema

Se você vir esse erro durante uma operação DRAIN, o disco de dados da instância da réplica estará cheio.

O que você deve tentar

Aumente o tamanho do disco da instância de réplica.

Réplica externa

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Mensagem de erro: The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires A réplica não sabe de onde começar a ler os registros. Crie um novo arquivo dump com as configurações de sinalização corretas e configure a réplica externa usando esse arquivo.

Registros binários removidos que contêm GTIDs

Você verá a mensagem de erro The slave is connecting ... master has purged binary logs containing GTIDs that the slave requires no MySQL.

Possível problema

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.

O que você pode tentar

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 meio de 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

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
A ativação de uma sinalização provoca falha na instância. O valor da sinalização max_connections pode ser definido como alto. Entre em contato com o suporte ao cliente para solicitar a remoção de uma sinalização.
O fuso horário não é alterado automaticamente. A alteração automática de fuso horário não está disponível. O horário precisa ser alterado manualmente. Saiba mais.
Bad syntax for dict arg Os valores de parâmetro complexos exigem tratamento especial. Saiba mais.

A ativação de uma sinalização provoca falha na instância

Após a ativação de uma sinalização, as instâncias ficam alternando entre pânico e falha.

O problema pode ser

Definir o valor da sinalização max_connections muito alto causa esse erro.

O que você pode tentar

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.


O fuso horário não é alterado automaticamente

O fuso horário não foi alterado automaticamente para o horário de verão.

O problema pode ser

As alterações automáticas de fuso horário não estão disponíveis no Cloud SQL e precisam ser feitas manualmente, e não por string, mas por valor de ajuste de fuso horário.

O que você pode tentar

Edite a instância para alterar a sinalização default_time_zone. Áreas com nome não são aceitas. Por exemplo: Europe/London Londres está no fuso horário UTC, que seria um valor aceito de +00:00 para a sinalização default_time_zone.


Sintaxe incorreta do argumento dict

Você verá a mensagem de erro Bad syntax for dict arg ao tentar definir uma sinalização.

Possível problema

Valores de parâmetro complexos, como listas separadas por vírgulas, exigem tratamento especial quando usados com comandos gcloud.

O que você pode tentar

Use o parâmetro --flags-file da gcloud, que especifica um arquivo YAML ou JSON que contém um dicionário --flag:value útil para valores de sinalização complexos.

Alta disponibilidade

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Não é possível encontrar métricas para failover manual. Somente failovers automáticos entram nas métricas. N/D
CPU e RAM próximas de 100% de uso O tamanho da máquina da instância é pequeno demais para a carga. Faça upgrade no tamanho da máquina da instância.

Não é possível encontrar métricas para failover manual

Você executou um failover manual e não consegue encontrar uma entrada correspondente nas métricas de failover automático do Metrics Explorer.

O problema pode ser

Somente failovers automáticos entram nas métricas. Failovers iniciados manualmente não.

O que você pode tentar

N/D


CPU e RAM próximas de 100% de uso

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 problema pode ser

O tamanho da máquina da instância é pequeno demais para a carga.

O que você pode tentar

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

Importar

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
A importação está demorando demais. Muitas conexões ativas podem interferir nas operações de importação. Feche as conexões não usadas ou reinicie a instância do Cloud SQL antes de iniciar uma operação de importação.
A importação falhou. O arquivo exportado pode conter usuários do banco de dados que ainda não existem. Limpe o banco de dados com falha antes de tentar realizar a importação novamente. Crie os usuários do banco de dados antes de fazer a importação.
Erro durante a importação: a tabela não existe. Uma tabela obrigatória não existe no momento. Desative FOREIGN_KEY_CHECKS no início da importação.
Mensagem de erro: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost' Há um DEFINER no arquivo dump que não existe no banco de dados. Veja mais informações sobre o uso de DEFINER e possíveis soluções alternativas no Cloud SQL.
Mensagem de erro: Unknown table 'COLUMN_STATISTICS' in information_schema Isso acontece se você usar o binário mysqldump do MySQL 8.0 para fazer dump de dados de um banco de dados MySQL 5.7 e importá-los para um banco de dados MySQL 8.0. Se você fizer dump de dados de um banco de dados MySQL 5.7 e importá-los para um banco de dados MySQL 8.0, use o binário mysqldump do MySQL 5.7. Se você usar o binário mysqldump do MySQL 8.0, precisará adicionar a sinalização --column-statistics=0.

A importação está demorando demais

A importação está demorando muito, o que bloqueia outras operações.

O problema pode ser

Muitas conexões ativas podem interferir nas operações de importação. As conexões consomem CPU e memória, limitando os recursos disponíveis.

O que você pode tentar

Feche operações não usadas. Verifique o uso de CPU e da memória para garantir que há vários recursos disponíveis. A melhor maneira de garantir o máximo de recursos para a operação de 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.


Falha na importação

A importação falha quando um ou mais usuários referenciados no arquivo de despejo SQL exportado não existem.

O problema pode ser

Antes de importar um arquivo de dump SQL, 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. Caso contrário, a restauração não recriará os objetos com a propriedade e/ou as permissões originais.

O que você pode tentar

Limpe o banco de dados com falha antes de tentar realizar a importação novamente. Crie os usuários do banco de dados antes de importar o dump SQL.


Erro durante a importação: a tabela não existe

Uma operação de importação falha com um erro de que uma tabela não existe.

Possível problema

As tabelas podem ter dependências de chave externa em outras tabelas e, dependendo da ordem das operações, uma ou mais delas ainda não existem durante a operação de importação.

O que você deve 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.


Mensagem de erro: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost'

Você verá o erro ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost'.

Possível problema

A causa raiz é que um usuário no arquivo dump com a cláusula DEFINER não existe no banco de dados, e que esse usuário tem referência cruzada nas definições de objetos no banco de dados.

O que você pode tentar

Consulte este documento sobre como importar um banco de dados com cláusulas DEFINER no arquivo dump. Talvez seja necessário criar primeiro um ou mais usuários no banco de dados.


Mensagem de erro: tabela desconhecida "COLUMN_STATISTICS" em information_schema

Você vê a mensagem de erro Unknown table 'COLUMN_STATISTICS' in information_schema.

Possível problema

Isso acontece se você usar o binário mysqldump do MySQL 8.0 para fazer dump de dados de um banco de dados MySQL 5.7 e importá-los para um banco de dados MySQL 8.0.

O que você pode tentar

Se você fizer dump de dados de um banco de dados MySQL 5.7 e importá-los para um banco de dados MySQL 8.0, use o binário mysqldump do MySQL 5.7. Se você usar o binário mysqldump do MySQL 8.0, precisará adicionar a sinalização --column-statistics=0.

Exportar

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
Não é possível ver o status da operação. A interface do usuário mostra apenas sucesso ou falha. Use estes comandos do banco de dados para saber mais.
408 Error (Timeout) durante a exportação. A exportação do SQL pode demorar muito, dependendo do tamanho do banco de dados e do conteúdo exportado. Use várias exportações de CSV para reduzir o tamanho de cada operação.
A exportação de CSV funcionou, mas a exportação de SQL falhou. A exportação de SQL tem mais chances de ter problemas de compatibilidade com o Cloud SQL. 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. Saiba mais.
Error 1412: Table definition has changed. A tabela foi alterada durante a exportação. Remova todas as instruções de alteração de tabela da operação de despejo.
Conexão fechada durante a operação de exportação. A consulta precisa produzir dados nos primeiros sete minutos. Teste a consulta manualmente. Saiba mais.
Erro desconhecido durante a exportação. Possível problema de largura de banda. Verifique se a instância e o bucket do Cloud Storage estão na mesma região.
Você quer automatizar as exportações. O Cloud SQL não oferece uma maneira de automatizar exportações. Crie seu próprio pipeline para executar essa funcionalidade. Saiba mais.
Mensagem de erro: Access denied; you need (at least one of) the SUPER privilege(s) for this operation Pode haver um evento, uma visualização, uma função ou um procedimento no arquivo dump usando superusuario@localhost (como o root@localhost). Isso não é compatível com o Cloud SQL. Saiba mais sobre o uso de DEFINER e as possíveis soluções alternativas no Cloud SQL.

Não é possível ver o status da operação

Não é possível ver o status de uma operação em andamento.

O problema pode ser

O Console do Google Cloud informa apenas o sucesso ou falha no momento da conclusão e não foi projetado para retornar avisos.

O que você pode tentar

Conecte-se ao banco de dados e execute SHOW WARNINGS.


Erro 408 (tempo limite) durante a exportação

Você vê a mensagem de erro 408 Error (Timeout) ao executar um job de exportação no Cloud SQL.

O problema pode ser

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.

O que você pode tentar

Use o formato CSV e execute vários jobs de exportação menores para reduzir o tamanho e a duração de cada operação.


A exportação de CSV funcionou, mas a exportação de SQL falhou

A exportação de CSV funcionou, mas a exportação de SQL falhou.

Possível problema

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.

O que você pode tentar

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


A exportação está demorando muito

A exportação está demorando muito, bloqueando outras operações.

O problema pode ser

O Cloud SQL não é compatível com operações síncronas simultâneas.

O que você pode tentar

Tente exportar conjuntos de dados cada vez menores.


mysqldump: erro 1412: a definição da tabela foi alterada

Você vê a mensagem de erro mysqldump: Error 1412: Table definition has changed, retry transaction when dumping the table.

Possível problema

Durante o processo de exportação, houve uma alteração na tabela.

O que você deve tentar

A transação de despejo poderá falhar se você usar as seguintes instruções durante a operação de exportação:

  • ALTER TABLE
  • CREATE TABLE
  • DROP TABLE
  • RENAME TABLE
  • TRUNCATE TABLE
Remova qualquer uma dessas instruções da operação de despejo.


Conexão fechada durante a operação de exportação

Conexão fechada durante a operação de exportação.

O problema pode ser

A conexão com o Cloud Storage pode expirar porque a consulta em execução na exportação não está produzindo nenhum dado nos primeiros sete minutos desde que a exportação foi iniciada.

O que você pode tentar

Teste a consulta manualmente conectando-se a partir de qualquer cliente e enviando a saída da consulta para STDOUT com o comando abaixo:

COPY (INSERT_YOUR_QUERY_HERE) TO STDOUT WITH ( FORMAT csv, DELIMITER ',', ENCODING 'UTF8', QUOTE '"', ESCAPE '"' ).

Esse é o comportamento esperado, porque quando a exportação é iniciada, o cliente deve começar a enviar dados imediatamente. Caso a conexão continue sem dados enviados, ela acaba sendo interrompida e, por fim, resultando em falha na exportação e deixando a operação em um estado incerto. Além disso, é isso que a mensagem de erro do gcloud está tentando dizer com esta mensagem:

operation is taking longer than expected.


Erro desconhecido durante a exportação

Você verá a mensagem de erro Unknown error ao tentar exportar um banco de dados para um bucket do Cloud Storage.

O problema pode ser

A transferência pode falhar devido a um problema de largura de banda.

A instância do Cloud SQL pode estar em uma região diferente do bucket do Cloud Storage. A leitura e a gravação de dados de um continente para outro envolve muito uso de rede e pode causar problemas intermitentes como esse. Verifique as regiões da instância e do bucket.

O que você pode tentar

Use a exportação sem servidor para descarregar a operação de exportação da instância principal.

Querer automatizar exportações

Você quer automatizar as exportações.

O problema pode ser

O Cloud SQL não oferece uma maneira de automatizar exportações.

O que você pode tentar

É possível criar seu próprio sistema de exportação automatizada usando produtos do Google Cloud, como Cloud Scheduler, Pub/Sub e Cloud Functions.


Houve um erro de sistema ERROR_RDBMS

Você vê a mensagem de erro [ERROR_RDBMS] system error occurred.

O problema pode ser

  • O usuário pode não ter todas as permissões necessárias do Cloud Storage.
  • A tabela de banco de dados pode não existir.

O que você pode tentar

  1. Verifique se você tem pelo menos as permissões WRITER no bucket e READER no arquivo de exportação. Para mais informações sobre como configurar o controle de acesso no Cloud Storage, consulte Criar e gerenciar listas de controle de acesso.
  2. Verifique se a tabela existe. Se a tabela existir, confirme se você tem as permissões corretas no bucket.

Acesso negado. Você precisa de (pelo menos um dos) privilégios de SUPER para esta operação

Você verá o erro Access denied; you need (at least one of) the SUPER privilege(s) for this operation.

Possível problema

Pode haver um evento, uma visualização, uma função ou um procedimento no arquivo dump usando superusuario@localhost (como root@localhost). Isso não é compatível com o Cloud SQL.

O que você pode tentar

Consulte este documento sobre como importar um banco de dados com cláusulas DEFINER.

Logging

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
A geração de registros está usando CPU e memória demais. A geração de registros precisa ser ajustada. Tente ajustar o uso de recursos de registro.
Registros de auditoria não encontrados. Autenticação de usuários. Verifique os papéis e permissões do usuário.
Informações de operações não encontradas nos registros. Os registros de auditoria não estão ativados. Ative os registros de auditoria.
A geração de registros está usando muito espaço em disco. Os registros refazer, binários e gerais usam espaço em disco. Execute estes comandos para ver os detalhes de uso do disco.
Os arquivos de registros são difíceis de ler. É melhor ver os registros como json ou texto. Use comandos gcloud logging.

A geração de registros está usando CPU e memória demais

A geração de registros está usando CPU e memória demais.

O problema pode ser

O uso da geração de registros precisa ser ajustado.

O que você pode tentar

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. Edite a instância para modificar essas sinalizações.


Geração de registros de auditoria

Você ativou a geração de registros de auditoria para o Cloud SQL, mas não consegue encontrar nenhum registro de auditoria no Cloud Logging

O problema pode ser

Os registros de acesso a dados só são gravados se a operação é uma chamada de API autenticada pelo usuário que cria, modifica ou lê dados criados pelo usuário ou se a operação acessa arquivos de configuração ou metadados de recursos.

O que você pode tentar

Verifique os papéis e as permissões do usuário que executa as operações.


Informações de operação 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.

O problema pode ser

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.

O que você pode tentar

Ative a geração de registros de auditoria no projeto.


A geração de registros está usando muito espaço em disco

Você quer descobrir quanto espaço em disco os arquivos de registros do MySQL estão usando.

Possível problema

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

O que tentar

Execute estes comandos para ver detalhes sobre cada tipo de arquivo de registro:

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

É difícil ler os registros no Explorador de registros.

Possível problema

Faça o download dos registros localmente no formato JSON ou de texto.

O que tentar

Use o comando gcloud logging read com os comandos de pós-processamento do Linux para fazer o download dos registros.

Para fazer o download como JSON:

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

Para fazer o download como TEXTO:

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


Como gerenciar instâncias

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 do MySQL. 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. Verifique se a instância tem 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.
ERROR 1142 (42000): ANY command denied to user 'root'@'%' for table ... O usuário não tem todas as permissões necessárias para a operação. Faça login e execute os comandos detalhados aqui.
Você quer renomear uma instância do Cloud SQL. Não é possível renomear uma instância atual. Há algumas maneiras de atingir o objetivo criando uma nova instância.
Metadata table locked Outra consulta, processo ou transação está bloqueando sua consulta e bloqueou a tabela. Encontre e elimine o processo de bloqueio e, em seguida, reinicie a instância.

Desempenho lento após a reinicialização do MySQL

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

Possível problema

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;
  • 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 instance.truncateLog.
  • Saiba mais sobre como configurar 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.

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ê pode 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ê pode 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ê pode 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ê pode 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ê pode 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ê pode 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ê pode 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ê pode 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ê pode 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ê pode 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ê pode 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ê pode 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"
        

    É possível fazer o download dos registros em 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 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ê pode tentar

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

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


ERRO 1142 (42000): QUALQUER comando negado ao usuário 'root'@'%' para a tabela…

Ao usar o MySQL 5.7, você pode encontrar ERROR 1142 (42000): ANY command denied to user 'root'@'%' for table ''" ao criar uma visualização que tem vários níveis de seleção.

Possível problema

O usuário não tem todas as permissões necessárias para a operação.

O que você pode tentar

  1. Conecte-se ao banco de dados (por exemplo, usando o Cloud Shell) e faça login como raiz.
  2. Execute USE mysql;.
  3. Execute o seguinte comando:
    GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER, CREATE TABLESPACE ON . TO 'root' WITH GRANT OPTION;
    
  4. Execute USE 'Database_Name';, em que Database_Name é o banco de dados em que você está criando as visualizações.
  5. Execute todas as visualizações de criação na sessão e confirme.

Você quer renomear uma instância do Cloud SQL

Por motivos comerciais ou por outros motivos, você quer renomear uma instância atual do Cloud SQL.

Possível problema

A renomeação de uma instância não é compatível com o Console do Google Cloud ou por meio de uma API.

O que você pode tentar

Há outras maneiras de atingir a meta criando uma nova instância.

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

  2. É 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 as configurações da configuração da instância, como sinalizações, tipo de máquina, tamanho do armazenamento e memória.


Tabela de metadados bloqueada

Você realizou uma consulta no banco de dados (por exemplo, ALTER TABLE) e recebeu uma mensagem de erro informando que a tabela de metadados está bloqueada. O banco de dados não conclui a consulta e não responde a outras atividades.

Possível problema

Outra consulta, transação ou processo está bloqueando sua consulta e bloqueou a tabela de metadados.

O que você pode tentar

Encontre o processo que bloqueou e elimine a tabela.

  • Diagnóstico com: sql> show processlist; O primeiro item da lista pode ser aquele que contém o cadeado, que os itens a seguir estão aguardando.
  • O comando SHOW INNODB STATUS também pode ser útil.
  • KILL <PID>;

Replicação

Clique nos links da tabela para ver detalhes:

Para este problema... O problema pode ser... Tente o seguinte...
A réplica de leitura não começou a ser replicada na criação. Há muitas causas possíveis. Verifique os registros para encontrar mais informações.
Não foi possível criar a réplica de leitura: erro invalidFlagValue. Uma das sinalizações fornecidas explicitamente ou por padrão é inválida. Verifique os valores e registros da sinalização para encontrar mais informações.
Não foi possível criar a réplica de leitura: erro desconhecido. Há muitas causas possíveis. Verifique os registros para encontrar mais informações.
O disco está cheio. O tamanho do disco da instância principal pode ficar cheio durante a criação da réplica. Faça upgrade da instância principal para um tamanho de disco maior.
A instância da réplica está usando memória demais. As réplicas podem armazenar em cache as operações de leitura solicitadas com frequência. Reinicie a instância da réplica para recuperar o espaço de memória temporário.
Replicação interrompida. O espaço de armazenamento máximo foi atingido e o aumento automático de armazenamento não está ativado. Ative o aumento automático de armazenamento.
O atraso da replicação é consistentemente alto. muitas causas diferentes possíveis. Veja algumas dicas neste link.
Alterar sinalizações paralelas de replicação resulta em um erro. Um valor incorreto foi definido para uma ou mais sinalizações. Veja algumas dicas neste link.

A réplica de leitura não começou a ser replicada na criação

A réplica de leitura não começou a ser replicada na criação.

Possível problema

Provavelmente há um erro mais específico nos arquivos de registro.

O que você pode tentar

Inspecione os registros no Cloud Logging para encontrar o erro real.


Não foi possível criar a réplica de leitura: erro invalidFlagValue.

Não foi possível criar a réplica de leitura: invalidFlagValue.

Possível problema

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.

O que você pode tentar

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

Não foi possível criar a réplica de leitura: unknown error.

O problema pode ser

Provavelmente há um erro mais específico nos arquivos de registro.

O que você pode tentar

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.


Disco cheio

Erro UPDATE_DISK_SIZE ou mysqld: disk is full.

O problema pode ser

O tamanho do disco da instância principal pode ficar cheio durante a criação da réplica.

O que você pode tentar

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 instância da réplica está usando memória demais.

O problema pode ser

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.

O que você deve tentar

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


Replicação interrompida

Replicação interrompida.

O problema pode ser

O limite máximo de armazenamento foi atingido e >automatic storage increase is disabled.

O que você pode tentar

Edite a instância para ativar automatic storage increase.


O atraso da replicação é consistentemente alto

O atraso da replicação é consistentemente alto.

O problema pode ser

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 longo ou temporário 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.

O que você deve tentar

Algumas soluções possíveis:

Alterar as sinalizações de replicação paralela resulta em um erro

Alterar as sinalizações de replicação paralela binlog_transaction_dependency_tracking, transaction_write_set_extraction ou slave_pending_jobs_size_max gera a seguinte mensagem de erro:

set MySQL flags error: Error 1221: Incorrect usage of binlog_transaction_dependency_tracking (!= COMMIT_ORDER) and transaction_write_set_extraction (= OFF).

Possível problema

Um valor incorreto é definido para uma ou mais dessas sinalizações.

O que você pode tentar

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

  1. Modifique as sinalizações binlog_transaction_dependency_tracking e transaction_write_set_extraction da seguinte maneira:

    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Adicione a sinalização slave_pending_jobs_size_max da seguinte maneira:

    slave_pending_jobs_size_max=33554432

  3. Modifique a sinalização transaction_write_set_extraction da seguinte maneira:

    transaction_write_set_extraction=XXHASH64

  4. Modifique a sinalização binlog_transaction_dependency_tracking da seguinte maneira:

    binlog_transaction_dependency_tracking=WRITESET