O escalonamento de recursos no Servidor Flexível do Banco de Dados do Azure para PostgreSQL
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 escalonamento vertical e horizontal.
Dimensionamento vertical
Você pode escalar 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 que uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL for criada, você poderá ajustar a escala de forma independente:
- Camada de computação e SKU.
- Camada de armazenamento e tamanho.
- Período de retenção de backup.
A camada de computação pode ser escalada para cima ou para baixo entre Capacidade de intermitência, Uso geral e Otimizado para memória, para se ajustar às necessidades da carga de trabalho. Em cada uma dessas camadas, há uma ampla seleção de hardware pré-configurado de diferentes gerações e com mais ou menos CPUs e memória instaladas. Nessa ampla seleção, você pode escolher a opção que dá suporte aos seus requisitos de recursos a qualquer momento, mantendo seus custos operacionais reduzidos e ajustados às suas necessidades.
O número de vCores e de memória instalada pode ser escalado para cima ou para baixo. A camada de armazenamento também pode ser configurada para cima ou para baixo, visando acomodar os requisitos de taxa de transferência e IOPS que sua carga de trabalho exige. O tamanho de armazenamento só pode ser aumentado. Além disso, dependendo de seus requisitos, você pode aumentar ou diminuir o período de retenção de backup entre 7 e 35 dias.
Esses recursos podem ser escalados usando várias interfaces. Por exemplo, você pode usar o portal do Azure ou o CLI do Azure.
Observação
Depois de aumentar o tamanho do armazenamento atribuído à sua instância, você não poderá reduzi-lo.
Dimensionamento horizontal
Você pode escalar sua instância horizontalmente criando 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 escalada horizontalmente, a instância primária e as réplicas de leitura também podem ser escaladas verticalmente.
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 estiver sensível à perda de transações em pré-lançamento que possam ocorrer durante a colocação em escala de computação, recomendamos implementar 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 Opções de armazenamento no Banco de Dados do Azure para PostgreSQL – Servidor Flexível.
As alterações de período de retenção de backup são uma operação online.
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.
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 passará por uma reinicialização 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. Depois, é sincronizado com a máquina virtual que está executando sua instância e, em seguida, alterna para o novo com uma breve interrupção. Em seguida, um processo em segundo plano elimina a máquina virtual antiga. Todo o processo ocorre sem custo adicional para você.
Esse processo permite atualizações perfeitas, minimizando o tempo de inatividade e garantindo a relação custo-benefício. Esse processo de colocação em escala é disparado quando são feitas alterações nas camadas de armazenamento e computação. Nenhuma ação do cliente é necessária para usar essa funcionalidade.
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, consulte Escala com réplicas de leitura.
Observação
A escala com quase zero tempo de inatividade é o tipo de operação padrão. Quando as limitações a seguir são encontradas, o sistema alterna para a colocação em escala regular, o que envolve mais tempo de inatividade em comparação com a colocação em escala com quase zero tempo de inatividade.
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 essas conexões não estiverem permitidas, o processo de colocação em escala com quase zero tempo de inatividade não funcionará, e a colocação em escala ocorrerá por meio do fluxo de trabalho de colocação em escala 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, consulte como habilitar a extensão pg_failover_slots em uma instância do servidor flexível.
- O dimensionamento de tempo de inatividade quase zero não funciona com tabelas não registradas. Caso esteja usando tabelas não registradas para qualquer um de seus dados, perderá todos os dados nessas tabelas após a escala com quase zero tempo de inatividade.