Unidad 5.3: Bases de datos relacionales (Managed PostgreSQL / MariaDB)

Introducción

El nivel relacional es donde se concentran las decisiones de diseño más importantes de FinCorp. El libro mayor de un banco no puede perder silenciosamente transacciones comprometidas, pero un nivel que bloquea escrituras cada vez que un Node tiene una pausa es su propia clase de interrupción. Los servicios de bases de datos gestionadas le permiten colocar el dial de durabilidad frente a disponibilidad con precisión, pero solo si usted entiende qué garantiza cada configuración y qué comodidades la plataforma no ofrece deliberadamente. Esta unidad trabaja a través de las decisiones de replicación, escalabilidad, conmutación por error, acceso y recuperación, y luego construye el libro mayor relacional de FinCorp en el Data Center Designer con esas decisiones incorporadas.

El marco honesto es más importante que lo habitual aquí. No hay réplicas de lectura, no hay producto de conmutación por error gestionado, y el Backup Service no toca una base de datos gestionada. Cada brecha tiene un patrón nativo que se compone alrededor de ella, y un arquitecto que trata estas como entradas de diseño en lugar de características que faltan termina con un nivel de datos más limpio y predecible.

1. La decisión del modo de replicación

Un Managed PostgreSQL Cluster es un primario con uno a cinco instancias en total, por lo que hasta cuatro de respaldo. El modo de replicación gobierna el contrato entre una transacción comprometida y su durabilidad en esos nodos, y es la única decisión que establece el RPO del Cluster. El PostgreSQL admite dos modos actuales: Asíncrono (el predeterminado) y Estrictamente síncrono. Un tercer modo, no estricto Síncrono, está en desuso para nuevos clústeres y no debe ser elegido; los clústeres existentes en él se pueden mover a asíncrono o estrictamente síncrono a través de la configuración de modo de replicación API.

Asíncrono confirma una transacción tan pronto como se escribe en el disco en el primario; la replicación a los de respaldo ocurre en segundo plano, con un retraso típico en los milisegundos bajos. El beneficio es la latencia de escritura más baja. El costo es un RPO no cero: si el primario falla antes de que un compromiso reciente se haya replicado, ese compromiso se pierde cuando un de respaldo es promovido. El peor caso documentado para la ruta de copia de seguridad es perder hasta los últimos 30 minutos o 16 MB de datos si todas las réplicas pierden sus datos simultáneamente, ya que los datos archivados se envían en bloques de 16 MB o cada 30 minutos, lo que ocurra primero. En un Cluster sano de varios Node, la exposición realista es de unos pocos milisegundos de compromisos en vuelo, pero el punto arquitectónico sigue siendo: el modo asíncrono intercambia una pequeña ventana de pérdida de datos limitada por disponibilidad y latencia.

Estrictamente síncrono mantiene el compromiso hasta que al menos un de respaldo síncrono tenga la transacción, por lo que no se pierde datos comprometidos durante un conmutación por error, incluida una falla de almacenamiento principal con una pérdida simultánea de todos los de respaldo. El precio se paga en dos lugares. La latencia gana un sobrecoste constante por transacción, porque cada COMMIT ahora espera la replicación (la latencia entre Node es generalmente inferior a 1 ms, pero se suma a cada escritura). Más importante aún, este modo sacrifica la disponibilidad por la durabilidad: si no hay un de respaldo síncrono disponible, el primario deja de aceptar escrituras en lugar de continuar sin protección. Para ejecutarlo de manera segura, por lo tanto, necesita un mínimo de tres instancias, para que la pérdida de un Node aún deje un primario y un de respaldo síncrono. Proporcionar menos nodos es la trampa clásica, ya que una falla de un solo de respaldo detiene todas las escrituras.

La siguiente tabla de la documentación contrasta los dos modos que deben estar en uso de producción:

