Dimensionando recursos no Banco de Dados do Azure para PostgreSQL

Uma instância de servidor flexível Azure Database for PostgreSQL suporta opções de escalabilidade vertical e horizontal.

Dimensionamento vertical

Pode escalar a sua instância verticalmente adicionando mais recursos à sua base de dados Azure para a instância de servidor flexível PostgreSQL. Você pode aumentar ou diminuir o número de CPUs e memória atribuída a ele.

O rendimento de rede da sua instância depende dos valores que escolhe para CPU e memória.

Depois de criar uma instância de servidor flexível Azure Database para PostgreSQL, pode escalar de forma independente:

• Camada de computação e SKU.
• Nível e tamanho do armazenamento.
• Período de retenção de backup.

Pode escalar o nível de computação para cima ou para baixo entre Burstable, General Purpose e Memory Optimized para se ajustar às necessidades da sua carga de trabalho. Em cada um destes níveis, pode escolher entre uma vasta seleção de hardware pré-configurado de diferentes gerações, com diferentes números de CPUs e quantidades de memória instalada. Pode selecionar a opção que suporte as suas necessidades de recursos, mantendo os custos operacionais reduzidos e ajustados às suas necessidades.

Podes aumentar ou diminuir o número de vCores e memória instalada. Também pode configurar o nível de armazenamento para aumentar ou diminuir, a fim de acomodar a largura de banda e os requisitos de IOPS que a sua carga de trabalho exige. Só podes aumentar o tamanho de armazenamento. Dependendo das suas necessidades, pode aumentar ou diminuir o período de retenção de cópias de segurança entre 7 e 35 dias.

Pode escalar estes recursos usando múltiplas interfaces. Por exemplo, pode usar o portal Azure ou o Azure CLI.

Nota

Depois de aumentar o tamanho do armazenamento atribuído à sua instância, não é possível reduzi-lo para um tamanho menor.

Dimensionamento horizontal

O Azure Database para clusters elásticos PostgreSQL permite-lhe escalar horizontalmente a sua base de dados para suportar cargas de trabalho de dados que vão além das capacidades de uma única instância de base de dados. Os clusters elásticos também permitem a possibilidade de executar operações paralelas simultaneamente em todos os nós de um cluster, aumentando significativamente o débito e desbloqueando latência ultra-baixa. Os clusters elásticos oferecem dois modelos de fragmentação de tabelas: fragmentação baseada em linhas e fragmentação baseada em esquemas.

Escala de réplica de leitura

Outra abordagem para escalar a sua instância horizontalmente é criar réplicas de leitura. As réplicas de leitura permitem dimensionar suas cargas de trabalho de leitura em instâncias de servidor flexíveis separadas do Banco de Dados do Azure para PostgreSQL. Eles não afetam o desempenho e a disponibilidade da instância principal.

Numa configuração de escala horizontal, também podes escalar a instância principal e as réplicas de leitura verticalmente.

Quando mudas o número de vCores ou o nível de computação, a instância reinicia para que o novo hardware atribuído comece a executar a carga de trabalho do teu servidor. Durante esse tempo, o sistema muda para o novo tipo de servidor. Nenhuma nova conexão pode ser estabelecida e todas as transações não confirmadas são revertidas.

O tempo total necessário para reiniciar o servidor depende do processo de recuperação de falhas e da atividade do banco de dados no momento da reinicialização. A reinicialização normalmente leva um minuto ou menos, mas pode ser de vários minutos. O tempo depende da atividade transacional quando a reinicialização foi iniciada.

Se a sua aplicação for sensível à perda de transações em processamento que possam ocorrer durante o escalamento de computação, implemente um padrão de repetição de tentativas de transação.

O dimensionamento do armazenamento não requer uma reinicialização do servidor na maioria dos casos. Para obter mais informações, consulte Opções de armazenamento no Banco de Dados do Azure para PostgreSQL.

As alterações no período de retenção de backup são uma operação online.

Para melhorar o tempo de reinicialização, realize operações de escala durante o horário de menor movimento. Essa abordagem reduz o tempo necessário para reiniciar o servidor de banco de dados.

Dimensionamento com tempo de inatividade quase inexistente

O dimensionamento de tempo de inatividade quase nulo é um recurso projetado para minimizar o tempo de inatividade quando você modifica os níveis de armazenamento e computação. Se modificares o número de vCores ou mudares o nível de computação, o servidor reinicia para aplicar a nova configuração. Durante essa transição para o novo servidor, nenhuma ligação nova pode ser estabelecida.

