¿Qué sucede con Azure Database for PostgreSQL: servidor único después del anuncio de retirada?
SE APLICA A:
Azure Database for PostgreSQL: servidor único
**Azure Database for PostgreSQL: el servidor único está en proceso de retirada y está programado para la retirada el 28 de marzo de 2025.
Azure Database for PostgreSQL: servidor único se puso a disposición de manera general en 2018. Dados los comentarios de los clientes y los nuevos avances en el cálculo, la disponibilidad, la escalabilidad y las funcionalidades de rendimiento del entorno de base de datos de Azure, la oferta de servidor único debe retirarse y actualizarse con una nueva arquitectura. El Servidor flexible de Azure Database for PostgreSQL es la próxima generación del servicio y le ofrece lo mejor de la plataforma de base de datos de código abierto de Azure.
Como parte de esta retirada, ya no se admitirá la creación de nuevas instancias de servidor único desde el Azure Portal a partir del 30 de noviembre de 2023. Sin embargo, si debe crear instancias de servidor único para satisfacer las necesidades de continuidad empresarial, puede continuar usando la CLI de Azure hasta marzo de 2025.
Si actualmente tiene un servicio de Servidor único de Azure Database for PostgreSQL que hospeda servidores de producción, nos complace informarle que puede migrar el Servidor único de Azure Database for PostgreSQL al Servidor flexible de Azure Database for PostgreSQL.
Servidor flexible de Azure Database for PostgreSQL es un servicio de base de datos totalmente administrado y listo para la producción diseñado para lograr un control más pormenorizado y una mayor flexibilidad de las funciones de administración de bases de datos y las opciones de configuración. Para más información, visite Azure Database for PostgreSQL: servidor flexible.
Migración desde Servidor único de Azure Database for PostgreSQL a Servidor flexible de Azure Database for PostgreSQL
Obtenga información sobre cómo migrar de Servidor único de Azure Database for PostgreSQL a Servidor flexible de Azure Database for PostgreSQL mediante la servicio de migración de PostgreSQL.
Preguntas más frecuentes (P+F)
Q. ¿Por qué se va a retirar el servidor único de Azure Database for PostgreSQL?
A. Azure Database for PostgreSQL: servidor único se puso a disposición de manera general en 2018. Dados los comentarios de los clientes y los nuevos avances en el cálculo, la disponibilidad, la escalabilidad y las funcionalidades de rendimiento del entorno de base de datos de Azure, la oferta de servidor único debe retirarse y actualizarse con una nueva arquitectura. El Servidor flexible de Azure Database for PostgreSQL es la próxima generación del servicio y le ofrece lo mejor de la plataforma de base de datos de código abierto de Azure.
Q. ¿Por qué se me pide que migre al servidor flexible de Azure Database for PostgreSQL?
R. Azure Database for PostgreSQL: servidor flexible es la mejor plataforma para ejecutar todas las cargas de trabajo de PostgreSQL de código abierto en Azure. El Servidor flexible de Azure Database for PostgreSQL es económico y proporciona un mejor rendimiento en todos los niveles de servicio y más formas de controlar los costos, para una recuperación ante desastres más barata y rápida. Otras mejoras en el servidor flexible incluyen:
- Compatibilidad con la versión 11 y posteriores de Postgres, además de mejoras de seguridad integradas
- Mejor rendimiento de precios y compatibilidad con opciones de proceso de nivel ampliable.
- Se ha mejorado el tiempo de actividad mediante la configuración de espera activa en la misma zona de disponibilidad, o en una diferente, y ventanas de mantenimiento controladas por el usuario.
- Una experiencia de desarrollador simplificada para cargas de trabajo de datos de alto rendimiento.
Q. ¿Cuándo tengo que migrar mi servidor único a un servidor flexible?
A. El Servidor único de Azure Database for PostgreSQL está programado para su retirada el 28 de marzo de 2025, por lo que se recomienda encarecidamente migrar el servidor único a un servidor flexible lo antes posible para garantizar un tiempo suficiente para la ejecución de todo el ciclo de vida de la migración y para aprovechar las ventajas que ofrece el servidor flexible.
Q. ¿Qué ocurre con mis instancias de servidor único de Azure Database for PostgreSQL existentes?
A Las cargas de trabajo existentes de Azure Database for PostgreSQL: servidor único serán compatibles hasta marzo de 2025.
Q. ¿Puedo crear una nueva versión 11 de Servidor único de Azure Database for PostgreSQL después de la fecha de EOL de la comunidad en noviembre de 2023?
A A partir del 30 de noviembre de 2023, ya no podrá crear nuevas instancias de servidor único de PostgreSQL versión 11 a través del Azure Portal. Sin embargo, todavía puede hacerlos a través de la CLI hasta marzo de 2025. Se admiten servidores únicos a través de nuestra directiva de compatibilidad con versiones. Lo mejor sería empezar a migrar a Azure Database for PostgreSQL: servidor flexible inmediatamente.
Q. ¿Puedo seguir ejecutando mi Servidor único de Azure Database for PostgreSQL más allá de la fecha de expiración del 28 de marzo de 2025?
A. Tenemos previsto admitir el servidor único hasta la fecha de vencimiento del 28 de marzo de 2025. Le recomendamos encarecidamente que empiece a planear la migración lo antes posible. Tenemos previsto finalizar la compatibilidad con las implementaciones de servidor único en la fecha de vencimiento del 28 de marzo de 2025.
Q. Después del anuncio de retirada del servidor único, ¿qué ocurre si todavía necesito crear un nuevo servidor único para satisfacer mis necesidades empresariales?
A No estamos deteniendo la capacidad de crear nuevos servidores únicos inmediatamente, por lo que puede seguir creando nuevos servidores a través de la CLI para satisfacer las necesidades empresariales de todas las versiones de PostgreSQL compatibles con Servidor único de Azure Database for PostgreSQL. Le recomendamos encarecidamente que explore el Servidor flexible y vea si satisface sus necesidades. No dude en ponerse en contacto con nosotros si es necesario para que podamos guiarle y sugerir la mejor ruta.
Q. ¿Hay costos adicionales asociados con la realización de la migración?
A. Durante la migración, se paga por el servidor flexible de destino y el servidor único de origen. La configuración y procesamiento del servidor flexible de destino determinarán los costos adicionales en los que se incurre (consulte Precios para obtener más detalles). Una vez que haya dado de baja el servidor único de origen después de una migración correcta, solo pagará por el servidor flexible. El uso del servicio de migración de servidor único a servidor flexible no tiene coste adicional. Si tiene preguntas o preocupaciones sobre el costo de migrar el servidor único a uno flexible, póngase en contacto con su representante de la cuenta Microsoft.
Q. ¿Mi facturación se verá afectada por la ejecución de Azure Database for PostgreSQ: servidor flexible en lugar de Azure Database for PostgreSQL: servidor único?
A. La facturación debe ser comparable si elige una configuración similar a la de Azure Database for PostgreSQL: servidor único. Sin embargo, si selecciona la misma zona o la redundancia de zona con alta disponibilidad para el servidor flexible de destino, su factura será superior a la de su servidor único. La misma zona o alta disponibilidad con redundancia de zona necesita que un servidor en espera activa adicional se acelere y almacene los datos de copia de seguridad redundantes, lo que explica el costo agregado del segundo servidor. Esta arquitectura permite reducir el tiempo de inactividad durante interrupciones no planeadas y mantenimientos planeados. Por lo general, el servidor flexible proporciona un mejor precio por rendimiento, pero esto depende de la carga de trabajo.
Q. ¿Se producirá un tiempo de inactividad al migrar mi Servidor único de Azure Database from PostgreSQL a un servidor flexible?
A El servicio de migración de PostgreSQL admite migraciones sin conexión y en línea. La migración sin conexión requiere tiempo de inactividad de las aplicaciones durante el proceso de migración. La migración en línea le ayuda a migrar bases de datos con un tiempo de inactividad limitado pero con pocas restricciones. Para más información, consulte Servicio de migración de PostgreSQL: Azure Database for PostgreSQL con la opción Servidor único a la opción Servidor flexible.
El tiempo de inactividad depende de varios factores, como el número y el tamaño de las bases de datos, el número de tablas de cada base, el número de índices y la distribución de los datos entre las tablas. También depende de la SKU del servidor de origen y de destino, además de las IOPS disponibles en el servidor de origen y de destino.
Dados los muchos factores implicados en una migración, el mejor enfoque para calcular el tiempo de inactividad de la aplicación es probar la migración en un servidor de recuperación a un momento dado restaurado desde el servidor principal para planear la migración de producción.
Las migraciones sin conexión son menos complejas y tienen pocas posibilidades de error. Son la manera recomendada de migrar cargas de trabajo con ventanas de servicio de un solo servidor a un servidor flexible. La migración en línea se puede usar para entornos de producción con baja tolerancia al tiempo de inactividad.
Q. ¿Habrá actualizaciones futuras del servidor único para que admita las versiones más recientes de PostgreSQL?
A. Se recomienda migrar al Servidor flexible si debe ejecutar en las versiones más recientes del motor de PostgreSQL. Seguimos implementando versiones secundarias publicadas por la comunidad para Postgres versión 11 hasta que la comunidad la retire en noviembre de 2023.
Nota:
Estamos ampliando la compatibilidad con la versión 11 de Postgres después de la fecha de retirada de la comunidad y admitiremos la versión 11 de PostgreSQL en un Servidor único y un Servidor flexible para facilitar esta transición. Considere la posibilidad de migrar a un Servidor flexible para usar las ventajas de las versiones del motor de Postgres más recientes.
Q. ¿En qué se diferencia el Acuerdo de Nivel de Servicio de disponibilidad del servidor flexible de 99,99 % del servidor único?
A La implementación con redundancia de zona del Servidor flexible proporciona disponibilidad del 99,99 % con resistencia de nivel de zona y el Servidor único ofrece una disponibilidad del 99,99 % pero sin resistencia zonal. La arquitectura de alta disponibilidad (HA) de Servidor flexible implementa un servidor en espera activa con proceso y almacenamiento redundantes (con los datos de cada sitio almacenados en 3 copias). Una arquitectura de alta disponibilidad de Servidor único no tiene un servidor en espera activa para ayudar a recuperarse de errores zonales. La arquitectura de alta disponibilidad del Servidor flexible reduce el tiempo de inactividad durante interrupciones no planeadas y el mantenimiento planeado.
Q. Mi servidor único se implementa en una región que no admite Servidor flexible. ¿Cómo debo proceder con la migración?
A Estamos cerca de la paridad regional con un servidor único. Estas son las regiones sin presencia de servidor flexible.
- Este de China (CE y CE2),
- Norte de China (CN y CN2)
- Oeste de la India
- Centro de Suecia
Se recomienda migrar a las regiones CN3/CE3, Centro de la India, Centro de Suecia y Sur de Suecia. Q. Tengo un vínculo privado configurado para mi único servidor. ¿Cómo realizo una migración?
A La compatibilidad con Private Link ya está disponible en el servidor flexible. Puede utilizar el servidor en tiempo de ejecución para pasar a un servidor flexible compatible con Private link. Para más información, consulte Servidor en tiempo de ejecución: Azure Database for PostgreSQL con la opción Servidor único a la opción Servidor flexible.
Q. ¿Hay alguna opción para revertir una migración de Servidor único a Servidor flexible?
A. Puede realizar cualquier número de migraciones de prueba, probar el éxito de la migración y hacer la migración final una vez que esté listo. Las migraciones de prueba no afectan al origen de servidor único, que permanece operativo hasta que se migran y se cambian las cadenas de conexión para que apunten al servidor flexible. Si se producen errores durante la migración de prueba, puede posponer la migración final y mantener el servidor de origen en ejecución. Luego, puede volver a intentar la migración final después de resolver los errores. Después de realizar una migración final a un servidor flexible y abrirla para la carga de trabajo de producción, perderá la capacidad de volver a un servidor único sin incurrir en una pérdida de datos.
Q. Cómo debo migrar mi base de datos (> 1 TB)
A. El servicio de migración de PostgreSQL puede migrar bases de datos de todos los tamaños de un servidor único a un servidor flexible. El servicio de migración no tiene restricciones con respecto al tamaño de las bases de datos.
Q. ¿Se admite la migración entre regiones?
A Sí.
Q. ¿Se admite la migración entre suscripciones?
A El servicio de migración de PostgreSQL admite migraciones entre suscripciones.
Q. ¿Se admite la suscripción entre grupos de recursos?
A El servicio de migración de PostgreSQL admite migraciones entre grupos de recursos.
Q. ¿Hay compatibilidad entre versiones?
A El servicio de migración de PostgreSQL admite la migración desde una versión anterior de PostgreSQL (PG 9.5 y versiones posteriores) hasta cualquier versión superior. Como siempre, la compatibilidad de aplicaciones con versiones de PostgreSQL posteriores debe comprobarse de antemano.
Servicio de migración de PostgreSQL
El servicio de migración PostgreSQL es un servicio eficaz que le permite migrar con facilidad la base de datos de servidor PostgreSQL de un servidor único a un servidor flexible. Con este servicio puede mover fácilmente la base de datos de un servidor local o una máquina virtual a un servidor flexible en la nube, lo que le permite aprovechar la escalabilidad y flexibilidad de la informática en la nube.
Q. ¿Qué componentes de datos, esquemas y metadatos se migran como parte de la migración?
A El servicio de migración de PostgreSQL migra el esquema, los datos y los metadatos del origen al destino. Todos los siguientes componentes de datos, esquemas y metadatos se migran como parte de la migración de la base de datos:
Migración de datos
- Todas las tablas de todas las bases de datos o esquemas.
Migración de esquemas:
- Nomenclatura
- Clave principal
- Tipo de datos
- Posición ordinal
- Valor predeterminado
- Nulabilidad
- Atributos de incremento automático
- Índices secundarios
Migración de metadatos:
- Procedimientos almacenados
- Functions
- Desencadenadores
- Vistas
- Restricciones de clave externa
Q. ¿Cuál es la diferencia entre la migración sin conexión y en línea?
A Con una migración sin conexión, el tiempo de inactividad de la aplicación se inicia cuando comienza la migración. Con una migración en línea, el tiempo de inactividad se limita al momento de transicionar al final del proceso. Sin embargo, usa un mecanismo de replicación lógica que está sujeto a algunas restricciones.
En la tabla siguiente se proporciona información general sobre las opciones de migración sin conexión y en línea.
| Opción | Ventajas | Desventajas | Recomendado para |
|---|---|---|---|
| Sin conexión | - Simple, fácil y menos compleja de ejecutar. - Muy pocas posibilidades de error. - No hay restricciones con respecto a los objetos de base de datos que puede controlar. |
Tiempo de inactividad para las aplicaciones. | - Lo mejor para escenarios en los que la simplicidad y una alta tasa de éxito son esenciales. - Ideal para escenarios en los que la base de datos puede estar sin conexión sin afectar significativamente a las operaciones empresariales. - Adecuado para las bases de datos cuando se puede completar el proceso de migración dentro de una ventana de mantenimiento planeado. |
| En línea | - Tiempo de inactividad mínimo para la aplicación. - Ideal para bases de datos de gran tamaño y para los clientes que tienen requisitos de tiempo de inactividad limitados. |
- La replicación usada en la migración en línea tiene algunas restricciones (por ejemplo, claves principales necesarias en todas las tablas). - Difícil y de ejecución mucho más compleja que la migración sin conexión. - Más probabilidades de errores debido a la complejidad de la migración. - Hay un impacto en el almacenamiento y el proceso de la instancia de origen si la migración se ejecuta durante mucho tiempo. El impacto debe supervisarse estrechamente durante la migración. |
- Más adecuado para empresas en las que la continuidad es crítica y el tiempo de inactividad debe ser mínimo. - Se recomienda para las bases de datos cuando el proceso de migración debe producirse sin interrumpir las operaciones en curso. |
Q. ¿Hay alguna recomendación para optimizar el rendimiento de la migración de Servidor único a Servidor flexible?
A Sí. Para realizar migraciones más rápidas, elija una SKU superior para el servidor flexible. Elija un mínimo de 4VCore o superior para completar la migración rápidamente. Siempre puede cambiar la SKU para que coincida con las necesidades de la aplicación después de la migración. Consulte más procedimientos recomendados.
Q. ¿Cuánto tiempo tarda la migración sin conexión con el servicio de migración de Servidor único a Servidor flexible?
A En la tabla siguiente se muestra el tiempo dedicado a realizar migraciones sin conexión para bases de datos de varios tamaños mediante el servicio de migración de PostgreSQL. La migración se realizó mediante un servidor flexible con la SKU:
Standard_D4ds_v4 (4 núcleos, 16 GB de memoria y 500 IOPS)
| Tamaño de base de datos | Hora (HH:MM) |
|---|---|
| 1 GB | 00:01 |
| 5 GB | 00:03 |
| 10 GB | 00:08 |
| 50 GB | 00:35 |
| 100 GB | 01:00 |
| 500 GB | 04:00 |
| 1000 GB | 07:00 |
Nota
Los números anteriores proporcionan una aproximación del tiempo necesario para completar la migración. Para obtener un tiempo preciso necesario para migrar al servidor, se recomienda encarecidamente tomar una PITR (recuperación a un momento dado) del servidor único y migrarlo con el servicio de migración de PostgreSQL.
Q. ¿Cuánto tiempo tarda la migración en línea con el servicio de migración de Servidor único a Servidor flexible?
A La migración en línea implica los pasos siguientes:
- Copia inicial de bases de datos
- Captura de datos modificados: reproducción de todas las transacciones en el origen durante el paso 1 al destino.
El tiempo que se tarda en el paso 1 es el mismo que para las migraciones sin conexión (consulte la pregunta anterior).
El tiempo necesario para el paso 2 depende de las transacciones que se produzcan en el origen. Si se trata de una carga de trabajo de escritura intensiva, es más larga.
Q. ¿Microsoft ofrece soporte técnico para pasar de Servidor único a Servidor flexible?
A Sí. Además de actualizar continuamente el servicio de migración, trabajamos con equipos de asociados internos que pueden interactuar con usted en todo el proceso de migración. Póngase en contacto con su representante de cuentas para obtener más información.
Q. ¿Puede Microsoft ayudarme a migrar mi Servidor único a Servidor flexible automáticamente? A Sí. Puede designar los servidores para la migración automática. Puede leer más sobre el tema y designar los servidores para la migración automática aquí.
Soporte técnico adicional
Q. Tengo más preguntas sobre la retirada.
A. Puede obtener más información de distintas maneras.
Obtenga respuestas de expertos de la comunidad en Microsoft Q&A.
Si tiene un plan de soporte técnico y necesita ayuda técnica, cree una solicitud de soporte técnico: - En Resumen, escriba una descripción del problema. - En Tipo de problema, seleccione Técnico. - En Suscripción, seleccione la suscripción. - En Servicio, seleccione Mis servicios. - En Tipo de servicio, seleccione Servidor único de Azure Database for PostgreSQL. - En Recurso, seleccione el recurso. - En Tipo de problema, seleccione Migrar a Azure DB for PostgreSQL. - En Subtipo de problema, seleccione Migración de un servidor único a un servidor flexible.
Advertencia
Este artículo no es para usuarios de servidores flexibles de Azure Database for PostgreSQL. Es para clientes de Servidor único de Azure Database for PostgreSQL que necesitan actualizar a Servidor flexible de Azure Database for PostgreSQL.
Sabemos que la migración de servicios puede ser frustrante y nos disculpamos con antelación por cualquier inconveniente que esto pueda causarle. Puede elegir qué escenario funciona mejor para usted y su entorno.