El PostgreSQL también le permite cambiar las garantías de compromiso por transacción, y la asimetría es importante: no puede hacer cumplir un compromiso síncrono en un Cluster asíncrono (sin un de respaldo síncrono, cualquier configuración más fuerte se reduce a local), pero puede ejecutar un Cluster estrictamente síncrono y relajar transacciones individuales a synchronous_commit=local donde se acepta una pequeña pérdida de datos. El valor predeterminado defensible es, por lo tanto, establecer el Cluster en la garantía más estricta que el Workload necesita y relajar selectivamente, no al revés.

El MariaDB elimina por completo esta decisión. El Managed MariaDB es solo asíncrono: un modo de replicación, el predeterminado. Esa es una decisión de alcance, no una falla que deba solucionarse. El MariaDB se ejecuta en Servidores Virtuales (no instancias de Cube), utiliza almacenamiento SSD Premium con motores InnoDB, MyISAM o Aria, y envía solo versiones LTS, actualmente a partir de la 10.6. Si un Workload de FinCorp realmente necesita compromisos con pérdida de datos cero, pertenece al PostgreSQL en modo estrictamente síncrono, no en el MariaDB. Elegir el motor es, por lo tanto, en parte una decisión de durabilidad, no solo de dialecto SQL.

1.1 Qué hace la conmutación por error automática dentro de un Cluster

La conmutación por error dentro de un solo Cluster es automática y no necesita ningún producto externo. Cuando el primario se vuelve no disponible, un de respaldo es promovido. En el modo asíncrono, cualquier de respaldo puede ser promovido y se pierden transacciones no replicadas; en el modo estrictamente síncrono, solo un de respaldo que contenga todas las transacciones confirmadas es elegible, lo que explica por qué el modo no puede perder datos comprometidos. Existe como máximo un de respaldo síncrono al mismo tiempo, y si falla, otro es elevado automáticamente al papel síncrono. Esta promoción dentro del Cluster es toda la conmutación por error administrada de la plataforma para una base de datos: protege contra la pérdida de Node dentro de un Cluster, no en clústeres o regiones.

2. Escalado de lectura sin réplicas de lectura

Las instancias de PostgreSQL en espera existen para alta disponibilidad, no para servir tráfico de lectura. No hay réplicas de lectura: no puede dirigir tráfico de informes o tráfico de lectura intensiva a una instancia en espera, y no hay un punto de conexión de solo lectura gestionado. Esto es un límite de plataforma rígido, y el patrón nativo que lo reemplaza tiene dos partes.

Primero, un límite de conexiones que se deriva, no se elige. El número máximo de conexiones a una PostgreSQL Cluster se calcula a partir del tamaño de RAM y no es configurable por el usuario. El mapeo documentado es:

De esas, 11 conexiones están reservadas para uso del sistema, por lo que el presupuesto utilizable de la aplicación es el valor de la tabla menos once. La consecuencia es que no puede resolver una tormenta de conexiones editando un parámetro; las únicas opciones son más RAM (hasta el límite de 1000 conexiones) o menos conexiones reales. Para un conjunto de microservicios o un frontend sin servidor que abre muchas más conexiones lógicas de las que permite el límite, la respuesta es el agrupamiento.

Segundo, el agrupador de conexiones gestionado (pgbouncer). Puede habilitarlo en la Cluster; la única cosa que configura es el modo de agrupación. Modo de transacción (el predeterminado) devuelve la conexión al grupo al final de cada transacción, lo que multiplexa muchas conexiones de cliente en pocas conexiones de backend y es la elección correcta para el tráfico web y de microservicios típicos. Modo de sesión mantiene la conexión de backend hasta que el cliente se desconecta, lo que solo es necesario cuando una sesión depende de un estado con ámbito de conexión, como variables de sesión o instrucciones preparadas que deben persistir. El agrupador escucha en un puerto diferente: 6432 en lugar del puerto predeterminado de la base de datos 5432, por lo que habilitarlo también es un cambio de configuración del cliente, no un conmutador transparente. Las aplicaciones deben apuntar a 6432 para obtener el beneficio.

