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

Introducción

La capa relacional es donde se concentran las decisiones de diseño más importantes de FinCorp. El libro mayor de un banco no puede perder de forma silenciosa transacciones confirmadas, pero una capa que bloquea las escrituras cada vez que un nodo presenta un problema es, en sí misma, un tipo de interrupción. Los servicios administrados de base de datos le permiten ajustar con precisión el equilibrio entre durabilidad y disponibilidad, pero solo si comprende qué garantiza cada configuración y qué comodidades la plataforma no ofrece deliberadamente. En esta unidad se abordan las decisiones sobre replicación, escalado, conmutación por error, acceso y recuperación, y luego se construye el clúster relacional de FinCorp en Data Center Designer con dichas decisiones integradas.

La formulación honesta es más importante de lo habitual en este contexto. No hay réplicas de solo lectura, no existe un producto de conmutación por error administrado y Backup Service no interactúa con una base de datos administrada. Cada brecha cuenta con un patrón nativo que se compone en torno a ella, y un arquitecto que trata estas limitaciones como entradas de diseño en lugar de funciones faltantes obtiene una capa de datos más limpia y predecible.

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

Un clúster de PostgreSQL administrado es un nodo primario con un total de uno a cinco instancias, por lo que hasta cuatro standby. El modo de replicación rige el contrato entre una transacción confirmada y su durabilidad a través de esos nodos, y es la única decisión que establece el RPO del clúster. PostgreSQL admite dos modos actuales: Asíncrono (el predeterminado) y Síncrono estricto. Un tercer modo, Síncrono no estricto, está deprecado para nuevos clústeres y no debe elegirse; los clústeres existentes que lo utilizan pueden migrarse a asíncrono o síncrono estricto a través de la API de modo de replicación.

Asíncrono confirma una transacción en cuanto se escribe en el disco en el primario; la replicación a los standby ocurre en segundo plano, con un retardo típico de pocos milisegundos. La ventaja es la menor latencia de escritura. El costo es un RPO no nulo: si el primario falla antes de que un commit reciente se haya replicado, ese commit se pierde cuando un standby es promovido. El peor caso documentado para la ruta de copia de seguridad es la pérdida de 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 fragmentos de 16 MB o cada 30 minutos, lo que ocurra primero. En un clúster multinodo saludable, la exposición realista es de unos pocos milisegundos de commits en curso, pero el punto arquitectónico se mantiene: el modo asíncrono intercambia una pequeña ventana acotada de pérdida de datos por disponibilidad y latencia.

