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 sua instância do Cloud SQL, revise o seguinte durante a solução de problemas:

Configuração e administração de instância

Melhores práticas Mais informações
Leia e siga as diretrizes operacionais para garantir que suas instâncias sejam cobertas pelo SLA do Cloud SQL .
Configure uma janela de manutenção para sua instância primária para controlar quando atualizações disruptivas podem ocorrer. Veja a janela Manutenção .
Para cargas de trabalho com muita leitura, adicione réplicas de leitura para descarregar o tráfego da instância primária. Opcionalmente, você pode usar um balanceador de carga como o HAProxy para gerenciar o tráfego para as réplicas.
Se você excluir e recriar instâncias regularmente, use um registro de data e hora no ID da instância para aumentar a probabilidade de que novos IDs de instância sejam utilizáveis.
Não inicie uma operação administrativa antes que a operação anterior tenha sido concluída.

As instâncias do Cloud SQL não aceitarão novas solicitações de operação até que a operação anterior seja concluída. Se você tentar iniciar uma nova operação prematuramente, a solicitação falhará. Isso inclui reinicializações de instâncias.

O status da instância no Google Cloud O console não indica se uma operação está em execução. A marca de seleção verde indica apenas que a instância está no estado RUNNABLE . Para verificar se uma operação está em execução, acesse a aba Operações e verifique o status da operação mais recente.

Configure o armazenamento para acomodar a manutenção crítica do banco de dados.

Se a configuração de instância para aumento automático de armazenamento estiver desabilitada ou o limite de aumento automático de armazenamento estiver habilitado, certifique-se de ter pelo menos 20% de espaço disponível para acomodar quaisquer operações críticas de manutenção de banco de dados que o Cloud SQL possa executar.

Para receber alertas quando o espaço em disco disponível estiver abaixo de 20%, crie uma política de alerta 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 obter mais informações, consulte Criar políticas de alerta baseadas em métricas .

Evite o uso excessivo da sua CPU.

Você pode visualizar a porcentagem de CPU disponível que sua instância está usando na página de detalhes da instância no Google Cloud console. Para obter mais informações, consulte Métricas . Você também pode monitorar o uso da CPU e receber alertas em um limite especificado usando Criar políticas de alerta de limite de métrica .

Para evitar a sobreutilização, você pode aumentar o número de CPUs da sua instância. A troca de CPUs exige a reinicialização da instância. Se a sua instância já atingiu o número máximo de CPUs, você deve fragmentar seu banco de dados em várias instâncias.

Evite o esgotamento da memória.

Ao procurar sinais de esgotamento de memória, você deve usar principalmente a métrica de uso . Para evitar erros de falta de memória, recomendamos que essa métrica permaneça abaixo de 90%.

Você também pode usar a métrica total_usage para observar a porcentagem de 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.

Observando a diferença entre as duas métricas, você pode identificar quanta memória é usada pelos processos em comparação com quanta é usada pelo cache do sistema operacional. Você pode redirecionar a memória desse cache.

Para prever problemas de falta de memória, verifique ambas as métricas e interprete-as em conjunto. Se as métricas parecerem altas, a instância pode estar com pouca memória. Isso pode ocorrer devido a uma configuração personalizada, ao tamanho insuficiente da instância para a carga de trabalho ou a uma combinação desses fatores.

Dimensione sua instância do Cloud SQL para aumentar o tamanho da memória. Alterar o tamanho da memória da instância exige uma reinicialização. Se a sua instância já estiver no tamanho máximo de memória, você deverá fragmentar seu banco de dados entre várias instâncias. Para saber mais sobre como monitorar ambas as métricas, consulte Google Cloud console, veja Métricas .

Certifique-se de que sua instância tenha IDs de transação ideais.

Você pode visualizar o uso do ID de transação da sua instância na página do Metrics Explorer no Google Cloud console definindo o Resource Type como Cloud SQL Database e Metric como Percentage of instance's transaction IDs consumed . Para obter mais informações, consulte Criar gráficos com o Metrics Explorer .

