Replicación geográfica en Azure Database for PostgreSQL: servidor flexible
SE APLICA A: 
Servidor flexible de Azure Database for PostgreSQL
Se puede crear una réplica de lectura en la misma región que el servidor principal o en una región geográfica diferente. La replicación entre regiones puede ser útil para escenarios como el planeamiento de la recuperación ante desastres o la incorporación de datos más cerca de los usuarios.
Puede tener un servidor principal en cualquier región de servidor flexible de Azure Database for PostgreSQL. Un servidor principal también puede tener réplicas en cualquier región global de Azure que admita el servidor flexible de Azure Database for PostgreSQL. Además, también se admiten regiones especiales de Azure Government y Microsoft Azure operadas por 21Vianet.
Regiones emparejadas con fines de recuperación ante desastres
Aunque es posible crear réplicas en cualquier región compatible, existen notables ventajas a la hora de elegir réplicas en regiones emparejadas, especialmente cuando se realiza una arquitectura con fines de recuperación ante desastres:
Secuencia de recuperación de regiones: cuando se produce una interrupción en toda la geografía, se prioriza la recuperación de una región de cada conjunto emparejado, lo que garantiza que las aplicaciones entre regiones emparejadas siempre tengan una región acelerada para la recuperación.
Actualización secuencial: las actualizaciones de las regiones emparejadas se registran cronológicamente, lo que minimiza el riesgo de tiempo de inactividad debido a problemas relacionados con la actualización.
Aislamiento físico: se mantiene una distancia mínima de 300 millas entre centros de datos en regiones emparejadas, lo que reduce el riesgo de interrupciones simultáneas de eventos significativos.
Residencia de datos: con algunas excepciones, las regiones de un conjunto emparejado residen dentro de la misma geografía y cumplen los requisitos de residencia de datos.
Rendimiento: aunque las regiones emparejadas suelen ofrecer baja latencia de red, lo que mejora la accesibilidad de los datos y la experiencia del usuario, es posible que no siempre sean las regiones con la latencia absoluta más baja. Si el objetivo principal es servir datos más cerca de los usuarios en lugar de priorizar la recuperación ante desastres, es fundamental evaluar todas las regiones disponibles para la latencia. En algunos casos, una región no emparejada podría presentar la latencia más baja. Para conocer a fondo este tema, puede consultar las cifras de latencia de ida y vuelta de Azure para tomar una decisión bien fundamentada.
Para profundizar en las ventajas de las regiones emparejadas, consulte la documentación de Azure sobre la replicación entre regiones.
Errores regionales y recuperación
Las instalaciones de Azure distribuidas por varias regiones están diseñadas para ofrecer una alta confiabilidad. Sin embargo, en circunstancias infrecuentes, es posible que una región completa sea inaccesible debido a razones que van desde errores de red hasta escenarios graves, como desastres naturales. Las funcionalidades de Azure permiten crear aplicaciones que se distribuyen entre varias regiones, lo que garantiza que un error en una región no afecte a otras.
Preparación para desastres regionales
Estar bien preparados ante posibles desastres regionales es fundamental para garantizar el funcionamiento ininterrumpido de sus aplicaciones y servicios. Si está considerando un plan de contingencia sólido para la instancia de servidor flexible de Azure Database for PostgreSQL, estos son los pasos y consideraciones clave:
- Establezca una réplica de lectura con replicación geográfica: es esencial tener configurada una réplica de lectura en una región independiente de la región primaria. Esto garantiza la continuidad en caso de que la región primaria se enfrente a una interrupción.
- Garantice la simetría entre servidores: la acción "promover al servidor principal" es la más recomendada para enfrentarse a interrupciones regionales, pero implica un requisito de simetría entre servidores. Esto significa que los servidores principal y de réplica deben tener configuraciones idénticas en valores específicos. Entre las ventajas de usar esta solución se incluyen:
- No es necesario modificar las cadenas de conexión de la aplicación si usa puntos de conexión virtuales.
- Proporciona un proceso de recuperación sin problemas en el que, una vez que la región afectada vuelve a estar en línea, el servidor principal original reanuda automáticamente su función, pero con un nuevo rol de réplica.
- Configure puntos de conexión virtuales: los puntos de conexión virtuales permiten realizar una transición sin problemas de la aplicación a otra región en caso de que se produzca una interrupción. Eliminan la necesidad de realizar cambios en las cadenas de conexión de la aplicación.
- Configure la réplica de lectura: no todas las opciones de configuración del servidor principal se replican en la réplica de lectura. Es fundamental asegurarse de que todas las configuraciones y características necesarias (por ejemplo, PgBouncer) estén configuradas correctamente en la réplica de lectura. Para más información, consulte la sección Administración de configuración.
- Prepárese para la alta disponibilidad (HA): si la configuración requiere alta disponibilidad, no se habilitará automáticamente en una réplica promocionada. No olvide activarla después de la promoción. Piense en la posibilidad de automatizar este paso para minimizar el tiempo de inactividad.
- Pruebas periódicas: simule periódicamente escenarios de desastres regionales para validar los umbrales, destinos y configuraciones existentes. Asegúrese de que la aplicación responda según lo previsto durante estos escenarios de prueba.
- Siga las instrucciones y guías generales de Azure: Azure proporciona una guía completa sobre confiabilidad y preparación ante desastres. Es muy beneficioso consultar estos recursos e integrar los procedimientos recomendados en el plan de preparación.
Ser proactivo y prepararse de antemano para desastres regionales garantiza la resistencia y confiabilidad de las aplicaciones y los datos.
¿Y si las interrupciones afectan al Acuerdo de Nivel de Servicio?
Si una interrupción prolongada con el servidor flexible de Azure Database for PostgreSQL en una región específica que amenaza el acuerdo de nivel de servicio (SLA) de la aplicación, tenga en cuenta que ambas acciones descritas a continuación no están controladas por el servicio. La intervención del usuario es necesaria para ambos casos. Un procedimiento recomendado es automatizar todo el proceso tanto como sea posible y mantener una supervisión sólida. Para obtener más información sobre qué información se proporciona durante una interrupción, consulte la página sobre interrupción del servicio. En un escenario de interrupción e inactividad de una región, solamente es posible recurrir a una promoción forzada, lo que significa que la cantidad de pérdida de datos es aproximadamente igual al retraso actual entre la réplica y la instancia principal. Por lo tanto, es fundamental supervisar el retraso. Tenga en cuenta los pasos siguientes:
Promover al servidor principal
Esta opción no requerirá actualizar las cadenas de conexión de la aplicación, siempre que se hayan configurado puntos de conexión virtuales. Una vez activado, el punto de conexión de escritura volverá a redirigir la nueva réplica principal en otra región y la columna de estado de replicación de Azure Portal mostrará "Reconfigurando". Una vez restaurada la región afectada, el servidor principal anterior se reanudará automáticamente, pero ahora con el rol de réplica.
Promover a un servidor independiente y quitar de la replicación
En ese caso, esta es la única opción viable. Después de promover el servidor, deberá actualizar las cadenas de conexión de la aplicación. Una vez restaurada la región original, es posible que el servidor principal anterior vuelva a estar activo. No olvide retirarlo para evitar incurrir en costos innecesarios. Si desea mantener la topología anterior, vuelva a crear la réplica de lectura.