El escalado de lectura adecuado se resuelve un nivel más arriba, en la caché. Debido a que las instancias en espera no pueden servir lecturas, el patrón de escalado de lectura de la plataforma es la caché de In-Memory DB (Unidad 5.5) colocada frente a la capa relacional en la red privada, combinada con el agrupamiento para proteger el presupuesto de conexiones. Las lecturas calientes son absorbidas por la caché, el primario relacional maneja escrituras y lecturas de error de caché, y el agrupamiento mantiene la cuenta de conexiones por debajo del límite derivado de RAM. Esta composición de caché y agrupamiento es lo que significa "escalado de lecturas" en esta plataforma, y es por eso que la Unidad 5.5 es una dependencia directa de cualquier servicio FinCorp de alta lectura, no un extra opcional.

3. Conmutación por error entre clústeres y acceso privado

La promoción In-Cluster (Sección 1.1) es la única conmutación por error gestionada. No hay un producto de conmutación por error gestionada que abarque clústeres o regiones, y crucialmente no hay replicación de base de datos nativa entre regiones o entre Cluster en absoluto. Si FinCorp necesita continuidad más allá de un solo Cluster, esa continuidad se ingenia, y se dirige, no se replica, en la capa de base de datos.

El patrón nativo entre Cluster es conmutación por error de DNS orquestada por el cliente (construida en la Unidad 3.7, revisada para la resiliencia en la Unidad 7.1). Se configuran dos clústeres independientes, mantenidos en sincronía por la aplicación o por volcado y restauración periódicos, y una comprobación de salud externa reenvía un registro Cloud DNS de baja TTL a cualquiera de los puntos de conexión que esté sano. El propio Cloud DNS no es consciente de la salud; sirve cualquier registro que se configure. Dos propiedades impulsan el diseño: DNS dirige solo nuevas conexiones, por lo que las sesiones existentes no migran y la aplicación debe volver a conectarse de manera limpia; y el tiempo de recuperación está dominado por el piso TTL del registro de conmutación por error, la palanca que se ajusta para el tiempo de recuperación objetivo (RTO). Dado que el segundo Cluster es una base de datos separada, este es un mecanismo de disponibilidad con su propio punto de recuperación ante desastres (RPO) gobernado por cómo se mantienen sincronizados los dos, no un espejo sin pérdidas.

El acceso es solo a través de un punto de conexión privado. Una Cluster gestionada no tiene un IP público; es accesible solo desde dentro del centro de datos virtual a través de un LAN privado. Durante la creación, se selecciona un centro de datos, un LAN y un IP privado. Las conexiones están protegidas por TLS de forma predeterminada: el modo SSL es prefer y no se puede deshabilitar por el cliente, con el certificado del servidor emitido por una autoridad de confianza. Varios rangos internos CIDR están reservados por la plataforma y no se pueden utilizar para el IP privado de la Cluster. El beneficio es que la capa de datos se encuentra detrás del equilibrador de carga de capa 4 privado de la arquitectura en capas canónica (Unidad 1.2), nunca expuesta a Internet, accesible solo por la capa de aplicación y la caché.

4. Migración y Recuperación: Dump/Restore y PITR

Dos hechos definen el plano de continuidad de datos para bases de datos relacionales gestionadas, y ambos son restricciones que deben tenerse en cuenta al diseñar.

El Backup Service no cubre bases de datos gestionadas. El Backup Service basado en Acronis respalda máquinas virtuales y Block Storage, no DBaaS, y las instantáneas de Block Storage son de nivel de deshacer VM, no copias de seguridad coherentes de bases de datos. La continuidad de la base de datos se construye a partir de dos mecanismos nativos solamente: recuperación gestionada en un momento determinado y dump/restore lógico.

