Dimensionamento de recursos no Banco de Dados do Azure para PostgreSQL

Uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte a opções de dimensionamento vertical e horizontal.

Escala vertical

Você pode dimensionar sua instância verticalmente adicionando mais recursos à instância de servidor flexível do Banco de Dados do Azure para PostgreSQL. Você pode aumentar ou diminuir o número de CPUs e a memória atribuída a elas.

A taxa de transferência de rede da instância depende dos valores escolhidos para CPU e memória.

Depois de criar uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, você poderá dimensionar de forma independente:

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

Você pode dimensionar a camada de computação para cima ou para baixo entre Burstable, General Purpose e Memory Optimized para ajustar-se às necessidades de sua carga de trabalho. Em cada uma dessas camadas, você pode escolher entre uma ampla seleção de hardware pré-configurado de diferentes gerações com números variados de CPUs e quantidades de memória instalada. Você pode selecionar a opção que dá suporte aos seus requisitos de recursos, mantendo seus custos operacionais reduzidos e ajustados às suas necessidades.

Você pode dimensionar o número de vCores e a memória instalada para cima ou para baixo. Você também pode configurar a camada de armazenamento para cima ou para baixo para acomodar os requisitos de taxa de transferência e IOPS que sua carga de trabalho exige. Você só pode aumentar o tamanho do armazenamento. Dependendo de seus requisitos, você pode aumentar ou diminuir o período de retenção de backup entre 7 e 35 dias.

Você pode dimensionar esses recursos usando várias interfaces. Por exemplo, você pode usar o portal do Azure ou a CLI do Azure.

Colocação em escala horizontal

Os clusters elásticos do Banco de Dados do Azure para PostgreSQL permitem que você expanda horizontalmente seu banco de dados para dar suporte a cargas de trabalho de dados que vão além dos recursos de uma única instância de banco de dados. Os clusters elásticos também permitem o potencial de executar operações paralelas simultaneamente em todos os nós em um cluster, aumentando significativamente a taxa de transferência e desbloqueando a latência ultra-baixa. Os clusters elásticos oferecem dois modelos de fragmentação de tabela: fragmentação baseada em linha e fragmentação baseada em esquema.

Escala de réplica de leitura

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

Em uma configuração dimensionada horizontalmente, você também pode dimensionar verticalmente as instâncias primárias e as réplicas de leitura.

Quando você altera o número de vCores ou a camada de computação, a instância é reiniciada para que o novo hardware atribuído comece a executar a carga de trabalho do servidor. Durante esse tempo, o sistema alterna 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 geral 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 levar vários minutos. O tempo depende da atividade transacional quando a reinicialização é iniciada.

Se o aplicativo for sensível à perda de transações em pré-lançamento que podem ocorrer durante o dimensionamento de computação, implemente um padrão de repetição de transação.

A colocação em escala do armazenamento não requer uma reinicialização do servidor na maioria dos casos. Para obter mais informações, consulte as opções de armazenamento no Banco de Dados do Azure para PostgreSQL.

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

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

Escala de Tempo de Inatividade Quase Zero

A colocação em escala com quase zero tempo de inatividade é um recurso projetado para minimizar o tempo de inatividade quando você modifica as camadas de armazenamento e computação. Se você modificar o número de vCores ou alterar a camada de computação, o servidor será reiniciado para aplicar a nova configuração. Durante essa transição para o novo servidor, nenhuma nova conexão pode ser estabelecida.

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

Como ele funciona

Quando você atualiza sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL em cenários de escalonamento, o serviço cria uma nova máquina virtual para o seu servidor com a configuração atualizada. Em seguida, ele é sincronizado com a máquina virtual que está executando sua instância no momento e, em seguida, alterna para a nova máquina virtual com uma breve interrupção. Em seguida, um processo em segundo plano elimina a máquina virtual antiga.

Esse processo permite atualizações perfeitas com tempo de inatividade mínimo e é disparado automaticamente quando você altera as camadas de armazenamento ou computação. Você não precisa tomar nenhuma ação para usar essa funcionalidade. Essa funcionalidade é compatível com instâncias de servidor flexível do Banco de Dados do Azure para PostgreSQL, tanto com alta disponibilidade quanto sem alta disponibilidade.

Para configurações escaladas horizontalmente, que consistem em um servidor primário e uma ou mais réplicas de leitura, as operações de escalonamento 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, confira Escala 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 colocação em escala, há um período de DNS Time-To-Live (TTL) inerente de aproximadamente 30 segundos. O processo de escalonamento não controla diretamente esse período. Ele é uma parte padrão do comportamento DNS. Do ponto de vista do aplicativo, o tempo de inatividade total experimentado durante a colocação em escala pode estar no intervalo de 40 a 60 segundos.

Considerações e limitações

• Para que a colocação em escala com quase zero tempo de inatividade funcione, permita que todas as conexões de entrada e saída entre os endereços IPs na sub-rede delegada ao usar a rede integrada à rede virtual. Se você não permitir essas conexões, o processo de escalonamento com quase zero tempo de inatividade não funcionará e o escalonamento ocorrerá por meio do fluxo de trabalho de escalonamento padrão.
• A escala com quase zero tempo de inatividade não funcionará se houver restrições de capacidade regionais ou limites de cota em suas assinaturas.
• A colocação em escala com quase zero tempo de inatividade não funciona para um servidor de réplica, porque ela só tem suporte no servidor primário. Para servidores de réplica, a operação de escalonamento passa automaticamente pelo processo regular.
• A escala com quase zero tempo de inatividade não funcionará se um servidor injetado em rede virtual 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 será necessário. Para uma instância com alta disponibilidade habilitada, são necessários dois endereços IP extras.
• Os slots de replicação lógica não são preservados durante um evento de failover com tempo de inatividade quase zero. 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, confira como habilitar a extensão pg_failover_slots em uma instância do servidor flexível.
• A colocação em escala de tempo de inatividade quase zero não funciona com tabelas não registradas. Se você usar tabelas não registradas para qualquer um dos seus dados, perderá todos os dados nessas tabelas após o dimensionamento de tempo de inatividade quase zero.
• Quase zero não funcionará se você dimensionar a computação do servidor de ou para um tamanho de computação de 1 ou 2 vCores da camada com capacidade de intermitência.

Conteúdo relacionado

• Gerenciar o Banco de Dados do Azure para PostgreSQL