Práticas recomendadas gerais

Esta página fornece práticas recomendadas para obter o melhor desempenho, durabilidade e disponibilidade do Cloud SQL.

Se ocorrerem problemas com a sua instância do Cloud SQL, reveja o seguinte durante a resoluçã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 suas instâncias estão abrangidas pelo ANS do Cloud SQL.
Configure um período de manutenção para a sua instância principal para controlar quando podem ocorrer atualizações disruptivas. Consulte o artigo Período de manutenção.
Para cargas de trabalho com muitas leituras, adicione réplicas de leitura para descarregar o tráfego da instância principal. Opcionalmente, pode usar um equilibrador de carga, como o HAProxy, para gerir o tráfego para as réplicas.
Se eliminar e recriar instâncias regularmente, use uma data/hora no ID da instância para aumentar a probabilidade de os novos IDs de instância serem utilizáveis.
Não inicie uma operação administrativa antes de a operação anterior estar concluída.

As instâncias do Cloud SQL não aceitam novos pedidos de operação até concluírem a operação anterior. Se tentar iniciar uma nova operação prematuramente, o pedido de operação falha. Isto inclui reinícios de instâncias.

O estado da instância na Google Cloud consola não reflete se uma operação está em execução. A marca de verificação verde indica apenas que a instância está no estado RUNNABLE. Para ver se uma operação está em execução, aceda ao separador Operações e verifique o estado da operação mais recente.

Configure o armazenamento para acomodar a manutenção crítica da base de dados.

Se a definição da instância ativar aumentos automáticos de armazenamento estiver desativada ou o limite de aumento automático de armazenamento estiver ativado, certifique-se de que tem, pelo menos, 20% de espaço disponível para acomodar quaisquer operações de manutenção críticas da base de dados que o Cloud SQL possa realizar.

Para receber alertas quando o espaço em disco disponível for inferior a 20%, crie uma política de alertas baseada em métricas para a métrica de utilização do disco com uma posição acima do limite e um valor de 0,8. Para mais informações, consulte o artigo Crie políticas de alerta baseadas em métricas.
Evite a utilização excessiva da CPU.

Pode ver a percentagem de CPU disponível que a sua instância está a usar na página de detalhes da instância na Google Cloud consola. Para mais informações, consulte Métricas. Também pode monitorizar a utilização da CPU e receber alertas a um limite especificado através da criação de políticas de alerta de limite de métricas.

Para evitar a utilização excessiva, pode aumentar o número de CPUs da sua instância. A alteração dos CPUs requer o reinício de uma instância. Se a sua instância já tiver o número máximo de CPUs, tem de dividir a base de dados em várias instâncias.
Evite o esgotamento da memória.

Quando procurar sinais de esgotamento da memória, deve usar principalmente a métrica de utilização. Para evitar erros de falta de memória, recomendamos que esta métrica permaneça abaixo dos 90% para instâncias inferiores ou iguais a 16 GB e 95% para instâncias superiores a 16 GB.

Também pode usar a métrica total_usage para observar a percentagem de memória disponível que a sua instância do Cloud SQL está a usar, incluindo a memória usada pelo contentor da base de dados e a memória alocada pela cache do sistema operativo.

Ao observar a diferença entre as duas métricas, pode identificar a quantidade de memória usada pelos processos em comparação com a quantidade usada pela cache do sistema operativo. Pode reutilizar a memória nesta cache.

Para prever problemas de falta de memória, verifique ambas as métricas e interprete-as em conjunto. Se as métricas forem elevadas, a instância pode ter pouca memória. Isto pode dever-se a uma configuração personalizada, ao facto de a instância ser demasiado pequena para a carga de trabalho ou a uma combinação destes fatores.

Dimensione a sua instância do Cloud SQL para aumentar o tamanho da respetiva memória. A alteração do tamanho da memória da instância requer o reinício da instância. Se a sua instância já tiver o tamanho máximo de memória, tem de fragmentar a base de dados em várias instâncias. Para saber mais sobre a monitorização de ambas as métricas na Google Cloud consola, consulte o artigo Métricas.

Segurança

Prática recomendada Mais informações
Preferir IP privado A menos que seja necessário o acesso ao IP público, é preferível usar o IP privado. Isto ajuda a minimizar as ligações de rede não autorizadas à sua base de dados.
Evite 0.0.0.0/0 nas redes autorizadas Evite incluir 0.0.0.0/0 em Redes autorizadas , uma vez que isto permite o acesso a partir da Internet global sem restrições.
Evite redes autorizadas excessivamente grandes Evite usar prefixos CIDR pequenos em Redes autorizadas , uma vez que isto permite o acesso a partir de um número potencialmente excessivo de anfitriões. Recomendamos um prefixo CIDR não inferior a /16 e, de preferência, superior a /19.
Ative as políticas de palavras-passe Use políticas de palavras-passe de instância para especificar políticas de palavras-passe adequadas para a sua instância da base de dados, de modo a evitar a configuração de palavras-passe fracas, definir o tempo de validade e configurar o bloqueio da conta em tentativas de início de sessão falhadas. Isto é especialmente importante se estiver a configurar a sua instância para um IP público.

Arquitetura de dados

Prática recomendada Mais informações
Divida as instâncias grandes em instâncias mais pequenas, sempre que possível. Quando possível, usar muitas instâncias do Cloud SQL mais pequenas é melhor do que uma instância grande. A gestão de uma instância grande e monolítica apresenta desafios que não são colocados por um grupo de instâncias mais pequenas.
Não use demasiadas bases de dados nem tabelas de bases de dados.

