Compartir a través de

Automigración de Azure Database for PostgreSQL de Servidor Único a Servidor Flexible

SE APLICA A: Azure Database for PostgreSQL - Servidor Único

Ahora se ha retirado el servidor único de Azure Database for PostgreSQL. Como resultado, los artículos de migración relacionados con este servicio se quitarán pronto. Es esencial migrar al servidor flexible de Azure Database for PostgreSQL para garantizar el mantenimiento y el soporte técnico continuos. Revise y complete las migraciones necesarias al servidor flexible antes de que estos recursos ya no estén disponibles.

La migración automática de Azure Database for PostgreSQL: servidor único a servidor flexible es una migración iniciada por el servicio que tiene lugar durante una ventana de tiempo de inactividad planeada para un solo servidor, independiente de su ventana de revisión o mantenimiento. El servicio identifica los servidores aptos y envía notificaciones anticipadas con pasos detallados sobre el proceso de migración automática. Puede revisar y ajustar la programación de migración si es necesario o enviar una solicitud de soporte técnico para rechazar la migración automática para los servidores.

La migración automática usa el servicio de migración de Azure PostgreSQL para ofrecer una migración sin conexión resistente durante la ventana de migración planeada. El tiempo de inactividad varía en función de las características de la carga de trabajo. Para conocer las pruebas comparativas de velocidad de migración, consulte Pruebas comparativas de velocidad de migración de Azure PostgreSQL. Esta migración elimina la necesidad de migración manual del servidor. Después de la migración, puede beneficiarse de características de servidor flexible, como mejorar el rendimiento del precio, el control de configuración de base de datos granular y las ventanas de mantenimiento personalizadas.

Nota:

El servicio de migración automática puede migrar todos los servidores únicos, excepto en los casos siguientes:

  • Servidores con claves administradas por el cliente configuradas
  • Servidores con denegación de acceso a la red pública establecido en Sí

Nominación de servidores únicos para la migración automática

El proceso de designación es para los usuarios que desean realizar voluntariamente un seguimiento rápido de su migración al servidor flexible. Si posee una carga de trabajo de servidor único, ahora puede designarse a usted mismo (si aún no lo ha programado el servicio) para la migración automática. Utilice este formulario para enviar los detalles del servidor.

Comprobaciones de los requisitos previos para la migración automática

Examine los siguientes requisitos previos para asegurarse de que la migración automática se realiza correctamente:

  • Para que se realice la migración automática, la instancia de servidor único debe estar en estado listo durante la ventana de migración planeada.

  • La instancia de servidor único debe tener la opción Denegar acceso a la red pública configurada en No. Puede encontrar esta opción en la página Seguridad de conexión en Azure Portal.

  • En el caso de la instancia de Servidor único con SSL habilitado, asegúrese de tener todos los certificados (DigiCertGlobalRootG2 Root CA y DigiCertGlobalRootCA Root CA) disponibles en el almacén raíz de confianza. Además, si tiene el certificado anclado a la cadena de conexión, cree un certificado CA combinado con los tres certificados antes de la migración automática programada para garantizar la continuidad empresarial después de la migración.

  • Si el servidor único de base de datos de Azure para PostgreSQL de origen tiene nombres de reglas de firewall que superan los 80 caracteres, cámbielos para asegurarse de que el nombre sea inferior a 80 caracteres. (la longitud del nombre de la regla de firewall admitida en el servidor flexible es de 80 caracteres, mientras que en el servidor único la longitud permitida es de 128 caracteres).

Proceso de migración automática

