Dimensionamento de recursos no Banco de Dados do Azure para servidor flexível PostgreSQL

Um servidor flexível do Base de Dados do Azure para PostgreSQL suporta opções de escalabilidade vertical e horizontal.

Dimensionamento vertical

Escale o seu servidor verticalmente adicionando mais recursos ao seu servidor flexível Base de Dados do Azure para PostgreSQL. Você pode aumentar ou diminuir o número de CPUs e memória atribuída a ele.

O throughput de rede do teu servidor depende dos valores que escolhes para CPU e memória.

Depois de criar um servidor flexível Base de Dados do Azure para PostgreSQL, pode escalar de forma independente:

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

Escale o nível de computação para cima ou para baixo entre Burstable, Uso Geral e Memória Otimizada para se ajustar às necessidades da sua carga de trabalho. Em cada um destes níveis, escolha 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. Selecione a opção que suporte as suas necessidades de recursos, mantendo os seus custos operacionais reduzidos e ajustados às suas necessidades.

Escala o número de vCores e memória instalada para cima ou para baixo. 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.

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

Dimensionamento horizontal

Clusters elásticos do Base de Dados do Azure para PostgreSQL permitem-lhe escalar a sua base de dados horizontalmente para suportar cargas de trabalho de dados que vão além das capacidades de um único servidor de base de dados. Clusters elásticos também oferecem a possibilidade de executar operações paralelas simultaneamente em todos os nós de um cluster, o que aumenta significativamente a taxa de transferência e desbloqueia 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

Podes escalar o teu servidor horizontalmente criando réplicas de leitura. As réplicas de leitura permitem-te escalar as tuas cargas de trabalho de leitura para servidores flexíveis separados no Base de Dados do Azure para PostgreSQL. Não afetam o desempenho e a disponibilidade do servidor principal.

Numa configuração com escalabilidade horizontal, também pode escalar verticalmente o servidor principal e as réplicas de leitura.

Quando mudas o número de vCores ou o nível de computação, o servidor reinicia para que o novo hardware atribuído comece a executar a tua carga de trabalho do servidor. Durante esse tempo, o sistema muda para o novo tipo de servidor. Não podes estabelecer novas ligações, e todas as transações não comprometidas 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.

Escalabilidade com tempo de inatividade quase nulo

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 esta transição para o novo servidor, não consegues estabelecer novas ligações.

Normalmente, este processo demora entre 2 a 10 minutos com escalabilidade normal. Ao utilizar a funcionalidade de escalonamento com tempo de inatividade quase nulo, reduz a duração 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 atualiza o seu servidor flexível Base de Dados do Azure para PostgreSQL em cenários de escalabilidade, o serviço cria uma nova máquina virtual para o seu servidor com a configuração atualizada. Depois sincroniza-se com a máquina virtual que está a correr o seu servidor e depois muda para a nova máquina virtual com uma breve interrupção. Um processo em segundo plano elimina a antiga máquina virtual.

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. Esta funcionalidade é suportada tanto para o servidor flexível do Base de Dados do Azure para PostgreSQL com HA como sem 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 mais detalhes sobre essa sequência, consulte dimensionamento com réplicas de leitura.

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 com tempo de indisponibilidade quase nulo funcione, permita todas as ligações de entrada e saída entre os endereços IP da sub-rede delegada, quando utilizar a integração 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 um servidor com alta disponibilidade ativada, são necessários dois endereços IP extra.
• 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 os slots de replicação lógica e garantir a consistência dos dados após uma operação de escalamento, use a extensão pg_failover_slot. Para obter mais informações, consulte a ativação da extensão pg_failover_slots numa instância do Servidor Flexível.
• A escalabilidade com tempo de indisponibilidade quase nulo não funciona com tabelas sem registo. 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údo relacionado

• Gerenciar o Banco de Dados do Azure para PostgreSQL