Colocação em escala 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 colocação em escala vertical e horizontal.

Colocação em escala vertical: você pode colocar em escala verticalmente adicionando mais recursos à instância de servidor flexível do Banco de Dados do Azure para PostgreSQL, como aumentar o número atribuído por instância de CPUs e memória. 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á alterar de forma independente:

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

O número de vCores pode ser ampliado ou reduzido, mas o tamanho do armazenamento só pode ser aumentado. Você também pode aumentar ou diminuir o período de retenção de backup, de 7 a 35 dias. Os recursos podem ser colocados em escala usando várias ferramentas, por exemplo, o portal do Azure ou a CLI do Azure.

Colocação em escala horizontal: você pode escalar 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.

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 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.

O dimensionamento do armazenamento não requer uma reinicialização do servidor na maioria dos casos. Para obter mais detalhes, consulte Opções de armazenamento no Banco de Dados do Azure para PostgreSQL com Servidor Flexível. Da mesma forma, as alterações do período de retenção do 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 novo recurso de escala de tempo de inatividade quase zero, 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 colocação em escala, criamos uma nova cópia do servidor (VM) com a configuração atualizada. Sincronizamos esse servidor com o atual e alternamos para a nova cópia com uma interrupção de 30 segundos. Em seguida, desativamos o servidor antigo. 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 servidores configurados para réplica de leitura, as operações de escala precisam 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, veja 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. Esse período não é controlado diretamente pelo processo de colocação em escala. 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 nenhum tempo de inatividade funcione, habilite todas as conexões de entrada/saída entre os IPs na sub-rede delegada ao usar a rede integrada à rede virtual. Se essas conexões não estiverem habilitadas, 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 colocação em escala com quase zero tempo de inatividade não funcionará se houver restrições de capacidade regionais ou limites de cota em assinaturas de clientes.
• 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. Os servidores de réplica passam automaticamente por um processo de colocação em escala regular.
• A colocação em escala com quase nenhum tempo de inatividade não funcionará se um servidor injetado em rede virtual 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 será 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 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 Habilitar a extensão em um servidor flexível.
• O dimensionamento de tempo de inatividade quase zero não funciona com tabelas não registradas. Os clientes que usam tabelas não registradas para qualquer um de seus dados perderão todos os dados nessas tabelas após o dimensionamento de tempo de inatividade quase zero.

Conteúdo relacionado

• Crie uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL no portal.