Práticas recomendadas gerais

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 é possível reutilizar o código de uma instância por alguns dias após sua exclusão.
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 uma nova solicitação 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 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 RUNNABLE. Para ver se há alguma operação em execução, acesse a guia Operações e verifique o status da operação mais recente.

Arquitetura de dados

Prática recomendada Mais informações
Quando possível, fragmente suas instâncias. 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 número maior de instâncias menores.
Não use muitas tabelas de banco de dados.

Muitas tabelas de banco de dados podem afetar o tempo de resposta da instância. Mais de 10.000 tabelas afetam sua cobertura de SLA. Para ver mais informações, consulte Diretrizes operacionais.

Embora as diretrizes operacionais ainda não estejam disponíveis para instâncias do PostgreSQL, os mesmos princípios gerais se aplicam.

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. Alterar o tipo de máquina de uma instância é o mais próximo de uma atualização de manutenção. Verifique se o aplicativo tenta se reconectar ao banco de dados usando a retirada exponencial, de preferência. Isso ocorre por pelo menos 10 minutos para garantir que o aplicativo retomará a operação após um evento de manutenção. Para mais informações, consulte Como gerenciar conexões de banco de dados.
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 Cloud, a ferramenta de linha de comando 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
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.

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. Uma alta atividade de gravação no banco de dados pode gerar um grande volume de registros de transação, 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.

Ajuste e monitoramento

Ajustar e monitorar instâncias de banco de dados pode ajudar a reduzir ou evitar problemas relacionados a limpeza.

A operação VACUUM tem variantes diferentes com níveis diferentes de bloqueio: VACUUM e VACUUM FULL padrão. A opção VACUUM FULL pode recuperar mais espaço em disco, mas é executado muito mais lentamente e bloqueia a tabela de modo exclusivo. Em vez disso, use a forma padrão de VACUUM, que pode ser executada em paralelo com as operações do banco de dados de produção. Quando você usa a operação VACUUM, comandos como SELECT, INSERT, UPDATE, and DELETE continuarão funcionando normalmente. Não será possível modificar a definição de uma tabela com comandos como ALTER TABLE enquanto ela estiver sendo limpa.

Veja algumas recomendações que podem ajudar a reduzir o tempo de conclusão da operação VACUUM:

  • Aumentar a memória do sistema e maintenance_work_mem. Isso agrupa mais tuplas em cada iteração e conclui o trabalho o mais rápido possível. Observe que, quando o autovacuum é executado, até autovacuum_max_workers vezes essa memória pode ser alocada. Por isso, tenha cuidado para não definir o valor padrão muito alto.
  • A operação VACUUM gera muitos registros de gravação (WAL, na sigla em inglês). Se for possível reduzir o número de registros WAL, como nenhuma réplica configurada para essa instância, a operação será concluída mais rapidamente.
  • Se a tabela tiver atingido o limite de dois bilhões de códigos de transação porque nenhuma das tuplas está congelada, tente reduzir a quantidade de trabalho realizada no modo de usuário único. Uma opção possível é definir vacuum_freeze_min_age=1,000,000,000 (o valor máximo permitido, elevado a partir do padrão de 50.000.000). Esse novo valor reduz o número de tuplas congeladas até duas vezes.
  • As versões 12.0 e posteriores do PostgreSQL são compatíveis com a limpeza e operações VACUUM sem limpar as entradas de índice. Isso é fundamental, porque a limpeza do índice requer uma verificação completa. Se houver vários índices, o tempo total dependerá do tamanho deles.
  • Índices maiores consomem um tempo significativo para a verificação de índices. Portanto, INDEX_CLEANUP OFF é preferível para limpar e congelar os dados da tabela rapidamente. As versões do PostgreSQL anteriores à 12.0 precisam ajustar o número de índices. Ou seja, se houver índices não críticos, pode ser útil soltar o índice NON-CRITICAL para acelerar a operação de limpeza.