Ajustar e monitorar instâncias de banco de dados pode ajudar a reduzir ou evitar problemas relacionados ao vácuo. Monitore o uso do ID de transação da sua instância e habilite e ajuste os parâmetros autovacuum de acordo com a carga de trabalho na sua instância. Para obter mais informações, consulte Superar a proteção de encapsulamento do ID de transação (TXID) .

Segurança

Melhores práticas Mais informações
Preferir IP privado A menos que seja necessário acesso a um IP público , prefira usar um IP privado . Isso ajudará a minimizar conexões de rede não autorizadas ao seu banco de dados.
Evite 0.0.0.0/0 em redes autorizadas Evite incluir 0.0.0.0/0 em Redes Autorizadas , pois isso permite acesso da Internet global sem restrições.
Evite Redes Autorizadas excessivamente grandes Evite usar prefixos CIDR pequenos em Redes Autorizadas , pois isso permite o acesso de um número potencialmente excessivo de hosts. Recomendamos um prefixo CIDR não menor que /16 e, de preferência, maior que /19.
Habilitar políticas de senha Usando as Políticas de Senha da Instância , especifique políticas de senha apropriadas para sua instância de banco de dados para evitar a configuração de senhas fracas, defina um tempo de expiração e configure o bloqueio de conta em tentativas de login malsucedidas. Isso é especialmente importante se você estiver configurando sua instância para IP público.

Arquitetura de dados

Melhores práticas Mais informações
Divida suas instâncias grandes em instâncias menores, sempre que possível. Sempre que possível, usar muitas instâncias menores do Cloud SQL é melhor do que uma instância grande. Gerenciar uma instância grande e monolítica apresenta desafios que não seriam enfrentados por um grupo de instâncias menores.
Não use muitas tabelas de banco de dados.

Mantenha o número de tabelas da sua instância abaixo de 10.000. O excesso de tabelas pode afetar o tempo de atualização do banco de dados.

Implementação do aplicativo

Melhores práticas Mais informações
Use boas práticas de gerenciamento de conexão, como pool de conexão e recuo exponencial. O uso dessas técnicas melhora o uso de recursos do seu aplicativo e ajuda você a permanecer dentro dos limites de conexão do Cloud SQL. Para obter mais informações e exemplos de código, consulte Gerenciando conexões de banco de dados .
Teste a resposta do seu aplicativo às atualizações de manutenção, que podem ocorrer a qualquer momento durante a janela de manutenção. Experimente a manutenção por autoatendimento para simular uma atualização de manutenção. Durante a manutenção, sua instância fica indisponível por um breve período e as conexões existentes são interrompidas. Testar implementações de manutenção permite entender melhor como seu aplicativo lida com a manutenção programada e a rapidez com que o sistema pode se recuperar.
Teste a resposta do seu aplicativo a failovers, que podem ocorrer a qualquer momento. Você pode iniciar manualmente um failover usando o Google Cloud console, a CLI do gcloud ou a API. Consulte Iniciando o failover .
Evite grandes transações. Mantenha as transações pequenas e curtas. Se for necessária uma grande atualização do banco de dados, faça-a em várias transações menores, em vez de uma única transação grande.
Se você estiver usando o Cloud SQL Auth Proxy, certifique-se de estar usando a versão mais atualizada. Consulte Como manter o proxy de autenticação do Cloud SQL atualizado .

Importação e exportação de dados

Melhores práticas Mais informações
Use exportações sem servidor. Exportações sem servidor transferem a operação de exportação para uma instância temporária, permitindo que a instância primária continue a atender consultas e executar operações com seu 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. Para instâncias pequenas, você pode aumentar temporariamente a CPU e a RAM de uma instância para melhorar o desempenho ao importar grandes conjuntos de dados.
Se você estiver exportando dados para importação no Cloud SQL, certifique-se de usar o procedimento adequado. Consulte Exportando dados de um servidor de banco de dados gerenciado externamente .