La recuperación en un momento determinado es la red de seguridad en el lugar. El servicio gestionado combina copias de seguridad periódicas con archivado continuo de registros de escritura anticipada, por lo que una copia de seguridad representa un rango de tiempo en lugar de un solo instante. Las copias de seguridad se crean cuando se crea un Cluster, cuando se aumenta su versión principal y cuando se ejecuta una operación PITR; se almacenan cifradas en un cubo IONOS Cloud Object Storage en la misma región (las bases de datos en una región sin Object Storage se respaldan en eu-central-2). La retención predeterminada es de 7 días y se puede establecer desde 1 hasta 365 días a través de la v2 API; reducirla purga las copias de seguridad más antiguas que la nueva ventana. Una restauración tiene como objetivo un recoveryTargetTime ISO-8601 no inclusivo, solo puede utilizar una copia de seguridad de la misma o una versión principal anterior, requiere que el Cluster esté DISPONIBLE, puede mover la base de datos a otra región y hace que la base de datos esté indisponible durante la duración de la operación (el servicio recomienda al menos 4 GB de RAM durante una restauración, escalado hacia atrás después). Trate la ventana predeterminada de 7 días como una fecha límite: si la política de auditoría de FinCorp requiere una recuperabilidad más larga, aumente la retención explícitamente en el momento del diseño en lugar de descubrir la brecha durante un incidente.

Dump/restore es el único camino de migración hacia o desde la plataforma. No hay un asistente de importación gestionado ni una migración basada en replicación al servicio. Mover una base de datos PostgreSQL existente hacia la plataforma o fuera de ella utiliza las herramientas lógicas estándar pg_dump, pg_restore y psql; para MariaDB, el equivalente es mariadb-dump. Las restricciones siguen la regla de punto final privado: porque el Cluster de destino es accesible solo desde dentro del VDC, la restauración debe ejecutarse desde un host en la red privada LAN del Cluster (por ejemplo, un salto VM en la capa de aplicación), y el corte incurre en un tiempo de inactividad honesto proporcional al tamaño del conjunto de datos mientras se carga el dump. Esto es la entrada relacional en el plan de migración de la Unidad 7.4, donde la ola de base de datos es la ola de dump/restore. Planifíquelo como una operación programada y dimensionada, no como una sincronización en segundo plano.

Una advertencia sobre credenciales tiene un peso real: las credenciales de usuario establecidas en el momento de la creación del Cluster son las únicas que establece el camino de creación, y solo se pueden establecer una vez. Capturelas en el almacén de secretos en el momento de la aprovisionamiento, porque no hay un camino de restablecimiento conveniente después.

DCD Implementación paso a paso

Ahora usted construirá la base de datos relacional FinCorp Cluster: una base de datos privada multi-Node en el VDC existente de FinCorp, con un modo de replicación deliberado, una ventana de mantenimiento real y una ruta de conexión privada al aplicativo LAN. Esto realiza la decisión de nivel de datos de las secciones 1 a 3. El requisito previo es un VDC existente con una conexión privada LAN que la capa de aplicación ya utiliza (la topología de la Unidad 3.1); la base de datos Cluster se conectará a esa conexión LAN con una conexión privada IP que usted elige para evitar el rango DHCP.

Objetivo de construcción: Construir una base de datos privada multi-Node con modo de replicación, ventana de mantenimiento y detalles de conexión.

Pasos (en el Data Center Designer):

