Visión general de la alta disponibilidad y la recuperación tras desastre para Databases for PostgreSQL
La alta disponibilidadCapacidad de un servicio o carga de trabajo para soportar fallos y seguir proporcionando capacidad de procesamiento de acuerdo con algún nivel de servicio predefinido. (HA) es la capacidad de un servicio de permanecer operativo y accesible ante fallos inesperados. La recuperación de desastresCapacidad de un servicio o carga de trabajo para recuperarse de incidentes graves poco frecuentes y fallos a gran escala, como la interrupción del servicio. Esto incluye un desastre físico que afecte a toda una región, la corrupción de una base de datos o la pérdida de un servicio que contribuya a una carga de trabajo. El impacto supera la capacidad del diseño de alta disponibilidad para gestionarlo. es el proceso de recuperación de la instancia de servicio a un estado de funcionamiento.
Databases for PostgreSQL es un servicio regional que cumple los Objetivos de Nivel de Servicio(OEN ) definidos con el plan estándar. Para más información, véase Acuerdo de nivel de servicio(SLA). Para más información sobre las regiones y centros de datos disponibles en IBM Cloud para site.data.keyword.databases-for-postgresql, consulte Disponibilidad de servicios e infraestructuras por ubicación.
Arquitectura de alta disponibilidad
Databases for PostgreSQL proporciona funciones de replicación, conmutación por error y alta disponibilidad para proteger sus bases de datos y datos del mantenimiento de la infraestructura, las actualizaciones y algunos fallos. Los despliegues contienen un clúster con dos miembros de datos: líder y réplica. La réplica se mantiene actualizada mediante replicación asíncrona. Se utiliza un mecanismo de consenso distribuido para mantener el estado del clúster y gestionar los fallos. Si el líder se vuelve inalcanzable, el cluster inicia un failover, y la réplica es promovida a líder, y una nueva réplica se reincorpora al cluster como réplica. El líder y la réplica siempre estarán en zonas diferentes de un MZR. Si la réplica falla, se crea una nueva réplica. Si un miembro falla en una zona, la nueva réplica se creará en una zona superviviente.
Puede ampliar aún más la alta disponibilidad añadiendo miembros de PostgreSQL al clúster para una mayor redundancia dentro de la región, o mediante el aprovisionamiento de réplicas de sólo lectura para la conmutación por error entre regiones o la descarga de lectura.
Revise la documentación de PostgreSQL sobre técnicas de replicación para comprender las limitaciones y compensaciones asociadas a la estrategia de replicación asíncrona que se despliega por defecto.
En situaciones en las que una base de datos se vuelve críticamente insalubre, como una caída del servidor en el líder, Databases for PostgreSQL intenta una conmutación por error. Esta capacidad de auto-failover tiene un límite de 16 MB de desfase de datos desde el líder a la réplica (unas pocas filas de datos una vez que representan más PostgreSQL sobrecarga de datos) y no se realiza si se supera el umbral de desfase. Si la posible pérdida de 16 MB de datos es intolerable para la aplicación, consulte la replicación síncrona.
Las cargas de trabajo que acceden mediante programación al clúster deben seguir la lógica de reintento de disponibilidad del cliente para mantener la disponibilidad.
El servicio realizará, en ocasiones, conmutaciones por error controladas en condiciones normales de funcionamiento. Estas conmutaciones por error no suponen pérdida de datos, pero provocan el restablecimiento de las conexiones activas. Hay un periodo de hasta 15 segundos en el que las reconexiones pueden fallar. En ocasiones, pueden producirse fallos no planificados debido a acontecimientos imprevistos en el entorno operativo. Pueden tardar hasta 45 segundos, pero generalmente menos de 30. El mantenimiento del servicio, por ejemplo, desencadena una conmutación por error controlada.
Funciones de alta disponibilidad
Databases for PostgreSQL admite las siguientes funciones de alta disponibilidad:
| Característica | Descripción | Consideración |
|---|---|---|
| Conmutación automática | De serie en todos los clústeres y resistente a fallos de zona o de un único miembro | |
| Número de miembros | Mínimo - 2 miembros. Por defecto es un despliegue estándar de dos miembros. Un clúster de dos miembros se recuperará automáticamente de un fallo de una sola instancia o zona (con pérdida de datos hasta el umbral de retardo). Durante la sincronización de datos para una nueva réplica, el clúster está expuesto a un segundo fallo que provoca la pérdida de datos. Una de tres miembros, véase la adición de PostgreSQL miembros, es resistente al fallo de dos miembros durante el mismo período de fallo | Tres miembros necesarios para la replicación sincrónica |
| Réplica síncrona | Mejora el RPO añadiendo la sincronización remota de miembros a la ruta de escritura de datos. Consulte Replicación sincrónica más abajo. | Impacto en el rendimiento y coste. |
| Réplica de solo lectura | Las réplicas de sólo lectura pueden proporcionar acceso local en regiones remotas, mejorando la disponibilidad ante posibles problemas de latencia o conectividad de la red. | Todas las solicitudes de escritura deben dirigirse exclusivamente al clúster de lectura-escritura asociado a la réplica de lectura |
Replicación sincrónica Databases for PostgreSQL
De forma predeterminada, la réplica de modalidad continua es asíncrona. Si el líder se bloquea, es posible que algunas transacciones comprometidas no se hayan sincronizado con la réplica, lo que provocaría una pérdida de datos. Cloud Databases
garantiza que la pérdida de datos se mantenga al mínimo sustancial; sin embargo, la replicación síncrona ofrece la posibilidad de confirmar que todos los cambios realizados por una transacción se han sincronizado con una réplica. Esto
garantiza la coherencia en todo el clúster. Esta coherencia proviene de la confirmación de que las escrituras se escriben en un secundario antes de volver al cliente que se conecta con success. Para conocer las variables relativas
a la replicación sincrónica, consulte synchronous_commit en la página Modificación de la configuración.
La réplica síncrona lleva la disponibilidad de réplica a la vía de acceso de escritura primaria. Si no hay ninguna réplica que acuse recibo de una escritura, se colgará hasta que haya una réplica disponible. Esto requiere que al menos tres miembros funcionen de forma fiable, ya que la réplica síncrona no está soportada en despliegues de dos miembros. Debe escalar horizontalmente al menos a tres miembros antes de habilitar la replicación sincrónica. Véase añadir miembros a PostgreSQL.
Aunque es poco probable, es posible que más de una réplica deje de estar disponible simultáneamente. Si esto sucede, la base de datos primaria no podrá completar ninguna escritura hasta que una réplica vuelva a estar en línea, bloqueando de forma efectiva todo el tráfico de escritura a la base de datos. Cuando decida utilizar la replicación síncrona, sopese los costes y beneficios relativos de una mayor durabilidad de los datos frente a los posibles problemas de disponibilidad.
Configurar la replicación sincrónica puede aumentar significativamente la latencia de escritura y reducir el rendimiento global. Para un rendimiento óptimo, se recomienda utilizar la replicación síncrona sólo en bases de datos o cargas de trabajo específicas que requieran el mayor grado de durabilidad de los datos.
Arquitectura de recuperación en caso de catástrofe
La estrategia general para la recuperación en caso de desastre consiste en crear una nueva base de datos, como la que se muestra a continuación en Restore. El contenido de la nueva base de datos puede ser una copia de seguridad
de la base de datos de origen creada antes de la catástrofe. Se puede crear una nueva base de datos utilizando la función de punto en el tiempo si la base de datos de producción está disponible.
Funciones de recuperación en caso de catástrofe
Databases for PostgreSQL admite las siguientes funciones de recuperación ante desastres:
| Característica | Descripción | Consideración |
|---|---|---|
| Restauración de copias de seguridad | Cree una base de datos a partir de una copia de seguridad creada previamente; consulte Gestión de copias de seguridad en Cloud Databases. | Las nuevas cadenas de conexión para la base de datos restaurada deben referenciarse en toda la carga de trabajo. |
| Restauración de punto en el tiempo | Crear una base de datos a partir de la producción en vivo utilizando la recuperación puntual | Esto sólo es posible si la base de datos activa está disponible y el RPO (desastre) entra dentro de la ventana soportada. No es útil si el clúster de producción no está disponible. Las nuevas cadenas de conexión para la base de datos restaurada deben referenciarse en toda la carga de trabajo. |
| Promover la réplica de lectura | Cree una réplica de sólo lectura cuando planifique un desastre en la misma región o en una región remota. Promover la réplica de sólo lectura para recuperarse de un desastre. | La réplica de lectura creada previamente debe estar disponible. Las nuevas cadenas de conexión para la base de datos restaurada deben referenciarse en toda la carga de trabajo. |
Planificación de la recuperación tras desastre
Las medidas de recuperación en caso de catástrofe deben practicarse con regularidad. Cuando elabore su plan, tenga en cuenta los siguientes escenarios de fracaso y resoluciones.
| Anomalía | Resolución |
|---|---|
| Fallo de hardware (punto único) | IBM proporciona una base de datos resistente a un único punto de fallo de hardware dentro de una zona, sin necesidad de configuración. |
| error de zona | Conmutación automática por error (#postgresql-high-availability). Los miembros de la base de datos se distribuyen entre las zonas. La configuración de tres miembros proporcionará resistencia adicional ante fallos de varias zonas.
La replicación síncrona reducirá el RPO a expensas del rendimiento. |
| Corrupción de datos | Restaurar copia de seguridad. Utilice la base de datos restaurada en producción o para datos de origen para corregir la corrupción en la base de datos restaurada.
Restauración puntual. Utilice la base de datos restaurada en producción o para datos de origen para corregir la corrupción en la base de datos restaurada. |
| Fracaso regional | Restaurar copia de seguridad. Utilice la base de datos restaurada en producción.
Promover la réplica de lectura. Promover una réplica de sólo lectura a una base de datos de lectura/escritura. Utilizar la base de datos restaurada en producción |
Alta disponibilidad a nivel de aplicación
Las aplicaciones que se comunican a través de redes y servicios en la nube están sujetas a errores de conexión transitorios. Desea diseñar las aplicaciones de modo que reintenten las conexiones cuando los errores están causados por una pérdida temporal de la conectividad con el despliegue o con IBM Cloud.
Dado que Databases for PostgreSQL es un servicio gestionado, las actualizaciones periódicas y el mantenimiento de la base de datos forman parte de las operaciones normales. Esto puede hacer que, ocasionalmente durante intervalos cortos, la base de datos no esté disponible. También puede hacer que la base de datos desencadene una migración tras error de forma ordenada, vuelva a intentarlo y vuelva a conectarse. La base de datos tarda poco tiempo en determinar qué miembro es una réplica y cuál es el líder, por lo que también puede darse una breve interrupción de la conexión. La migración tras error suele tardar menos de 30 segundos.
Las aplicaciones deben estar diseñadas de modo que gestionen las interrupciones temporales en la base de datos, implementen el manejo de errores para los mandatos anómalos de la base de datos e implementen la lógica de reintento para recuperarse de una interrupción temporal.
No se esperan faltas de disponibilidad de base de datos ni interrupciones de conexión de varios minutos. Abre un caso de soporte con detalles si tienes periodos de más de un minuto sin conectividad para que podamos investigar.
límites de conexiones
Databases for PostgreSQL establece el número máximo de conexiones a la base de datos PostgreSQL en 115. Se reservan 15 conexiones para que el superusuario mantenga el estado y la integridad de la base de datos, y hay 100 conexiones disponibles para usted y sus aplicaciones. Una vez alcanzado el límite de conexiones, cualquier intento de iniciar una nueva conexión produce un error. Para evitar saturar su despliegue con conexiones, utilice la agrupación de conexiones o escale su despliegue y aumente su límite de conexiones. Consulte la página Gestión de conexiones PostgreSQL para obtener más información.
Sus responsabilidades en HA y DR
La siguiente información puede ayudarle a crear y practicar continuamente su plan de HA y DR.
Cuando se restaura una base de datos a partir de copias de seguridad o se utiliza la restauración puntual, se crea una nueva base de datos con nuevas cadenas de conexión. Las cargas de trabajo y los procesos existentes deben ajustarse para consumir las nuevas cadenas de conexión. La promoción de una réplica de lectura a un clúster tendrá un impacto similar, aunque las partes existentes de sólo lectura de la carga de trabajo no se verán afectadas.
Una base de datos recuperada también puede necesitar las mismas dependencias creadas por el cliente de la base de datos del desastre - asegúrese de que este y otros servicios existen en la región recuperada:
- IBM® Key Protect for IBM Cloud®
Recuerda que al borrar una base de datos también se borran sus copias de seguridad asociadas. Sin embargo, las bases de datos borradas pueden recuperarse en un plazo limitado. Consulte la documentación para obtener detalles específicos sobre los procedimientos de recuperación de bases de datos.
No es posible copiar copias de seguridad fuera de IBM Cloud, por lo que se recomienda utilizar las herramientas específicas de la base de datos para realizar copias de seguridad adicionales. Puede ser necesario para recuperarse de la eliminación maliciosa de una base de datos seguida de una recuperación-eliminación de una base de datos. Una gestión cuidadosa del acceso IAM a las bases de datos puede ayudar a reducir la exposición a este problema.
La siguiente lista de comprobación asociada a cada característica puede ayudarle a crear y poner en práctica su plan.
- Restauración de copias de seguridad
- Verificar que las copias de seguridad están disponibles con la frecuencia deseada para cumplir los requisitos de RPO. La gestión de las copias de seguridad de Cloud Databases documenta la frecuencia de las copias de seguridad. Considere un script usando IBM Cloud® Code Engine- Trabajando con el productor de eventos del temporizador periódico(cron) para crear copias de seguridad adicionales bajo demanda para mejorar el RPO si la criticidad y el tamaño de la base de datos lo permiten. Sin embargo, dadas las capacidades de PostgreSQL's PITR, evalúe cuidadosamente la necesidad de copias de seguridad adicionales.
- Existen algunas restricciones en las regiones de restauración de bases de datos - verifique que sus objetivos de restauración se pueden alcanzar leyendo la gestión de copias de seguridad Cloud Databases.
- Compruebe que el periodo de conservación de las copias de seguridad cumple sus requisitos.
- Programe restauraciones de prueba con regularidad para verificar que los tiempos de restauración reales cumplen el RTO definido. Recuerda que el tamaño de la base de datos influye significativamente en el tiempo de restauración. Ten en cuenta estrategias para minimizar los tiempos de restauración, como dividir las bases de datos grandes en unidades más pequeñas y manejables y purgar los datos no utilizados.
- Verifique el servicio Key Protect.
- Restauración de punto en el tiempo
- Verifique los procedimientos descritos anteriormente.
- Compruebe que la copia de seguridad deseada aparece en la ventana.
- Promover la réplica de lectura
- Compruebe que existe una réplica de lectura en la región de recuperación.
- Practique el proceso de promoción: cree una réplica de lectura temporal en la región deseada. La réplica temporal puede ser promovida a lectura/escritura y algunas pruebas realizadas con poco impacto en la producción.
Para saber más sobre la propiedad de la responsabilidad entre el cliente y IBM Cloud por el uso de Databases for PostgreSQL, consulte Responsabilidades compartidas en Cloud Databases.
Manténgase informado: IBM notificaciones
Las actualizaciones que afectan a las cargas de trabajo de los clientes se comunican a través de las notificaciones de IBM Cloud. Para mantenerse informado sobre el mantenimiento previsto, los anuncios y las notas de la versión relacionadas con este servicio, consulte la página de notificaciones y estado de la supervisión. Además, revise periódicamente la página Política de versiones para conocer las últimas actualizaciones sobre versiones y fechas de fin de vida útil.