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.
En este artículo se describe la alta disponibilidad en Azure Database for PostgreSQL, que incluye zonas de disponibilidad y recuperación entre regiones y continuidad empresarial. Para obtener información general más detallada sobre la confiabilidad de Azure, consulte Confiabilidad de Azure.
Azure Database for PostgreSQL admite la alta disponibilidad mediante el aprovisionamiento de réplicas principales y en espera separadas físicamente, ya sea dentro de la misma zona de disponibilidad (zonal) o entre zonas de disponibilidad (con redundancia de zona). Este modelo de alta disponibilidad está diseñado para garantizar que los datos confirmados nunca se pierdan durante los errores. En una configuración de alta disponibilidad (HA), los datos se confirman sincrónicamente en los servidores principal y en espera. El modelo está diseñado para que la base de datos no se convierta en un único punto de error en la arquitectura de software. Para obtener más información sobre la alta disponibilidad y la compatibilidad con zonas de disponibilidad, consulte Compatibilidad con zonas de disponibilidad.
Soporte para zonas de disponibilidad
Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de cada región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.
Azure Database for PostgreSQL admite modelos con redundancia de zona y zonales para configuraciones de alta disponibilidad. Ambas configuraciones de alta disponibilidad permiten la funcionalidad de conmutación automática por error sin pérdida de datos durante eventos planeados y no planeados.
Con redundancia de zona. La alta disponibilidad con redundancia de zona implementa una réplica en espera en una zona diferente con capacidad de conmutación automática por error. La redundancia de zona proporciona el mayor nivel de disponibilidad, pero debe configurar la redundancia de aplicaciones entre zonas. Por ese motivo, elija la redundancia de zona cuando desee protección frente a errores de nivel de zona de disponibilidad y cuando se acepte la latencia entre las zonas de disponibilidad. Aunque puede haber algún impacto de latencia en las escrituras y confirmaciones debido a la replicación sincrónica, no afecta a las consultas de lectura. Este impacto es específico de las cargas de trabajo, el tipo de SKU que seleccione y la región.
Puede elegir la región y las zonas de disponibilidad para los servidores principal y en espera. El servidor de réplica en espera se aprovisiona en la zona de disponibilidad elegida en la misma región con una configuración similar de proceso, almacenamiento y red que la del servidor principal. Los archivos de datos y los archivos de registro de transacciones (registros de escritura previa, también conocidos como WAL) se almacenan en el almacenamiento con redundancia local (LRS) dentro de cada zona de disponibilidad, almacenando automáticamente tres copias de datos. Una configuración con redundancia de zona proporciona aislamiento físico de toda la pila entre los servidores principal y en espera.
La opción con redundancia de zona solo está disponible en las regiones que cuentan con soporte para zonas de disponibilidad.
No se ofrece soporte para la redundancia entre zonas para:
Nivel de proceso ampliable
Regiones con disponibilidad de zona única
Zonal. Elija una implementación zonal cuando quiera lograr el mayor nivel de disponibilidad dentro de una sola zona de disponibilidad, pero con la latencia de red más baja. Puede elegir la región y la zona de disponibilidad para implementar el servidor de bases de datos principal. Un servidor de réplica en espera se aprovisiona automáticamente y se administra en la misma zona de disponibilidad con una configuración similar de proceso, almacenamiento y red que la del servidor principal. Una configuración zonal 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. si se produce alguna interrupción en el servidor principal, el servidor cambia automáticamente a la réplica en espera.
La opción de implementación zonal está disponible en todas las regiones de Azure donde puede implementar el Servidor flexible.
Nota:
Los modelos de implementación con redundancia de zona y zonales tienen el mismo comportamiento arquitectónico. Varias discusiones de las secciones siguientes se aplican a ambos, a menos que se indique lo contrario.
Configuración de la resistencia zonal en el portal
Puede configurar la alta disponibilidad (HA) de dos maneras: alta disponibilidad con redundancia de zona, que coloca el servidor en espera en una zona de disponibilidad diferente para lograr máxima resistencia o alta disponibilidad de la misma zona, que implementa el servidor en espera en la misma zona que el servidor principal para minimizar la latencia.
Para simplificar la configuración y garantizar la resistencia zonal, el portal proporciona una opción resistencia zonal con dos botones de radio: Habilitado y Deshabilitado. Al seleccionar Habilitado, se intenta crear el servidor en espera en una zona de disponibilidad diferente (modo de alta disponibilidad con redundancia de zona). Si la región no admite alta disponibilidad con redundancia de zona, puede seleccionar la casilla de verificación de respaldo (resaltada en la siguiente imagen) para habilitar la alta disponibilidad en la misma zona.
Al activar la casilla de respaldo, el sistema crea el servidor en espera en la misma zona. Si la capacidad zonal está disponible más adelante, Azure le notificará para que pueda optar por migrar a una configuración de alta disponibilidad con redundancia de zona mediante PITR o réplicas de lectura. Si no selecciona la casilla de verificación y la capacidad zonal no está disponible, la habilitación de alta disponibilidad fallará. Este diseño aplica la alta disponibilidad redundante por zonas como opción predeterminada, al tiempo que proporciona una alternativa controlada para la alta disponibilidad en la misma zona, lo que garantiza que las cargas de trabajo alcancen finalmente una resiliencia total de la zona sin intervención manual.
Características de alta disponibilidad
Una réplica en espera se implementa en la misma configuración de máquina virtual ( incluidos los núcleos virtuales, el almacenamiento y la configuración de red) que el servidor principal.
Puede agregar compatibilidad con zonas de disponibilidad para un servidor de bases de datos existente.
Puede quitar la réplica en espera si deshabilita la alta disponibilidad.
Puede elegir zonas de disponibilidad para los servidores de base de datos principal y en espera para la disponibilidad con redundancia de zona.
Las operaciones como detener, iniciar y reiniciar se realizan en los servidores de base de datos principal y en espera al mismo tiempo.
En los modelos con redundancia de zona y zonales, el servidor de base de datos principal realiza periódicamente copias de seguridad automáticas. Al mismo tiempo, la réplica en espera archiva continuamente los registros de transacciones en el almacenamiento de copia de seguridad. Si la región admite zonas de disponibilidad, los datos de copia de seguridad se almacenan en un almacenamiento con redundancia de zona (ZRS). En las regiones que no admiten zonas de disponibilidad, los datos de copia de seguridad se almacenan en un almacenamiento con redundancia local (LRS).
Los clientes siempre se conectan al nombre de host final del servidor de bases de datos principal.
Los cambios en los parámetros del servidor también se aplican a la réplica en espera.
Puede reiniciar el servidor para reflejar los cambios de parámetros estáticos del servidor.
Las actividades de mantenimiento periódicas, como las actualizaciones de versiones secundarias, se realizan primero en el sistema de respaldo. Para reducir el tiempo de inactividad, el modo de espera se promueve a principal para que las cargas de trabajo puedan mantenerse mientras se aplican las tareas de mantenimiento en el nodo restante.
Nota:
Para garantizar que las funciones de alta disponibilidad sean correctas, configure los valores de parámetros max_replication_slots de servidor y max_wal_senders . La alta disponibilidad requiere cuatro de cada uno para controlar las conmutaciones por error y las actualizaciones sin interrupciones. Para una configuración de alta disponibilidad con cinco réplicas de lectura y 12 ranuras de replicación lógica, establezca los valores de los parámetros max_replication_slots y max_wal_senders en 21. Esta configuración es necesaria porque cada réplica de lectura y cada ranura de replicación lógica requieren uno de cada uno, además de los cuatro necesarios para que la alta disponibilidad funcione correctamente. Para obtener más información sobre max_replication_slots parámetros y max_wal_senders, consulte la documentación.
Supervisar el estado de alta disponibilidad
La supervisión del estado de mantenimiento de alta disponibilidad (HA) en Azure Database for PostgreSQL proporciona una visión general continua del estado y la preparación de las instancias habilitadas para alta disponibilidad. Esta característica de supervisión aplica el marco de Resource Health Check (RHC) de Azure para detectar y alertar sobre cualquier problema que pueda afectar a la preparación de la conmutación por error de la base de datos o a la disponibilidad general. Al evaluar métricas clave como el estado de la conexión, el estado de conmutación por error y el estado de la replicación de datos, la supervisión del estado de alta disponibilidad permite la resolución proactiva de problemas y ayuda a mantener el tiempo de actividad y el rendimiento de la base de datos.
Utilice la supervisión del estado de salud de alta disponibilidad para:
- Obtenga información en tiempo real sobre el estado de las réplicas principales y en espera, con indicadores de estado que revelan posibles problemas, como el rendimiento degradado o el bloqueo de red.
- Configure alertas para notificaciones oportunas sobre cualquier cambio en el estado de alta disponibilidad, por lo que puede tomar medidas inmediatas para solucionar posibles interrupciones.
- Optimizar la preparación de la conmutación por error mediante la identificación y la resolución de problemas antes de que afecten a las operaciones de la base de datos.
Para obtener una guía detallada sobre cómo configurar e interpretar los estados de mantenimiento de alta disponibilidad, consulte Supervisión del estado de mantenimiento de alta disponibilidad (HA) para Azure Database for PostgreSQL.
Limitaciones de alta disponibilidad
Debido a la replicación sincrónica al servidor en espera, especialmente con una configuración redundante por zonas, las aplicaciones pueden experimentar una latencia elevada en la escritura y la confirmación.
No se puede utilizar la réplica en espera para consultas de lectura.
Dependiendo de la carga de trabajo y la actividad del servidor principal, el proceso de conmutación por error puede tardar más de 120 segundos, ya que la réplica en espera debe recuperarse antes de poder promocionarse.
El servidor en espera normalmente recupera archivos WAL a 40 MB/s. Para versiones más grandes, esta tasa puede aumentar hasta 200 MB/s. Si la carga de trabajo supera este límite, puede encontrar tiempo prolongado para que la recuperación se complete durante la conmutación por error o después de establecer un nuevo modo de espera.
Al reiniciar el servidor de bases de datos principal también se reinicia la réplica del servidor en espera.
No se puede configurar un modo de espera adicional.
No se pueden programar tareas de administración iniciadas por el cliente durante la ventana de mantenimiento administrado.
Los eventos planificados, como el cálculo a escala y el almacenamiento a escala, se producen primero en el servidor en espera y luego en el servidor principal. Actualmente, el servidor no realiza la conmutación por error para estas operaciones planeadas.
Si configura la descodificación lógica o la replicación lógica en un servidor flexible habilitado para alta disponibilidad:
- En PostgreSQL 16 y versiones anteriores, las ranuras de replicación lógica no se conservan en el servidor en espera después de una conmutación por error de forma predeterminada.
- Para asegurarse de que la replicación lógica sigue funcionando después de la conmutación por error, debe habilitar la
pg_failover_slotsextensión y configurar las opciones auxiliares, comohot_standby_feedback = on. - A partir de PostgreSQL 17, la sincronización de ranuras se admite de forma nativa. Si habilita las configuraciones de PostgreSQL correctas (
sync_replication_slots,hot_standby_feedback), las ranuras de replicación lógica se conservan automáticamente después de la conmutación por error y no se requiere ninguna extensión. - Para conocer los pasos de configuración y los requisitos previos, consulte la documentación de la extensión PG_Failover_Slots.
No se admite la configuración de zonas de disponibilidad entre la red privada (red virtual) y el acceso público con puntos de conexión privados. Debe configurar zonas de disponibilidad dentro de una red virtual (distribuidas entre zonas de disponibilidad dentro de una región) o el acceso público con puntos de conexión privados.
Solo puede configurar zonas de disponibilidad dentro de una sola región. No se pueden configurar zonas de disponibilidad entre regiones.
Acuerdo de nivel de servicio
El modelo zonal ofrece un tiempo de actividad de aproximadamente un 99,95% según el Acuerdo de Nivel de Servicio.
El modelo de redundancia de zona ofrece un tiempo de actividad garantizado por un Acuerdo de Nivel de Servicio de aproximadamente 99,99%.
Creación de una instancia de Azure Database for PostgreSQL con la zona de disponibilidad habilitada
Para obtener información sobre cómo crear una instancia de Azure Database for PostgreSQL para alta disponibilidad con zonas de disponibilidad, consulte Inicio rápido: Creación de una instancia de Azure Database for PostgreSQL en Azure Portal.
Reimplementación y migración de una zona de disponibilidad
Para obtener información sobre cómo habilitar o deshabilitar la configuración de alta disponibilidad en su servidor flexible, tanto en modelos de implementación con redundancia de zona como zonales, consulte Administrar la alta disponibilidad en el servidor flexible.
Componentes y flujo de trabajo de alta disponibilidad
Finalización de transacciones
Una transacción de la aplicación desencadena una escritura y confirmación registrándose primero en el WAL del servidor principal. El servidor principal transmite estos registros al servidor en espera mediante el protocolo de streaming postgres. Cuando el almacenamiento del servidor en espera conserva los registros, el servidor principal confirma la finalización de escritura. La aplicación confirma su transacción solo después de esta confirmación. Este recorrido de ida y vuelta adicional agrega latencia a la aplicación. El porcentaje de impacto depende de la aplicación. Este proceso de confirmación no espera a que los registros se apliquen al servidor en espera. El servidor en espera permanece en modo de recuperación hasta que se promueve.
Comprobación de estado
La supervisión flexible del estado del servidor comprueba periódicamente el estado de los servidores principal y en espera. Después de varios pings, si la supervisión de estado detecta que no se puede acceder a un servidor principal, el servicio inicia una conmutación automática al servidor en espera. El algoritmo de supervisión de estado usa varios puntos de datos para evitar situaciones de falsos positivos.
Modos de conmutación por error
El Servidor flexible admite dos modos de conmutación por error, Conmutación por error planeada y Conmutación por error no planeada. En ambos modos, una vez que se interrumpe la replicación, el servidor en espera ejecuta la recuperación antes de su promoción como servidor primario y se habilita para operaciones de lectura/escritura. Con las entradas DNS automáticas actualizadas con el nuevo punto de conexión de servidor principal, las aplicaciones pueden conectarse al servidor mediante el mismo punto de conexión. Se establece un nuevo servidor en espera en segundo plano para que la aplicación pueda mantener la conectividad.
Estado de alta disponibilidad
El sistema supervisa continuamente el estado de los servidores principales y en espera. Toma las medidas adecuadas para solucionar los problemas, incluyendo la activación de una conmutación por error al servidor en espera. En la tabla siguiente se enumeran los posibles estados de alta disponibilidad:
| Estado | Descripción |
|---|---|
| Inicializar | En proceso de crear un servidor en espera. |
| Replicando datos | Una vez creado el modo de espera, se está poniendo al día con la principal. |
| Healthy | La replicación está en estado estable y es correcta. |
| Conmutar por error | El servidor de bases de datos está en proceso de conmutar por error al de espera. |
| Quitar servidor en espera | En proceso de eliminar el servidor en espera. |
| Sin habilitar | La alta disponibilidad no está habilitada. |
Nota:
Puede habilitar la alta disponibilidad durante la creación del servidor o en un momento posterior. Si habilita o deshabilita la alta disponibilidad durante la fase posterior a la creación, hágalo cuando la actividad del servidor principal sea baja.
Operaciones de estado estable
Las aplicaciones cliente de PostgreSQL se conectan al servidor principal mediante el nombre del servidor de base de datos. El servidor principal atiende directamente las lecturas de la aplicación. Al mismo tiempo, la aplicación recibe la confirmación de transacciones y solo escribe después de que los datos del registro hayan persistido tanto en el servidor principal como en la réplica en espera. Debido a esta ida y vuelta adicional, las aplicaciones pueden esperar una latencia elevada para las operaciones de escritura y confirmación. Puede supervisar el estado de la alta disponibilidad en el portal.
- Los clientes se conectan al servidor flexible y realizan operaciones de escritura.
- Los cambios se replican en el sitio de respaldo.
- El servidor principal recibe una confirmación.
- Se reconocen las escrituras y los compromisos.
Restauración a un momento dado de servidores de alta disponibilidad
Para los servidores flexibles configurados con alta disponibilidad, el sistema replica los datos de registro en tiempo real en el servidor en espera. Los errores de usuario en el servidor principal , como una eliminación accidental de una tabla o actualizaciones de datos incorrectas, se replican en la réplica en espera. Por lo tanto, no puede usar el modo de espera para recuperarse de estos errores lógicos. Para recuperarse de estos errores, debe realizar una restauración a un momento dado desde la copia de seguridad. Mediante la funcionalidad de restauración en el punto de tiempo de un servidor flexible, puede restaurar al estado anterior antes de que ocurriera el error. Un nuevo servidor de bases de datos se restaurará como un servidor flexible de una sola zona con un nuevo nombre proporcionado por el usuario para las bases de datos configuradas con alta disponibilidad. Puede usar el servidor restaurado para varios casos de uso:
Use el servidor restaurado para producción y, opcionalmente, habilite la alta disponibilidad con réplica en espera en la misma zona u otra zona de la misma región.
Si desea restaurar un objeto, expórtelo desde el servidor de bases de datos restaurado e impórtelo al servidor de bases de datos de producción.
Si quiere clonar el servidor de bases de datos con fines de prueba y desarrollo, o bien realizar la restauración para cualquier otro fin, puede realizar una restauración a un momento dado.
Para obtener información sobre cómo realizar una restauración a un momento dado de un servidor flexible, consulte Restauración a un momento dado de un servidor flexible.
Compatibilidad con la conmutación por error
Conmutación por error planeada
Los eventos de tiempo de inactividad planificados incluyen actualizaciones de software frecuentes programadas de Azure y actualizaciones de versiones secundarias. También puede usar una conmutación por error planeada para devolver el servidor principal a una zona de disponibilidad preferida. Al configurar la alta disponibilidad, estas operaciones se aplican primero a la réplica en espera mientras las aplicaciones siguen accediendo al servidor principal. Una vez que el proceso actualiza la réplica en espera, drena las conexiones del servidor principal y desencadena una conmutación por error que activa la réplica en espera como el servidor principal, manteniendo el mismo nombre de servidor de base de datos. Las aplicaciones cliente se vuelven a conectar con el mismo nombre del servidor de base de datos al nuevo servidor principal y pueden reanudar sus operaciones. El proceso establece un nuevo servidor en espera en la misma zona que la principal anterior.
En el caso de otras operaciones iniciadas por el usuario, como scale-compute o scale-storage, el proceso aplica los cambios en el modo de espera primero y, a continuación, el principal. Actualmente, el servicio no se traslada al modo de espera. Por lo tanto, mientras que la operación de escalado se ejecuta en el servidor principal, las aplicaciones experimentan un breve tiempo de inactividad.
También puede usar esta característica para conmutar por error al servidor en espera con un tiempo de inactividad reducido. Por ejemplo, el servidor principal podría estar en una zona de disponibilidad diferente a la de la aplicación después de una conmutación por error no planeada. Quiere devolver el servidor principal a la zona anterior para colocarlo con la aplicación.
Al ejecutar esta característica, el proceso prepara primero el servidor en espera para asegurarse de que se ponga al día con las transacciones recientes, lo que permite a la aplicación seguir realizando lecturas y escrituras. El proceso promueve el modo de espera y corta las conexiones con el primario. La aplicación puede seguir escribiendo en el servidor principal mientras el proceso establece un nuevo servidor en espera en segundo plano. En la tabla siguiente se describen los pasos involucrados en el failover programado.
| paso | Descripción | ¿Se prevé algún tiempo de inactividad? |
|---|---|---|
| 1 | Espere a que el servidor en espera se sincronice con el servidor principal. | No |
| 2 | El sistema de supervisión interno inicia el flujo de trabajo de conmutación por error. | No |
| 3 | Las escrituras de aplicación se bloquean cuando el servidor en espera está cerca del número de secuencia de registro principal (LSN). | Sí |
| 4 | El servidor en espera se promueve como un servidor independiente. | Sí |
| 5 | El registro DNS se actualiza con la nueva dirección IP del servidor en espera. | Sí |
| 6 | La aplicación vuelve a conectarse y reanuda su lectura y escritura con el nuevo servidor primario. | No |
| 7 | Se establece un nuevo servidor en espera en otra zona. | No |
| 8 | El servidor en espera comienza a recuperar los registros (desde Azure Blob) que perdió durante su establecimiento. | No |
| 9 | Se establece un estado estable entre el servidor principal y el servidor en espera. | No |
| 10 | Se ha completado el proceso de conmutación por error planeado. | No |
El tiempo de inactividad de la aplicación se inicia en el paso 3 y puede reanudar la operación después del paso 5. El resto de los pasos se producen en segundo plano sin afectar a las escrituras y confirmaciones de la aplicación.
Sugerencia
Con el servidor flexible, puede programar opcionalmente las actividades de mantenimiento iniciadas por Azure eligiendo una ventana de 60 minutos en un día de su preferencia cuando se espera que las actividades de las bases de datos sean bajas. Las tareas de mantenimiento de Azure, como la aplicación de revisiones o las actualizaciones de versiones secundarias, se producen durante esa ventana. Si no elige una ventana personalizada, el sistema asigna una ventana de una hora entre las 11 p. m. y la hora local de 7 a. m. para el servidor. Estas actividades de mantenimiento iniciadas por Azure también se realizan en la réplica de espera para servidores flexibles que están configurados con zonas de disponibilidad.
Para obtener una lista de posibles eventos de tiempo de inactividad planeados, consulte Eventos de tiempo de inactividad planeados.
conmutación por error no planeada
Los tiempos de inactividad no planeados pueden producirse como resultado de interrupciones imprevistas, como errores de hardware subyacentes, problemas de red y errores de software. Si el servidor de bases de datos configurado con alta disponibilidad deja de funcionar inesperadamente, el proceso activa la réplica en espera y los clientes pueden reanudar sus operaciones. Si no configura la alta disponibilidad (HA) y se produce un error en el intento de reinicio, el proceso aprovisiona automáticamente un nuevo servidor de bases de datos. Aunque no se puede evitar un tiempo de inactividad no planeado, el servidor flexible ayuda a mitigar el tiempo de inactividad realizando automáticamente operaciones de recuperación sin necesidad de intervención humana.
Para obtener información sobre las conmutaciones por error no planeadas y el tiempo de inactividad, incluidos los posibles escenarios, consulte Mitigación de tiempo de inactividad no planeado.
Prueba de conmutación por error (conmutación por error forzada)
Con una conmutación por error forzada, puede simular un escenario de interrupción no planeado mientras ejecuta la carga de trabajo de producción y observa el tiempo de inactividad de la aplicación. También puede usar una conmutación por error forzada cuando el servidor principal deja de responder.
Una conmutación por error forzada desactiva el servidor principal e inicia el flujo de trabajo de conmutación por error en el que se realiza la operación de promoción en espera. Una vez que el servidor en espera completa el proceso de recuperación hasta los últimos datos confirmados, pasa a ser el servidor principal. Los registros DNS se actualizan y la aplicación puede conectarse al servidor principal promocionado. La aplicación puede seguir escribiendo en el servidor principal mientras se establece un nuevo servidor en espera en segundo plano, y eso no afecta al tiempo de actividad.
En la tabla siguiente se describen los pasos durante un failover forzado:
| paso | Descripción | ¿Se prevé algún tiempo de inactividad? |
|---|---|---|
| 1 | El servidor principal se detiene poco después de recibir la solicitud de conmutación por error. | Sí |
| 2 | La aplicación encuentra tiempo de inactividad cuando el servidor principal está inactivo. | Sí |
| 3 | El sistema de supervisión interno detecta el error e inicia una conmutación por error en el servidor en espera. | Sí |
| 4 | El servidor en espera entra en modo de recuperación antes de promocionarse por completo como un servidor independiente. | Sí |
| 5 | El proceso de conmutación por error espera a que se complete la recuperación en espera. | Sí |
| 6 | Una vez que el servidor está activo, el proceso actualiza el registro DNS con el mismo nombre de host, pero usa la dirección IP del modo de espera. | Sí |
| 7 | La aplicación puede volver a conectarse al nuevo servidor principal y reanudar la operación. | No |
| 8 | Se establece un servidor en espera en la zona preferida. | No |
| 9 | El servidor en espera comienza a recuperar los registros (desde Azure Blob) que perdió durante su establecimiento. | No |
| 10 | Se establece un estado estable entre el servidor principal y el servidor en espera. | No |
| 11 | Se ha completado el proceso de conmutación por error forzada. | No |
El tiempo de inactividad de la aplicación se inicia después del paso 1 y continúa hasta que finaliza el paso 6. Los demás pasos se ejecutan en segundo plano sin afectar a las escrituras y confirmaciones de la aplicación.
Importante
El proceso de conmutación por error de un extremo a otro incluye (a) conmutar por error al servidor en espera después del error principal y (b) establecer un nuevo servidor en espera en un estado estable. Dado que su aplicación sufre un tiempo de inactividad hasta que se completa la conmutación por error al modo de espera, mida el tiempo de inactividad desde la perspectiva de su aplicación/cliente en lugar de desde el proceso global de conmutación por error de extremo a extremo.
Consideraciones al realizar conmutaciones por error forzadas
El tiempo total de operación de un extremo a otro puede ser mayor que el tiempo de inactividad real experimentado por la aplicación.
Importante
Observe siempre el tiempo de inactividad desde la perspectiva de la aplicación.
No realice conmutaciones por error inmediatas consecutivas. Espere al menos 15-20 minutos entre las conmutaciones por error, para que el nuevo servidor en espera pueda establecerse completamente.
Realice una conmutación por error forzada durante un período de baja actividad para reducir el tiempo de inoperatividad.
Procedimientos recomendados para las estadísticas de PostgreSQL después de la conmutación por error
Después de una conmutación por error de PostgreSQL, mantener un rendimiento óptimo de la base de datos implica comprender los distintos roles de pg_statistic y las tablas pg_stat_* . La pg_statistic tabla almacena las estadísticas del optimizador, que son cruciales para el planificador de consultas. Estas estadísticas incluyen distribuciones de datos dentro de las tablas y permanecen intactas después de una conmutación por error, lo cual garantiza que el planificador de consultas pueda seguir optimizando la ejecución de consultas de forma eficaz en función de la información de distribución de datos histórica precisa.
Por el contrario, las tablas pg_stat_*, que registran estadísticas de actividad como el número de exploraciones, tuplas leídas y actualizaciones, se restablecen tras la conmutación por error. Un ejemplo de este tipo de tabla es pg_stat_user_tables, que realiza un seguimiento de la actividad de las tablas definidas por el usuario. Este restablecimiento refleja con precisión el estado operativo del nuevo servidor principal, pero también implica la pérdida de métricas históricas de actividad que podrían ser útiles para el proceso de limpieza automática y otras eficiencias operativas.
Dada esta distinción, ejecute ANALYZEdespués de una conmutación por error de PostgreSQL. Esta acción actualiza las tablas pg_stat_*, como pg_stat_user_tables, con estadísticas de actividad nuevas, lo cual ayuda al proceso de vacío automático y garantiza que el rendimiento de la base de datos sigue siendo óptimo en su nuevo rol. Este paso proactivo supera la brecha entre conservar las estadísticas esenciales del optimizador y actualizar las métricas de actividad para alinearse con el estado actual de la base de datos.
Experiencia de reducción de zona
Zonal: Para recuperarse de un fallo a nivel de zona, puede realizar una restauración a un punto en el tiempo utilizando la copia de seguridad. Puede elegir un punto de restauración personalizado con la hora más reciente para restaurar los datos más recientes. Un nuevo servidor flexible se implementa 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.
Para más información sobre la restauración a un momento dado, consulte Copia de seguridad y restauración en el Servidor flexible de Azure Database for PostgreSQL.
Con redundancia de zona: el servidor flexible conmuta automáticamente al servidor en espera en un plazo de 60 a 120 segundos sin pérdida de datos.
Configuraciones sin zonas de disponibilidad
Aunque no se recomienda, puede configurar el servidor flexible sin alta disponibilidad habilitada. Para servidores flexibles configurados sin alta disponibilidad, el servicio proporciona almacenamiento con redundancia local con tres copias de datos, copia de seguridad con redundancia de zona (en regiones donde se admite) y resistencia integrada del servidor para reiniciar automáticamente un servidor bloqueado y reubicar el servidor en otro nodo físico. Esta configuración ofrece un SLA de disponibilidad del 99,9%. Durante los eventos de conmutación por error planeados o no planeados, si el servidor deja de funcionar, el servicio mantiene la disponibilidad de los servidores mediante el siguiente procedimiento automatizado:
- Se aprovisiona una nueva máquina virtual Linux de proceso.
- El almacenamiento con archivos de datos se asigna a la nueva máquina virtual.
- El motor de base de datos PostgreSQL pasa a estar en línea en la nueva máquina virtual.
En la imagen siguiente se muestra la transición entre la máquina virtual y el error de almacenamiento.
Recuperación ante desastres entre regiones y continuidad empresarial
Si se produce un desastre en toda la región, Azure puede proporcionar protección frente a desastres de geografía regional o grande con recuperación ante desastres mediante el uso de otra región. Para más información sobre la arquitectura de recuperación ante desastres de Azure, consulte Arquitectura de recuperación ante desastres de Azure a Azure.
El servidor flexible 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. Según la infraestructura de Azure que ofrece una sólida resistencia y disponibilidad, un servidor flexible ofrece características de continuidad empresarial que proporcionan protección ante errores, se ocupan de los requisitos de tiempo de recuperación y reducen el riesgo de 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.
Recuperación ante desastres en la geografía de varias regiones
Copia de seguridad y restauración con redundancia geográfica
La copia de seguridad y restauración con redundancia geográfica le permiten restaurar el servidor en otra región si se produce un desastre. Proporciona al menos una durabilidad del 99,99999999999999 % (16 nueves) de los objetos de copia de seguridad durante un año.
Solo puede configurar la copia de seguridad con redundancia geográfica al crear el servidor. Al configurar el servidor con copia de seguridad con redundancia geográfica, los datos de copia de seguridad y los registros de transacciones se copian en la región emparejada de forma asincrónica mediante la replicación de almacenamiento.
Para más información sobre la copia de seguridad y la restauración con redundancia geográfica, consulte copia de seguridad y restauración con redundancia geográfica.
Réplicas 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 pueden retardar la réplica principal. Los niveles de procesos optimizados para memoria y uso general admiten réplicas de lectura.
Para obtener más información sobre las características y consideraciones de réplica de lectura, consulte Réplicas de lectura.
Detección, notificación y administración de interrupciones
Si configura el servidor con copia de seguridad con redundancia geográfica, puede realizar la restauración geográfica en la región emparejada. Se aprovisiona y recupera un nuevo servidor en los últimos datos disponibles que se copiaron en esta región.
También puede usar réplicas de lectura entre regiones. Si se produce un error en la región, puede realizar una operación de recuperación ante desastres promocionando su réplica de lectura a un servidor independiente con capacidad de lectura y escritura. Se espera que el RPO sea de hasta 5 minutos (posible pérdida de datos), excepto si se produce un error regional grave cuando el RPO puede estar cerca del retraso de replicación en el momento del error.
Para obtener más información sobre la mitigación y recuperación de tiempos de inactividad no planeados después del desastre regional, consulte Mitigación de tiempo de inactividad no planeado.