ApsaraDB RDS:Change Serverless to pay-as-you-go

Pré-requisitos

A instância do ApsaraDB RDS for SQL Server deve atender aos seguintes requisitos:

• Edição: High-availability Edition

• Método de faturamento: Serverless

• Estado da instância: Running

Considerações

Ao selecionar um tipo de instância, recomendamos que o número de vCores seja igual ou superior ao limite máximo de RCU atual. Por exemplo, se a instância original tiver um limite máximo de 4 RCUs, selecione um tipo de instância com 4 ou mais vCores.

Limitações

• A alteração do método de faturamento de Serverless para pagamento conforme o uso é permitida apenas uma vez a cada 24 horas.

• A conversão suporta apenas o tipo de instância compartilhada como destino. Caso precise de um tipo diferente, primeiro converta a instância para o tipo compartilhado conforme descrito neste tópico e, em seguida, altere a configuração da instância para o tipo desejado.

Impactos

• Essa conversão exige migração de dados subjacente, que inclui a criação de uma nova instância, backup completo, sincronização de logs incrementais, restauração de dados e chaveamento de rede. O tempo de inatividade normalmente é inferior a 20 minutos. Certifique-se de que sua aplicação tenha capacidade de reconexão automática.

  Duração estimada para converter uma instância Serverless em uma instância de pagamento conforme o uso

  A tabela a seguir lista a duração estimada de cada etapa. As velocidades de backup e restauração são baseadas em tamanhos de dados não comprimidos.

  Operação	Obrigatório	Duração estimada	Observações
  Criar e configurar a nova instância	Sim	10 a 15 minutos	A duração depende da edição do produto e do tipo de instância selecionados.
  Executar um backup completo da instância	Condicional	200 GB/hora	Com base na política de backup completo, se nenhum backup completo tiver sido feito nas últimas 36 horas, um backup completo será executado durante a conversão. Isso equilibra o tempo necessário para a restauração do backup completo e o replay do log de transações. Para reduzir o tempo de conversão, recomendamos fazer o backup dos dados do SQL Server em um momento adequado antes da conversão. Outra opção é iniciar a conversão dentro de 36 horas após a conclusão de um backup completo automático. A velocidade de backup pode variar de acordo com a região e o horário do dia. Para uma estimativa mais precisa do desempenho de backup e restauração, consulte o volume de dados e a duração do último backup completo.
  Restaurar o backup completo na instância de destino	Sim	200 GB/hora	Nenhuma
  Fazer backup dos logs de transações incrementais na instância de origem	Sim	200 GB/hora	Pode ser necessário até 2 minutos adicionais antes e depois do backup de log incremental para tarefas como preparação, finalização e alocação de recursos.
  Aplicar os backups de log de transações incrementais na instância de destino	Sim	200 GB/hora	Pode ser necessário até 2 minutos adicionais antes e depois da aplicação dos backups de log para tarefas como verificação de consistência de backup.
  Colocar o banco de dados online	Sim	Normalmente em até 2 minutos	Consumo de recursos: a aplicação de logs de transações incrementais é uma operação que consome muitos recursos. Para instâncias com tipo pequeno, como 2 vCores e 4 GB de memória, a velocidade de recuperação pode diminuir caso haja um grande volume de logs de transações. Accelerated Database Recovery: o ApsaraDB RDS for SQL Server 2019 e versões posteriores oferecem o recurso Accelerated Database Recovery, que pode reduzir o tempo necessário para colocar o banco de dados online. Para mais detalhes, consulte a documentação oficial da Microsoft.
  Chaveamento de rede e migração de conexão	Sim	10 minutos	Nenhuma

• O endereço IP virtual (VIP) muda durante a conversão devido à migração dos recursos subjacentes. Para garantir a estabilidade e a continuidade do serviço, use o endpoint interno ou endpoint público da instância RDS na sua aplicação, em vez de um endereço IP fixo no código. O endpoint é um nome de domínio dinâmico que roteia automaticamente o tráfego para o endereço IP de backend atualizado.

• Limpe o cache DNS no seu cliente. Se o cliente for uma aplicação baseada em JVM, recomendamos defina o TTL na configuração da JVM para 60 segundos ou menos. Isso garante que, quando o endereço VIP do endpoint mudar, a aplicação obtenha o novo endereço VIP ao consultar o DNS novamente.

  Nota

  Os seguintes métodos para defina o TTL na JVM são fornecidos como referência:

  • Para defina o TTL em todas as aplicações baseadas em JVM, defina o parâmetro networkaddress.cache.ttl como 60 no arquivo $JAVA_HOME/jre/lib/security/java.security.

  • Para defina o TTL apenas para uma aplicação local, adicione java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); no código de inicialização da aplicação, antes que qualquer conexão de rede seja estabelecida — especificamente antes da primeira chamada a InetAddress.getByName().

Faturamento

A conversão de Serverless para pagamento conforme o uso é gratuita. Para mais informações sobre como as instâncias de pagamento conforme o uso são cobradas, consulte Visão geral do faturamento.

Procedimento

1. Acesse a página ApsaraDB RDS Instances. No canto superior esquerdo, selecione a região onde sua instância está localizada e clique em no ID da instância.

2. Na página Basic Information, na seção Configuration Information, clique em Change to Pay-As-You-Go.

3. Na página de compra, configure os parâmetros Instance Type e Switching Time.

4. Clique em Pay Now. Confirme os detalhes de configuração antes e após a alteração, clique em OK e conclua o pagamento.

   Nota

   Durante a conversão, o estado da instância muda para Upgrading/Downgrading. Após a conclusão da conversão, o estado muda para Running.

Perguntas frequentes

P: Após converter uma instância Serverless para pagamento conforme o uso, por que o tipo de pedido é exibido como New Purchase em Expenses and Costs > Order Management?

R: A conversão provisiona uma nova instância de pagamento conforme o uso e migra os dados da instância original, por isso o pedido é registrado como New Purchase.

Operações relacionadas

Ao usar a operação ModifyDBInstanceSpec para alterar o método de faturamento de Serverless para pagamento conforme o uso, observe o seguinte:

• Verifique se o método de faturamento original da instância é Serverless e defina o parâmetro PayType como Postpaid.

• Defina o parâmetro DBInstanceClass com o tipo de instância de destino. Para consultar a lista de tipos de instância suportados, acesse Tipos de instância primária do ApsaraDB RDS for SQL Server.

• Mantenha os demais parâmetros, como capacidade de armazenamento, sem alterações. Eles não podem ser modificados durante a conversão.