Esta página apresenta práticas recomendadas gerais para ajudar você a melhorar a performance, a durabilidade e a disponibilidade do AlloyDB para PostgreSQL. Esta página é destinada a administradores de banco de dados e desenvolvedores que já conhecem o AlloyDB e o PostgreSQL.
Configuração e administração de instâncias
use as ferramentas do AlloyDB para monitorar o uso e o status do banco de dados.
Siga as diretrizes operacionais.
Configure uma janela de manutenção para a instância principal.
Adicione instâncias do pool de leitura para descarregar o tráfego de leitura.
Gerencie o lag de replicação.
Não inicie uma operação administrativa antes que a operação anterior seja concluída.
Configure uma cota de armazenamento suficiente para acomodar a manutenção crítica do banco de dados.
Evite o uso excessivo da CPU.
Evite a exaustão de memória.
Verifique se a instância tem os IDs de transação ideais.
Usar ferramentas do AlloyDB para monitorar o uso e o status do banco de dados
Use a tabela a seguir para saber mais sobre as ferramentas do AlloyDB que ajudam a monitorar o uso, o status e o desempenho do banco de dados.
| Ferramenta AlloyDB | Descrição |
|---|---|
| O relatório de resumo de performance | Compara snapshots de métricas do sistema entre dois pontos diferentes no tempo. |
| Insights de consulta | Ajuda a detectar, diagnosticar e evitar problemas de desempenho de consulta em bancos de dados do AlloyDB. Eles oferecem serviço de autoatendimento, monitoramento intuitivo e informações de diagnóstico que vão além da detecção, para ajudar você a identificar a causa raiz dos problemas de performance. |
| Insights do sistema | Permite monitorar recursos e métricas do banco de dados, incluindo contagem de nós ativos, uso da CPU, picos de conexões, erros de registro, transações por segundo e atraso máximo de replicação. |
Seguir as diretrizes operacionais
Para garantir que suas instâncias estejam cobertas pelo SLA do AlloyDB para PostgreSQL, siga as diretrizes operacionais.
Configurar uma janela de manutenção para a instância principal
Configure uma janela de manutenção para a instância principal para planejar quando as atualizações disruptivas podem ocorrer. Para mais informações, consulte Conferir e definir horários de manutenção.
Adicionar instâncias do pool de leitura para descarregar o tráfego de leitura
Para cargas de trabalho com muita leitura, adicione instâncias do pool de leitura para descarregar o tráfego de leitura da instância principal.
Configure um ou mais pools de leitura para cada banco de dados na instância para melhorar o armazenamento em cache.
Considere adicionar outros nós por pool para facilitar o balanceamento automático de carga e a alta disponibilidade.
Gerenciar atraso de replicação
O AlloyDB fez várias melhorias para melhorar o atraso da replicação. No entanto, você pode encontrar cenários em que a repetição de registro é bloqueada ou não pode ser mantida, o que pode aumentar o atraso da replicação.
Por exemplo, se o tamanho da VM principal for muito maior que o tamanho do nó do pool de leitura, em cargas de trabalho de gravação pesadas, a VM principal poderá gerar registros de log mais rápido do que os nós de leitura podem reproduzi-los, especialmente se houver uma carga de leitura pesada em execução simultaneamente nos nós de leitura. Nesse cenário, pode ser útil aumentar o tamanho do nó de leitura para oferecer mais recursos a ele.
Dependendo das necessidades do aplicativo, talvez seja necessário ajustar os seguintes parâmetros:
max_standby_streaming_delay: determina quanto tempo a repetição espera antes de cancelar consultas que estão bloqueando ela.google_storage.log_replay_throttle_read_transactions: determina se as consultas serão limitadas quando o atraso for alto. O estrangulamento de consultas oferece mais recursos de repetição para acompanhar mais rapidamente e evitar o retorno de dados desatualizados às consultas.alloydb.promote_cancel_to_terminate: determina se os back-ends de consulta que não respondem ao cancelamento são encerrados à força.
Não inicie uma operação administrativa antes que a operação anterior seja concluída.
As instâncias do AlloyDB não podem aceitar novas solicitações de operação até que a operação anterior seja concluída. Se você tentar iniciar uma nova operação antes que a anterior seja concluída, 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 se a instância está no estado RUNNABLE. Para saber se uma operação está em execução, clique na guia Operações e verifique o status da operação mais recente.
Configurar cota de armazenamento suficiente para acomodar a manutenção crítica do banco de dados
Por padrão, é possível usar armazenamento de até 16 TB por cluster. Se você precisar de mais armazenamento, aumente sua cota de armazenamento.
Evite o uso excessivo da CPU
É possível conferir a porcentagem de CPU disponível que a instância está usando na página "Detalhes da instância" no console Google Cloud . Para mais informações, consulte Monitorar instâncias. 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, escalone a instância para um número maior de CPUs. É necessário reiniciar a instância para alterar as CPUs. Se a instância já tiver o número máximo de CPUs, recomendamos que você divida o banco de dados em várias instâncias.
Evite a exaustão de memória
O AlloyDB tem gerenciamento automático de memória para evitar problemas de falta de memória. No entanto, a pressão constante de memória pode causar problemas de desempenho. Ao procurar sinais de esgotamento da memória, use principalmente a métrica uso. Recomendamos que essa métrica permaneça abaixo de 90% para um desempenho ideal.
Também é possível usar a métrica total_usage para observar a porcentagem de memória disponível que sua instância do AlloyDB 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 métricas de uso e uso total, é possível identificar a quantidade de memória usada pelos processos em comparação com a quantidade usada pelo cache do sistema operacional. É possível reaproveitar a memória nesse cache.
Dimensione a instância do AlloyDB 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 da memória, será necessário dividir o banco de dados em várias instâncias.
Para mais informações sobre como monitorar o uso e as métricas de uso total no console do Google Cloud , consulte Monitorar instâncias.
Verifique se a instância tem os IDs de transação ideais
Para conferir o uso do ID de transação da instância, acesse a página Metrics Explorer
no console do Google Cloud ,
definindo Resource Type como AlloyDB for PostgreSQL Database e
Metric como Percentage of instance's transaction IDs consumed. Para mais
informações, consulte
Criar gráficos com o Metrics Explorer.
O AlloyDB tem um autovacuum adaptativo integrado que ajuda a reduzir problemas relacionados a ele.
Arquitetura de dados
divida suas instâncias grandes em instâncias menores, quando possível.
Não use muitas tabelas de banco de dados.
Divida as instâncias grandes em instâncias menores, quando possível
Sempre que possível, use muitos clusters menores do AlloyDB em vez de uma instância grande. Gerenciar uma instância grande e monolítica apresenta desafios que não são criados por um grupo de instâncias menores.
Não use muitas tabelas de banco de dados
Mantenha a contagem da tabela de instâncias abaixo de 10.000. Muitas tabelas de banco de dados podem afetar o tempo de upgrade do banco de dados.
Desempenho da consulta
ative o mecanismo colunar se você executar consultas analíticas.
Aumente a instância para melhorar o desempenho da consulta.
Implante os pools de leitura e descarregue as consultas de leitura para o pool de leitura.
Ative o mecanismo colunar se você executar consultas analíticas
Leia uma visão geral do mecanismo de colunas do AlloyDB. Verifique os tipos de consultas que se beneficiam da ativação do mecanismo de colunas.
É possível monitorar o uso do mecanismo de colunas.
Se você não conhece o mecanismo de colunas, comece a se familiarizar com a colunização automática. Em seguida, você pode gerenciar as colunas manualmente.
Ampliar a instância para melhorar a performance da consulta
Se você estiver com um desempenho de consulta baixo, considere aumentar a instância.
Cada SKU tem configurações limitadas de vCPU e memória, além de um cache rápido limitado. Se o tamanho dos dados for grande e a performance das consultas estiver ruim, considere aumentar a instância.
Implantar pools de leitura e descarregar consultas de leitura para o pool de leitura
Se o aplicativo realizar muitas gravações e leituras, considere implantar pools de leitura e descarregar consultas de leitura para o pool de leitura.
Para cargas de trabalho com muita leitura, adicione instâncias do pool de leitura para descarregar o tráfego de leitura da instância principal.
Implementação do aplicativo
use boas técnicas de gerenciamento de conexões.
Teste a resposta do aplicativo às atualizações de manutenção.
Teste a resposta do aplicativo a failovers.
Evite transações grandes.
Evite um grande número de subtransações.
Use a versão mais recente do Auth Proxy.
Use boas práticas de gerenciamento de conexão
Use as práticas recomendadas de gerenciamento de conexão, como o pooling de conexões e a espera exponencial.
O uso de boas técnicas de gerenciamento de conexão melhora o uso de recursos do seu aplicativo e ajuda a permanecer dentro dos limites de conexão do AlloyDB.
Testar a resposta do aplicativo às atualizações de manutenção
Teste a resposta do aplicativo às atualizações de manutenção, que podem acontecer a qualquer momento durante a janela de manutenção.
É possível simular uma atualização de manutenção executando operações de escalonamento de computação ou atualizando flags estáticas do PostgreSQL que acionam a manutenção com pouco tempo de inatividade (LDTM, na sigla em inglês).
Durante o LDTM, sua instância fica indisponível por um breve período, e as conexões atuais são descartadas. Testar o LDTM permite uma melhor compreensão de como seu aplicativo lida com a manutenção programada e com que rapidez o sistema pode se recuperar.
Testar a resposta do aplicativo a failovers
Teste a resposta do aplicativo a failovers, que podem acontecer a qualquer momento.
É possível iniciar manualmente um failover usando o console do Google Cloud , a Google Cloud CLI ou a API. Para mais informações, 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 executar uma grande.
Evite um grande número de subtransações
Evite um grande número de subtransações em uma transação quando transações de longa duração estiverem presentes.
No AlloyDB, a execução de uma transação em um bloco de erro PL/pgSQL cria subtransações da transação correspondente ao bloco de erro. O desempenho geral do sistema é prejudicado se o número de subtransações exceder 64 na presença de transações de longa duração.
Use a versão mais recente do Auth Proxy
Se você estiver usando o proxy de autenticação do AlloyDB, use a versão mais recente. Para mais informações, consulte Manter o cliente do proxy de autenticação atualizado.
Importação e exportação de dados
restaurar de backups do Cloud SQL para PostgreSQL para migração.
Acelere as importações para instâncias pequenas.
Restaurar de backups do Cloud SQL para PostgreSQL para migração
Para facilitar a migração, consulte Migrar do Cloud SQL para PostgreSQL para o AlloyDB.
Para saber como migrar dados do Cloud SQL para PostgreSQL para o AlloyDB usando a replicação contínua de dados, consulte Database Migration Service para PostgreSQL para AlloyDB.
Acelerar as importações para instâncias pequenas
Ao importar conjuntos de dados grandes para instâncias pequenas, é possível aumentar temporariamente a CPU e a RAM de uma instância para melhorar a performance.
Backup e recuperação
proteja seus dados usando os recursos apropriados do AlloyDB.
Proteja sua instância e os backups contra exclusão acidental.
Proteja seus dados usando os recursos apropriados do AlloyDB
Use backups, recuperação pontual (PITR) e exportações para redundância e proteção. Cada uma protege contra diferentes cenários e se complementam em uma estratégia robusta de proteção de dados.
Os backups são leves e fornecem uma forma de restaurar os dados na sua instância ao estado em que você fez o backup. No entanto, o recurso de backup do AlloyDB tem 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 restaurar a instância, 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 nova instância. 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. As exportações não serão afetadas se você excluir a instância. Além disso, é possível exportar apenas um único banco de dados ou tabela, dependendo do formato de exportação.
Proteger sua instância e seus backups contra exclusão acidental
Para ativar a prevenção de exclusão acidental padrão, crie uma instância do AlloyDB usando o console do Google Cloud ou o Terraform.
Use o recurso de exportação no AlloyDB para exportar seus dados e aumentar a proteção. Use o Cloud Scheduler com a API Cloud Scheduler para automatizar o gerenciamento de exportações.
Para cenários mais avançados, use o Cloud Scheduler com as funções do Cloud Run para automação.