Backup e recuperação

Melhores práticas 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 um deles protege contra diferentes cenários e se complementa em uma estratégia robusta de proteção de dados.

Os backups são leves; eles fornecem uma maneira de restaurar os dados da sua instância ao estado em que estavam no momento 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 onde a instância está localizada não estiver disponível, você não poderá restaurá-la a partir desse backup, mesmo em uma 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 perda de dados, você pode recuperar um banco de dados para o estado anterior à ocorrência do erro. Uma recuperação pontual sempre cria uma nova instância; não é possível executar uma recuperação pontual para uma instância existente.

As exportações demoram mais para serem criadas, pois um arquivo externo é criado no Cloud Storage e pode ser usado para recriar seus dados. As exportações não serão afetadas se você excluir a instância. Além disso, você pode exportar apenas um único banco de dados ou até mesmo uma tabela, dependendo do formato de exportação escolhido.

Dimensione as instâncias para contabilizar a retenção do log de transações (binário). Alta atividade de gravação no banco de dados pode gerar um grande volume de logs de transações (binários), o que pode consumir espaço em disco significativo e levar ao crescimento do disco para instâncias habilitadas para aumentar o armazenamento automaticamente. Recomendamos dimensionar o armazenamento da instância para levar em conta a retenção de logs de transações.
Proteja sua instância e backups contra exclusão acidental.

Uma instância do Cloud SQL que você cria no Google Cloud console ou via Terraform habilita a prevenção de exclusão acidental por padrão.

Use o recurso de exportação do Cloud SQL para exportar seus dados e obter proteção adicional. Use o Cloud Scheduler com a API REST para automatizar o gerenciamento de exportações. Para cenários mais avançados, o Cloud Scheduler com funções do Cloud Run para automação.

Sintonize e monitore

Ajustar e monitorar instâncias de banco de dados pode ajudar a reduzir ou evitar problemas relacionados ao vácuo.

A operação VACUUM possui diferentes variantes com diferentes níveis de bloqueio: VACUUM padrão e VACUUM FULL . A opção VACUUM FULL pode recuperar mais espaço em disco, mas bloqueia exclusivamente a tabela e é executada lentamente. 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. Ao usar a operação VACUUM , comandos como SELECT, INSERT, UPDATE, and DELETE continuarão funcionando normalmente. Você não poderá modificar a definição de uma tabela com comandos como ALTER TABLE enquanto ela estiver sendo limpa.

Aqui estão algumas recomendações que podem ajudar a reduzir o tempo necessário para concluir a operação VACUUM :

  • Aumente a memória do sistema e maintenance_work_mem . Isso agrupa mais tuplas a cada iteração e conclui o trabalho o mais rápido possível. Observe que, quando o autovacuum é executado, essa memória pode ser alocada até autovacuum_max_workers vezes, portanto, tome cuidado para não definir um valor padrão muito alto.
  • A operação VACUUM gera muitos registros de log de gravação antecipada (WAL). Se for possível reduzir o número de registros WAL, por exemplo, não configurando réplicas para esta instância, a operação será concluída mais rapidamente.
  • Se a tabela atingiu o limite de dois bilhões de IDs de transação porque nenhuma das tuplas está congelada, tente reduzir a quantidade de trabalho realizado 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, acima do padrão de 50.000.000). Esse novo valor reduz o número de tuplas congeladas em até duas vezes.
  • O PostgreSQL versão 12.0 e versões posteriores suportam operações de limpeza e VACUUM sem limpar as entradas do índice. Isso é crucial, pois a limpeza do índice exige uma varredura completa e, se houver vários índices, o tempo total dependerá do tamanho do índice.
  • Índices maiores consomem uma quantidade significativa de tempo para a varredura de índice, portanto, INDEX_CLEANUP OFF é preferível para limpar e congelar rapidamente os dados da tabela. 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 remover o índice NON-CRITICAL para acelerar a operação de vácuo.