Nesta página, você verá as práticas recomendadas para conseguir melhor desempenho, durabilidade e disponibilidade do Cloud SQL.
Se ocorrerem problemas na sua instância do Cloud SQL, verifique o seguinte durante a solução de problemas:
Configuração e administração de instâncias
Prática recomendada | Mais informações |
---|---|
Leia e siga as diretrizes operacionais para garantir que as instâncias estejam cobertas pelo SLA do Cloud SQL. | |
Configure uma janela de manutenção para sua instância principal para controlar quando as atualizações disruptivas podem ser feitas. | Consulte Janela de manutenção. |
Para cargas de trabalho com muita leitura, adicione réplicas de leitura para descarregar o tráfego da instância primária. | Outra opção é usar um balanceador de carga, como o HAProxy para gerenciar o tráfego para as réplicas. |
Se você exclui e recria instâncias regularmente, use um carimbo de data e hora no código da instância para aumentar a probabilidade de que novos códigos sejam utilizáveis. | |
Não inicie uma operação administrativa antes que a operação anterior seja concluída. |
As instâncias do Cloud SQL não aceitam novas solicitações de operação até que tenham concluído a operação anterior. Se você tentar iniciar uma nova operação antes do tempo, a solicitação falhará. Isso inclui reinicializações de instâncias.
O status da instância no console do Google Cloud não mostra se uma operação está em execução. A marca de verificação verde indica apenas que a instância está no estado |
Configure o armazenamento para acomodar a manutenção crítica do banco de dados. |
Se a configuração de instância ativar aumento automático de armazenamento estiver desativada ou o limite de aumento automático de armazenamento estiver ativado, verifique se pelo menos 20% do espaço está disponível para acomodar qualquer operação crítica de manutenção de banco de dados que o Cloud SQL possa realizar. Para receber alertas quando o espaço em disco disponível estiver abaixo de 20%, crie uma política de alertas com base em métricas para a métrica de utilização de disco com uma posição acima do limite e um valor de 0,8. Para mais informações, consulte Criar políticas de alertas baseadas em métricas. |
Evite o uso excessivo da CPU. |
Veja a porcentagem de CPU disponível que sua instância está usando na página de detalhes da instância no console do Google Cloud. Para mais informações, consulte Métricas. Também é possível monitorar o uso da CPU e receber alertas em um limite especificado usando Criar políticas de alertas de limite de métrica. Para evitar o uso excessivo, aumente o número de CPUs da instância. É necessário reiniciar a instância para alterar as CPUs. Se a instância já tiver o número máximo de CPUs, será necessário dividir o banco de dados em várias instâncias. |
Evite exaustão de memória. |
Ao procurar sinais de esgotamento da memória, use principalmente a métrica . Para evitar erros de memória insuficiente, recomendamos que essa métrica permaneça abaixo de 90%. Também é possível usar a métrica total_usage para observar a porcentagem da memória disponível que sua instância do Cloud SQL está usando, incluindo a memória usada pelo contêiner do banco de dados e a memória alocada pelo cache do sistema operacional. Ao observar a diferença entre as duas métricas, é possível identificar a quantidade de memória que é utilizada pelos processos em comparação com a quantidade de cache usada pelo sistema operacional. É possível reaproveitar a memória nesse cache. Para prever problemas de falta de memória, verifique as duas métricas e interprete-as juntas. Se as métricas parecerem altas, a instância pode estar com pouca memória. Isso pode ocorrer por causa de uma configuração personalizada, da instância com tamanho menor que a carga de trabalho ou de uma combinação desses fatores. Dimensione a instância do Cloud SQL para aumentar o tamanho da memória. É necessário reiniciar a instância para alterar o tamanho dela. Se a instância já estiver no tamanho máximo de memória, será necessário fragmentar seu banco de dados em várias instâncias. Para saber mais sobre como monitorar as duas métricas no console do Google Cloud, consulte Métricas. |
Arquitetura de dados
Prática recomendada | Mais informações |
---|---|
Divida suas instâncias grandes em instâncias menores, quando possível. | Usar várias instâncias pequenas do Cloud SQL é melhor do que uma única instância grande. Gerenciar uma instância grande e monolítica apresenta desafios que não existem quando se usa um grupo de instâncias menores. |
Não use muitos bancos de dados ou tabelas de banco de dados. |
Mantenha seu banco de dados com menos de 500 bancos de dados. Mantenha a tabela da instância com menos de 50.000 ou 500.000, se você atender ao requisito mínimo de hardware de mais de 32 núcleos e mais de 200 G de memória. Mantenha a contagem de tabelas para cada banco de dados com menos de 50.000 tabelas. O excesso de bancos de dados ou tabelas de banco de dados pode afetar o tempo de upgrade do banco de dados. |
Certifique-se de que suas tabelas tenham uma chave primária ou exclusiva. | O Cloud SQL usa replicação baseada em linha, que funciona melhor em tabelas com chaves primárias ou exclusivas. |
Implementação do aplicativo
Prática recomendada | Mais informações |
---|---|
Use boas práticas de gerenciamento de conexão, como o pooling de conexões e a retirada exponencial. | Com essas técnicas, seu aplicativo aproveita melhor os recursos e torna mais fácil permanecer dentro dos limites de conexão do Cloud SQL. Para mais informações e amostras de código, consulte Como gerenciar conexões de banco de dados. |
Teste a resposta do aplicativo às atualizações de manutenção, que podem acontecer a qualquer momento durante a janela de manutenção. | Teste a manutenção de autoatendimento para simular uma atualização de manutenção. Durante a manutenção, sua instância ficará indisponível por um breve período, e as conexões atuais serão descartadas. Testar os lançamentos de manutenção permite uma melhor compreensão de como seu aplicativo lida com a manutenção programada e com que rapidez o sistema pode se recuperar. |
Teste a resposta da sua aplicação a failovers, que podem acontecer a qualquer momento. | É possível iniciar manualmente um failover usando o console do Google Cloud, a CLI gcloud ou a API. Consulte Como iniciar um failover. |
Evite transações grandes. | Faça transações pequenas e curtas. Se for necessária uma grande atualização de banco de dados, faça isso em várias transações menores, em vez de em uma transação grande. |
Se você estiver usando o proxy do Cloud SQL Auth, verifique se sua versão é a mais recente. | Consulte Como manter o Cloud SQL Auth atualizado. |
Importação e exportação de dados
Prática recomendada | Mais informações |
---|---|
Use exportações sem servidor. | As exportações sem servidor descarregam a operação de exportação em uma instância temporária, permitindo que a instância principal continue a veicular consultas e a executar operações com o desempenho normal. Quando a exportação de dados é concluída, a instância temporária é excluída automaticamente. |
Acelere as importações para instâncias pequenas. | Em instâncias pequenas, aumente a CPU e a RAM temporariamente para melhorar o desempenho ao importar conjuntos de dados grandes. |
Se você estiver exportando dados para importação no Cloud SQL, certifique-se de usar o procedimento adequado. | Consulte Como exportar dados de um servidor de banco de dados gerenciado externamente. |
Ao migrar dados com uma exportação e importação, use exatamente o mesmo modo SQL para a importação que a exportação. | Consulte Usar o mesmo modo SQL para importar e exportar. |
Backup e recuperação
Prática recomendada | Mais informações |
---|---|
Proteja seus dados com a funcionalidade apropriada do Cloud SQL. |
Backups, recuperação pontual e exportações são maneiras de fornecer redundância e proteção de dados. Cada uma protege contra diferentes cenários e complementam-se em uma estratégia robusta de proteção de dados. Os backups são leves e fornecem uma forma de restaurar os dados na instância para o estado em que você fez o backup. No entanto, os backups têm algumas limitações. Se você excluir a instância, os backups também serão excluídos. Não é possível fazer backup de um único banco de dados ou tabela. E se a região em que a instância está localizada estiver indisponível, não será possível usar o backup para restaurá-la, nem mesmo em uma região disponível. A recuperação pontual ajuda a recuperar uma instância em um momento específico. Por exemplo, se houver perda de dados devido a um erro, será possível recuperar um banco de dados no estado anterior a esse evento. Uma recuperação pontual sempre cria uma instância nova. Não é possível executar esse processo em uma instância existente. As exportações levam mais tempo para serem estruturadas. Isso ocorre porque um arquivo externo que pode ser usado para refazer seus dados é criado no Cloud Storage. Elas não serão afetadas se você excluir a instância. Além disso, é possível exportar apenas um único banco de dados ou até mesmo uma tabela, dependendo do formato de exportação escolhido. |
Dimensionar instâncias de acordo com a retenção do registro de transações (binária). | Uma alta atividade de gravação no banco de dados pode gerar um grande volume de registros de transação (binária), que pode consumir muito espaço em disco e levar ao crescimento do disco de instâncias ativadas para aumentar o armazenamento automaticamente. Recomendamos dimensionar o armazenamento da instância para considerar a retenção do registro de transações. |
Proteger sua instância e seus backups contra exclusão acidental. | Uma instância do Cloud SQL criada no console do Google Cloud ou pelo Terraform permite a prevenção contra exclusão acidental por padrão. Use o recurso de exportação no Cloud SQL para exportar seus dados e aumentar a proteção. Use o Cloud Scheduler com a API REST para automatizar o gerenciamento de exportações. Para cenários mais avançados, use o Cloud Scheduler com o Cloud Run functions para automação. |
A seguir
Para mais informações sobre as práticas gerais por mecanismo de banco de dados, consulte:
- Práticas recomendadas gerais para MySQL
- Práticas recomendadas gerais para PostgreSQL
- Práticas recomendadas gerais para o SQL Server