1. Abra Menú > Bases de datos > PostgreSQL. La visión general muestra los recursos asignados a su contrato y cuántos se utilizan; confirme que hay espacio antes de crear la base de datos Cluster.
2. Haga clic en Crear base de datos Cluster. Proporcione un Nombre de base de datos Cluster que codifica el entorno y la capa de FinCorp, y seleccione la Ubicación (región) que satisface la decisión de residencia tomada en la Unidad 1.4. La región es una decisión de colocación, no algo que se pueda revisar más adelante.
3. Elija la Versión de PostgreSQL del conjunto compatible (actualmente 14, 15 o 16). Seleccionar una versión principal actual mantiene la mayor longitud de actualización.
4. Seleccione el Modo de replicación. Para la base de datos de nivel de libro de FinCorp Workload, elija Estrictamente sincrónico y asegúrese de que la cuenta de instancias en el siguiente paso sea de al menos tres para que una pérdida de un solo standby no detenga las escrituras. Para servicios sensibles a la latencia y tolerantes a pérdidas, deje que sea Asincrónico. No seleccione el modo de sincronización no estricto obsoleto.
5. Establezca la Ubicación de copia de seguridad (región). Puede colocar copias de seguridad en una región diferente de la base de datos para protección fuera del sitio; decida esto en función de los requisitos de auditoría y residencia en lugar de aceptar el valor predeterminado ciegamente.
6. En Configuración de instancia, establezca los CPU y la RAM por instancia (recuerde que el límite de conexión se deriva de RAM), elija un Tipo de almacenamiento (HDD es el predeterminado; elija SSD o SSD Premium para la base de datos Workload, ya que SSD por debajo de aproximadamente 100 GB no es recomendado), e ingrese el Tamaño de almacenamiento. Establezca la cuenta de instancias para que una base de datos estrictamente sincrónica tenga tres o más nodos.
7. En Configuración de red, seleccione el Centro de datos, la Conexión de centro de datos LAN que utiliza la capa de aplicación y una Conexión privada IP. No hay un punto de conexión público. Para encontrar una conexión privada IP segura, tenga en cuenta que el DHCP de la conexión LAN utiliza un /24, así que reutilice los primeros tres octetos de la subred de aplicación y elija una dirección que termine entre .3 y .10, que DHCP nunca asigna, para evitar una colisión.
8. En Período de mantenimiento, elija un Día y una Hora de inicio (UTC). Elija un intervalo de baja actividad real, porque el mantenimiento se ejecuta dentro de una ventana de 4 horas a partir de esa hora de inicio. Dejar esto efectivamente sin restricciones invita a trabajos disruptivos durante las horas de negocio.
9. En Creación de usuario, establezca el Nombre de usuario y la Contraseña iniciales. Estas son las credenciales con las que se crea la base de datos Cluster; capturelas en el almacén de secretos inmediatamente, ya que el camino de creación es el lugar previsto para establecerlas.
10. Cree la base de datos Cluster. Una vez que alcance el estado DISPONIBLE, conéctese desde un host en la misma conexión privada LAN utilizando la conexión privada IP asignada o el nombre de DNS devuelto en el puerto 5432. Si más tarde habilita el grupo de conexiones administrado (pgbouncer), redirija los clientes al puerto 6432 y elija el modo de transacción a menos que una característica de ámbito de sesión obligue al modo de sesión.

Errores comunes:

• Aprovisionar una base de datos estrictamente sincrónica Cluster con menos de tres instancias. Con solo un standby, una falla de un solo standby detiene todas las escrituras, porque el modo estricto se niega a dejar de lado la replicación sincrónica. Ajuste a tres o más nodos antes de elegir el modo estricto.
• Elegir el modo de sincronización no estricto obsoleto para una nueva base de datos Cluster. Utilice Asincrónico o Estrictamente sincrónico; el modo intermedio no garantiza la durabilidad multi-Node en todas las circunstancias y existe solo como una ruta de herencia.
• Asignar a la base de datos Cluster una conexión privada IP dentro del rango DHCP. Las colisiones interrumpen la conectividad de forma intermitente; reutilice los primeros tres octetos de la conexión LAN y elija una dirección que termine entre .3 y .10.
• Establecer una ventana de mantenimiento durante las horas de negocio, o tratarla como cosmética. El mantenimiento se ejecuta en una ventana de 4 horas a partir de la hora de inicio que elija; elija un intervalo de baja actividad real.
• Esperar que los standbys sirvan tráfico de lectura o que sean un punto de conexión de lectura administrado. No hay réplicas de lectura; escala las lecturas con la caché In-Memory DB más el grupo de conexiones pgbouncer, y recuerde que el grupo de conexiones está en el puerto 6432.
• Asumir que el Backup Service o un Block Storage Snapshot protege la base de datos. Ninguno de los dos cubre DBaaS. La continuidad de la base de datos es PITR (retención predeterminada de 7 días, establecida deliberadamente) más volcado/restaurado.
• Perder las credenciales iniciales de la base de datos. Se establecen una vez en el camino de creación sin una reinicialización conveniente; almacénelas en el momento de aprovisionamiento.

Una breve ilustración en el lado del cliente de los dos hechos que más muerden, el punto de conexión privado y el puerto del grupo de conexiones:

# Direct connection (port 5432), from a host on the cluster's private LAN
psql -h pg-xxxxxxxx.postgresql.de-fra.ionos.com -U fincorp_app -d ledger

