Migração Automática da Base de Dados do Azure para PostgreSQL - Servidor Único para Servidor Flexível
APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Único
A migração automática do Banco de Dados do Azure para PostgreSQL – Servidor Único para Servidor Flexível é uma migração iniciada por serviço que ocorre durante uma janela de tempo de inatividade planejada para Servidor Único, separada de sua janela de aplicação de patches ou manutenção. O serviço identifica servidores qualificados e envia notificações antecipadas com etapas detalhadas sobre o processo de migração automática. Você pode revisar e ajustar o cronograma de migração, se necessário, ou enviar uma solicitação de suporte para desativar a migração automática para seus servidores.
A migração automática usa o serviço de migração PostgreSQL do Azure para fornecer uma migração offline resiliente durante a janela de migração planejada. O tempo de inatividade varia de acordo com as características da carga de trabalho. Para benchmarks de velocidade de migração, consulte Azure PostgreSQL Migration Speed Benchmarking. Essa migração elimina a necessidade de migração manual do servidor, permitindo que você se beneficie dos recursos do Servidor Flexível pós-migração, incluindo melhor desempenho de preço, controle granular de configuração do banco de dados e janelas de manutenção personalizadas.
Nota
O serviço de Migração Automática seleciona o servidor único para migrar com base nos seguintes critérios:
- Servidores sem funcionalidades complexas, tais como CMK, Microsoft Entra ID, Réplica de Leitura e ponto final privado.
- Tamanho dos dados <= 100 GB
- O acesso público está ativado
Nota
Caso algum desses recursos, como CMK, Microsoft Entra ID, réplica de leitura e ponto de extremidade privado seja usado, será necessário um planejamento extra. Mencione os detalhes no formulário de nomeação abaixo e entraremos em contacto consigo.
Nomear servidores únicos para migração automática
O processo de nomeação destina-se aos utilizadores que pretendam acelerar voluntariamente a sua migração para o servidor Flexível. Se for proprietário de uma carga de trabalho de Servidor Único, pode agora nomear-se a si próprio (se ainda não tiver sido agendado pelo serviço) para a migração automática. Envie os detalhes do seu servidor através deste formulário.
Verificações de pré-requisitos para migração automática
Analise os seguintes pré-requisitos para garantir uma migração automática bem-sucedida:
A instância do Servidor Único deve estar pronta durante a janela de migração planejada para que a migração automática ocorra.
A instância do Servidor Único deve ter a configuração Negar acesso à rede pública configurada como Não. Você pode encontrar essa opção na folha Segurança de Conexão no portal do Azure.
Para instância de servidor único com SSL habilitado, certifique-se de ter todos os certificados (DigiCertGlobalRootG2 Root CA e DigiCertGlobalRootCA Root CA) disponíveis no armazenamento raiz confiável. Além disso, se você tiver o certificado fixado à cadeia de conexão, crie um certificado de CA combinado com todos os três certificados antes da migração automática agendada para garantir a continuidade de negócios pós-migração.
Se o Banco de Dados do Azure de origem para postgresql Single Server tiver nomes de regra de firewall superiores a 80 caracteres, renomeie-os para garantir que o comprimento do nome seja inferior a 80 caracteres. (O comprimento do nome da regra de firewall suportado no Servidor Flexível é de 80 caracteres, enquanto no Servidor Único o comprimento permitido é de 128 caracteres.)
Processo de migração automática
O processo de migração automática inclui várias fases principais:
Criação de Servidor Flexível de Destino - Um Servidor Flexível é criado para corresponder ao desempenho e ao custo do seu SKU de Servidor Único. Ele herda todas as regras de firewall do Servidor Único de origem.
Migração de dados - A migração de dados ocorre durante a janela de migração designada, normalmente agendada fora do horário comercial para a região de hospedagem do servidor (se a janela for escolhida pelo serviço). O Servidor Único de origem é definido como somente leitura e todos os dados, esquemas, funções de usuário, privilégios e propriedade de objetos de banco de dados são migrados para o Servidor Flexível. Além disso, copia todas as regras de firewall existentes para o servidor flexível, garantindo conectividade ininterrupta.
Comutador DNS - Após a migração de dados, um comutador DNS é executado, permitindo que a cadeia de conexão de Servidor Único existente se conecte perfeitamente ao novo Servidor Flexível. Os formatos de cadeia de conexão Servidor Único e Flexível, bem como os formatos de nome de usuário (username@server_name e nome de usuário), são suportados no Servidor Flexível migrado.
Visibilidade do Servidor Flexível - Após uma migração de dados e um comutador DNS bem-sucedidos, o novo Servidor Flexível aparece sob a sua subscrição e pode ser gerido através do portal do Azure ou da CLI.
Cadeias de Conexão de Servidor Único atualizadas - As cadeias de conexão atualizadas para o Servidor Único herdado são enviadas por meio de notificações de Integridade do Serviço no portal do Azure. Eles também podem ser acessados na página do portal do Servidor Único em Configurações -> Cadeias de Conexão.
Exclusão de Servidor Único - O Servidor Único é retido por sete dias após a migração antes de ser excluído.
Como o servidor flexível postgresql de destino é provisionado?
A camada de computação e a SKU para o servidor flexível de destino são provisionadas com base na camada de preços do servidor único de origem e VCores, conforme mostrado abaixo.
Escalão de Preço do Servidor Único | VCores de Servidor Único | Camada de servidor flexível | Nome SKU flexível do servidor |
---|---|---|---|
Básica | 1 | Expansível | B1ms |
Básica | 2 | Expansível | B2s |
Fins Gerais | 2 | GeneralPurpose | Standard_D2s_v3 |
Fins Gerais | 4 | GeneralPurpose | Standard_D4s_v3 |
Fins Gerais | 8 | GeneralPurpose | Standard_D8s_v3 |
Fins Gerais | 16 | GeneralPurpose | Standard_D16s_v3 |
Fins Gerais | 32 | GeneralPurpose | Standard_D32s_v3 |
Fins Gerais | 64 | GeneralPurpose | Standard_D64s_v3 |
Otimizada para Memória | 2 | MemóriaOtimizado | Standard_E2s_v3 |
Otimizada para Memória | 4 | MemóriaOtimizado | Standard_E4s_v3 |
Otimizada para Memória | 8 | MemóriaOtimizado | Standard_E8s_v3 |
Otimizada para Memória | 16 | MemóriaOtimizado | Standard_E16s_v3 |
Otimizada para Memória | 32 | MemóriaOtimizado | Standard_E32s_v3 |
- A versão, região, cadeia de conexão, assinatura e grupo de recursos do postgresql para o Servidor Flexível de destino permanecerão os mesmos do Servidor Único de origem.
- Para Servidores Únicos com menos de 20 GiB de armazenamento, o tamanho do armazenamento é definido como 32 GiB, pois esse é o limite mínimo de armazenamento no Banco de Dados do Azure para postgresql - Servidor Flexível.
- Para servidores únicos com maior requisito de armazenamento, é alocado armazenamento suficiente equivalente a 1,25 vezes ou 25% mais armazenamento do que o que está sendo usado no servidor único. Durante a cópia de base inicial dos dados, várias instruções de inserção são executadas no destino, o que gera WALs (Write Ahead Logs). Até que esses WALs sejam arquivados, os logs consomem armazenamento no destino e, portanto, a margem de segurança.
- Ambos os formatos de nome de usuário – username@server_name (Servidor Único) e nome de usuário (Servidor Flexível) são suportados no Servidor Flexível migrado.
- Ambos os formatos de cadeia de conexão – Servidor Único e Servidor Flexível são suportados no Servidor Flexível migrado.
Migração automática entre as principais versões do PostgreSQL
Essa migração pode envolver a movimentação de dados do PostgreSQL Single Server (versões 9.5, 9.6 ou 10) para o PostgreSQL 11 no Flexible Server. Observe que essas versões anteriores foram desativadas pela comunidade PostgreSQL. Para garantir segurança, estabilidade e desempenho, recomenda-se a adoção de versões de comunidade suportadas.
Ao migrar entre as principais versões do PostgreSQL, considere os seguintes fatores-chave para garantir uma transição bem-sucedida e suave:
Recursos desativados - Recursos que foram desativados em versões mais antigas podem não estar mais disponíveis no PostgreSQL 11. É importante revisar as notas de versão para verificar se há alterações significativas ou recursos preteridos que possam afetar seu aplicativo.
Teste de aplicativo - Realize testes completos de seu aplicativo no PostgreSQL 11. Preste atenção a possíveis problemas com consultas SQL, funções ou ferramentas de terceiros, pois eles podem se comportar de forma diferente ou falhar inteiramente devido a alterações na versão mais recente.
Alterações de configuração - As atualizações de versão principal geralmente introduzem alterações nos parâmetros do servidor, seja adicionando novos parâmetros ou alterando os valores padrão dos existentes. Essas alterações podem afetar o agrupamento, a execução de consultas e o armazenamento de dados. Para garantir a compatibilidade, teste seu aplicativo em relação a essas configurações atualizadas e resolva quaisquer problemas que surjam. Se você encontrar problemas, use o script fornecido na seção de etapas pós-migração para copiar os parâmetros de servidor existentes da instância do Servidor Único para o Servidor Flexível migrado automaticamente.
Passos pós-migração
Aqui estão as informações necessárias sobre as etapas pós-migração automática.
Se a migração automática envolver a migração entre as principais versões do PostgreSQL, teste completamente seu aplicativo para identificar o impacto de alterações de quebra e ajustes de parâmetros. Faça as alterações necessárias para garantir a compatibilidade e o desempenho ideal.
Todos os scripts Terraform/CLI que você hospeda para gerenciar sua instância de Servidor Único devem ser atualizados com referências de Servidor Flexível.
Os parâmetros do servidor no servidor Flexível são ajustados às normas da comunidade. Se pretender manter os mesmos valores de parâmetros do servidor que o seu servidor Único, pode iniciar sessão através do PowerShell e executar o script aqui para copiar os valores dos parâmetros.
As configurações de Controle de Acesso (IAM) para seu servidor flexível serão herdadas das configurações de Assinatura. Se você tiver fornecido quaisquer atribuições de função específicas para o servidor único, deverá criar essas atribuições de função em seu servidor flexível.
Copie as configurações da página de monitoramento (Alertas, Métricas e Configurações de diagnóstico) para o servidor flexível.
Para ativar Consulta de Informações de Desempenho, tem de ativar o armazenamento de consultas no servidor Flexível, que não está ativado por predefinição.
Se for necessária Elevada Disponibilidade, pode ativar sem qualquer tempo de inatividade.
Verifique se a SKU do servidor flexível corresponde à mencionada na notificação de migração automática de Estado de Funcionamento do Serviço. Se for diferente, reverta-o para a SKU especificada na notificação. Isso é crucial para garantir uma cobrança precisa.
As cadeias de conexão existentes do seu Servidor Único agora apontarão para o Servidor Flexível. Para acessar seu Servidor Único, um novo conjunto de cadeias de conexão foi gerado. Você pode recuperá-los a partir da notificação de Integridade do Serviço enviada para a migração automática do seu Servidor Único.
Manipulando regras de VNet no servidor flexível
No Banco de Dados do Azure para PostgreSQL Single Server, uma regra de rede virtual (VNet) é uma sub-rede listada na ACL (lista de controle de acesso) do servidor. Esta regra permite que o Servidor Único aceite comunicação de nós dentro dessa sub-rede específica. Para o Servidor Flexível, as regras de VNet não são suportadas. Em vez disso, o Servidor Flexível permite criar pontos finais privados, permitindo que o servidor funcione na sua rede virtual. Um ponto final privado atribui um IP privado ao Servidor Flexível, e todo o tráfego entre a sua rede virtual e o servidor desloca-se em segurança através da rede principal do Azure, eliminando a necessidade de exposição à Internet pública.
Após a migração, você deve adicionar um ponto de extremidade privado ao seu Servidor Flexível para todas as sub-redes anteriormente cobertas pelas regras de VNet em seu Servidor Único. Você pode concluir esse processo usando o portal do Azure ou a CLI do Azure. Quando esta etapa for concluída, sua conectividade de rede permanecerá intacta no Servidor Flexível após a migração do Servidor Único.
Backup de retenção de longo prazo
A migração automática de servidores únicos não configura automaticamente o backup de retenção de longo prazo (LTR) após a migração para o servidor flexível. Você pode fazer backup do Banco de Dados do Azure para servidor flexível PostgreSQL com retenção de longo prazo usando o Backup do Azure.
Como verificar se o seu Servidor Único está agendado para Migração Automática
Para determinar se o servidor único está selecionado para migração automática, siga estas etapas:
Notificações de Integridade do Serviço - No portal do Azure, vá para Eventos de Manutenção Planejada da Integridade > do Serviço . Procure eventos rotulados como 'Notificação para migração automática agendada para o Banco de Dados do Azure para Servidor Único PostgreSQL'. As notificações são enviadas 30, 14 e 7 dias antes da data de migração, e novamente durante as etapas de migração: em andamento, concluídas e seis dias antes da desativação do Servidor Único.
Nota
Essas notificações não chegam à sua caixa de entrada por padrão. Para recebê-los por e-mail ou SMS, você precisa configurar os Alertas de Integridade do Serviço seguindo as etapas aqui
Página de Visão Geral do Servidor Único - Navegue até sua instância de Servidor Único no portal do Azure e verifique a página Visão Geral. Se agendada para a migração automática, você encontrará detalhes aqui, incluindo uma opção para adiar a migração por um mês de cada vez ou reagendar dentro do mês atual.
Nota
O agendamento de migração é bloqueado 7 dias antes da janela de migração agendada, durante a qual você não poderá reagendar.
Notificações por email do Azure CXP - A Experiência do Cliente do Azure (CXP) também envia emails diretos para funções clássicas e funções RBAC associadas à assinatura que contém o Servidor Único, fornecendo informações sobre migrações automáticas futuras.
Perguntas mais frequentes (FAQs)
P. Por que estou sendo migrado automaticamente?
A. Seu Banco de Dados do Azure para Postgresql - instância de Servidor Único é elegível para migração automática para nossa principal oferta Banco de Dados do Azure para Postgresql - Servidor Flexível. Essa migração automática remove a sobrecarga para migrar manualmente o servidor. Você pode aproveitar os benefícios do Servidor Flexível, incluindo melhor preço e desempenho, controle granular sobre a configuração do banco de dados e janelas de manutenção personalizadas.
P. Como ocorre a automigração? O que tudo isso migra?
A. O Servidor Flexível é provisionado para corresponder aos mesmos VCores e armazenamento do seu Servidor Único. Em seguida, o Servidor Único de origem é colocado em um estado somente leitura, o esquema e os dados são copiados para o Servidor Flexível de destino. O comutador DNS é executado para encaminhar todas as ligações existentes para o destino e o Servidor Flexível de destino é colocado online. A migração automática migra os bancos de dados (incluindo esquema, dados, usuários/funções e privilégios). A migração é off-line, onde você vê um tempo de inatividade de alguns minutos até 2 horas, dependendo do tamanho da sua carga de trabalho. Para benchmarks de velocidade de migração, consulte Azure PostgreSQL Migration Speed Benchmarking.
P. Como posso configurar ou visualizar alertas de migração automática?
A. Seguem-se as formas de configurar alertas:
- Configure alertas de integridade do serviço para receber notificações de agendamento e progresso de migração automática por e-mail/SMS seguindo as etapas aqui.
- Verifique a notificação de migração automática no portal do Azure seguindo as etapas aqui.
P. Como posso adiar a migração agendada do meu servidor único?
A. Você pode revisar o cronograma de migração navegando até a página Visão geral da sua instância de Servidor Único. Se desejar adiar a migração, você pode adiar por um mês, no máximo, navegando até a página Visão geral da sua instância de servidor único no portal do Azure. Você pode reagendar a migração selecionando outra janela de migração dentro de um mês. Os detalhes da migração serão bloqueados sete dias antes da janela de migração agendada, após a qual você não poderá reagendar. Esta migração automática pode ser adiada mensalmente até 28 de março de 2025.
P. Como posso desativar uma migração automática agendada do meu servidor único?
A. Se desejar desativar a migração automática, você pode levantar um tíquete de suporte para essa finalidade.
P. Que etapas pós-migração devo seguir se meu servidor único usar regras de VNet?
A. As regras de VNet não são suportadas no servidor flexível. Consulte esta secção
P. Preciso reconfigurar backups de retenção de longo prazo no servidor flexível?
A. Sim. Consulte esta secção
P. Que nome de utilizador e cadeia de ligação seriam suportados para o Servidor Flexível migrado?
A. Ambos os formatos de nome de usuário - username@server_name (formato de servidor único) e nome de usuário (formato de servidor flexível) são suportados para o servidor flexível migrado e, portanto, você não precisa atualizá-los para manter a continuidade do aplicativo após a migração. Além disso, ambos os formatos de cadeia de conexão (formato de servidor único e flexível) também são suportados para o servidor flexível migrado.
P. Eu vejo uma diferença de preço na minha potencial mudança de postgresql Basic Single Server para postgresql Flexible Server??
A. Poucos servidores podem ver uma pequena revisão de preço após a migração, pois o limite mínimo de armazenamento em ambas as ofertas é diferente (5 GiB no Servidor Único e 32 GiB no Servidor Flexível). O custo de armazenamento para o Servidor Flexível é marginalmente maior do que o de Servidor Único. Qualquer aumento de preço é compensado por meio de uma melhor taxa de transferência e desempenho em comparação com o Servidor Único. Para obter mais informações sobre preços flexíveis do servidor, consulte este documento:
P. O que acontece se eu não migrar ou meu servidor não for migrado automaticamente até 28 de março de 2025?
A. Após o prazo de aposentadoria de 28 de março de 2025, todos os servidores únicos existentes que não migraram serão forçados a migrar para o servidor flexível. Servidores com recursos adicionais, como CMK ou ponto de extremidade privado, exigirão mais ações do usuário após a migração para garantir a operação normal. Não existe prorrogação da data de descontinuação.