Mantenha a contagem de bases de dados abaixo de 500. Mantenha a contagem de tabelas da instância abaixo de 50 000 ou 500 000 se cumprir o requisito mínimo de hardware de mais de 32 núcleos e mais de 200 GB de memória. Mantenha o número de tabelas de cada base de dados inferior a 50 000. Ter demasiadas bases de dados ou tabelas de bases de dados pode afetar o tempo de atualização da base de dados.

Certifique-se de que as suas tabelas têm uma chave principal ou exclusiva. O Cloud SQL usa a replicação baseada em linhas, que funciona melhor em tabelas com chaves principais ou únicas.

Implementação de aplicações

Prática recomendada Mais informações
Use boas práticas de gestão de ligações, como a pool de ligações e a retirada exponencial. A utilização destas técnicas melhora a utilização de recursos da sua aplicação e ajuda a manter-se dentro dos limites de ligação do Cloud SQL. Para mais informações e exemplos de código, consulte o artigo Gerir ligações à base de dados.
Teste a resposta da sua aplicação a atualizações de manutenção, que podem ocorrer em qualquer altura durante o período de manutenção. Experimente a manutenção self-service para simular uma atualização de manutenção. Durante a manutenção, a sua instância fica indisponível durante um breve período e as ligações existentes são interrompidas. Os implementos de manutenção de testes dão-lhe uma melhor compreensão de como a sua aplicação processa a manutenção agendada e a rapidez com que o sistema consegue recuperar.
Teste a resposta da sua aplicação a comutações por falha, que podem ocorrer em qualquer altura. Pode iniciar manualmente uma comutação por falha através da Google Cloud consola, da CLI gcloud ou da API. Consulte a secção Iniciar comutação por falha.
Evite transações grandes. Mantenha as transações pequenas e curtas. Se for necessária uma atualização de base de dados grande, faça-a em várias transações mais pequenas em vez de numa transação grande.
Se estiver a usar o proxy Auth do Cloud SQL, certifique-se de que está a usar a versão mais atualizada. Consulte o artigo Manter o proxy Auth do Cloud SQL 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 para uma instância temporária, o que permite que a instância principal continue a responder a consultas e a realizar operações com o seu desempenho habitual. Quando a exportação de dados estiver concluída, a instância temporária é eliminada automaticamente.
Acelere as importações para tamanhos de instâncias pequenos. Para instâncias pequenas, pode aumentar temporariamente a CPU e a RAM de uma instância para melhorar o desempenho quando importa grandes conjuntos de dados.
Se estiver a exportar dados para importação no Cloud SQL, certifique-se de que usa o procedimento adequado. Consulte o artigo Exportar dados de um servidor de base de dados gerido externamente.
Quando migrar dados com uma exportação e uma importação, use exatamente o mesmo modo SQL para a importação e a exportação. Consulte Use o mesmo modo SQL para importação e exportação.

Cópia de segurança e recuperação

Prática recomendada Mais informações
Proteja os seus dados com a funcionalidade adequada do Cloud SQL.

As cópias de segurança, a recuperação num ponto específico no tempo e as exportações são formas de oferecer redundância e proteção de dados. Cada uma protege contra cenários diferentes e complementa-se numa estratégia de proteção de dados robusta.

As cópias de segurança são simples e oferecem uma forma de restaurar os dados na sua instância para o estado em que se encontravam no momento em que fez a cópia de segurança. No entanto, as cópias de segurança têm algumas limitações. Se eliminar a instância, as cópias de segurança também são eliminadas. Não pode fazer uma cópia de segurança de uma única base de dados ou tabela. Além disso, se a região onde a instância está localizada estiver indisponível, não pode restaurar a instância a partir dessa cópia de segurança, mesmo numa região disponível.

A recuperação pontual ajuda a recuperar uma instância para um ponto específico no tempo. Por exemplo, se um erro causar uma perda de dados, pode recuperar uma base de dados para o estado em que se encontrava antes de o erro ocorrer. Uma recuperação num momento específico cria sempre uma nova instância. Não pode fazer uma recuperação num momento específico para uma instância existente.

As exportações demoram mais tempo a criar, porque é criado um ficheiro externo no Cloud Storage que pode ser usado para recriar os seus dados. As exportações não são afetadas se eliminar a instância. Além disso, pode exportar apenas uma única base de dados ou até uma tabela, consoante o formato de exportação que escolher.

Dimensionar as instâncias para ter em conta a retenção de registos de transações (binários). A atividade de escrita elevada na base de dados pode gerar um grande volume de registos de transações (binários), o que pode consumir um espaço em disco significativo e levar ao crescimento do disco para instâncias ativadas para aumentar o armazenamento automaticamente. Recomendamos que dimensione o armazenamento de instâncias para ter em conta a retenção de registos de transações.
Proteja a sua instância e cópias de segurança contra eliminação acidental.

Uma instância do Cloud SQL que criar na Google Cloud consola ou através do Terraform ativa a prevenção de eliminação acidental por predefinição.

Use a funcionalidade de exportação no Cloud SQL para exportar os seus dados para proteção adicional. Use o Cloud Scheduler com a API REST para automatizar a gestão de exportações. Para cenários mais avançados, use o Cloud Scheduler com funções do Cloud Run para automatização.