# Through the managed pooler (transaction mode): same host, port 6432
psql -h pg-xxxxxxxx.postgresql.de-fra.ionos.com -U fincorp_app -d ledger --port=6432

Resumen

El nivel relacional administrado concentra las decisiones de durabilidad de FinCorp: el modo de replicación de PostgreSQL establece el RPO (asynchronous para trabajo de baja latencia y tolerante a pérdidas; estrictamente síncrono con tres o más nodos para cero pérdida de datos comprometidos; nunca el modo no estricto obsoleto), mientras que MariaDB elimina la elección al ser solo asíncrono. La escalada de lectura no se realiza con réplicas, que no existen, sino con una caché In-Memory y el pooler pgbouncer contra un límite de conexión derivado de RAM. El failover es automático dentro de un Cluster y está diseñado a través de clústeres con comprobaciones de salud DNS. El acceso es solo a través de puntos de conexión privados, y la continuidad se construye a partir de PITR y dump/restore porque Backup Service no cubre las bases de datos. La compilación DCD compromete esas decisiones en un Cluster real.

Puntos clave:

• El modo de replicación de PostgreSQL es el control de RPO: Asíncrono (predeterminado) acepta una ventana de pérdida limitada para la latencia; Estrictamente síncrono no pierde datos comprometidos pero necesita un mínimo de tres Node y detiene las escrituras si no hay un standby síncrono disponible. El modo síncrono no estricto está obsoleto; MariaDB es solo asíncrono.
• No hay réplicas de lectura. Escalar lecturas con la caché In-Memory más el pooler pgbouncer administrado (modo de transacción predeterminado, puerto 6432); el límite de conexión se deriva de RAM (hasta 1000, menos 11 reservados) y no es configurable.
• El failover es automático dentro de un Cluster (promoción de standby); el failover entre Cluster está diseñado con un reenvío de Cloud DNS de bajo TTL dirigido por una comprobación de salud externa, que dirige solo nuevas conexiones y cuyo piso de TTL conduce a RTO.
• Los clústeres son solo de puntos de conexión privados, TLS-enforced (prefer, no deshabilitable por el cliente), y deben tener un IP privado fuera del rango DHCP.
• Backup Service no cubre DBaaS. La continuidad es PITR (retención predeterminada de 7 días, configurable de 1 a 365 días) más dump/restore (pg_dump/pg_restore/psql, o mariadb-dump), ejecutado desde un host en la red privada LAN del Cluster; este es el camino de migración hacia y desde.

Terminología importante:

• Replicación estrictamente síncrona: Un compromiso se confirma solo después de que un standby síncrono lo mantenga, y el primario rechaza escrituras en lugar de ejecutarse sin protección; garantiza cero pérdida de datos comprometidos a costa de la disponibilidad y la latencia por transacción.
• Replicación asíncrona: El primario confirma un compromiso en la escritura local y replica en segundo plano; la latencia más baja, con una ventana de pérdida de datos limitada en caso de failover.
• Pooler pgbouncer: El pooler de conexiones administrado, configurado solo por el modo de grupo (transacción o sesión), alcanzado en el puerto 6432, utilizado para mantener las conexiones del cliente por debajo del límite derivado de RAM.
• Recuperación en un momento dado (PITR): Restauración en su lugar a una marca de tiempo no inclusiva elegida utilizando copias de seguridad base más WAL archivado, retenido 7 días por defecto (1 a 365 configurable).

Lectura adicional

• Unidad 5.5: Base de datos en memoria (nivel de caché) - la mitad de escalado de lectura y externalización de sesión del patrón de no réplicas de lectura.
• Unidad 3.7: DNS y enrutamiento de conmutación por error - el mecanismo de conmutación por error entre Cluster mencionado aquí.
• Unidad 5.7: Protección de datos y ciclo de vida - cómo PITR, volcado/restauración, instantáneas y archivo Object Storage se componen en un plano de continuidad.
• Unidad 7.4: Migración y corte híbrido - donde se planifica la ola de bases de datos como la ola de volcado/restauración.