Normalmente, esse processo pode levar entre 2 a 10 minutos com dimensionamento regular. Com o recurso de dimensionamento de tempo de inatividade quase zero, essa duração é reduzida para menos de 30 segundos. Essa redução no tempo de inatividade durante o dimensionamento de recursos melhora a disponibilidade geral da instância do banco de dados.

Como funciona

Quando você atualiza seu Banco de Dados do Azure para instância de servidor flexível PostgreSQL em cenários de escala, o serviço cria uma nova máquina virtual para seu servidor com a configuração atualizada. Depois sincroniza-se com a máquina virtual que está a executar a sua instância e muda para a nova máquina virtual com uma breve interrupção. Em seguida, um processo em segundo plano elimina a máquina virtual antiga.

Este processo permite atualizações contínuas com tempo de inatividade mínimo e é ativado automaticamente quando muda de nível de armazenamento ou de computação. Não precisa de tomar qualquer ação para usar esta capacidade. Essa capacidade é suportada para instâncias de servidor flexíveis do Banco de Dados do Azure para PostgreSQL, tanto em configurações HA quanto não HA.

Para configurações dimensionadas horizontalmente, consistindo em um servidor primário e uma ou mais réplicas de leitura, as operações de dimensionamento devem seguir uma sequência específica para garantir a consistência dos dados e minimizar o tempo de inatividade. Para obter detalhes sobre essa sequência, consulte Dimensionamento com réplicas de leitura.

Nota

O dimensionamento de tempo de inatividade quase nulo é o tipo padrão de operação. Quando as limitações a seguir são encontradas, o sistema muda para o dimensionamento regular, que envolve mais tempo de inatividade em comparação com o dimensionamento de tempo de inatividade quase zero.

Expectativas precisas de tempo de inatividade

• Duração do tempo de inatividade: Na maioria dos casos, o tempo de inatividade varia de 10 a 30 segundos.
• Outras considerações: após um evento de dimensionamento, há um período de DNS Time-To-Live inerente (TTL) de aproximadamente 30 segundos. O processo de dimensionamento não controla diretamente esse período. É uma parte padrão do comportamento do DNS. Do ponto de vista do aplicativo, o tempo total de inatividade experimentado durante o dimensionamento pode estar na faixa de 40 a 60 segundos.

Considerações e limitações

• Para que o dimensionamento de tempo de inatividade quase zero funcione, permita todas as conexões de entrada e saída entre os endereços IP na sub-rede delegada, quando você usar a rede integrada de rede virtual. Se não permitires estas ligações, o processo de escalabilidade sem quase nenhuma interrupção não funciona, e a escalabilidade ocorre através do processo padrão de escalabilidade.
• O dimensionamento de tempo de inatividade quase zero não funciona se houver restrições regionais de capacidade ou limites de cota na sua assinatura.
• O dimensionamento de tempo de inatividade quase nulo não funciona para um servidor de réplica, porque só é suportado no servidor primário. Para servidores de réplica, a operação de dimensionamento passa automaticamente pelo processo regular.
• O dimensionamento de tempo de inatividade quase zero não funciona se um servidor virtual injetado na rede não tiver endereços IP utilizáveis suficientes na sub-rede delegada. Se você tiver um servidor autônomo, um endereço IP extra é necessário. Para uma instância com alta disponibilidade habilitada, dois endereços IP extras são necessários.
• Os slots de replicação lógica não são preservados durante um evento de failover de tempo de inatividade quase nulo. Para manter slots de replicação lógica e garantir a consistência dos dados após uma operação de escala, use a extensão pg_failover_slot . Para obter mais informações, consulte habilitando a extensão pg_failover_slots em uma instância de servidor flexível.
• O dimensionamento de tempo de inatividade quase zero não funciona com tabelas não registradas. Se usares tabelas não logadas para qualquer um dos teus dados, perdes todos os dados nessas tabelas após a escalabilidade quase zero do tempo de inatividade.
• Quase zero não funciona se escalares o cálculo do teu servidor de ou para um tamanho de computação de 1 ou 2 vCores do tier Burstable.

Conteúdos relacionados

• Gerenciar o Banco de Dados do Azure para PostgreSQL