El proceso de migración automática incluye varias fases clave:

  • Creación de servidor flexible de destino: se crea un servidor flexible para que coincida con el rendimiento y el costo de la SKU de servidor único. Hereda todas las reglas de firewall del servidor único de origen.

  • Migración de datos: la migración de datos se produce durante la ventana de migración designada, normalmente programada fuera del horario comercial para la región de hospedaje del servidor (si el servicio elige la ventana). El servidor único de origen se establece en de solo lectura. La migración transfiere todos los datos, esquemas, roles de usuario, privilegios y propiedad del objeto de base de datos al servidor flexible. Además, copia todas las reglas de firewall existentes en el servidor flexible, lo que garantiza una conectividad ininterrumpida.

  • Conmutador DNS: después de la migración de datos, se realiza un conmutador DNS, lo que permite que la cadena de conexión de servidor único existente se conecte sin problemas al nuevo servidor flexible. Tanto los formatos de cadena de conexión de servidor único como flexible, así como los formatos de nombre de usuario (username@server_name y nombre de usuario), se admiten en el servidor flexible migrado.

  • Visibilidad del servidor flexible: después de una migración de datos correcta y un conmutador DNS, el nuevo servidor flexible aparece en la suscripción y se puede administrar a través de Azure Portal o la CLI.

  • Cadenas de conexión de servidor único actualizadas: las cadenas de conexión actualizadas para el servidor único heredado se envían a través de notificaciones de Service Health en Azure Portal. También son accesibles en la página del portal de servidor único en Configuración:> cadenas de conexión.

  • Eliminación de servidor único : el servidor único se conserva durante siete días después de la migración antes de eliminarlo.

¿Cómo se aprovisiona el servidor flexible de Postgresql de destino?

El nivel de computación y la SKU para el Servidor Flexible de destino se aprovisionan en función del nivel de precios y los núcleos virtuales del Servidor Único de origen.

Nivel de precios de servidor único Núcleos virtuales de servidor único Nivel del servidor flexible Nombre de SKU del servidor flexible
Básico 1 Flexible B1ms
Básico 2 Flexible B2s
Uso general 2 Propósito General Standard_D2s_v3
Uso general 4 Propósito General Standard_D4s_v3
Uso general 8 Propósito General Standard_D8s_v3
Uso general 16 Propósito General Standard_D16s_v3
Uso general 32 Propósito General Standard_D32s_v3
Uso general 64 Propósito General Standard_D64s_v3
Memoria optimizada 2 MemoryOptimized Standard_E2s_v3
Memoria optimizada 4 MemoryOptimized Standard_E4s_v3
Memoria optimizada 8 MemoryOptimized Standard_E8s_v3
Memoria optimizada 16 MemoryOptimized Standard_E16s_v3
Memoria optimizada 32 MemoryOptimized Standard_E32s_v3
  • La versión, región, cadena de conexión, suscripción y grupo de recursos de postgresql para el servidor flexible de destino sigue siendo la misma que la configuración del servidor único de origen.
  • En los servidores únicos con menos de 20 GiB de almacenamiento, el tamaño de almacenamiento se establece en 32 GiB, ya que es el límite de almacenamiento mínimo en Azure Database for MySQL: servidor flexible.
  • En los servidores únicos con un mayor requisito de almacenamiento, se asigna un almacenamiento suficiente, que equivale a 1,25 veces o un 25 % más de almacenamiento del que se usa en el servidor único. Durante la copia base inicial de los datos, se ejecutan múltiples instrucciones de inserción en el destino, lo que genera WAL (registros de escritura anticipada). Hasta que se archiven estos WAL, los registros consumirán almacenamiento en el destino y, por lo tanto, afectarán al margen de seguridad.
  • Ambos formatos de nombre de usuario: username@server_name (servidor único) y nombre de usuario (servidor flexible) se admiten en el servidor flexible migrado.
  • Ambos formatos de cadena de conexión: servidor único y servidor flexible se admiten en el servidor flexible migrado.

Migración automática entre las versiones principales de PostgreSQL

Esta migración puede implicar mover datos de PostgreSQL single Server (versiones 9.5, 9.6 o 10) a PostgreSQL 11 en el servidor flexible. La comunidad de PostgreSQL ha retirado estas versiones anteriores. Para garantizar la seguridad, la estabilidad y el rendimiento, se recomienda adoptar versiones de la comunidad compatibles.

