Dimensionando recursos no Banco de Dados do Azure para PostgreSQL - Servidor Flexível
APLICA-SE A: 
Banco de Dados do Azure para PostgreSQL - Servidor Flexível
O Banco de Dados do Azure para PostgreSQL - Servidor Flexível dá suporte a opções de dimensionamento vertical e horizontal.
Dimensionamento vertical
Você pode dimensionar sua instância verticalmente, adicionando mais recursos à sua 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 memória atribuída a ele.
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 é criada, você pode dimensionar de forma independente:
- Camada de computação e SKU.
- Nível e tamanho do armazenamento.
- Período de retenção de backup.
A camada de computação pode ser dimensionada 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 desses níveis, há uma ampla seleção de hardware pré-configurado de diferentes gerações e com mais ou menos CPUs e mais ou menos memória instalada. Entre essa ampla seleção, você pode escolher aquele que suporta seus requisitos de recursos a qualquer momento, mantendo seus custos operacionais reduzidos e ajustados às suas necessidades.
O número de vCores e memória instalada pode ser dimensionado para cima ou para baixo. O nível de armazenamento também pode ser configurado para cima ou para baixo para se adaptar aos requisitos de taxa de transferência e IOPS que sua carga de trabalho exige. O tamanho do armazenamento só pode ser aumentado. Além disso, dependendo dos seus requisitos, você pode aumentar ou diminuir o período de retenção de backup entre 7 a 35 dias.
Esses recursos podem ser dimensionados usando várias interfaces. Por exemplo, você pode usar o portal do Azure ou a CLI do Azure.
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
Você pode dimensionar sua instância 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.
Em uma configuração dimensionada horizontalmente, a instância primária e as réplicas de leitura também podem ser dimensionadas 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 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. Para obter mais informações, consulte Opções de armazenamento no Banco de Dados do Azure para PostgreSQL - Servidor Flexível.
As alterações no 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.
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 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. Em seguida, é sincronizado com a máquina virtual que está executando sua instância no momento 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 este processo ocorre sem custos adicionais para si.
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. Nenhuma ação do cliente é necessária para usar esse recurso.
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-Liveinerente (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 essas conexões não forem permitidas, 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 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 você estiver usando 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.