Alta disponibilidad en Azure Database for PostgreSQL: servidor único

  • Artículo

Se aplica a: Azure Database for PostgreSQL: servidor único

Importante

El servicio de servidor único de Azure Database for PostgreSQL está en proceso de retirada. Se recomienda encarecidamente actualizar a Azure Database for PostgreSQL: servidor flexible. Para obtener más información sobre la migración a Azure Database for PostgreSQL: servidor flexible, consulte ¿Qué sucede con el servidor único de Azure Database for PostgreSQL?.

El servicio de Azure Database for PostgreSQL: servidor único proporciona un alto nivel de disponibilidad garantizada gracias al acuerdo de nivel de servicio (SLA) respaldado financieramente con un tiempo de actividad . Azure Database for PostgreSQL proporciona una alta disponibilidad durante los eventos planeados, como la operación de proceso de escalado iniciada por el usuario, y también cuando se producen eventos no planeados, como los errores subyacentes de hardware, software o red. Azure Database for PostgreSQL puede recuperarse rápidamente de las circunstancias más críticas, lo que garantiza que las aplicaciones prácticamente no tengan tiempo de inactividad al usar este servicio.

Azure Database for PostgreSQL resulta adecuado para ejecutar bases de datos esenciales que requieren un tiempo de actividad elevado. Basado en la arquitectura de Azure, el servicio tiene funcionalidades intrínsecas de alta disponibilidad, redundancia y resistencia para mitigar el tiempo de inactividad de la base de datos frente a interrupciones planeadas y no planeadas, sin necesidad de configurar ningún componente adicional.

Componentes de Azure Database for PostgreSQL: servidor único

Componente Descripción
Servidor de bases de datos de PostgreSQL Azure Database for PostgreSQL proporciona seguridad, aislamiento, medidas de seguridad para recursos y una funcionalidad de reinicio rápido para los servidores de bases de datos. Estas funcionalidades facilitan las operaciones como el escalado y la operación de recuperación del servidor de bases de datos después de una interrupción en segundos.
Normalmente, las modificaciones de datos en el servidor de base de datos se producen en el contexto de una transacción de base de datos. Todos los cambios en la base de datos se registran sincrónicamente como registros de escritura previa (WAL) en Azure Storage, que está conectado al servidor de bases de datos. Durante el proceso de punto de comprobación, las páginas de datos de la memoria del servidor de bases de datos también se vacían en el almacenamiento.
Almacenamiento remoto Todos los archivos de datos físicos de PostgreSQL y los archivos WAL se almacenan en Azure Storage, que está diseñado para almacenar tres copias de los datos dentro de una región para garantizar la redundancia, disponibilidad y confiabilidad de los datos. La capa de almacenamiento también es independiente del servidor de bases de datos. Se puede desasociar de un servidor de base de datos con errores y asociarse de nuevo a un nuevo servidor de base de datos en pocos segundos. Además, Azure Storage supervisa continuamente el entorno en busca de errores de almacenamiento. Si se detectan daños en un bloque, se corrige automáticamente mediante la creación de una nueva copia de almacenamiento.
Gateway La puerta de enlace actúa como un proxy de base de datos, enruta todas las conexiones de cliente al servidor de base de datos.

Mitigación del tiempo de inactividad planeado

Azure Database for PostgreSQL está diseñado para proporcionar alta disponibilidad durante las operaciones de tiempo de inactividad planeado.

Captura de pantalla del escalado elástico en Azure PostgreSQL.

  1. Escalado y reducción vertical de servidores de bases de datos PostgreSQL en segundos.
  2. Puerta de enlace que actúa como proxy para enrutar las conexiones de cliente al servidor de bases de datos adecuado.
  3. El escalado vertical del almacenamiento se puede realizar sin tiempo de inactividad. El almacenamiento remoto permite desasociar o volver a asociar rápidamente después de la conmutación por error. Estos son algunos escenarios de mantenimiento planeado:
Escenario Descripción
Escalado y reducción vertical de proceso Cuando el usuario realiza una operación de escalado o reducción vertical de procesos, se aprovisiona un nuevo servidor de base de datos con la configuración de proceso escalado. En el servidor de base de datos anterior, se permite que se finalicen los puntos de comprobación activos, se purgan las conexiones de cliente, se cancelan las transacciones no confirmadas y, a continuación, se apaga el servidor. A continuación, el almacenamiento se desasocia del servidor de base de datos anterior y se conecta al nuevo servidor de base de datos. Cuando la aplicación cliente reintenta la conexión o trata de establecer una conexión nueva, la puerta de enlace dirige la solicitud de conexión al nuevo servidor de bases de datos.
Escalado vertical del almacenamiento El escalado vertical del almacenamiento es una operación en línea y no interrumpe el servidor de base de datos.
Nueva implementación de software (Azure) Las nuevas características de implementación o corrección de errores se producen automáticamente como parte del mantenimiento planeado del servicio. Para obtener más información, consulte la documentación y consulte también el portal.
Actualizaciones de versiones secundarias Azure Database for PostgreSQL revisa automáticamente los servidores de bases de datos según la versión secundaria determinada por Azure. Se produce como parte del mantenimiento planeado del servicio. Esto provocaría un breve tiempo de inactividad en términos de segundos y el servidor de base de datos se reiniciará automáticamente con la nueva versión secundaria. Para obtener más información, consulte la documentación y consulte también el portal.

Mitigación del tiempo de inactividad no planeado