Al migrar entre versiones principales de PostgreSQL, tenga en cuenta los siguientes factores clave para garantizar una transición correcta y fluida:

  • Características retiradas : es posible que las características que se retiraron en versiones anteriores ya no estén disponibles en PostgreSQL 11. Es importante revisar las notas de la versión para ver los cambios importantes o las características en desuso que podrían afectar a la aplicación.

  • Pruebas de aplicaciones: realice pruebas exhaustivas de la aplicación en PostgreSQL 11. Preste atención a posibles problemas con consultas, funciones o herramientas de terceros de SQL, ya que podrían comportarse de forma diferente o producir errores por completo debido a cambios en la versión más reciente.

  • Cambios de configuración: las actualizaciones de la versión principal suelen introducir cambios en los parámetros del servidor, ya sea agregando nuevos parámetros o modificando los valores predeterminados de los existentes. Estos cambios pueden afectar a la intercalación, la ejecución de consultas y el almacenamiento de datos. Para garantizar la compatibilidad, pruebe la aplicación con esta configuración actualizada y solucione los problemas que surjan. Si tiene problemas, use el script proporcionado en la sección de pasos posteriores a la migración para copiar los parámetros de servidor existentes de la instancia de servidor único al servidor flexible migrado automáticamente.

Pasos posteriores a la migración

Esta es la información que debe tener en cuenta con respecto a los pasos posteriores a la migración automática.

  • Si la migración automática implica migrar a través de las versiones principales de PostgreSQL, pruebe exhaustivamente la aplicación para identificar el impacto de los cambios importantes y los ajustes de parámetros. Realice los cambios necesarios para garantizar la compatibilidad y un rendimiento óptimo.

  • Los scripts de Terraform/CLI que hospede para administrar la instancia de servidor único deben actualizarse con referencias al servidor flexible.

  • Los parámetros del servidor en Servidor flexible se ajustan a los estándares de la comunidad. Si desea conservar los mismos valores de parámetro de servidor que el servidor único, puede iniciar sesión a través de PowerShell y ejecutar el script aquí para copiar los valores de parámetro.

  • La configuración de control de acceso (IAM) del servidor flexible se hereda de la configuración de suscripción. Si ha proporcionado asignaciones de roles específicas del servidor único, debe crear estas asignaciones de roles en el servidor flexible.

  • Copie la configuración de la página de supervisión (Alertas, Métricas y Configuración de diagnóstico) en el servidor flexible.

  • Para habilitar la información de rendimiento de consultas, debe habilitar el almacén de consultas en el servidor flexible, que no está habilitado de forma predeterminada.

  • Si se necesita alta disponibilidad, puede habilitarla sin tiempo de inactividad.

  • Compruebe que la SKU de servidor flexible coincide con la mencionada en la notificación de migración automática de Service Health. Si es diferente, reviértalo a la SKU especificada en la notificación. Esto es fundamental para garantizar una facturación precisa.

  • Las cadenas de conexión existentes del servidor único ahora apuntan al servidor flexible. Para acceder al servidor único, se genera un nuevo conjunto de cadenas de conexión. Puede recuperarlas de la notificación de Service Health enviada para la migración automática del servidor único.

Control de reglas de red virtual en un servidor flexible

En el servidor único de Azure Database for PostgreSQL, una regla de red virtual (red virtual) es una subred que aparece en la lista de control de acceso (ACL) del servidor. Esta regla permite que el servidor único acepte la comunicación de los nodos dentro de esa subred determinada. En el caso del servidor flexible, no se admiten reglas de red virtual. En su lugar, el servidor flexible permite la creación de puntos de conexión privados, lo que permite que el servidor funcione dentro de la red virtual. Un punto de conexión privado asigna una dirección IP privada al servidor flexible y todo el tráfico entre la red virtual y el servidor viaja de forma segura a través de la red troncal de Azure, lo que elimina la necesidad de exposición pública a Internet.

