Mensagens de erro do Cloud SQL

Verifique as seguintes condições:

• O aplicativo não chamou mysql_close() antes de sair.
• Erros de comunicação (em inglês).
• O aplicativo pode ter ficado suspenso por mais tempo do que o número de segundos especificado em `wait_timeout` ou `interactive_timeout` sem emitir qualquer solicitação ao servidor. Consulte a seção 5.1.7, "Variáveis de sistema do servidor".
• O aplicativo foi encerrado repentinamente no meio de uma transferência de dados.
• O valor da variável max_allowed_packet pode ser muito pequeno ou as consultas exigem mais memória do que o alocado para mysqld. Isso pode ser resolvido aumentando a sinalização max_allowed_packet para um número muito maior.

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

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

Tente fazer o seguinte:

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

É 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

Tente isto:

1. Conecte-se ao banco de dados (por exemplo, usando o Cloud Shell) e faça login como raiz.
2. Execute USE mysql;.
3. Conceda as seguintes permissões usando a sintaxe:

   GRANT PERMISSION_1,PERMISSION_2 ON *.* TO 'root' WITH GRANT OPTION;
      

   • SELECT
   • INSERT
   • ATUALIZAR
   • EXCLUIR
   • CRIAR
   • DROP
   • ATUALIZAR
   • SHUTDOWN
   • PROCESSO
   • REFERÊNCIAS
   • INDEX
   • ALTER
   • SHOW DATABASES
   • CREATE TEMPORARY TABLES
   • LOCK TABLES
   • EXECUTE
   • REPLICATION SLAVE
   • REPLICATION CLIENT
   • CREATE VIEW
   • SHOW VIEW
   • CREATE ROUTINE
   • ALTER ROUTINE
   • CREATE USER
   • EVENTO
   • TRIGGER
   • CREATE TABLESPACE
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.

Para Illegal Argument, verifique a solicitação para saber se cada argumento é permitido e se cada valor de argumento é válido. Para todas as outras causas, verifique os arquivos de registros para ver se há mais informações disponíveis.

É 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

Se você estiver tentando fazer uma exportação e o Cloud Storage não receber dados em um determinado período, a conexão será redefinida.

Tente fazer uma exportação manual usando pg_dump.

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.

Use o comando sp_helpdb para ver informações sobre o banco de dados.

Considere as seguintes soluções:

• Expanda manualmente o espaço em disco ou reduza os dados no banco de dados.
• Verifique se Automatic storage increase está ativado para a instância de banco de dados.
• Adicione mais grupos de arquivos e mova dados para eles.
• Garanta que o crescimento não seja limitado. Use o comando ALTER DATABASE para ativar o crescimento automático, se ainda não estiver ativado, e aumentar o tamanho máximo do arquivo.
• Gerencie arquivos tempdb. Use os comandos DBCC OPENTRAN e DBCC SQLPERF para verificar se há transações abertas que podem fazer com que o arquivo tempdb ou o registro de transações aumente.

Conecte-se com o usuário padrão e mude os usuários.

Edite a instância principal com upgrade para um tamanho de disco maior.

Não foi possível encontrar blocos gratuitos em intervalos de IP alocados. Aloque novos intervalos para este provedor de serviços.

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

Considere estes 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.
• 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 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, tenha 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 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 \
--force

No momento, não é possível se conectar do Cloud Shell a uma instância apenas com um endereço IP particular.

Use mysqldump com a opção max_allowed_packet.

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

Verifique se o SO e o sistema de arquivos são compatíveis com arquivos desse tamanho. Verifique se o disco não está cheio ou com cota de disco insuficiente. É possível solicitar um aumento nas suas cotas pelo Console do Google Cloud ou editar a instância com upgrade para um tamanho de disco maior.

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

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.

Encontre o processo que bloqueou a tabela e pare-o.

1. Diagnóstico com: sql> show processlist;

   O primeiro item da lista talvez seja aquele que contém a trava, que os itens subsequentes estão esperando.

2. O comando SHOW INNODB STATUS também pode ser útil.
3. Execute o comando KILL <var>PID</var>;

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.

Aguarde a operação anterior ser concluída antes de iniciar outra.

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

Solicite um aumento nas suas cotas pelo Console do Google Cloud.

Aumente o valor da sinalização max_connections. Consulte Como configurar sinalizações do banco de dados.

Verifique se você tem um arquivo JSON de chave de conta de serviço válido no local armazenado na variável de ambiente GOOGLE_APPLICATION_CREDENTIALS e se a variável aponta para o local correto.

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