Síncrono estricto retiene el commit hasta que al menos un standby síncrono tenga la transacción, por lo que no se pierde ningún dato confirmado durante un failover, incluido un fallo de almacenamiento del primario con una pérdida simultánea de todos los standby. El precio se paga en dos frentes. La latencia adquiere un sobrecoste constante por transacción, porque cada COMMIT ahora espera la replicación (la latencia entre nodos suele ser 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 ningún standby síncrono disponible, el primario deja de aceptar escrituras en lugar de continuar sin protección. Para ejecutarlo de forma segura, por lo tanto, se necesita un mínimo de tres instancias, de modo que la pérdida de un nodo aún deje un primario y un standby síncrono. Provisionar menos nodos es la trampa clásica, ya que un fallo de un solo standby entonces detiene todas las escrituras.

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

PostgreSQL también le permite cambiar las garantías de commit por transacción, y la asimetría importa: no puede aplicar un commit síncrono en un clúster asíncrono (sin un standby síncrono, cualquier configuración más fuerte colapsa a local), pero puede ejecutar un clúster síncrono estricto y relajar transacciones individuales a synchronous_commit=local donde una pequeña pérdida de datos sea aceptable. La opción predeterminada defendible es, por lo tanto, configurar el clúster con la garantía más estricta que la carga de trabajo necesite y relajar selectivamente, no al revés.

MariaDB elimina esta decisión por completo. Managed MariaDB es solo asíncrono: un modo de replicación, el predeterminado. Esa es una decisión de alcance, no un defecto que deba sortearse. MariaDB se ejecuta en Virtual Servers (no en instancias Cube), utiliza almacenamiento SSD Premium con motores InnoDB, MyISAM o Aria, y solo distribuye versiones LTS, actualmente desde la 10.6 en adelante. Si una carga de trabajo de FinCorp necesita genuinamente commits sin pérdida de datos, debe estar en PostgreSQL en modo síncrono estricto, no en MariaDB. Elegir el motor es, por lo tanto, en parte una decisión de durabilidad, no solo de dialecto SQL.

1.1 Qué hace el failover automático dentro de un clúster

El failover dentro de un solo clúster es automático y no requiere ningún producto externo. Cuando el primario se vuelve no disponible, un standby es promovido. En modo asíncrono, cualquier standby puede ser promovido y las transacciones no replicadas se pierden; en modo síncrono estricto, solo un standby que contenga todas las transacciones confirmadas es elegible, por lo que el modo no puede perder datos confirmados. Existe como máximo un standby síncrono a la vez, y si falla, otro se eleva automáticamente al rol de síncrono. Esta promoción dentro del clúster es la totalidad del failover administrado de la plataforma para una base de datos: protege contra la pérdida de nodos dentro de un clúster, no entre clústeres o regiones.

2. Escalado de lecturas sin réplicas de lectura

Los standby de PostgreSQL existen para la alta disponibilidad, no para servir tráfico de lectura. No hay réplicas de lectura: no se puede dirigir el tráfico de informes o de alta intensidad de lectura a un standby, y no existe un punto de solo lectura administrado. Este es un límite fijo de la plataforma, y el patrón nativo que lo reemplaza tiene dos partes.

Primero, un límite de conexiones que se deriva, no que se elige. El número máximo de conexiones a un clúster de PostgreSQL se calcula a partir del tamaño de la RAM y no es configurable por el usuario. La correspondencia documentada es la siguiente:

De estas, 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 se puede resolver una tormenta de conexiones editando un parámetro; las únicas palancas son más RAM (hasta el límite de 1000 conexiones) o menos conexiones reales. Para un conjunto de microservicios o un front end serverless que abre muchas más conexiones lógicas de las que permite el límite, la respuesta es el agrupamiento de conexiones.

Segundo, el agrupador de conexiones administrado (pgbouncer). Se puede habilitar en el clúster; lo único que se configura es el modo de agrupación. El modo Transaction (el predeterminado) devuelve la conexión al grupo al final de cada transacción, lo que multiplexa muchas conexiones de cliente sobre pocas conexiones de backend y es la elección correcta para el tráfico típico de web y microservicios. El modo Session mantiene la conexión de backend hasta que el cliente se desconecta, lo cual es necesario solo cuando una sesión depende de un estado acotado a la conexión, como variables de sesión o sentencias preparadas que deben persistir. El agrupador escucha en un puerto diferente: 6432 en lugar del 5432 predeterminado de la base de datos, por lo que habilitarlo también es un cambio de configuración del cliente, no un conmutador transparente. Las aplicaciones deben dirigirse al puerto 6432 para obtener el beneficio.

El escalado de lecturas propiamente dicho se resuelve un nivel superior, en la caché. Dado que los standby no pueden servir lecturas, el patrón de escalado de lecturas de la plataforma es la caché In-Memory DB (Unidad 5.5) colocada delante de la capa relacional en la red privada, combinada con agrupamiento para proteger el presupuesto de conexiones. Las lecturas frecuentes son absorbidas por la caché, el primario relacional maneja las escrituras y las lecturas con fallo de caché, y el agrupamiento mantiene el número de conexiones por debajo del límite derivado de la RAM. Esta composición de caché más agrupamiento es lo que significa "escalar lecturas" en esta plataforma, y es por eso que la Unidad 5.5 es una dependencia directa de cualquier servicio FinCorp con alta lectura, no un extra opcional.

3. Conmutación por error entre Clusters y acceso privado

La promoción dentro del Cluster (Sección 1.1) es la única conmutación por error administrada. No existe un producto de conmutación por error administrado que abarque Clusters o regiones, y, de manera crucial, no existe en absoluto una replicación de base de datos nativa entre regiones o entre Clusters. Si FinCorp necesita continuidad más allá de un solo Cluster, esa continuidad se diseña y se dirige, no se replica, en la capa de base de datos.

El patrón nativo entre Clusters es la conmutación por error de DNS orquestada por el cliente (construida en la Unidad 3.7 y revisitada para la resiliencia en la Unidad 7.1). Se establecen dos Clusters independientes, se mantienen sincronizados por la aplicación o mediante volcados/restauraciones periódicas, y una comprobación de estado externa redirige un registro de Cloud DNS con TTL bajo hacia el punto de acceso que esté operativo. Cloud DNS en sí mismo no es consciente del estado; sirve el registro que usted configure. Dos propiedades dirigen el diseño: DNS solo dirige las nuevas conexiones, por lo que las sesiones existentes no se migran y la aplicación debe reconectarse de manera limpia; y el tiempo de recuperación lo determina el límite inferior de TTL del registro de conmutación por error, el parámetro que usted ajusta para el RTO. Dado que el segundo Cluster es una base de datos separada, este es un mecanismo de disponibilidad con su propio RPO, gobernado por cómo usted mantiene sincronizadas las dos instancias, y no un espejo sin pérdida.

El acceso es exclusivamente a través de puntos de acceso privados. Un Cluster administrado no tiene IP pública; es accesible únicamente desde dentro del centro de datos virtual a través de una LAN privada. Durante la creación, usted selecciona un centro de datos, una LAN y una IP privada. Las conexiones están protegidas por TLS de forma predeterminada: el modo SSL es prefer y no puede desactivarse por el cliente, con el certificado del servidor emitido por una autoridad de confianza. Varios rangos CIDR internos están reservados por la plataforma y no pueden usarse para la IP privada del Cluster. La ventaja es que la capa de datos se sitúa detrás del equilibrador de carga privado de capa 4 de la arquitectura por capas canónica (Unidad 1.2), nunca expuesta a internet, y solo es alcanzada 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 las bases de datos relacionales administradas, y ambos son restricciones sobre las que hay que diseñar.

El Backup Service no cubre las bases de datos administradas. El Backup Service basado en Acronis realiza copias de seguridad de VMs y Block Storage, no de DBaaS, y las instantáneas de Block Storage son un retroceso a nivel de VM, no copias de seguridad consistentes a nivel de base de datos. La continuidad de la base de datos se construye únicamente a partir de dos mecanismos nativos: la recuperación en un punto en el tiempo administrada, y el volcado/restauración lógico.

La recuperación en un punto en el tiempo es la red de seguridad in situ. El servicio administrado combina copias de seguridad periódicas de base con el archivado continuo del Write-Ahead Log, de modo que una copia de seguridad representa un intervalo de tiempo en lugar de un instante único. Las copias de seguridad se crean cuando se crea un clúster, cuando se eleva su versión principal y cuando se ejecuta una operación de PITR; se almacenan cifradas en un bucket de IONOS Cloud Object Storage en la misma región (las bases de datos en una región sin Object Storage se copian de seguridad a eu-central-2). La retención predeterminada es de 7 días y puede configurarse de 1 a 365 días a través de la API v2; reducirla elimina las copias de seguridad más antiguas que la nueva ventana. Una restauración apunta a un recoveryTargetTime ISO-8601 no inclusivo, solo puede utilizar una copia de seguridad de la misma versión principal o de una versión anterior, requiere que el clúster esté en estado AVAILABLE, puede mover la base de datos a otra región y hace que la base de datos no esté disponible durante la duración de la operación (el servicio recomienda al menos 4 GB de RAM durante una restauración, reduciéndola posteriormente). Considere la ventana predeterminada de 7 días como un plazo 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.

El volcado/restauración es la única ruta de migración hacia adentro o hacia afuera. No existe un asistente de importación administrado ni una migración basada en replicación hacia el servicio. Mover una base de datos PostgreSQL existente a 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 derivan de la regla de punto de acceso privado: dado que el clúster de destino solo es accesible desde dentro del VDC, la restauración debe ejecutarse desde un host en la LAN privada del clúster (por ejemplo, una VM de salto en la capa de aplicación), y el cambio implica un tiempo de inactividad real proporcional al tamaño del conjunto de datos mientras se carga el volcado. Esta es la entrada relacional en el plan de migración de la Unidad 7.4, donde la ola de bases de datos es la ola de volcado/restauración. Planifíquela como una operación dimensionada y programada, no como una sincronización en segundo plano.

Una advertencia sobre credenciales tiene un peso real: las credenciales de usuario establecidas en la creación del clúster son las únicas que establece la ruta de creación, y se configuran una sola vez. Captúrelas en el almacén de secretos en el momento de la aprovisionamiento, porque no existe una ruta de restablecimiento conveniente posteriormente.

Guía de implementación de DCD

Ahora construirá el Cluster relacional de FinCorp: un Cluster privado de PostgreSQL multinodo 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 hacia la LAN de la aplicación. Esto materializa la decisión de la capa de datos de las secciones 1 a 3. El requisito previo es un VDC existente con una LAN privada que la capa de aplicación ya utiliza (la topología de la Unidad 3.1); el Cluster se conectará a esa LAN con una IP privada que usted elija para evitar el rango de DHCP.

Objetivo de construcción: Construir un Cluster privado multinodo con modo de replicación, ventana de mantenimiento y detalles de conexión.

Pasos (en Data Center Designer):

1. Abra Menú > Bases de datos > PostgreSQL. La visión general muestra los recursos asignados a su contrato y cuántos están en uso; confirme que hay margen disponible antes de crear el Cluster.
2. Haga clic en Crear Cluster. Proporcione un Nombre del Cluster que codifique el entorno y la capa de FinCorp, y seleccione la Ubicación (región) que satisfaga la decisión de residencia tomada en la Unidad 1.4. La región es una decisión de ubicación, no algo que se deba revisar más adelante.
3. Elija la versión de PostgreSQL del conjunto admitido (actualmente 14, 15 o 16). Seleccionar una versión principal actual mantiene el mayor margen de actualización.
4. Seleccione el Modo de replicación. Para la carga de trabajo de nivel de libro mayor de FinCorp, elija Sincrónico estricto y asegúrese de que la cantidad de instancias en el siguiente paso sea de al menos tres, para que la pérdida de un solo nodo de respaldo no detenga las escrituras. Para servicios sensibles a la latencia y tolerantes a la pérdida, déjelo en Asincrónico. No seleccione el modo Sincrónico no estricto obsoleto.
5. Establezca la Ubicación de copia de seguridad (región). Puede colocar las copias de seguridad en una región diferente a la de la base de datos para protección fuera del sitio; tome esta decisión en función de los requisitos de auditoría y residencia, en lugar de aceptar el valor predeterminado a ciegas.
6. En Configuración de instancia, establezca las CPUs y la RAM por instancia (recuerde que el límite de conexiones se deriva de la RAM), elija un Tipo de almacenamiento (SSD Premium es el predeterminado; manténgalo para la carga de trabajo de la base de datos, y tenga en cuenta que el SSD por debajo de aproximadamente 100 GB no se recomienda), e introduzca el Tamaño de almacenamiento. Establezca la cantidad de instancias para que un Cluster estrictamente sincrónico tenga tres o más nodos.
7. En Configuración de red, seleccione el Centro de datos, la LAN del centro de datos que utiliza la capa de aplicación y una IP privada. No hay un punto de extremo público. Para encontrar una IP privada segura, tenga en cuenta que el DHCP de la LAN utiliza un /24, por lo que reutilice los tres primeros octetos de la subred de la 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 bajo tráfico genuino, 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 trabajo.
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 el Cluster; captúrelas en el almacén de secretos de inmediato, ya que la ruta de creación es el lugar previsto para establecerlas.
10. Cree el Cluster. Una vez que alcance el estado DISPONIBLE, conéctese desde un host en la misma LAN privada usando la IP privada asignada o el nombre de DNS devuelto en el puerto 5432. Si más adelante habilita el pooler administrado (pgbouncer), redirija a los clientes al puerto 6432 y elija el modo de transacción, a menos que una función con alcance de sesión fuerce el modo de sesión.

Errores comunes:

• Aprovisionar un Cluster estrictamente sincrónico con menos de tres instancias. Con solo un nodo de respaldo, una falla de un solo nodo de respaldo detiene todas las escrituras, porque el modo estricto se niega a eliminar la replicación síncrona. Dimensione a tres o más nodos antes de elegir el modo estricto.
• Elegir el modo Sincrónico no estricto obsoleto para un Cluster nuevo. Use Asincrónico o Sincrónico estricto; el modo intermedio no garantiza la durabilidad multinodo en todas las circunstancias y existe solo como ruta de herencia.
• Asignar al Cluster una IP privada dentro del rango de DHCP. Las colisiones rompen la conectividad de forma intermitente; reutilice los tres primeros octetos de la LAN y elija una dirección que termine entre .3 y .10.
• Establecer una ventana de mantenimiento durante las horas de trabajo, o tratarla como cosmética. El mantenimiento se ejecuta en una ventana de 4 horas a partir de la hora de inicio que usted elija; elija un intervalo de baja demanda real.
• Esperar que los nodos de respaldo sirvan tráfico de lectura o que sean un punto de extremo de lectura administrado. No hay réplicas de lectura; escale las lecturas con la caché de In-Memory DB más el pooler pgbouncer, y recuerde que el pooler está en el puerto 6432.
• Suponer que Backup Service o una instantánea de Block Storage protege la base de datos. Ninguno cubre DBaaS. La continuidad de la base de datos es PITR (retención predeterminada de 7 días, establecida deliberadamente) más volcado/restauración.
• Perder las credenciales iniciales de la base de datos. Se establecen una sola vez en la ruta de creación sin una restablecimiento conveniente; guárdelas en el momento del aprovisionamiento.

Una breve ilustración del lado del cliente de los dos hechos que más a menudo causan problemas, el punto de extremo privado y el puerto del pooler:

# 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

La capa relacional administrada centraliza las decisiones de durabilidad de FinCorp: el modo de replicación de PostgreSQL define el RPO del Cluster (asíncrono para cargas de trabajo de baja latencia y tolerantes a la pérdida de datos; estrictamente síncrono con tres o más nodos para una pérdida nula de datos confirmados; nunca el modo no estricto obsoleto), mientras que MariaDB elimina la elección al ser exclusivamente asíncrono. La escalabilidad de lectura no se realiza mediante réplicas, que no existen, sino mediante una caché In-Memory y el pooler pgbouncer frente a un límite de conexiones derivado de la RAM. El failover es automático dentro de un Cluster y se diseña entre Clusters mediante comprobaciones de estado de DNS. El acceso es solo a través de un punto de conexión privado, y la continuidad se construye con PITR y volcado/restauración, porque el Backup Service no cubre las bases de datos. La compilación DCD fija entonces esas decisiones en un Cluster real.

Puntos clave:

• El modo de replicación de PostgreSQL es el regulador del RPO: el modo asíncrono (predeterminado) acepta una ventana de pérdida acotada por latencia; el modo estrictamente síncrono no pierde datos confirmados, pero requiere un mínimo de tres nodos y detiene las escrituras si no hay un standby síncrono disponible. El modo síncrono no estricto está obsoleto; MariaDB es exclusivamente asíncrono.
• No hay réplicas de lectura. Escale las lecturas con la caché In-Memory junto con el pooler pgbouncer administrado (modo de transacción por defecto, puerto 6432); el límite de conexiones se deriva de la RAM (hasta 1000, menos 11 reservadas) y no es configurable.
• El failover es automático dentro de un Cluster (promoción del standby); el failover entre Clusters se diseña mediante un reencaminamiento de Cloud DNS con TTL bajo, orquestado por el cliente y dirigido por una comprobación de estado externa, que desvía solo las nuevas conexiones y cuyo límite inferior de TTL determina el RTO.
• Los Clusters son solo de punto de conexión privado, con TLS obligatorio (prefer, no desactivable por el cliente) y deben asignarse una IP privada fuera del rango DHCP.
• El 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 volcado/restauración (pg_dump/pg_restore/psql, o mariadb-dump), ejecutado desde un host en la LAN privada del Cluster; esta es la ruta de migración de entrada y salida.

Terminología importante:

• Replicación estrictamente síncrona: Un commit se confirma solo después de que un standby síncrono lo retenga, y el primario rechaza las escrituras en lugar de operar sin protección; garantiza una pérdida nula de datos confirmados a costa de la disponibilidad y la latencia por transacción.
• Replicación asíncrona: El primario confirma un commit en la escritura local y replica en segundo plano; menor latencia, con una ventana de pérdida de datos acotada en caso de failover.
• Pooler pgbouncer: El pooler de conexiones administrado, configurado solo por modo de pool (transacción o sesión), accesible en el puerto 6432, utilizado para mantener las conexiones del cliente por debajo del límite derivado de la RAM.
• Recuperación en un punto en el tiempo (PITR): Restauración in situ a una marca de tiempo no inclusiva elegida, utilizando copias de seguridad base más WAL archivado, retenida 7 días por defecto (configurable de 1 a 365).

Lectura adicional

• Unidad 5.5: Base de datos en memoria (capa de caché): la mitad del patrón sin réplicas de lectura que se encarga de la escalabilidad de lectura y la externalización de sesiones.
• Unidad 3.7: DNS y enrutamiento de conmutación por error: el mecanismo de conmutación por error entre clústeres al que se hace referencia aquí.
• Unidad 5.7: Protección de datos y ciclo de vida: cómo PITR, volcado/restauración, instantáneas y el archivo en Object Storage se combinan en un solo plano de continuidad.
• Unidad 7.4: Migración y conmutación híbrida: donde la ola de la base de datos se planifica como la ola de volcado/restauración.