Después de la migración, debe agregar un punto de conexión privado al servidor flexible para todas las subredes cubiertas anteriormente por las reglas de red virtual en el servidor único. Puede completar este proceso mediante Azure Portal o la CLI de Azure. Una vez completado este paso, la conectividad de red permanecerá intacta en el servidor flexible después de la migración desde un solo servidor.

Copia de seguridad de retención a largo plazo

La migración automática de servidores únicos no configura automáticamente la copia de seguridad de retención a largo plazo (LTR) después de la migración al servidor flexible. Puede realizar una copia de seguridad del servidor flexible de Azure Database for PostgreSQL con retención a largo plazo mediante Azure Backup.

Cómo comprobar si el servidor único está programado para la migración automática

Para determinar si el servidor único está seleccionado para la migración automática, siga estos pasos:

  • Notificaciones del Estado del Servicio: En el Portal de Azure, vaya a los eventos de Estado del Servicio > Mantenimiento Planeado. Busque eventos con la etiqueta "Notificación para la migración automática programada a Azure Database para PostgreSQL Servidor Único". Las notificaciones se envían 30, 14 y 7 días antes de la fecha de migración y de nuevo durante las fases de migración: en curso, completadas y seis días antes de que se retire el servidor único.

    Nota:

    Estas notificaciones no llegan a la bandeja de entrada de forma predeterminada. Para recibirlos por correo electrónico o SMS, debe configurar alertas de Service Health. Para más información, consulte Configuración de alertas de Service Health.

  • Página de información general de servidor único: vaya a la instancia de servidor único en Azure Portal y compruebe la página Información general. Si está programado para la migración automática, encontrará los detalles aquí.

    Nota:

    La programación de migración se bloquea siete días antes de la ventana de migración programada durante la cual no se puede volver a programar.

  • Notificaciones por correo electrónico de Azure CXP: la experiencia del cliente de Azure (CXP) también envía correos electrónicos directos a roles clásicos y roles de RBAC asociados a la suscripción que contiene el servidor único, lo que proporciona información sobre las próximas migración automáticas.

Preguntas más frecuentes (FAQ)

Q. ¿Por qué se está produciendo la migración automática?

A. Su instancia de Azure Database for PostgreSQL: servidor único es apta para la migración local a nuestra oferta insignia de Azure Database for PostgreSQL: servidor flexible. Esta migración automática elimina la sobrecarga que supone migrar un servidor manualmente. Puede aprovechar las ventajas de Servidor flexible, entre las que se incluyen una mejor relación entre precio y rendimiento, control pormenorizado de la configuración de las bases de datos y ventanas de mantenimiento personalizadas.

Q. ¿Cómo tiene lugar la migración automática? ¿Qué tantos elementos migra?

A. El servidor flexible se aprovisiona para que tenga más o menos los mismos núcleos virtuales y el mismo almacenamiento que su servidor único. A continuación, el servidor único de origen se coloca en estado de solo lectura y tanto el esquema como los datos se copian en el servidor flexible de destino. El cambio de DNS se realiza para redirigir todas las conexiones existentes hacia el destino, y el servidor flexible de destino se activa. En la migración automática se migran las bases de datos (incluidos el esquema, los datos, los usuarios y roles, y los privilegios). La migración se realiza sin conexión con tiempo de inactividad desde unos minutos hasta varias horas, dependiendo del tamaño de la carga de trabajo. Para conocer las pruebas comparativas de velocidad de migración, consulte Pruebas comparativas de velocidad de migración de Azure PostgreSQL.

Q. ¿Cómo puedo configurar o ver las alertas de la migración automática?

A. A continuación se muestran las formas en que puede configurar alertas:

  • Para configurar las alertas del estado del servicio para recibir notificaciones sobre el progreso y la programación de la migración automática a través de correo electrónico o SMS, siga estos pasos.
  • Siga estos pasos para comprobar la notificación de migración automática en Azure Portal.

