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 |
| 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%. 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. |
| Certifique-se de que a sua instância tem IDs das transações ideais. |
Pode ver a utilização do ID da transação
da sua instância na página Explorador de métricas na
Google Cloud consola definindo A otimização e a monitorização das instâncias da base de dados podem ajudar a reduzir ou evitar problemas relacionados com o vácuo. Monitorize a utilização do ID da transação da sua instância e ative e ajuste os parâmetros |
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 tabelas de base de dados. |
Mantenha o número de tabelas da instância inferior a 10 000. Um número excessivo de tabelas de base de dados pode afetar o tempo de atualização da base de dados. |
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. |
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. |
Ajuste e monitorize
A otimização e a monitorização das instâncias da base de dados podem ajudar a reduzir ou evitar problemas relacionados com o vácuo.
A operação VACUUM tem diferentes variantes com diferentes níveis de bloqueio: VACUUM padrão e VACUUM FULL.
A opção VACUUM FULL pode reclamar mais espaço em disco, mas bloqueia exclusivamente a tabela e é executada lentamente. Em alternativa, use a forma padrão de
VACUUM, que pode ser executada em paralelo com as operações da base de dados de produção.
Quando usa a operação VACUUM, os comandos como SELECT, INSERT, UPDATE, and DELETE continuam a funcionar normalmente. Não pode modificar a definição de uma tabela com comandos como ALTER TABLE enquanto está a ser limpa.
Seguem-se algumas recomendações que podem ajudar a reduzir o tempo necessário para concluir a operação VACUUM:
- Aumentar a memória do sistema e
maintenance_work_mem. Este processo agrupa mais tuplos em cada iteração e conclui o trabalho o mais rapidamente possível. Tenha em atenção que, quando o autovacuum é executado, pode ser alocada atéautovacuum_max_workersvezes esta memória, pelo que deve ter cuidado para não definir o valor predefinido demasiado elevado. - A operação
VACUUMgera muitos registos de registo antecipado (WAL). Se for possível reduzir o número de registos WAL, por exemplo, não tendo réplicas configuradas para esta instância, a operação é concluída mais rapidamente. - Se a tabela tiver atingido o limite de dois mil milhões de IDs de transações porque nenhum dos tuplos está congelado, experimente reduzir a quantidade de trabalho feito no modo de utilizador único. Uma opção possível é definir
vacuum_freeze_min_age=1,000,000,000(o valor máximo permitido, que é superior ao valor predefinido de 50 000 000). Este novo valor reduz o número de tuplos congelados até duas vezes. - A versão 12.0 e as versões posteriores do PostgreSQL suportam a limpeza e as operações
VACUUMsem limpar as entradas de índice. Isto é crucial, uma vez que a limpeza do índice requer uma análise completa do índice e, se existirem vários índices, o tempo total depende do tamanho do índice. - Os índices maiores consomem uma quantidade significativa de tempo para a análise de índice. Por isso, é preferível usar
INDEX_CLEANUP OFFpara limpar rapidamente e congelar os dados da tabela. As versões do PostgreSQL anteriores à 12.0 têm de ajustar o número de índices. Ou seja, se existirem índices não críticos, pode ser útil remover o índiceNON-CRITICALpara acelerar a operação de limpeza.