RA6 · verificado

RA6 de Administración de Sistemas Gestores de Bases de Datos · ASIR

Aplica criterios de disponibilidad analizándolos y ajustando la configuración del sistema gestor.

Comprobar mi dominio con José →

Contenido verificado asociado a este RA

Fundamentos de Bases de Datos Distribuidas y Estrategias de Fragmentación

Esta unidad explora la necesidad y utilidad de las bases de datos distribuidas para mejorar la disponibilidad y escalabilidad, detallando las políticas de fragmentación horizontal, vertical y mixta, y sus implicaciones en el diseño.

Implementación de Bases de Datos Distribuidas Homogéneas e Integración de BDD Preexistentes

Esta unidad aborda la implementación práctica de bases de datos distribuidas, diferenciando entre la creación de un sistema homogéneo desde cero y la integración de bases de datos preexistentes para formar un sistema distribuido.

Configuración de Replicación Maestro-Esclavo y Replicación en Cadena

Esta unidad se centra en la configuración de sistemas de replicación para alta disponibilidad, cubriendo la arquitectura maestro-esclavo y la replicación en cadena, explicando sus mecanismos y casos de uso.

Comprobación de la Tolerancia a Fallos en Sistemas Distribuidos y Replicados

Esta unidad se enfoca en la verificación práctica de la resiliencia de bases de datos distribuidas y replicadas, simulando fallos de nodos para evaluar la disponibilidad y la integridad de los datos.

Conceptos clave

Base de Datos Distribuida (BDD)DisponibilidadEscalabilidadFragmentación HorizontalFragmentación VerticalFragmentación MixtaTransparencia de localizaciónBase de Datos Distribuida HomogéneaIntegración de BDDHeterogeneidadMiddleware de BDDFederación de Bases de DatosTransparencia de datosReplicación de Bases de DatosMaestro-Esclavo (Master-Slave)Log Binario (Binlog/WAL)FailoverReplicación en Cadena (Chain Replication)

Errores que conviene evitar

  • Fragmentar sin considerar la reconstrucción: Un error común es fragmentar una tabla sin asegurar que los fragmentos puedan ser unidos para reconstruir la tabla original, por ejemplo, omitiendo la clave primaria en fragmentos verticales. Corrección: Siempre incluir la clave primaria en todos los fragmentos verticales y asegurar que las condiciones de fragmentación horizontal sean disjuntas y completas.
  • Ignorar el patrón de acceso: Diseñar la fragmentación basándose solo en la estructura de la tabla y no en cómo las aplicaciones acceden a los datos. Esto puede llevar a un alto coste de comunicación entre nodos. Corrección: Analizar las consultas más frecuentes y diseñar la fragmentación para que la mayoría de las consultas se resuelvan dentro de un único fragmento o nodo.
  • Ignorar la latencia de red en BDD homogéneas: Al distribuir datos, las operaciones que requieren acceso a múltiples nodos pueden ser lentas si la red no es óptima. Corrección: Diseñar la fragmentación para minimizar las operaciones de unión entre nodos y optimizar la infraestructura de red.
  • Subestimar la complejidad de la heterogeneidad: La integración de BDD preexistentes con diferentes SGBD y esquemas es mucho más compleja que una BDD homogénea. Corrección: Planificar una fase de análisis exhaustiva para mapear esquemas y definir estrategias de resolución de conflictos, y considerar el uso de herramientas ETL para consolidación si la federación directa es demasiado compleja.
  • Desincronización de esclavos: No monitorear el retraso de replicación (replication lag) puede llevar a que los esclavos tengan datos obsoletos. Corrección: Implementar monitoreo constante del `Seconds_Behind_Master` (MySQL) o `pg_last_wal_receive_lsn` (PostgreSQL) y configurar alertas.
  • Fallo en la promoción del maestro: No tener un procedimiento claro y automatizado para la promoción de un esclavo a maestro en caso de fallo del original. Corrección: Utilizar herramientas de orquestación de replicación (ej. Orchestrator para MySQL, Patroni para PostgreSQL) o scripts robustos que gestionen el failover de forma segura y consistente.
  • No probar los escenarios de fallo: Configurar la replicación pero nunca simular un fallo real. Corrección: Establecer un plan de pruebas de desastre periódico y documentar los resultados y las lecciones aprendidas.
  • Falta de automatización en el failover: Depender de la intervención manual para promover un esclavo a maestro. Corrección: Implementar y probar herramientas de orquestación de replicación que automaticen el proceso de failover para reducir el RTO y minimizar el error humano.

Qué se evalúa en este RA

CE a

Se ha reconocido la utilidad de las bases de datos distribuidas.

CE b

Se han descrito las distintas políticas de fragmentación de la información.

CE c

Se ha implantado una base de datos distribuida homogénea.

CE d

Se ha creado una base de datos distribuida mediante la integración de un conjunto de bases de datos preexistentes.

CE e

Se ha configurado un «nodo» maestro y varios «esclavos» para llevar a cabo la replicación del primero.

CE f

Se ha configurado un sistema de replicación en cadena.

CE g

Se ha comprobado el efecto de la parada de determinados nodos sobre los sistemas distribuidos y replicados.

Canal Estudios es un servicio de Skillback S.L. · NIF B2481724 · Barcelona, España
Aviso legal · Privacidad · Cookies · Términos · Atles de Catalunya