Q. ¿Cómo puedo optar por no recibir una migración automática programada de mi servidor único?

A. Si desea optar por no participar en la migración automática, puede abrir un ticket de soporte para tal fin.

Q. ¿Qué pasos posteriores a la migración debo seguir si mi servidor único usa reglas de red virtual?

A. Las reglas de red virtual no se admiten en el servidor flexible. Consulte esta sección

Q. ¿Es necesario volver a configurar las copias de seguridad de retención a largo plazo en el servidor flexible?

A. Sí. Consulte esta sección

Q. ¿Qué nombre de usuario y cadena de conexión se admitirá para el servidor flexible migrado? ​​

A. Ambos formatos de nombre de usuario: username@server_name (formato de servidor único) y nombre de usuario (formato de servidor flexible) se admiten para el servidor flexible migrado y, por lo tanto, no es necesario actualizarlos para mantener la continuidad de la aplicación después de la migración. Además, ambos formatos de cadena de conexión (formato de servidor único y flexible) también se admiten para el servidor flexible migrado.

Q. Veo una diferencia de precios en mi posible cambio de un servidor único básico de PostgreSQL a un servidor flexible de PostgreSQL.

A. Algunos servidores pueden ver una revisión de precio menor después de la migración, ya que el límite de almacenamiento mínimo en ambas ofertas es diferente (5 GiB en servidor único y 32 GiB en servidor flexible). El costo de almacenamiento del servidor flexible es marginalmente mayor que el del servidor único. Cualquier aumento de precio se traduce en un mejor rendimiento, en comparación con el servidor único. Para obtener más información sobre los precios del servidor flexible, consulte este documento.

Q. ¿Qué ocurre si no migre o mi servidor no se migra automáticamente el 28 de marzo de 2025?

A. Después de la fecha límite de retirada del 28 de marzo de 2025, todos los servidores únicos existentes que no hayan sido migrados serán migrados forzosamente al servidor Flexible. Los servidores con características de complemento, como punto de conexión privado y réplicas de lectura, requieren más acciones por parte del usuario después de la migración para garantizar el funcionamiento normal. No hay extensiones para la fecha de retirada.

Q. ¿Hay alguna advertencia al realizar una actualización de versión principal (MVU) en un servidor de migración automática?

A. Sí, hay una advertencia importante de tener en cuenta. Aunque las actualizaciones de la versión principal a cualquier versión de PostgreSQL compatible con el servidor flexible son totalmente compatibles con los servidores con migración automática, el formato de la cadena de conexión cambia ligeramente después de una actualización correcta. En concreto, el formato de nombre de usuario "username@servername" ya no se admitirá después de la actualización. Si la aplicación o los scripts usan actualmente este formato en la cadena de conexión, debe actualizarlos para que usen el formato estándar: solo "nombre de usuario". Asegúrese de revisar y actualizar todas las cadenas de conexión afectadas después de la actualización para evitar problemas de conexión.

Q. ¿La automigración tiene compatibilidad con la migración de roles autenticados de Microsoft Entra?

A. Sí, la migración automática admite la migración de roles autenticados de Microsoft Entra. Una vez que el servidor se haya migrado automáticamente a un servidor flexible, debe usar el formato entraid@servername como nombre de usuario al iniciar sesión con su id. de Entra. El formato entraid más sencillo no es compatible actualmente.

Ejemplo:

Si el id. de Entra es abc@xyz.com y el nombre del servidor es server1, el nombre de usuario para iniciar sesión en el servidor flexible de migración automática será abc@xyz.com@server1. Intentar iniciar sesión utilizando solo abc@xyz.com como nombre de usuario no funcionará.

Se trata de un problema conocido y Microsoft está trabajando activamente en solucionarlo en futuras actualizaciones.

Contenido relacionado