Crie um novo certificado de servidor e alterne-o.

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

Tente fazer o seguinte:

• Verifique se você tem pelo menos as permissões de WRITER no bucket e de 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.
• Verifique se a tabela existe. Se a tabela existir, confirme se você tem as permissões corretas no bucket de armazenamento.

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.

Aumente o tamanho de temp_file_limit. Consulte Como configurar sinalizações do banco de dados.

[Warning] InnoDB: Load table db.table failed, the table has missing
foreign key indexes. Turn off 'foreign_key_checks' and try again.
[Warning] InnoDB: Cannot open table db/table from the internal data
dictionary of InnoDB though the .frm file for the table exists.
See InnoDB troubleshooting
for more information.
      

Após a reinicialização do banco de dados, o MySQL precisa carregar tabelas no cache do dicionário do InnoDB no primeiro acesso. Se detectar a discrepância, o acesso a essa tabela será bloqueado.

mysql> select * from db.table;
ERROR 1146 (42S02): Table db.table doesn't exist
      

Desativar foreign_key_checks para a sessão do MySQL permite acesso à tabela novamente. Depois que a tabela for acessada e carregada no cache do dicionário, o InnoDB não verificará e reclamará sobre uma incompatibilidade de chave externa até a próxima reinicialização do banco de dados

A incompatibilidade de chave externa deve ser corrigida para evitar outros problemas.

1. Desative o foreign_key_checks para a sessão do cliente mysql e acesse a tabela.

   mysql> SET SESSION FOREIGN_KEY_CHECKS=0;
               

2. Inspecione as tabelas pai e filho e identifique as incompatibilidades entre a chave externa e as colunas de chave referenciadas.

   mysql> SHOW CREATE TABLE parent_table;
   mysql> SHOW CREATE TABLE child_table;
               

   Verifique se as colunas correspondentes têm tipos de dados semelhantes. O tamanho e o sinal dos tipos de precisão fixa, como INTEGER e DECIMAL, são os mesmos. Para colunas de strings não binárias (caractere), o conjunto de caracteres e a compilação precisam ser iguais.

3. Corrija a incompatibilidade usando a instrução ALTER TABLE. Algumas operações podem exigir que você primeiro remova a restrição de chave externa, aplique a alteração e depois adicione a chave externa novamente.
4. Reative foreign_key_checks novamente.

   mysql> SET SESSION FOREIGN_KEY_CHECKS=1;
               

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.

Reduza o valor da sinalização max_connections ou 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.

• 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, o usuário pode não ter as permissões de IAM corretas, incluindo as permissões serviceusage.services.use ou cloudsql.instances.connect.
• 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.

Tente fazer o seguinte:

• Verifique se o usuário existe e corresponde à senha.
• Atribua o papel Service Usage Consumer à conta de usuário. Esse papel inclui a permissão serviceusage.services.use.
• Se estiver usando IP público, verifique se o IP de origem está em uma rede autorizada.

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, será necessário adicionar a sinalização --column-statistics=0.

Até que o problema seja resolvido, confira esta discussão no GitHub (em inglês), que inclui uma solução alternativa.

• Isso pode ocorrer quando você tenta reutilizar o mesmo nome de uma instância excluída recentemente.
• Também pode ser causado por problemas de conectividade intermitente.
• Os registros podem mostrar que a API Service Networking não está ativada para o projeto.
• O erro também foi visto ao tentar criar várias instâncias em paralelo. Por exemplo, os scripts do Terraform tornam essa tentativa possível.
• O problema também pode ocorrer porque um recurso específico está esgotado ou um limite de cota foi excedido. Nos registros, procure uma entrada como Quota 'INTERNAL_FORWARDING_RULES_WITH_TARGET_INSTANCE_PER_NETWORK' exceeded. Limit: 100.0 globally
• Esse erro poderá ocorrer se a criação da sub-rede falhar quando não houver mais endereços disponíveis no intervalo de IP.

• Os nomes de instância só podem ser reutilizados uma semana após a exclusão.
• No caso de problemas de conectividade intermitente, a única solução é tentar novamente.
• Ative a API Service Networking no projeto host.
• Scripts de criação de instâncias paralelas só terão êxito na criação de uma das instâncias. Modifique o script para aguardar até que cada operação de criação da instância seja concluída antes de avançar para a próxima.
• Alocar novos intervalos.