Solução de problemas do Cloud SQL

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:

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

Se você excluir uma instância sem fazer um backup final dos dados, não será possível recuperar nada. No entanto, se você restaurar a instância, o Cloud SQL também vai restaurar os backups. Para mais informações sobre como recuperar uma instância excluída, consulte Reter backups após a exclusão da instância.

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.

• Pode haver muitas conexões abertas. Conexões em excesso podem resultar de erros que ocorrem no meio de uma conexão em que não há configurações autovacuum para limpar conexões inativas.
• A alternância pode ocorrer se qualquer código personalizado estiver usando uma lógica de repetição que não pare após algumas falhas.
• Pode haver muito tráfego. Use o pool de conexões e outras práticas recomendadas para conectividade.

O que tentar

1. Verifique se o banco de dados está configurado para autovacuum.
2. Verifique se há alguma lógica de repetição de conexão configurada no código personalizado.
3. Reduza o tráfego até que o banco de dados seja recuperado e aumente lentamente o tráfego.

CREATE UNLOGGED TABLE ....

Estas tabelas não estão incluídas em uma restauração de um backup:

• O conteúdo de tabelas não registradas não sobrevive ao failover na instância de alta disponibilidade.
• Tabelas não registradas não sobrevivem a falhas postgres.
• As tabelas não registradas não são replicadas para réplicas de leitura.
• As tabelas não registradas são automaticamente excluídas durante a restauração do backup.

A solução é evitar o uso de tabelas não registradas se você quiser restaurar essas tabelas com um backup. Ao restaurar um banco de dados que já tem tabelas não registradas, é possível despejar o banco de dados em um arquivo e recarregar os dados depois de modificar o arquivo despejado para ALTER TABLE para SET LOGGED nessas tabelas.

• Defina o valor final do backup para corresponder à configuração de backup existente da instância.
• Deixe o campo de backup final vazio ao excluir a instância. Se você deixar o campo em branco, o Cloud SQL usará a configuração final de backup definida nas configurações da instância para fazer um backup final e definir a retenção dele.

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

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

• Operações lentas para criar logins do Microsoft Entra ID
• Não é possível criar logins do Microsoft Entra ID
• Não é possível se conectar à instância usando a autenticação do Microsoft Entra ID

Para mais informações sobre como resolver esses problemas, consulte Solução de problemas da integração do Microsoft Entra ID.

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

A zona selecionada não tem capacidade para os recursos solicitados ou o tipo de VM no momento da solicitação de criação da instância. Pode haver uma alta demanda operacional simultânea nesse local regional específico no momento da solicitação.

Para resolver esse problema, tente criar a instância em outra zona ou tente criar a instância na mesma zona que recebeu o erro em um horário diferente do dia.

• 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
    

Ative a API Service Networking usando o comando a seguir e tente criar a instância do Cloud SQL novamente.

gcloud services enable servicenetworking.googleapis.com \
--project=PROJECT_ID
    

Verifique se os nomes DNS que você quer adicionar ao certificado do servidor de uma instância do Cloud SQL atendem aos seguintes critérios:

• Eles não têm caracteres curinga.
• Não adicione pontos finais.
• Eles atendem às especificações da RFC 1034.

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.

Edite o arquivo dump para remover as referências.

Faça uma exportação manual usando a ferramenta pg_dump.

É 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

Resolução:não execute instruções DDL no banco de dados de origem durante a fase inicial de despejo. Antes de executar qualquer instrução DDL, reinicie a migração e aguarde a conclusão da fase de despejo inicial.

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

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

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

O que tentar

• Verifique as métricas de replicação da instância de réplica na seção Cloud Monitoring do console Google Cloud .
• Os erros da linha de execução de E/S do MySQL ou da linha de execução do SQL podem ser encontrados no Cloud Logging nos arquivos de registro mysql.err.
• O erro também pode ser encontrado ao se conectar à instância da réplica. Execute o comando SHOW REPLICA STATUS e verifique os seguintes campos na saída:
  • Replica_IO_Running
  • Replica_SQL_Running
  • Last_IO_Error
  • Last_SQL_Error

Se você encontrar o erro Unknown database DATABASE_NAME on query. Error_code: MY-001049, a replicação falhou porque uma instrução SQL replicada tentou referenciar um banco de dados que não foi selecionado para a migração. Para recuperar a replicação, determine se o erro com base na mensagem é devido a DDL em um dos seguintes objetos:

• Um evento ou uma rotina. É possível executar CALL mysql.skipReplicationError() na réplica, o que impede que o evento ou a rotina sejam replicados e retoma a replicação.
• Uma restrição ou visualização de chave externa. Depois de determinar em qual banco de dados reside o objeto modificado pela instrução, você tem duas opções de recuperação. Você pode remover o banco de dados dos bancos de dados selecionados que estão sendo migrados ou executar CALL mysql.skipReplicationError() na réplica para retomar a replicação, ignorando a restrição ou a propagação da visualização para a réplica.

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.