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

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Flexível

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

Dimensionamento vertical: você pode dimensionar verticalmente adicionando mais recursos ao Banco de Dados do Azure para instância de servidor flexível do PostgreSQL, como aumentar o número atribuído à instância de CPUs e memória. A taxa de transferência de rede da sua instância depende dos valores escolhidos para CPU e memória.

Depois que uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL for criada, você poderá alterar independentemente a:

  • CPU (vCores).
  • Quantidade de armazenamento.
  • Período de retenção de backup.

O número de vCores pode ser dimensionado para cima ou para baixo, mas o tamanho do armazenamento só pode ser aumentado. Você também pode dimensionar o período de retenção de backup, para cima ou para baixo, de 7 para 35 dias. Os recursos podem ser dimensionados usando várias ferramentas, por exemplo, o portal do Azure ou a CLI do Azure.

Nota

Depois de aumentar o tamanho do armazenamento, não é possível voltar para um tamanho de armazenamento menor.

Dimensionamento horizontal: você pode dimensionar horizontalmente criando 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.

Quando você altera o número de vCores ou a camada de computação, a instância é reiniciada para que o novo tipo de servidor entre em vigor. 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 seu aplicativo for sensível à perda de transações em voo que podem ocorrer durante o dimensionamento de computação, recomendamos a implementação de um padrão de repetição de transação.

O dimensionamento do armazenamento não requer uma reinicialização do servidor na maioria dos casos. Da mesma forma, as alterações no período de retenção de backup são uma operação on-line. Para melhorar o tempo de reinicialização, recomendamos que você execute operações de escala fora do horário de pico. 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 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 ligação nova pode ser estabelecida.

Normalmente, esse processo pode levar entre 2 a 10 minutos com dimensionamento regular. Com o novo recurso de escalonamento 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, criamos uma nova cópia do seu servidor (VM) com a configuração atualizada. Sincronizamo-lo com o seu atual e mudamos para a nova cópia com uma interrupção de 30 segundos. Em seguida, aposentamos o antigo servidor. O processo ocorre sem nenhum custo extra para você.

Esse processo permite atualizações contínuas, minimizando o tempo de inatividade e garantindo a eficiência de custos. Esse processo de dimensionamento é acionado quando são feitas alterações nas camadas de armazenamento e computação. A experiência permanece consistente para servidores de alta disponibilidade (HA) e não HA. Esse recurso está habilitado em todas as regiões do Azure. Nenhuma ação do cliente é necessária para usar esse recurso.

Para servidores configurados com réplica 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 processo de dimensionamento de tempo de inatividade quase zero é a operação padrã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. Esse período não é controlado diretamente pelo processo de dimensionamento. É 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, habilite todas as conexões de entrada/saída entre os IPs na sub-rede delegada ao usar a rede integrada de rede virtual. Se essas conexões não estiverem habilitadas, o processo de dimensionamento de tempo de inatividade quase zero não funcionará e o dimensionamento ocorrerá por meio do fluxo de trabalho de dimensionamento padrão.
  • O dimensionamento de tempo de inatividade quase zero não funciona se houver restrições regionais de capacidade ou limites de cota nas assinaturas de clientes.
  • O dimensionamento de tempo de inatividade quase zero não funciona para um servidor de réplica porque só é suportado no servidor primário. Para um servidor de réplica, ele passa automaticamente por um processo de dimensionamento regular.
  • O dimensionamento de tempo de inatividade quase zero não funciona se um servidor virtual injetado em rede com uma sub-rede delegada não tiver endereços IP utilizáveis suficientes. Se você tiver um servidor autônomo, um endereço IP extra é necessário. Para um servidor habilitado para HA, 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 em um servidor flexível.
  • Para servidores habilitados para HA, o dimensionamento de tempo de inatividade quase nulo está atualmente habilitado para um conjunto limitado de regiões. Mais regiões serão habilitadas de forma faseada com base na capacidade regional.

Conteúdos relacionados