Se puede producir un tiempo de inactividad no planeado como resultado de errores imprevistos, incluidos los errores subyacentes de hardware, los problemas de red y los errores de software. Si el servidor de base de datos deja de funcionar de forma inesperada, se aprovisiona automáticamente un nuevo servidor de base de datos en segundos. El almacenamiento remoto se asocia automáticamente al nuevo servidor de base de datos. El motor de PostgreSQL realiza la operación de recuperación mediante WAL y archivos de base de datos, y abre el servidor de base de datos para permitir que los clientes se conecten. Las transacciones no confirmadas se pierden y la aplicación debe volver a intentarlas. Aunque no se puede evitar un tiempo de inactividad no planeado, Azure Database for PostgreSQL reduce el tiempo de inactividad al realizar de forma automática operaciones de recuperación en el servidor de base de datos y en las capas de almacenamiento sin necesidad de intervención humana.

Captura de pantalla de alta disponibilidad en Azure PostgreSQL.

  1. Servidores de Azure PostgreSQL con funcionalidades de escalado rápido.
  2. Puerta de enlace que actúa como proxy para enrutar las conexiones de cliente al servidor de bases de datos adecuado.
  3. Azure Storage con tres copias para obtener confiabilidad, disponibilidad y redundancia.
  4. El almacenamiento remoto también permite desasociar o volver a asociar rápidamente después de la conmutación por error del servidor.

Tiempo de inactividad no planeado: escenarios de error y recuperación de servicio

Estos son algunos escenarios de error y cómo Azure Database for PostgreSQL se recupera automáticamente:

Escenario Recuperación automática
Error de servidor de bases de datos Si el servidor de base de datos está inactivo debido a un error de hardware subyacente, se quitan las conexiones activas y se anulan las transacciones inactivas. Se implementa automáticamente un nuevo servidor de base de datos y el almacenamiento de datos remotos se adjunta al nuevo servidor de base de datos. Una vez completada la recuperación de la base de datos, los clientes pueden conectarse al nuevo servidor de base de datos a través de la puerta de enlace.

El tiempo de recuperación (RTO) depende de varios factores, por ejemplo, la actividad en el momento del error, como una transacción de gran tamaño y la cantidad de recuperación que se va a realizar durante el proceso de inicio del servidor de bases de datos.

Las aplicaciones que usan bases de datos de PostgreSQL se deben crear de forma que detecten y reintenten conexiones eliminadas y transacciones erróneas. Cuando la aplicación vuelve a intentarlo, la puerta de enlace redirige de forma transparente la conexión al servidor de base de datos recién creado.
Error de almacenamiento Las aplicaciones no verán ningún impacto por los problemas relacionados con el almacenamiento, como un error de disco o un daño de bloque físico. Puesto que los datos se almacenan en tres copias, el almacenamiento sobreviviente proporciona la copia de los datos. Los daños en bloques se corrigen automáticamente. Si se pierde una copia de los datos, se crea automáticamente una nueva.
Error de proceso Los errores de proceso son eventos poco frecuentes. En caso de error de proceso, se aprovisiona un nuevo contenedor de proceso y se le asigna el almacenamiento con archivos de datos, el motor de base de datos de PostgreSQL se activa en el nuevo contenedor y el servicio de puerta de enlace garantiza una conmutación por error transparente sin necesidad de cambios en la aplicación. Tenga en cuenta también que la capa de proceso se ha integrado en la resistencia de la zona de disponibilidad y que un nuevo proceso se activa en otra zona de disponibilidad en caso de error de AZ Compute.

Estos son algunos escenarios de error que requieren de la acciones del usuario para recuperarse:

Escenario Plan de recuperación
Error de región Un error en una región es un evento poco habitual. Sin embargo, si necesita protección ante un error de región, puede configurar una o varias réplicas de lectura en otras regiones para la recuperación ante desastres (DR). (Consulte este artículo sobre cómo crear y administrar réplicas de lectura para más información). En caso de que se produzca un error de nivel de región, puede promover manualmente la réplica de lectura configurada en la otra región para que sea el servidor de base de datos de producción.
Error de zona de disponibilidad El error de una zona de disponibilidad también es un evento poco frecuente. Pero si necesita protección frente a un error de zona de disponibilidad, puede configurar una o varias réplicas de lectura o considerar la posibilidad de usar nuestra oferta de Servidor flexible, que proporciona alta disponibilidad con redundancia de zona.
Errores de usuario o lógicos La recuperación de los errores de usuario, como las tablas eliminadas accidentalmente o los datos actualizados incorrectamente, implica la realización de una recuperación a un momento dado (PITR), de modo que se restauran y recuperan los datos hasta el momento justo antes de que se produjera el error.

Si quiere restaurar únicamente un subconjunto de bases de datos o tablas específicas en lugar de todas las bases de datos del servidor de bases de datos, puede restaurar el servidor de base de datos en una nueva instancia, exportar las tablas a través de pg_dump y, a continuación, usar pg_restore para restaurar esas tablas en la base de datos.

Resumen

Azure Database for PostgreSQL ofrece una capacidad de reinicio rápido de servidores de bases de datos, almacenamiento redundante y enrutamiento eficaz desde la puerta de enlace. Para proteger los datos de forma adicional, puede configurar las copias de seguridad para que se repliquen geográficamente, así como implementar una o varias réplicas de lectura en otras regiones. Con funcionalidades de alta disponibilidad intrínsecas, Azure Database for PostgreSQL protege las bases de datos de las interrupciones más comunes y ofrece un acuerdo de Nivel de Servicio con tiempo de actividad del 99,99 % con respaldo financiero. Todas estas funcionalidades de disponibilidad y confiabilidad permiten que Azure sea la plataforma ideal para ejecutar aplicaciones críticas.

Pasos siguientes