Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La continuidad empresarial en Azure Database for PostgreSQL hace referencia a los mecanismos, directivas y procedimientos que permiten a su empresa seguir funcionando frente a la interrupción, especialmente a su infraestructura informática. En la mayoría de los casos, Azure Database for PostgreSQL controla los eventos disruptivos que pueden producirse en el entorno de nube y mantiene las aplicaciones y los procesos empresariales en ejecución. Sin embargo, algunos eventos no se pueden controlar automáticamente, como:
- Un usuario elimina o actualiza accidentalmente una fila de una tabla.
- Un terremoto provoca una interrupción de energía y deshabilita temporalmente una zona de disponibilidad o una región.
- Se necesita una revisión de bases de datos para corregir un error o un problema de seguridad.
Azure Database for PostgreSQL proporciona características que protegen los datos y mitigan el tiempo de inactividad de las bases de datos críticas durante los eventos de tiempo de inactividad planeados y no planeados. Basado en la infraestructura de Azure que ofrece una sólida resistencia y disponibilidad, Azure Database for PostgreSQL tiene características de continuidad empresarial que proporcionan otra protección de errores, abordan los requisitos de tiempo de recuperación y reducen la exposición a la pérdida de datos. A medida que diseñe las aplicaciones, tenga en cuenta la tolerancia al tiempo de inactividad (RTO) y la exposición a la pérdida de datos, el objetivo de punto de recuperación (RPO). Por ejemplo, su base de datos empresarial esencial tiene unos requisitos de tiempo de actividad más estrictos que una base de datos de prueba.
En la tabla siguiente se muestran las características que Azure Database for PostgreSQL ofrece.
| Feature | Descripción | Consideraciones |
|---|---|---|
| Copias de seguridad automáticas | Una instancia de servidor flexible de Azure Database for PostgreSQL realiza automáticamente copias de seguridad diarias de los archivos de base de datos y realiza continuamente copias de seguridad de los registros de transacciones. Puede conservar las copias de seguridad de 7 días hasta 35 días. Puede restaurar el servidor de bases de datos a cualquier momento en el período de retención de copia de seguridad. El RTO depende del tamaño de los datos que se van a restaurar, además del tiempo necesario para la recuperación de registros. Puede ser de unos minutos hasta 12 horas. Para obtener más información, vea Conceptos: copia de seguridad y restauración. | Los datos de copia de seguridad permanecen en la región. |
| Alta disponibilidad con redundancia de zona | Puede implementar una instancia de servidor flexible Azure Database for PostgreSQL con configuración de alta disponibilidad con redundancia de zona (HA) donde los servidores principales y en espera se implementan en dos zonas de disponibilidad diferentes dentro de una región. Esta configuración de alta disponibilidad protege las bases de datos frente a errores de nivel de zona y también ayuda a reducir el tiempo de inactividad de la aplicación durante los eventos de tiempo de inactividad planeados y no planeados. Los datos del servidor principal se replican de modo sincrónico en la réplica en espera. En caso de que se produzca una interrupción en el servidor principal, el servidor se conmuta por error automáticamente a la réplica en espera. Se espera que el RTO en la mayoría de los casos sea inferior a 120 segundos. Se espera que el RPO sea cero (sin pérdida de datos). Para obtener más información, consulte Conceptos: alta disponibilidad. | Es compatible con los niveles de proceso de uso general y optimizado para memoria. Está disponible únicamente en regiones con varias zonas. |
| Alta disponibilidad en la misma zona | Puede implementar una instancia de servidor flexible Azure Database for PostgreSQL con la misma configuración de alta disponibilidad de zona (HA) en la que los servidores principales y en espera se implementan en la misma zona de disponibilidad de una región. Esta configuración de alta disponibilidad protege las bases de datos frente a errores de nivel de nodo y también ayuda a reducir el tiempo de inactividad de la aplicación durante los eventos de tiempo de inactividad planeados y no planeados. Los datos del servidor principal se replican de modo sincrónico en la réplica en espera. En caso de que se produzca una interrupción en el servidor principal, el servidor se conmuta por error automáticamente a la réplica en espera. Se espera que el RTO en la mayoría de los casos sea inferior a 120 segundos. Se espera que el RPO sea cero (sin pérdida de datos). Para más información, consulte [Conceptos: alta disponibilidad]/azure/reliability/reliability-postgresql-flexible-server. | Es compatible con los niveles de proceso de uso general y optimizado para memoria. |
| Discos administrados premium | Los archivos de la base de datos se guardan en un almacenamiento premium administrado de alta disponibilidad y muy duradero. Este almacenamiento proporciona redundancia de datos con tres copias de la réplica almacenadas dentro de una zona de disponibilidad con funcionalidades de recuperación automática de datos. Para obtener más información, consulte la documentación de Managed Disks. | Datos almacenados en una zona de disponibilidad. |
| Copia de seguridad con redundancia de zona | Las copias de seguridad de instancias de servidor flexibles de Azure Database for PostgreSQL se almacenan automáticamente y de forma segura en un almacenamiento con redundancia de zona dentro de una región, si la región admite zonas de disponibilidad. Durante un error en la zona en la que está aprovisionado su servidor, si su servidor no está configurado con redundancia de zona, aún puede restaurar la base de datos usando el punto de restauración más reciente de otra zona. Para obtener más información, consulte Conceptos: copias de seguridad y restauración. | Aplicable únicamente a regiones con varias zonas disponibles. |
| Copia de seguridad con redundancia geográfica | Las copias de seguridad de instancias de servidor flexibles de Azure Database for PostgreSQL se copian en una región remota. Esta característica ayuda con la situación de recuperación ante desastres en caso de que la región del servidor principal esté inactiva. | Esta característica está habilitada actualmente en las regiones seleccionadas. Se tarda un RTO más largo y un RPO mayor en función del tamaño de los datos que se restaurarán y la cantidad de recuperación que se realizará. |
| Réplica de lectura | Puede implementar réplicas de lectura entre regiones para proteger las bases de datos frente a errores de nivel de región. Las réplicas de lectura se actualizan de forma asincrónica mediante la tecnología de replicación física de PostgreSQL y podrían retardar la principal. Para obtener más información, vea Conceptos: réplicas de lectura. | Es compatible con los niveles de proceso de uso general y optimizado para memoria. |
En la tabla siguiente se comparan el RTO y el RPO en un escenario de carga de trabajo típica:
| Capacidad | Ampliable | SKU de producción (Uso General/Memoria Optimizada) |
|---|---|---|
| Restauración a un momento dado a partir de una copia de seguridad | Cualquier punto de restauración dentro del período de retención RTO: varía RPO < 5 minutos |
Cualquier punto de restauración dentro del período de retención RTO: varía RPO < 5 minutos |
| Restauración geográfica de las copias de seguridad con replicación geográfica | RTO: varía RPO < 1 hora |
RTO: varía RPO < 1 hora |
| Réplicas de lectura | No es aplicable | RTO: minutos* RPO: normalmente oscila entre 30 segundos y 5 minutos* |
| Alta disponibilidad | No es aplicable | RTO < 120 segundos RPO = 0 |
Eventos de tiempo de inactividad planeados
En la tabla siguiente se describen algunos escenarios comunes de mantenimiento planeado. Estos eventos suelen provocar unos minutos de inactividad, pero no provocan pérdida de datos.
| Escenario | Proceso |
|---|---|
| Escalado de proceso (iniciado por el usuario) | Durante la operación de escalado de proceso, el proceso permite que se completen los puntos de comprobación activos, se purgan las conexiones de cliente, se cancelan las transacciones no confirmadas, se retira el almacenamiento y, a continuación, se apaga el servidor. El proceso aprovisiona una nueva instancia de servidor flexible de Azure Database for PostgreSQL con el mismo nombre de servidor de base de datos, pero con la configuración de proceso escalada. El proceso adjunta el almacenamiento al nuevo servidor e inicia la base de datos, que realiza la recuperación si es necesario antes de aceptar conexiones de cliente. |
| Escalado vertical del almacenamiento (iniciado por el usuario) | Al iniciar una operación de ampliación de almacenamiento, el proceso permite que los puntos de control activos se completen, drena las conexiones de los clientes y cancela las transacciones no confirmadas. Después, el proceso cierra el servidor. El proceso escala el almacenamiento al tamaño deseado y, a continuación, lo asocia al nuevo servidor. El proceso realiza la recuperación si es necesario antes de aceptar conexiones de cliente. Tenga en cuenta que no se admite la reducción vertical para el tamaño del almacenamiento. |
| Nueva implementación de software (iniciada por Azure) | El servicio implementa automáticamente nuevas características o correcciones de errores como parte del mantenimiento planeado. Puede programar cuándo se producen esas actividades. Para obtener más información, consulte su portal. |
| Actualizaciones de versiones secundarias (iniciadas por Azure) | Azure Database for PostgreSQL revisa automáticamente los servidores de bases de datos según la versión secundaria determinada por Azure. Esta aplicación de parches se realiza como parte del mantenimiento programado del servicio. El proceso reinicia automáticamente el servidor de bases de datos con la nueva versión secundaria. Para obtener más información, vea la documentación. También puede comprobar su portal. |
Al configurar el Azure Database for PostgreSQL instancia de servidor flexible con alta disponibilidad, el servicio realiza primero el escalado y las operaciones de mantenimiento en el servidor en espera. Para más información, consulte [Conceptos: alta disponibilidad]/azure/reliability/reliability-postgresql-flexible-server.
Mitigación del tiempo de inactividad no planeado
Se pueden producir tiempos de inactividad no planeados como resultado de interrupciones imprevistas, incluidos errores subyacentes de hardware, problemas de red y errores de software. Si el servidor de bases de datos configurado con alta disponibilidad deja de funcionar inesperadamente, el servicio activa la réplica en espera y los clientes pueden reanudar sus operaciones. Si no configura el servidor con alta disponibilidad (HA), el servicio aprovisiona automáticamente un nuevo servidor de bases de datos si se produce un error en el intento de reinicio. Aunque no se puede evitar un tiempo de inactividad no planeado, Azure Database for PostgreSQL ayuda a mitigar el tiempo de inactividad realizando automáticamente operaciones de recuperación sin necesidad de intervención humana.
Aunque el equipo de ingeniería se esfuerza continuamente por proporcionar alta disponibilidad, hay ocasiones en las que Azure Database for PostgreSQL incurre en una interrupción que provoca una falta de disponibilidad de las bases de datos y, por tanto, afecta a la aplicación. Cuando la supervisión del servicio detecta problemas que provocan errores de conectividad generalizados, errores o problemas de rendimiento, el servicio declara automáticamente una interrupción para mantenerle informado.
Interrupción del servicio
Si una instancia de servidor flexible Azure Database for PostgreSQL deja de funcionar, puede encontrar más detalles sobre la interrupción en los siguientes lugares:
- Banner del portal de Azure: Si la suscripción se ve afectada, en Notificaciones del portal de Azure se muestra una alerta de interrupción por un problema del servicio.
- Ayuda + soporte técnico o soporte técnico + solución de problemas: al crear una incidencia de soporte técnico a partir de ayuda y soporte técnico o soporte técnico y solución de problemas, el portal incluye información sobre los problemas que afectan a los recursos. Seleccione Ver los detalles de la interrupción para obtener más información y un resumen del alcance. La página Nueva solicitud de soporte técnico también incluye una alerta.
- Service Health: la página Service Health del portal de Azure contiene información sobre Azure estado del centro de datos globalmente. Busque "Estado del servicio" en la barra de búsqueda del portal de Azure y, a continuación, vea los problemas de servicio en la categoría Eventos activos. También puede ver el estado de un recurso concreto en la página Estado de los recursos del recurso en cuestión, en el menú Ayuda. En la captura de pantalla siguiente de la página Service Health se muestra información sobre un problema de servicio activo en sudeste asiático.
- Notificación por correo electrónico: si configura alertas, recibirá una notificación por correo electrónico cuando una interrupción del servicio afecte a la suscripción y al recurso. Los correos electrónicos proceden de "azure-noreply@microsoft.com". El cuerpo del correo electrónico comienza con "La alerta del registro de actividad... se activó por un problema de servicio para la suscripción de Azure...". Para obtener más información sobre las alertas de estado del servicio, consulte Recibir alertas del registro de actividad sobre notificaciones de servicio de Azure mediante el portal de Azure.
Importante
Como su nombre implica, los espacios de tablas temporales de PostgreSQL se usan para objetos temporales, así como para otras operaciones internas de base de datos, como la ordenación. Por lo tanto, no cree objetos de esquema de usuario en el espacio de tablas temporal, ya que no se garantiza la persistencia de estos objetos tras reinicios del servidor, conmutaciones por error de alta disponibilidad y eventos similares.
Tiempo de inactividad no planeado: escenarios de error y recuperación de servicio
En la tabla siguiente se describen los escenarios comunes de error no planeados y el proceso de recuperación.
| Escenario |
Proceso de recuperación [Servidores configurados sin alta disponibilidad con redundancia de zona] |
Proceso de recuperación [Servidores configurados con alta disponibilidad con redundancia de zona] |
|---|---|---|
| Error de servidor de bases de datos | Si el servidor de bases de datos deja de funcionar, Azure intenta reiniciar el servidor de bases de datos. Si se produce un error en ese intento, Azure reinicia el servidor de bases de datos en otro nodo físico. El tiempo de recuperación (RTO) depende de varios factores, incluida la actividad en el momento del error, como una transacción grande y el volumen de recuperación que se va a realizar durante el proceso de inicio del servidor de base de datos. Las aplicaciones que usan las bases de datos postgreSQL deben detectar y reintentar las conexiones eliminadas y las transacciones con errores. |
Si se detecta un error del servidor de bases de datos, se activa el servidor en espera, que reduce el tiempo de inactividad. Para más información, consulte [página de conceptos de alta disponibilidad]/azure/reliability/reliability-postgresql-flexible-server. Se espera que el RTO sea de 60 a 120 segundos, con una pérdida de datos cero. |
| Error de almacenamiento | Las aplicaciones no ven ningún impacto en ningún problema relacionado con el almacenamiento, como un error de disco o un bloqueo físico dañado. Dado que los datos se almacenan en tres copias, el almacenamiento superviviente sirve a la copia de los datos. El bloque de datos dañado se repara automáticamente y se crea una copia de los datos de manera automática. | En el caso de errores poco frecuentes y no recuperables, como cuando no se puede acceder a todo el almacenamiento, la instancia de servidor flexible de Azure Database for PostgreSQL conmuta por error a la réplica en espera para reducir el tiempo de inactividad. Para más información, consulte [página de conceptos de alta disponibilidad]/azure/reliability/reliability-postgresql-flexible-server. |
| Errores lógicos o de usuario | Para recuperarse de los errores de usuario, como las tablas eliminadas accidentalmente o los datos actualizados incorrectamente, realice una recuperación a un momento dado (PITR). Al realizar la operación de restauración, especifique el punto de restauración personalizado, que es el momento adecuado antes de que se produzca el error. Si desea restaurar solo 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 bases 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. |
Estos errores de usuario no están protegidos por alta disponibilidad, ya que todos los cambios se replican en la réplica en espera de forma sincrónica. Necesita realizar una restauración a un momento dado para recuperarse de estos errores. |
| Fallo de zona de disponibilidad | Para recuperarse de un error de nivel de zona, realice una restauración a un momento dado mediante la copia de seguridad y elija un punto de restauración personalizado con la hora más reciente para restaurar los datos más recientes. Implemente una nueva instancia de servidor flexible Azure Database for PostgreSQL en otra zona no afectada. El tiempo necesario para la restauración depende de la copia de seguridad anterior y del volumen de registros de transacciones que se van a recuperar. | Una instancia de servidor flexible de Azure Database for PostgreSQL realiza automáticamente la conmutación por error al servidor en espera en un plazo de entre 60 y 120 segundos, sin pérdida de datos. Para más información, consulte [página de conceptos de alta disponibilidad]/azure/reliability/reliability-postgresql-flexible-server. |
| Error de región | Si el servidor está configurado con copia de seguridad con redundancia geográfica, puede realizar la restauración geográfica en la región emparejada. Azure aprovisiona y recupera un nuevo servidor con los últimos datos disponibles que se habían copiado en esta región. También puede usar réplicas de lectura entre regiones. En caso de error de la región, puede realizar una operación de recuperación ante desastres promoviendo la réplica de lectura para que sea un servidor independiente de lectura y escritura. Se espera que el RPO sea de hasta cinco minutos (posible pérdida de datos), excepto en el caso de un error regional grave cuando el RPO puede estar cerca del retraso de replicación en el momento del error. |
Mismo proceso. |
Configure su base de datos tras la recuperación de un error regional
- Si usa la restauración geográfica o la réplica geográfica para recuperarse de una interrupción, asegúrese de que la conectividad con el nuevo servidor está configurada correctamente para que la función de aplicación normal pueda reanudarse. Siga las tareas posteriores a la restauración.
- Si anteriormente configuró una configuración de diagnóstico en el servidor original, asegúrese de hacer lo mismo en el servidor de destino si es necesario, como se explica en Configurar y acceder a los registros en Azure Database for PostgreSQL.
- Para configurar alertas de telemetría, asegúrese de que la configuración de la regla de alerta existente se actualice para asignarla al nuevo servidor. Para más información sobre las reglas de alerta, consulte Uso de Azure Portal para configurar alertas en métricas para Azure Database for PostgreSQL.
Importante
Puede restaurar servidores eliminados. Si elimina el servidor, siga las instrucciones de Restauración de un servidor eliminado para recuperarlo. Use el bloqueo de recursos de Azure para evitar la eliminación accidental del servidor.