5 UNIDAD

5.1 Espejo (mirroring)

El Mirroring (Base de Datos Espejo) proporciona una solución de alta disponibilidad de bases de datos, aumenta la seguridad y la disponibilidad, mediante la duplicidad de la base de datos.

Esta tecnología está disponible a partir de la versión de SQL Server 2005 (es la evolución del log shipping presente en versiones anteriores)

En el Mirroring tenemos un servidor principal/primario que mantiene la copia activa de la base de datos (bbdd accesible). Otro servidor de espejo que mantiene una copia de la base de datos principal y aplica todas las transacciones enviadas por el Servidor Principal (en el que no se podrá acceder a la bbdd). Y un servidor testigo/arbitro que permite recuperaciones automáticas ante fallos, monitoriza el servidor principal y el de espejo para en caso de caída cambiar los roles (servidor opcional, no es obligatorio).

 

 

Existen varios tipos de mirroring:

•      Alta disponibilidad: Garantiza la consistencia transaccional entre el servidor

principal y el servidor de espejo y ofrece Automatic Failover mediante un servidor Instituto Tecnológico de Comitán testigo.

•      Alta Protección: Garantiza la consistencia transaccional entre el servidor principal y el espejo.

•      Alto Rendimiento: Aplica las transacciones en el Servidor Espejo de manera asíncrona ocasionando mejoras significativas en el rendimiento del servidor principal pero no garantiza que dichas transacciones se hallan realizado de manera exitosa en el espejo.

 

 

Base de Datos Espejo (Database Mirroring).

 

Donde actúan dos servidores o más para mantener copias de la base de datos y archivo de registro de transacciones.

El servidor primario como el servidor espejo mantienen una copia de la base de datos y el registro de transacciones, mientras que el tercer servidor, llamado el servidor árbitro, es usado cuando es necesario determinar cuál de los otros dos servidores puede tomar la propiedad de la base de datos. El árbitro no mantiene una copia de la base de datos. La configuración de los tres servidores de base de datos (el primario, el espejo y el árbitro) es llamado Sistema Espejo (Mirroring System), y el servidor primarioy espejo juntos son llamados Servidores Operacionales (Operational Servers) o Compañeros (Partners).

 

BENEFICIOS DEL ESPEJEO DE DATOS EN UN DBMS

Esta característica tiene 3 modalidades que son Alto rendimiento, Alta Seguridad, y Alta Disponibilidad, este caso estamos hablando de las 2 primeras, las cuales el levantamiento es manual.

La creación de reflejo de la base de datos es una estrategia sencilla que ofrece las siguientes ventajas:

•      Incrementa la disponibilidad de una base de datos.

•      Si se produce un desastre en el modo de alta seguridad con conmutación automática por error, la conmutación por error pone en línea rápidamente la copia en espera de la base de datos, sin pérdida de datos. En los demás modos operativos, el administrador de bases de datos tiene la alternativa del servicio forzado (con una posible pérdida de datos) para la copia en espera de la base de datos. Para obtener más información, vea Conmutación de roles, más adelante en este tema.

•      Aumenta la protección de los datos.

•      La creación de reflejo de la base de datos proporciona una redundancia completa o casi completa de los datos, en función de si el modo de funcionamiento es el de alta seguridad o el de alto rendimiento.

La Tecnología Espejeo o Espejo, mejor conocida como Mirroring, busca que, cuando un servidor en productivo falle, algún otro servidor, sea capaz de tomar la carga de operatividad que están generando los consumidores de la base de datos sin pérdidas ni de datos, ni de tiempo, manteniendo la consistencia y la disponibilidad de datos en todo momento.

La configuración básica de una Base de Datos Espejo necesita dos servidores de bases de datos que estén comunicados entre sí. Normalmente, estas instancias de servidor residen en computadoras en diferentes ubicaciones. La Figura 2.1 muestra la idea esencial de la tecnología, cuenta con dos bases de datos una primaria o principal y un espejo, copia de la primaria o reflejo. La principal es la base de datos activa u operativa (sobre la que se ejecutan todas las transacciones) y la base de datos espejo será la copia idéntica de la base de datos principal incluyendo el registro de transacciones (log). De tal forma que, al ocurrir un fallo, se pueda habilitar la base de datos espejo.

Tecnología Espejo o Espejeo (Mirroring). Configuración con dos servidores

 

En este tipo de configuración el intercambio de servidores se realiza de forma manual y es responsabilidad del administrador de la base de datos (DBA). 

La siguiente figura muestra la secuencia de eventos cuando ocurre un fallo dentro de este tipo de configuración: 

1.  Sincronización de la base de datos principal con la base de datos espejo. La configuración básica de Espejo está activa. 

2.  Ocurre un Fallo en la base de datos principal. 

3.  El DBA deshabilita la base de datos principal, para recuperarla. Inmediatamente configura la base de datos espejo como principal. Entonces, la base de datos espejo ahora es la base de datos activa. 

4.  Después de recuperar la base de datos dañada o deshabilitada al momento del fallo, se configura como base de datos espejo.

Secuencia de eventos en una configuración básica de la Tecnología Espejo

 

Sin embargo, para ofrecer Alta Disponibilidad en una base de datos empleando la Tecnología Espejo, es necesario que exista un tercer servidor llamado servidor testigo o árbitro. El Testigo (Witness) no mantiene una copia de la base de datos, únicamente es necesario para detectar el fallo y determinar cuál de los otros dos servidores toma el rol de la base de datos principal en caso de una caída de servicio. Cuando existen el servidor testigo en la configuración, el intercambio de servidores se realiza de forma automática y transparente a los usuarios. La siguiente figura muestra la secuencia de eventos cuando ocurre un fallo dentro de este tipo de configuración: 

1.  Sincronización de la base de datos principal con la base de datos espejo. La Configuración con Testigo de la Tecnología Espejo está activa. 

2.  Ocurre un Fallo en la base de datos principal. 

3.  El servidor Testigo detecta el fallo de la base de datos principal e inmediatamente configura la base de datos espejo como principal. La base de datos espejo ahora es la base de datos activa. 

4.  Después de recuperar la base de datos dañada al momento del fallo, se configura como base de datos espejo.

Secuencia de eventos en una Configuración con Testigo en la Tecnología Espejo

 

Por lo anterior, se identifican tres roles de la configuración de la Tecnología Espejo: 

− Servidor Principal. Mantiene la copia activa de la base de datos (base de datos principal), a través de la cual se ofrece el servicio a los usuarios. 

 

− Servidor Espejo (Mirror). Mantiene una copia de la base de datos principal (base de datos espejo) y aplica todas las transacciones enviadas por el Servidor Principal, manteniendo sincronizada la base de datos espejo. 

− Servidor Testigo (Witness). No es necesario implementar un Servidor Testigo. No obstante, si deseamos que nuestra solución ofrezca recuperación automática ante fallos (automatic failover), entonces sí se debe configurar. 

Dentro del sistema gestor de base de datos Microsoft SQL Server 2016, éstos tres roles de la Tecnología Espejo deben residir en diferentes instancias. Particularmente, en el sistema gestor de base de datos Microsoft SQL Server 2016 la configuración de la Tecnología Espejo funciona con una relación, conocida como sesión de creación de espejo o reflejo de la base de datos, entre estas instancias del servidor. Una de las instancias sirve como base de datos principal (en producción) a los clientes o usuarios. Otra instancia actúa como base de datos espejo (en espera o cálido). El servidor principal y el servidor espejo cooperan como socios en una sesión de creación de espejo o reflejo de la base de datos. Los dos socios realizan funciones complementarias en la sesión: el rol principal y el rol espejo o reflejo. 

La creación de reflejo de la base de datos implica rehacer cada operación de inserción, actualización y eliminación que se produce en la base de datos principal en la base de datos espejo o reflejada. La reedición se lleva a cabo enviando una secuencia de registros de transacciones activos al servidor reflejado, que aplica los registros a la base de datos reflejada, en secuencia, lo más rápido posible. A diferencia de la tecnología Replicación, que funciona en el nivel lógico, el Espejo de la base de datos funciona en el nivel de registro físico. Microsoft SQL Server 2016 permite configurar tres tipos de Espejo: 

− Alta disponibilidad: Garantiza la consistencia transaccional entre el servidor principal y el servidor de espejo y ofrece recuperación automática ante fallos mediante un servidor testigo. 

 

− Alta Protección: Garantiza la consistencia transaccional entre el servidor principal y el servidor espejo.

− Alto Rendimiento: Aplica las transacciones en el Servidor Espejo de manera asíncrona ocasionando mejoras significativas en el rendimiento del servidor principal pero no garantiza que dichas transacciones se hallan realizado de manera exitosa en el espejo.

La siguiente tabla muestra los diferentes modos de configuración y sus características principales. 

Tabla Tipos de Espejo en Microsoft SQL Server

 

El modo de configuración a implementar en este estudio es el de Alta disponibilidad, el cual requiere una tercera instancia cuyo rol actúa como árbitro o testigo que permite la automatización del cambio de roles dentro del mecanismo y permitiendo la recuperación automática de la base de datos principal ante un fallo.

 

 

 

 

 

 

 

 

 

5.2 Replica (replication)

 

La Réplica de Mezcla, además de hacer el back-up de la Base de Datos del Servidor (comúnmente por razones de seguridad), es capaz de brindar el mismo servicio que ofrece el Servidor  a los clientes, cuando éste por cualquier motivo se encuentre de baja en las conexiones.

La réplica además de suplirlo en la conexión de una forma completamente invisible para el Cliente, es a la vez, totalmente capaz de enviarle todas las modificaciones que la base de datos haya sufrido en su ausencia, cuando éste entra de nuevo a su papel de servidor central.

• Tipos de replicación

▪  Replicación de Instantáneas

También conocida como replicación estática. Copia y distribuye datos y objetos de base  de datos exactamente como aparecen en el momento en el que ocurren.

Características

Los cambios de datos en el subscritor no son actualizados continuamente.

El Subscritor actualiza los datos de forma completa y no de forma transaccional.

¿Cuándo usarla?

Datos/objetos son estáticos o no cambian con frecuencia.

La cantidad de datos a ser replicados es pequeña.

Los usuarios trabajan desconectados, no siempre interesa la última información. 

 

▪  Replicación Transaccional

También conocida como replicación dinámica.  Las modificaciones de la publicación en el publicador son propagadas al subscritor de forma incremental.

 

Características

Publicador y subscritor siempre están sincronizados.

Las Transacciones son preservadas; Ej. si son modificados 5 registros de datos, siempre serán los 5 registros propagados al subscriptor o no serán propagados.

El publicador y el suscriptor deberán siempre estar conectados.

¿Cuándo usar la Replicación Transaccional?

La información que se replica será utilizada solo de lectura.  La información de ventas e inventarios de una Central son replicados a las Sucursales.

El subscriptor siempre necesita la última información.

 

▪ Replicación de Mezcla

Provee las ventajas de ambas replicaciones anteriores. La instantánea inicial se aplica a los suscriptores; se hace un seguimiento de los cambios realizados en los datos publicados en el publicador y en los suscriptores. Los datos se sincronizan entre los servidores a una hora programada o a petición.

Características

Actualiza los datos haciendo independiente a más de un servidor.

Los datos son mezclados basados en un calendario o en la demanda.

Permite a los usuarios trabajar online/offline y sincronizar más adelante las modificaciones de datos realizadas en un resultado único y uniforme.

¿Cuándo usar la Replicación de Mezcla?

La autonomía del sitio es un factor crucial.

Múltiples subscriptores necesitan actualizar datos en diferentes ocasiones y propagar los cambios al publicador y a otros suscriptores; los suscriptores necesitan recibir datos,  realizar cambios sin conexión y sincronizar más adelante los cambios con el publicador y otros suscriptores

Requisitos y consideraciones para el uso de la replicación con la creación de reflejo de la base de datos

 

Se deben tener en cuenta los siguientes requisitos y consideraciones al utilizar la replicación con la creación de reflejo de la base de datos:

Las entidades de seguridad y reflejada deben compartir un distribuidor. Se recomienda que éste sea un distribuidor remoto, ya que proporciona mayor tolerancia a errores si se produce una conmutación por error imprevista en el publicador.

La replicación admite la creación de reflejo de la base de datos de publicación en la replicación de mezcla y en la replicación transaccional con suscriptores de solo lectura o suscriptores de actualización en cola. No se admiten suscriptores de actualización inmediata, publicadores de Oracle, publicadores en una topología punto a punto ni republicación.

Los metadatos y los objetos que existen fuera de la base de datos, incluidos inicios de sesión, trabajos, servidores vinculados, etc., no se copian en la entidad reflejada. Si se requieren los metadatos y los objetos en la entidad reflejada, se deben copiar manualmente. Para obtener más información, vea Administración de inicios de sesión y trabajos tras la conmutación de roles (SQL Server).

 

•      Beneficios de la réplica de Datos en un DBMS

 

•      Disponibilidad.- El modo en que la replicación incrementa la disponibilidad de los datos para los usuarios y aplicaciones.

 

 

 

•      Fiabilidad.- Al haber múltiples copias de los datos disponibles en el sistema, se dispone de un mecanismo excelente de recuperación cuando existan fallos en nodos.

•      Rendimiento.- Se mejora para las transacciones de consulta cuando se introduce la replicación en un sistema que estuviera aquejado de sobrecarga de recursos centralizados.

•      Reducción de la carga.- Modo en q se utiliza la replicación para distribuir datos en ubicaciones remotas.

•      Procesamiento Desconectado.- Modo en que la replicación puede implementarse mediante mecanismo instantáneas.

•      Soporta muchos usuarios.- Se puede crear múltiples instantáneas personalizadas que satisfagan los requisitos de cada usuario o grupo de usuarios del sistema.

•      Soporta Aplicaciones Avanzadas.- Para OLPT(Online transaction Processing),  OLAP(Online Analitical Processing)

 

La replicación de base de datos es una herramienta muy potente en el mundo de las aplicaciones distribuidas. Sus aplicaciones en el mundo real son muy variadas. Sin embargo, para que se pueda utilizar de forma correcta y funcione como esperamos es importante conocer realmente cómo funciona y las diferentes opciones que nos ofrece.

Los beneficios o los entornos donde es aplicable la replicación de bases de datos son los siguientes: 

•      Usuarios trabajando en ubicaciones geográficamente alejados trabajando con sus propias copias locales de la base de datos. 

•      Entornos en los que se replica la base de datos principal en una secundaria como copia de seguridad. En el caso que la primaria caiga, la secundaria toma el control. 

 

 

 

 

 

•      En entornos en los que la carga de usuarios sea muy grande para un sólo gestor, se pueden replicar las bases de datos en varios servidores asignando a cada usuario un servidor. 

Balanceando de esta manera la carga podremos aliviar a los gestores. Como observamos, los entornos son variados y comunes en muchos casos. El problema reside en la configuración y la elección correcta del tipo de replicación Modelo de Replicación Antes de empezar, vamos a clarificar los conceptos y términos que se utilizan cuando hablamos de la replicación.

 Los elementos que componen la replicación son los siguientes:

•      Publicador: es la instancia que pone sus datos a disposición de otras localizaciones mediante la replicación. El Publicador puede tener varias publicaciones configuradas cada una relacionada con un conjuntos lógico de objetos y datos. 

•      Distribuidor: es la base de datos destinada a almacenar la información específica asociada a la replicación de uno o más publicadores. Cada publicador es asociado con una base de datos (conocida como la base de datos de distribución) en el Distribuidor. La base de datos de distribución guarda el estado de la replicación, metadatos y en algunos casos hace de cola de distribución entre el publicador y el suscriptor. 

En la mayoría de los casos, la misma base de datos actúa como Publicador y Distribuidor. Cuando el Publicador y el Distribuidor se encuentran en servidores separados, el Distribuidor es conocido como "Distribuidor Remoto". 

•      Artículo: un artículo identifica un objeto de base de datos que es incluido en la publicación. Una publicación puede tener varios tipos de artículos: procedimientos almacenados, vistas, tablas y otro tipo de objetos. Cuando las tablas son 

 

 

 

•      publicadas, se pueden establecer filtros para restringir los datos y/o columnas que se envían al suscriptor. 

•      Publicación: es una colección de no o más artículos de una base de datos. La agrupación de artículos en una publicación hace más fácil especificar el conjunto de datos asociados en la replicación como una sola unidad

•      Suscripción: es una petición para que una copia de la publicación sea enviada al suscriptor. La suscripción define que publicación será recibida, cuando y donde. 

Hay dos tipos de suscripción: de inserción y de extracción.

•      Agentes: son los encargados de gestionar la comunicación y el envío de los datos entre los suscriptores y los publicadores.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5.3 Métodos de respaldo de un SGBD

 

En mySQL existen varios métodos para la realización de un backup y esto se debe principalmente a que mySQL guarda las tablas como archivos y al tipo de tablas que se este manejando (InnoDB, MyISAM, ISAM). Así por ejemplo para la presente práctica se utilizó el tipo de tabla InnoDB y el método de backup utilizado es el que funciona con este tipo de tablas. InnoDB es una de las tecnologías de almacenamiento que utiliza mySQL, es de codigo abierto. Entre sus características principales estan que soporta transacciones con características ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), tiene bloque de registros e integridad referencial (cosa que no maneja ISAM, ni myISAM). Esta última es una de sus características más importantes pues una base de datos sin integridad referencial, es nada mas un conjunto de datos que no denotan infomación. Este tipo de almacenamiento también ofrece una alta fiabilidad y consistencia. El mismo gestiona el control de los datos y no se lo deja al sistema operativo, una de sus desventajas es que no tiene una buena compresión de datos, por lo que ocupa un poco mas de espacio que myISAM.

 

 

 

 

5.4 Métodos de recuperación de un SGBD.

 

•      Técnica de recuperación de aires

Representa a los métodos actuales de recuperación.

•      Usa números de secuencia del registro histórico (NSR) para implementar varias optimizaciones que reducen el tiempo de recuperación.

Estrategia robar/no forzar para la escritura en disco:

•      Escritura anticipada en el log.

•      Repetición de la historia.

•      Anotación en el log de las modificaciones durante el deshacer

La recuperación consiste en tres pasos principales:

•      Análisis: Identifica las páginas sucias y el conjunto de transacciones activas en el momento de la caída y el punto del logapropiado para empezar la operación REHACER

•      Rehacer: se replican las operaciones del log.

•      Deshacer: Se recorre el log hacia atrás y se deshacen las transacciones activas en el momento de la caída, o iniciadas después, de las que no se ha encontrado confirmación.

 

❖  Recuperación en Oracle Red Log Files: dos o más archivos donde se registra cualquier modificación transaccional de una memoria intermedia de la BD. 

❖  Archivos de control: metadatos necesarios para operar en la base de datos, incluyendo información sobre copias de seguridad. 

❖  Segmento Rollback: guarda las últimas sentencias realizadas sobre la BD y sabe cuándo se ha confirmado o no una transacción. En la Recuperación de un fallo: 

 

 

 

❖  Recupera los datos con REHACER (Desde Redo Log File). Deshace las transacciones no comprometidas con Deshacer (Desde el segmento de rollback). 

 

1. Comandos para recuperación Cada vez que se ejecuta una tarea de copia de seguridad, CA ARCserve Backup registra la información en la base de datos sobre los equipos, directorios y archivos de los que se ha realizado copia de seguridad y los medios utilizados. Esto permite localizar archivos para cuando sea necesario restaurarlos. El comando de recuperación de base de datos (ca_recoverdb) es una opción de protección propia que permite recuperar una base de datos de CA ARCserve Backup si se ha perdido y se ha realizado copia de seguridad mediante el dominio de CA ARCserve Backup que está utilizando la base de datos. La utilidad ca_recoverdb sólo se utiliza para recuperar una base de datos de ARCserve (ASDB) en el mismo equipo o dominio de ARCserve en el que se ha realizado la copia de seguridad de ASDB. Si desea realizar la copia de seguridad de ASDB en un equipo y recuperarla en otro (los dos equipos no se encuentran en el mismo dominio de ARCserve), no se puede utilizar este comando. 

Ante esta situación dispone de dos soluciones:

❖  Solución 1: Realizar una copia de seguridad de recuperación de desastres desde el equipo A y después recuperarla en el equipo 

❖  Esta solución necesita que esté instalada la opción de recuperación de desastres (DR, Disaster Recovery) .

 

     

 

5.5 Migración de la Base de Datos.

 

La migración de bases de datos es generalmente una tarea compleja que no sólo supone transferir datos entre tipos de almacenaje y formatos de un servidor de base de datos a otro; sino que también supone reescribir sentencias SQL o incluso procedimientos (SPL) de lógica de negocio. En comparación con los esquemas estándares de migración a mano, ofrecemos una potente gama de herramientas desarrolladas de probada eficacia en complejos módulos de bases de datos relacionales. Estas herramientas y nuestros especialistas pueden asegurar que las transiciones de las bases de datos se realicen perfectamente, independientemente de la naturaleza del sistema. Desde la experiencia, estamos familiarizados con la complejidad, el coste que supone una larga migración de bases de datos y los problemas que aparecen durante el proceso cuando se emplean métodos inapropiados; ya que siempre comprobamos con los clientes potenciales que el uso de nuestras herramientas y métodos pueda ofrecer una ventaja significativa. HERRAMIENTAS DE MIGRACIÓN En comparación con la consultoría estándar de migraciones, la cual puede ofrecer poco más que soporte a la base de datos, nosotros tenemos gran experiencia en escribir grandes aplicaciones para empresas en sintaxis de la base de datos nativa y cross. Además, enseñamos a los equipos de las empresas una metodología y les proporcionamos una potente gama de herramientas para reducir costes y optimizar el proceso de migración.

En si La migración de bases de datos es el proceso mediante el que se migran datos de una o más bases de datos de origen a una o más bases de datos de destino mediante un servicio de migración de bases de datos. Cuando finaliza una migración, el conjunto de datos en las bases de datos de origen reside completo, aunque posiblemente reestructurado, en las bases de datos de destino. Los clientes que accedían a las bases de datos de origen se pasan a las bases de datos de destino, y las bases de datos de origen se desactivan.

En el siguiente diagrama, se ilustra este proceso de migración de las bases de datos.

 

 

 

En este documento, se describe la migración de bases de datos desde el punto de vista arquitectónico:

•       Los servicios y tecnologías involucrados en la migración de la base de datos

•       Las diferencias entre la migración de bases de datos homogéneas y heterogéneas

•       Las compensaciones y la selección de una tolerancia para el tiempo de inactividad de migración

•       Una arquitectura de configuración que admite un resguardo si se producen errores imprevistos durante una migración

En este documento, no se describe cómo configurar una tecnología de migración de base de datos en particular. En su lugar, presenta los principios, conceptos y fundamentos de la migración de bases de datos.

En el siguiente diagrama, se muestra una arquitectura de migración de base de datos genérica.

 

 

 

Un servicio de migración de bases de datos se ejecuta en Google Cloud y accede a las bases de datos de origen y de destino. Se representan dos variantes: (a) muestra la migración de una base de datos de origen desde un centro de datos local o una nube remota a una base de datos administrada como Cloud Spanner; (b) muestra una migración a una base de datos en Compute Engine.

Aunque las bases de datos de destino son de diferente tipo (administrado y no administrado) y configuración, la arquitectura y la configuración de migración de la base de datos es la misma para ambos casos.

 

 

Terminología

Los términos de migración de datos más importantes para estos documentos se definen de la siguiente manera:

Base de datos de origen: Es una base de datos que contiene datos para migrar a una o más bases de datos de destino.

 

Base de datos de destino: Es una base de datos que recibe datos migrados desde una o más bases de datos de origen.

Migración de bases de datos: Es una migración de datos desde bases de datos de origen hacia bases de datos de destino con el objetivo de desactivar los sistemas de bases de datos de origen una vez que se completa la migración. Se migra el conjunto de datos completo o un subconjunto.

Migración homogénea: Es una migración desde las bases de datos de origen hacia las bases de datos de destino en la que las bases de origen y de destino pertenecen al mismo sistema de administración de bases de datos, del mismo proveedor.

Migración heterogénea: Es una migración desde las bases de datos de origen hacia las bases de datos de destino en la que las bases de datos de origen y de destino pertenecen a diferentes sistemas de administración de bases de datos, de diferentes proveedores.

Sistema de migración de bases de datos: Es un sistema o servicio de software que se conecta a bases de datos de origen y de destino y realiza migraciones de datos desde bases de datos de origen hacia bases de datos de destino.

Proceso de migración de datos: Es un proceso configurado o implementado que ejecuta el sistema de migración de datos para transferir datos de bases de datos de origen a bases de destino, durante el cual es posible que los datos se transformen.

 

 

Replicación de base de datos: Es una transferencia continua de datos desde bases de datos de origen hacia bases de datos de destino sin la intención de desactivar las bases  de datos de origen. La replicación de bases de datos (a veces llamada transmisión de bases de datos) es un proceso continuo.

Clasificación de las migraciones de bases de datos

Existen diferentes tipos de migraciones de bases de datos que pertenecen a diferentes clases. En esta sección, se describen los criterios que definen esas clases.

Comparación entre la replicación y la migración

En una migración de bases de datos, mueves datos de bases de datos de origen a bases de datos de destino. Una vez que los datos se migran por completo, borras las bases de datos de origen y redireccionas el acceso de los clientes a las bases de datos de destino. A veces, puedes mantener las bases de datos de origen como una medida de resguardo en caso de que surjan problemas imprevistos con las bases de datos de destino. Sin embargo, una vez que las bases de datos de destino funcionan de manera confiable, debes borrar las bases de datos de origen.

En cambio, con la replicación de base de datos, transfieres datos de forma continua desde las bases de datos de origen hacia las bases de datos de destino, sin borrar las de origen. A veces, la replicación de bases de datos se conoce como transmisión de bases de datos. Si bien hay una hora de inicio definida, por lo general, no se establece una hora de finalización. La replicación puede detenerse o convertirse en una migración.

En este documento, solo se analiza la migración de bases de datos.

Comparación entre la migración parcial y la migración completa

La migración de bases de datos se entiende como una transferencia de datos completa y coherente. Debes definir que el conjunto de datos inicial se transfiera como una base de datos completa o parcial (un subconjunto de los datos en la base de datos), además  de que se transfiera cada cambio posterior confirmado en el sistema de base de datos de origen.

Comparación entre la migración heterogénea y la migración homogénea

Una migración de bases de datos homogénea es una migración entre bases de datos de origen y de destino con la misma tecnología de base de datos, por ejemplo, una migración desde una base de datos de MySQL hacia una de MySQL, o desde una base de datos de Oracle® hacia una de Oracle. Las migraciones homogéneas también incluyen migraciones entre un sistema de base de datos alojado en sí mismo, como PostgreSQL, y una versión administrada, como Cloud SQL (una variante de PostgreSQL).

En una migración de bases de datos homogénea, es probable que los esquemas de las bases de datos de origen y de destino sean idénticos. Si los esquemas son diferentes, los datos de las bases de datos de origen deben transformarse durante la migración.

La migración de base de datos heterogénea es una migración entre bases de datos de origen y de destino con diferentes tecnologías de base de datos, por ejemplo, desde una base de datos de Oracle hacia una de Spanner. La migración de base de datos heterogénea puede ser entre los mismos modelos de datos (por ejemplo, de un modelo relacional a uno relacional) o entre diferentes modelos de datos (por ejemplo, de un modelo relacional a uno de clave-valor).

La migración entre diferentes tecnologías de base de datos no siempre implica diferentes modelos de datos. Por ejemplo, Oracle, MySQL, PostgreSQL y Spanner admiten el modelo de datos relacionales. Sin embargo, las bases de datos de varios modelos, como Oracle, MySQL o PostgreSQL, admiten diferentes modelos de datos. Los datos almacenados como documentos JSON en una base de datos de varios modelos se pueden migrar a MongoDB con poca o ninguna transformación, ya que el modelo de datos es el mismo en las bases de datos de origen y de destino.

Aunque la distinción entre la migración homogénea y heterogénea se basa en tecnologías de base de datos, una categorización alternativa se basa en los modelos de bases de datos involucrados. Por ejemplo, una migración de una base de datos de Oracle a una de Spanner es homogénea si ambas usan el modelo de datos relacionales; una migración es heterogénea si, por ejemplo, los datos almacenados como objetos JSON en Oracle se migran a un modelo relacional en Spanner.

La categorización de las migraciones según el modelo de datos expresa con mayor precisión la complejidad y el esfuerzo necesarios para migrar los datos que cuando la categorización se basa en el sistema de base de datos involucrado. Sin embargo, debido a que la categorización que más se usa en la industria es la basada en los sistemas de bases de datos involucrados, las secciones restantes se enfocan en esa distinción.

Tiempo de inactividad de la migración: nulo frente a casi nulo

Después de migrar un conjunto de datos de la base de datos de origen a la de destino de forma correcta, debes cambiar el acceso del cliente a la base de datos de destino y borrar la base de datos de origen.

El cambio de clientes de las bases de datos de origen a las de destino implica varios procesos:

•       Para continuar con el procesamiento, los clientes deben cerrar las conexiones existentes a las bases de datos de origen y crear conexiones nuevas a las bases de datos de destino. Lo ideal es que las conexiones se cierren de forma correcta para que no debas revertir las transacciones en curso sin necesidad.

•       Después de cerrar las conexiones en las bases de datos de origen, debes migrar los cambios restantes de las bases de datos de origen a las de destino (llamado desvío) para asegurarte de que se capten todos los cambios.

•       Es posible que debas probar las bases de datos de destino para garantizar que funcionen, además de comprobar que los clientes también funcionen y operen dentro de sus objetivos de nivel de servicio (SLO) definidos.

En una migración, es imposible lograr un tiempo de inactividad nulo para los clientes. A veces, los clientes no pueden procesar solicitudes. Sin embargo, puedes minimizar el

 

 tiempo en el que los clientes no pueden procesar solicitudes de varias maneras (tiempo de inactividad casi nulo):

•       Puedes iniciar tus clientes de prueba en modo de solo lectura en las bases de datos de destino mucho antes de cambiar los clientes. Con este método, las pruebas son simultáneas con la migración.

•       Puedes configurar la cantidad de datos que se migrarán (es decir, que estarán en tránsito entre las bases de datos de origen y de destino) para que sea lo más pequeña posible cuando se acerque el período de cambio. Este paso reduce el tiempo de desvío porque hay menos diferencias entre las bases de datos de origen y las de destino.

•       Si los clientes nuevos que operan en las bases de datos de destino pueden iniciarse de forma simultánea junto con los clientes existentes que operan en las bases de datos de origen, puedes acortar el tiempo de cambio, ya que los clientes nuevos están listos para ejecutarse en cuanto se desvían todos los datos.

Si bien es poco realista esperar un tiempo de inactividad nulo durante un cambio, puedes minimizar el tiempo de inactividad si inicias actividades en simultáneo con la migración de datos continua cuando sea posible.

 

En algunos casos de migración de bases de datos, se acepta un tiempo de inactividad significativo. Por lo general, esto se debe a requisitos empresariales. En tales casos, puedes simplificar el método que usas. Por ejemplo, con una migración de bases de datos homogénea, es posible que no necesites modificar los datos. La importación y exportación, así como la creación de copias de seguridad y el restablecimiento, son métodos perfectos. Con las migraciones heterogéneas, el sistema de migración de bases de datos no tiene que lidiar con las actualizaciones de los sistemas de base de datos durante la migración.

Sin embargo, debes establecer un tiempo de inactividad aceptable que sea tan largo como para que ocurran la migración de la base de datos y las pruebas de seguimiento. Si este tiempo de inactividad no se puede establecer de forma clara o es demasiado largo, debes planificar una migración que incluya un tiempo de inactividad mínimo.

Cardinalidad de migración de bases de datos

En muchos casos, la migración de bases de datos se realiza entre una sola base de datos de origen y una única base de datos de destino. En tales casos, la cardinalidad es 1:1 (mapeo directo). Es decir, una base de datos de origen se migra sin cambios a una base de datos de destino.

Sin embargo, el mapeo directo no es la única posibilidad. Estas son otras cardinalidades posibles:

•       Consolidación (n:1). En una consolidación, migras datos de varias bases de datos de origen a una cantidad menor de bases de datos de destino (o incluso a solo una). Puedes usar este método para simplificar la administración de bases de datos o emplear una base de datos de destino que pueda escalar.

•       Distribución (1:n). En una distribución, migras datos de una base de datos de origen a varias bases de datos de destino. Por ejemplo, puedes usar este método 

 

 

•       cuando necesites migrar una gran base de datos centralizada que contenga datos regionales a varias bases de datos de destino regionales.

•       Redistribución (n:m). En una redistribución, migras datos de varias bases de datos de origen a varias bases de datos de destino. Puedes usar este método cuando tienes bases de datos fragmentadas con fragmentos de tamaños muy diferentes. La redistribución reparte los datos fragmentados de manera uniforme en varias bases de datos de destino que representan los fragmentos.

La migración de la base de datos brinda la oportunidad de rediseñar y de implementar la arquitectura de la base de datos, además de solo migrar datos.

 

Coherencia de la migración

Se espera que la migración de una base de datos sea coherente. En el contexto de la migración, coherentesignifica lo siguiente:

•       Completa. Todos los datos que se especifican para migrar se migran realmente. Los datos especificados pueden ser todos los datos en una base de datos de origen o un subconjunto de datos.

•       Sin duplicados. Cada dato se migra solo una vez. No se ingresan datos duplicados en la base de datos de destino.

•       Ordenada. Los cambios de datos en la base de datos de origen se aplican a la base de datos de destino en el mismo orden en que ocurrieron los cambios en la base de datos de origen. Este aspecto es esencial para garantizar la coherencia de los datos.

Otra forma de describir la coherencia de la migración es que, después de que se completa una migración, el estado de los datos de las bases de datos de origen y de destino debe

ser equivalente. Por ejemplo, en una migración homogénea que implica el mapeo directo

de una base de datos relacional, las mismas tablas y filas deben existir en las bases Instituto Tecnológico de Comitánde datos de origen y de destino.

Esta forma alternativa de describir la coherencia de la migración es importante porque no todas las migraciones de datos se basan en la aplicación secuencial de transacciones de la base de datos de origen a la de destino. Por ejemplo, puedes crear una copia de seguridad de la base de datos de origen y usar esta copia para restablecer el contenido de la base de datos de origen en la de destino (cuando haya el suficiente tiempo de inactividad disponible).

Migración activa-pasiva y migración activa-activa

Una distinción importante es si las bases de datos de origen y de destino están abiertas para modificar el procesamiento de consultas. En una migración de base de datos activapasiva, las bases de datos de origen se pueden modificar durante la migración, mientras que las bases de datos de destino permiten nada más que el acceso de solo lectura.

Una migración activa-activa admite que los clientes escriban en las bases de datos de origen y de destino durante la migración. En este tipo de migración, pueden ocurrir conflictos. Por ejemplo, si el mismo elemento de datos en las bases de datos de origen y de destino se modifica de modo que se genere un conflicto semántico, es posible que debas ejecutar reglas de resolución de conflictos para solucionar el conflicto.

En una migración activa-activa, debes poder resolver todos los conflictos de datos mediante reglas de resolución de conflictos. Si no puedes hacerlo, es posible que experimentes incoherencias en los datos.

Arquitectura de migración de bases de datos

Una arquitectura de migración de una base de datos describe los diversos componentes necesarios para ejecutar una migración de base de datos. En esta sección, se presenta una arquitectura de implementación genérica y se trata el sistema de migración de bases de datos como un componente independiente. También se analizan las características de un sistema de administración de bases de datos que admite la migración de datos, así

como las propiedades no funcionales que son importantes para muchos casos de uso.Instituto Tecnológico de Comitán

Arquitectura de implementación

Una migración de bases de datos puede ocurrir entre las bases de datos de origen y de destino ubicadas en cualquier entorno, como en diferentes nubes o entornos locales. Cada base de datos de origen y de destino puede estar en un entorno diferente. No es necesario que todas estén ubicadas en el mismo entorno.

En el siguiente diagrama, se muestra un ejemplo de una arquitectura de implementación que involucra varios entornos.

 

DB1 y DB2 son las dos bases de datos de origen, y DB3 y Spanner son las bases de datos de destino. En esta migración de bases de datos, se incluyen dos nubes y dos centros de datos locales. Las flechas representan las relaciones de invocación: el servicio de migración de bases de datos invoca a las interfaces de todas las bases de datos de origen y de destino.

Un caso especial que no se analiza aquí es la migración de datos de una base de datos a la misma base de datos. En este caso especial, se usa el sistema de migración de bases de datos solo para la transformación de datos, no con el objetivo de migrar datos entre sistemas diferentes en entornos diferentes.

En esencia, existen tres métodos para la migración de bases de datos, que se analizan

en esta sección:                                                                                   Instituto Tecnológico de Comitán

•       Usar un sistema de migración de bases de datos

•       Usar la función de replicación del sistema de administración de bases de datos

•       Usa la función de migración de base de datos personalizada

Sistema de migración de base de datos

El sistema de migración de bases de datos es el núcleo de la migración de bases de datos. El sistema ejecuta la extracción de datos desde las bases de datos de origen, transporta los datos a las bases de datos de destino y, de manera opcional, modifica los datos durante el envío. En esta sección, se realiza un análisis general de las funciones básicas del sistema de migración de bases de datos. Algunos ejemplos de sistemas de migración de bases de datos son Striim, tcVision y Cloud Data Fusion.

Proceso de migración de datos

El componente básico principal de un sistema de migración de bases de datos es el proceso de migración de datos. Un desarrollador especifica el proceso de migración de datos, y este proceso define las bases de datos de origen de las que se extraen los datos, las bases de datos de destino a las que se migran los datos y cualquier lógica de modificación de datos que se aplique a los datos durante la migración.

Puedes especificar uno o más procesos de migración de datos y ejecutarlos de manera secuencial o simultánea, según las necesidades de la migración. Por ejemplo, si migras bases de datos independientes, los procesos de migración de datos correspondientes pueden ejecutarse en paralelo.

Función de migración de base de datos personalizada

Instituto Tecnológico de Comitán Entre algunos de los motivos para compilar la función de migración de bases de datos en lugar de usar un sistema de migración de bases de datos o la función del sistema de administración de bases de datos, se incluyen los siguientes:

•       Necesitas un control total de cada detalle.

•       Quieres volver a usar la función.

•       Quieres reducir los costos o simplificar la huella tecnológica.

Los componentes básicos para compilar la función de migración incluyen los siguientes:

•       Operaciones de importación y exportación. Si el tiempo de inactividad no es un factor, puedes usar la importación y exportación de bases de datos para migrar datos en migraciones de bases de datos homogéneas. Sin embargo, las 

        •      

        •      

•       operaciones de importación y exportación requieren que desactives la base de datos de origen para evitar actualizaciones antes de exportar los datos. De lo contrario, es posible que los cambios no se registren en la exportación y que la base de datos de destino no sea una copia exacta de la base de datos de origen.

•       Copias de seguridad y restablecimientos. Al igual que en el caso de las operaciones de importación y exportación, las operaciones de copia de seguridad y restablecimiento generan tiempo de inactividad porque necesitas desactivar la base de datos de origen para que la copia de seguridad contenga todos los datos y los últimos cambios. El tiempo de inactividad continúa hasta que el restablecimiento se completa de forma correcta en la base de datos de destino.

•       Consultas diferenciales. Si el cambio de esquema de la base de datos es una opción, puedes extender el esquema para que los cambios de la base de datos se puedan consultar en la interfaz de consultas. Se agrega un atributo de marca de tiempo adicional, que indica la hora del último cambio. Se puede agregar una

marca de eliminación adicional, que indica si el elemento de datos se borró o no Instituto Tecnológico de Comitán

(eliminación lógica). Con estos dos cambios, una aplicación de sondeo que se ejecuta a un intervalo regular puede consultar todos los cambios que se implementaron desde su última ejecución. Los cambios se aplican a la base de datos de destino. En Cambia la captura de datos, se analizan otros métodos.

Estas son solo algunas de las opciones posibles para compilar una migración de base de datos personalizada. Aunque una solución personalizada proporciona la mayor flexibilidad y el mayor control posibles sobre la implementación, también requiere mantenimiento constante para abordar errores, limitaciones de escalabilidad y otros problemas que puedan surgir durante una migración de base de datos.

Consideraciones adicionales para la migración de bases de datos

En las siguientes secciones, se analizan con brevedad los aspectos no funcionales que son importantes en el contexto de la migración de bases de datos. En estos aspectos, se incluyen el manejo de errores, la escalabilidad, la alta disponibilidad y la recuperación ante desastres.

Manejo de errores

Las fallas durante la migración de bases de datos no deben causar la pérdida de datos ni el procesamiento de los cambios de la base de datos en un orden incorrecto. La integridad de los datos debe conservarse sin importar la causa del error (como un error en el sistema, una interrupción de la red, una falla de la VM o una falla en la zona).

Se produce una pérdida de datos cuando un sistema de migración recupera los datos de las bases de datos de origen y no los almacena en las bases de datos de destino debido a algún error. Cuando se pierden datos, las bases de datos de destino no coinciden con las de origen y, por lo tanto, son incoherentes y están incompletas. La función de verificación de integridad y coherencia marca este estado (Verificación de integridad y coherencia).

Escalabilidad Instituto Tecnológico de Comitán En una migración de base de datos, el tiempo de migración es una métrica importante. En una migración sin tiempo de inactividad (en el sentido de un tiempo de inactividad mínimo), la migración de los datos se produce mientras las bases de datos de origen siguen cambiando. Para migrar en un plazo razonable, la velocidad de transferencia de datos debe ser mucho más rápida que la velocidad de las actualizaciones de los sistemas de bases de datos de origen, en especial, cuando el sistema de base de datos de origen es grande. Cuanto mayor sea la velocidad de transferencia, más rápido se podrá completar la migración de la base de datos.

Cuando los sistemas de bases de datos de origen están inactivos y no se modifican, la migración puede ser más rápida porque no hay cambios que se deban incorporar. En una base de datos homogénea, el tiempo de migración puede ser bastante rápido porque puedes usar las funciones de copia de seguridad y restablecimiento o de importación y exportación, y la transferencia de archivos se escala.

Alta disponibilidad y recuperación ante desastres

En general, las bases de datos de origen y de destino están configuradas para la alta disponibilidad. Una base de datos principal tiene una réplica de lectura correspondiente que se convierte en la base de datos principal cuando se produce una falla.

Cuando una zona falla, las bases de datos de origen o de destino se conmutan por error a una zona diferente para estar disponibles de forma continua. Si se produce una falla zonal durante una migración de bases de datos, el sistema de migración se ve afectado porque varias de las bases de datos de origen o de destino a las que accede se vuelven inaccesibles. El sistema de migración debe volver a conectarse a las bases de datos principales recién promovidas que se ejecutan después de una falla. Una vez que el sistema de migración de bases de datos se vuelve a conectar, debe recuperar la migración para garantizar la integridad y coherencia de los datos en las bases de datos de destino. El sistema de migración debe determinar la última transferencia coherente para establecer desde qué punto se debe reanudar la operación.

Si el sistema de migración de bases de datos falla (por ejemplo, la zona en la que se

ejecuta se vuelve inaccesible), debe recuperarse. Un método de recuperación consiste Instituto Tecnológico de Comitán en un reinicio en frío. En este método, el sistema de migración de bases de datos se instala en una zona operativa y se reinicia. El mayor problema que se debe abordar es que el sistema de migración debe poder determinar la última transferencia de datos coherente antes de la falla y continuar desde ese punto a fin de garantizar la integridad y coherencia de los datos en las bases de datos de destino.

Si el sistema de migración de bases de datos está habilitado para la alta disponibilidad, puede conmutar por error y continuar con el procesamiento luego. Si el tiempo de inactividad limitado del sistema de migración de bases de datos es importante, debes seleccionar una base de datos e implementar la alta disponibilidad.

En cuanto a la recuperación de la migración de una base de datos, la recuperación ante desastres es muy similar a la alta disponibilidad. En lugar de volver a conectarse a las bases de datos principales que se acaban de ascender en una zona diferente, el sistema de migración de bases de datos debe volver a conectarse a las bases de datos en una región diferente (una región de conmutación por error). Lo mismo sucede con el sistema de migración de bases de datos. Si la región en la que se ejecuta el sistema de migración de bases de datos se vuelve inaccesible, el sistema de migración de bases de datos debe conmutar por error a una región diferente y continuar a partir de la última transferencia de datos coherente. Errores

Varios errores pueden generar datos incoherentes en las bases de datos de destino. Algunos de los más comunes que debes evitar son los siguientes:

• Incumplimiento del orden. Si la escalabilidad del sistema de migración se logra mediante el escalamiento horizontal, varios procesos de transferencia de datos se ejecutan en simultáneo (en paralelo). Los cambios en un sistema de base de datos de origen se ordenan según las transacciones confirmadas. Si los cambios se detectan a partir del registro de transacciones, el orden debe mantenerse durante

la migración. La transferencia de datos en paralelo puede cambiar el orden debido

a la velocidad variable entre los procesos subyacentes. Es necesario asegurarse Instituto Tecnológico de Comitán de que los datos se inserten en las bases de datos de destino en el mismo orden en que se reciben de las bases de datos de origen.

•       Incumplimiento de la coherencia. Con las consultas diferenciales, las bases de datos de origen tienen atributos de datos adicionales que contienen, por ejemplo, marcas de tiempo de confirmación. Las bases de datos de destino no tendrán marcas de tiempo de confirmación porque estas solo se incluyen para establecer la administración de cambios en las bases de datos de origen. Es importante asegurarse de que las inserciones en las bases de datos de destino sean coherentes con las marcas de tiempo, lo que significa que todos los cambios con la misma marca de tiempo deben estar en la misma transacción de inserción, actualización o upsert. De lo contrario, la base de datos de destino podría tener un estado incoherente (de forma temporal) si se insertan algunos cambios y otros con la misma marca de tiempo no se insertan. Este estado de incoherencia temporal no es importante si no se accede a las bases de datos de destino para el procesamiento. Sin embargo, si se usan para pruebas, la coherencia es primordial. Otro aspecto es la creación de los valores de marca de tiempo en la base de datos de origen y cómo se relacionan con el tiempo de confirmación de la transacción en la que se establecen. Debido a dependencias de confirmación de transacciones, una transacción con una marca de tiempo anterior puede ser visible después de una transacción con una marca de tiempo posterior. Si la consulta diferencial se ejecuta entre las dos transacciones, no verá la transacción con la marca de tiempo anterior, lo que da como resultado una incoherencia en la base de datos de destino.

•       Datos faltantes o duplicados. Cuando se produce una conmutación por error, se requiere una recuperación cuidadosa si algunos datos no están replicados entre la instancia principal y la réplica de conmutación por error. Por ejemplo, cuando una base de datos de origen falla, no todos los datos están replicados en la réplica de conmutación por error. Al mismo tiempo, los datos ya se migraron a la base de datos de destino antes del error. Después de la conmutación por error, la base de

datos principal que se acaba de ascender se encuentra atrasada en términos de Instituto Tecnológico de Comitán

cambios de datos con respecto a la base de datos de destino (esto se conoce como flashback). Un sistema de migración debe reconocer esta situación y recuperarse de ella, de manera que las bases de datos de destino y de origen vuelvan a ser coherentes.

•       Transacciones locales. Para que las bases de datos de origen y de destino reciban los mismos cambios, un método común consiste en que los clientes escriban en ambas bases de datos en lugar de usar un sistema de migración de datos. Este método presenta varios posibles errores. Un posible error consiste en que dos operaciones de escritura de la base de datos sean dos transacciones separadas; es posible que se genere una falla después de que termine la primera y antes de que termine la segunda. Esta situación genera datos incoherentes cuya situación debes revertir. Además, hay varios clientes en general y no están coordinados. Los clientes no conocen el orden de confirmación de las transacciones de la base de datos de origen y, por lo tanto, no pueden escribir en las bases de datos de destino de modo que se implemente ese orden de transacciones. Los clientes pueden cambiar el orden, lo que puede generar incoherencia de datos. A menos que todo el acceso pase por clientes coordinados y que todos los clientes garanticen el orden de las transacciones de destino, este método puede generar un estado de incoherencia con la base de datos de destino.

En general, hay otros errores que se deben tener en cuenta. La mejor manera de encontrar problemas que puedan generar casos de incoherencia de datos es realizar un análisis completo de las fallas que itere todas las situaciones de fallas posibles. Si la simultaneidad se implementa en el sistema de migración de bases de datos, se deben examinar todos los posibles órdenes de ejecución de procesos de migración de datos para garantizar que se conserve la coherencia de datos. Si se implementa la alta disponibilidad o la recuperación ante desastres (o ambas), se deben examinar todas las combinaciones de fallas posibles.

Configuración de la migración de bases de datos

En esta sección, se describen las diversas fases de una migración de bases de datos.

Primero, configuras la migración. Luego de completar la migración y cambiar los clientes Instituto Tecnológico de Comitán a las bases de datos de destino, quita las bases de datos de origen o, si es necesario, implementa un plan de resguardo debido a problemas con la migración después del cambio. Un resguardo ayuda a garantizar la continuidad de la empresa.

Durante la migración, debes prestar atención especial a cualquier cambio de esquema o de datos que pueda producirse. Para obtener más información sobre el impacto que pueden tener estos cambios, consulta Cambios dinámicos durante la migración más adelante en este documento.

Especificación del esquema de destino

Para cada sistema de base de datos de destino, debes definir y crear su esquema. Para las migraciones de bases de datos homogéneas, puedes crear esta especificación más rápido si exportas el esquema de la base de datos de origen a la base de datos de destino, lo que crea el esquema de las bases de datos de destino.

La forma en que nombras tu esquema es importante. Una opción es hacer coincidir los nombres del esquema de origen y de destino. Sin embargo, aunque esto simplifica el cambio de clientes, este enfoque podría confundir a los usuarios si las herramientas se conectan a los esquemas de las bases de datos de origen y de destino de forma simultánea, por ejemplo, para comparar datos. Si abstraes el nombre del esquema mediante un archivo de configuración, asignar nombres diferentes a los esquemas de la base de datos de destino facilita la diferenciación de los esquemas.

En las migraciones de bases de datos heterogéneas, debes crear cada esquema de la base de datos de destino. Este proceso de ingeniería puede llevar varias iteraciones. Antes de que puedas implementar la migración, es posible que debas cambiar los esquemas un poco más para ajustar tu proceso de migración y cualquier modificación de los datos.

Debido a que es probable que crees bases de datos de destino varias veces cuando pruebes y ejecutes la migración, el proceso de creación del esquema debe ser repetible (lo ideal es hacerlo mediante secuencias de comandos de instalación). Puedes usar un

sistema de administración de código para controlar la versión de las secuencias de Instituto Tecnológico de Comitán comandos, garantizar la coherencia y acceder al historial de cambios de las secuencias de comandos.

Semántica de migración y ejecución de consultas

Con el tiempo, debes realizar un cambio para que el cliente deje de acceder a los sistemas de la base de datos de origen y acceda a los de destino. En integraciones de bases de datos homogéneas, las consultas pueden permanecer sin cambios si los esquemas no se modifican. Si bien los clientes deben probarse en los sistemas de la base de datos de destino, los clientes no tienen que modificarse debido a las consultas.

En el caso de las migraciones de bases de datos homogéneas en general, debes modificar las consultas porque los esquemas entre las bases de datos de origen y destino son diferentes. La diferencia podría ser una discrepancia de tipos de datos entre las bases de datos de origen y de destino. Además, no todas las funciones del lenguaje de consulta disponibles en los sistemas de la base de datos de origen pueden estar disponibles en los sistemas de la base de datos de destino, o viceversa. En casos extremos, es posible que debas convertir una consulta de un sistema de la base de datos de origen en varias consultas en el sistema de destino. En una situación inversa, en la que tienes más funciones de lenguaje de consulta disponibles en la base de datos de destino que en la base de datos de origen, es posible que debas combinar varias consultas de la base de datos de origen en una sola consulta en la base de datos de destino correspondiente.

La semántica de las consultas también puede variar. Por ejemplo, algunos sistemas de bases de datos materializan una actualización dentro de una transacción de inmediato, por lo que se recupera el valor actualizado cuando se lee el mismo elemento de datos. Otros sistemas no materializan una actualización de inmediato y esperan hasta que se confirme la transacción. Si la lógica en el sistema de la base de datos de origen depende de que se materialice la escritura, la misma lógica en la base de datos de destino puede generar datos incorrectos o incluso fallas.

Si debes migrar consultas, debes probar todas las funciones para asegurarte de que el

comportamiento de los clientes sea el mismo antes y después de la migración. También Instituto Tecnológico de Comitán puedes realizar pruebas a nivel de los datos, pero estas no reemplazan a las pruebas a nivel del cliente. Los clientes ejecutan consultas desde el punto de vista de la lógica empresarial y solo se pueden probar a nivel de la lógica empresarial.

Procesos de migración

Para las migraciones de bases de datos heterogéneas, los procesos de migración especifican cómo se modifican y se insertan los datos extraídos de los sistemas de la base de datos de origen en la de destino. Las modificaciones de datos, como las que se analizan en Cambios de datos en este documento, se definen y se ejecutan mientras los elementos de datos se extraen de las bases de datos de origen y se transfieren a las de destino.

En las migraciones de bases de datos homogéneas, cuando los esquemas de las bases de datos de origen y de destino son equivalentes, no es necesario modificar los datos. Los datos se insertan en las bases de datos de destino como se extrajeron de las bases de datos de origen.

Según el sistema de migración de la base de datos, es posible que se requieran varios parámetros de configuración. Por ejemplo, debes especificar si los datos que se modifican y se transfieren deben almacenarse de forma intermitente en el sistema de migración de la base de datos. El almacenamiento de los datos puede ralentizar el proceso de migración general, pero acelerar bastante la recuperación en caso de que ocurra una falla. Es posible que debas especificar el tipo de verificación. Por ejemplo, algunos sistemas de migración de bases de datos consultan los sistemas de origen y de destino para establecer la equivalencia del conjunto de datos migrado hasta el punto de la consulta. El control de errores requiere que especifiques el comportamiento de recuperación ante fallas. Este requisito también dependerá del sistema de migración de bases de datos en uso.

Es importante que pruebes la migración de datos de forma exhaustiva y repetida. Lo ideal

es que la migración se pruebe para garantizar que se migren todos los elementos de Instituto Tecnológico de Comitán

datos conocidos, que no se produzcan errores de modificación de datos, que el rendimiento y la capacidad de procesamiento sean suficientes y que se pueda cumplir el tiempo de migración.

Procesos de resguardo

Durante una migración de bases de datos, las bases de datos de origen permanecen en funcionamiento (a menos que la migración implique tiempo de inactividad planificado). Si la migración de tu base de datos falla en algún momento, puedes (en el peor de los casos) anular la migración y restablecer la base de datos de destino a su estado inicial. Después de resolver los errores, puedes reiniciar la migración. La falla y la resolución no afectan a los sistemas operativos de las bases de datos de origen.

Si ocurren fallas después de que se completa la migración de la base de datos y se cambian los clientes a las bases de datos de destino, el proceso de falla y resolución puede afectar a los clientes de modo que no puedan funcionar de manera correcta. En el mejor de los casos, la falla se resuelve con rapidez y el tiempo de inactividad para los clientes es corto. En el peor de los casos, la falla no se resuelve o la resolución lleva mucho tiempo y debes volver a cambiar los clientes a las bases de datos de origen.

Para volver a cambiar los clientes a las bases de datos de origen, debes migrar todas las modificaciones de datos de las bases de datos de destino a las de origen. Puedes configurar y ejecutar este proceso como una migración de base de datos independiente y completa. Sin embargo, debido a que los clientes no funcionan en las bases de datos de destino en este punto, se generará un tiempo de inactividad significativo.

Para evitar el tiempo de inactividad del cliente en esta situación, debes iniciar los procesos de migración de inmediato una vez de que se complete la migración de la base de datos original. Cada cambio que se aplica a los sistemas de la base de datos de destino se aplica de inmediato a los sistemas de la base de datos de origen. Mediante este enfoque, se garantiza que los sistemas de la base de datos de destino y de origen se mantengan sincronizados en todo momento. Instituto Tecnológico de Comitán

Preparar un resguardo de las bases de datos de destino a las bases de datos de origen requiere un esfuerzo significativo. Es fundamental decidir entre implementar y probar procesos de resguardo, o comprender las consecuencias de no hacerlo, es decir, un tiempo de inactividad significativo.

Ejecución de la migración de bases de datos

Ejecutar una migración de bases de datos implica cinco fases distintas, que se analizan en esta sección. Una sexta fase comprende un resguardo, pero es un caso extremo y se considera una excepción a la ejecución de una migración de bases de datos normal.

El proceso que se analiza en esta sección es una migración de bases de datos heterogéneas con un tiempo de inactividad casi nulo. Si puedes incurrir en un tiempo de inactividad significativo, puedes combinar las tres primeras fases (carga inicial, migración continua y desvío) en una fase mediante el enfoque de copia de seguridad y restablecimiento, o de importación y exportación.

Una migración de bases de datos homogéneas presenta un caso especial. Con este tipo de migración, puedes usar la funcionalidad de replicación del sistema de administración de bases de datos (para los sistemas compatibles) que migra los datos mientras los sistemas de las bases de datos de origen permanecen operativos.

Las fases analizadas aquí describen un enfoque que quizás debas modificar según los requisitos de tu proceso de migración de bases de datos.

Fase 1: Carga inicial

El punto de partida es migrar todos los datos especificados para migrar de todas las bases de datos de origen. Al comienzo de la migración de datos, las bases de datos de origen tienen un estado específico, que cambia durante la migración.

Una sugerencia para iniciar una migración mientras se producen cambios de forma

simultánea es anotar la hora del sistema de la base de datos justo antes de que se Instituto Tecnológico de Comitán extraiga el primer elemento de datos. Con esta marca de tiempo, puedes obtener todos los cambios de la base de datos del registro de transacciones a partir de ese momento. Además, la carga inicial debe leer un estado de base de datos coherente en todos los datos. Es posible que necesites un bloqueo de corta duración en la base de datos para evitar la lectura de un conjunto de datos incoherente.

Esta fase consta de lo siguiente:

•       Tomar nota de la hora del sistema de la base de datos justo antes de que comience la migración

•       Ejecutar un proceso de migración de carga inicial que consulta el conjunto de datos (ya sea completo o parcial) desde las bases de datos de origen que se migrarán y migrar el conjunto de datos. En un modelo de base de datos relacional, los procesos de migración de carga iniciales ejecutan consultas como SELECT *, o consultas con selección, proyección o ambas opciones. El proceso de migración realiza la modificación de los datos como se especifica en el proceso.

Mientras se ejecutan los procesos de migración de carga inicial, los clientes suelen realizar cambios en las bases de datos de origen. Debido a que registras la hora del sistema de la base de datos al principio, podrás obtener esos cambios del registro de transacciones más adelante.

El resultado de la fase de carga inicial es la migración completa del conjunto de datos inicial desde los sistemas de las bases de datos de origen hacia los sistemas de las bases de datos de destino. Sin embargo, las bases de datos de origen y de destino aún no están sincronizadas porque es probable que los clientes hayan modificado las bases de datos de origen durante la migración. La fase 2 implica capturar y migrar esos cambios.

Fase 2: Continuación de la migración

Instituto Tecnológico de Comitán La continuación de la migración tiene dos fines. Primero, lee los cambios que se produjeron en las bases de datos de origen después del inicio de la carga inicial. En segundo lugar, captura y transfiere esos cambios a las bases de datos de destino.

Esta fase consta de lo siguiente:

•       Iniciar los procesos de continuación de la migración desde la hora del sistema de la base de datos registrada en la fase 1. La migración lee el registro de transacciones desde esa hora y aplica cada cambio al sistema de la base de datos de destino.

•       Ejecutar todas las modificaciones de datos. El proceso de migración realiza este paso como lo especificas.

Los cambios que se registran después de la hora del sistema de la base de datos a veces se transfieren durante la carga inicial. Por lo tanto, es posible que esos cambios se apliquen por segunda vez durante la continuación de la migración. Debes definir tus procesos de migración para asegurarte de que los cambios no se apliquen dos veces, por ejemplo, mediante identificadores. Supongamos que un elemento de datos modificado se transfiere durante la carga inicial y esa inserción se registra en el registro de transacciones. Cuando aplicas un identificador al elemento de datos, el sistema de migración puede determinar a partir del registro de transacciones que no se necesita otra inserción porque el elemento de datos ya existe.

El resultado de la fase de continuación de la migración es que las bases de datos de destino están sincronizadas en su totalidad o casi en ella con las bases de datos de origen. Cuando un cambio en un sistema de la base de datos de origen no se migra, tienes una base de datos casi sincronizada.

Según cómo configures el sistema de migración de bases de datos, las discrepancias pueden ser pequeñas o grandes. Por ejemplo, para aumentar la eficiencia, no todos los cambios se deben migrar de inmediato; de lo contrario, puedes generar una gran carga en el origen si aumentan los cambios abruptos. En general, los cambios se recopilan y

se migran en lotes como operaciones masivas. Con lotes más pequeños, se producen Instituto Tecnológico de Comitán menos discrepancias entre el origen y el destino, pero el origen puede generar una carga mayor si se realizan cambios con frecuencia.

Si el tamaño del lote se configura de forma dinámica, lo mejor es sincronizar los lotes más grandes al inicio en la fase de continuación de la migración y, luego, sincronizar lotes cuyo tamaño se reduce de forma gradual cuando las bases de datos estén casi listas. Este enfoque hace que el proceso de actualización sea más eficiente y reduce la discrepancia entre las bases de datos de origen y de destino más adelante.

Fase 3: Desvío

A fin de prepararte para cambiar los clientes de las bases de datos de origen a las de destino, debes asegurarte de que las bases de datos estén completamente sincronizadas. El desvío es el proceso de migración de los cambios restantes de las bases de datos de origen a las bases de datos de destino.

Esta fase consta de lo siguiente:

•       Dejar inactivos los sistemas de la base de datos de origen. Esto significa que no se pueden realizar modificaciones a los datos en la base de datos de origen y que el registro de transacciones no recibe entradas de modificación adicionales.

•       Esperar a que todos los cambios migren a las bases de datos de destino. Este proceso es el desvío real de los cambios.

•       Después de que se completa el desvío, se crea una copia de seguridad de las bases de datos de destino con el fin de tener un punto de partida definido para las futuras copias de seguridad incrementales.

El resultado de la fase de desvío es que los sistemas de la base de datos de origen y los de destino están sincronizados, y no se producirán modificaciones de datos.

Para garantizar que se completó el desvío, se puede escribir un elemento de datos de

“última inserción” en una base de datos de origen. Una vez que aparece el elemento de Instituto Tecnológico de Comitán

datos de “última inserción” en la base de datos de destino correspondiente, se completa la fase de desvío.

Fase 4: Cambio

Una vez finalizada la fase de desvío, puedes cambiar los clientes de las bases de datos de origen a las de destino. Estas son las prácticas recomendadas:

•       Antes de habilitar el acceso a la base de datos de producción, prueba la funcionalidad básica para asegurarte de que los clientes funcionen y se comporten según lo previsto. La cantidad de casos de prueba determinará el tiempo de inactividad real para la base de datos de producción.

•       Crea una copia de seguridad de las bases de datos de destino antes de habilitar el acceso a los clientes. Esta práctica recomendada garantiza que el estado inicial de las bases de datos de destino sea recuperable.

Al final del cambio, los clientes funcionan completamente y comienzan a acceder a las bases de datos de producción (que en este documento se denominaron bases de datos de destino hasta este punto).

Fase 5: Eliminación de bases de datos de origen

Después de completar el cambio a las bases de datos de producción, puedes borrar las bases de datos de origen. Se recomienda realizar una copia de seguridad final de cada base de datos de origen a fin de tener un estado final definido al que se pueda acceder. Es posible que las regulaciones de datos también requieran copias de seguridad finales por motivos de cumplimiento.

Fase 6: Resguardo

Implementar un resguardo, en particular para clientes de bases de datos muy críticos, puede ser una buena protección contra los errores y los problemas de la migración. Un resguardo es como una migración, pero a la inversa. Es decir, en un resguardo,

configuras una migración de las bases de datos de destino a las bases de datos de origen.Instituto Tecnológico de Comitán

Después de desviar las bases de datos de origen y crear una copia de seguridad de todas, puedes habilitar los procesos de migración que identifican cambios en las bases de datos de destino y los migran a las bases de datos de origen antes del cambio.

Compilar estos procesos de migración garantiza que, luego de que los clientes realicen cambios en las bases de datos de destino, las bases de datos de origen se mantengan actualizadas. Es posible que se requiera un resguardo días o semanas después del cambio. Por ejemplo, es posible que los clientes accedan a la funcionalidad por primera vez y esté bloqueada debido a una funcionalidad que no se puede corregir de forma rápida. En este caso, los clientes pueden volver a acceder a las bases de datos de origen. Antes de volver a cambiar los clientes, se deben desviar todos los cambios en las bases de datos de destino a las bases de datos de origen.

En este enfoque, algunas circunstancias requieren atención especial:

•       Debes diseñar esquemas de destino para que sea posible realizar una migración inversa (de las bases de datos de destino a las bases de datos de origen). Por ejemplo, si tu proceso de migración inicial (de origen a destino) tiene uniones o agregaciones, una migración inversa no es trivial ni imposible. En ese caso, los datos individuales también deben estar disponibles en las bases de datos de destino.

•       Podría surgir un problema en el que las bases de datos de origen tienen registros de transacciones, pero las bases de datos de destino no proporcionan esa característica no funcional. En este caso, una migración inversa (de destino a origen) debe basarse en consultas diferenciales. Esa configuración debe diseñarse y prepararse en los esquemas de las bases de datos de destino.

•       Los clientes que en un comienzo operaban en las bases de datos de origen deben estar disponibles y en funcionamiento para que puedan activarse en un resguardo. Cualquier cambio funcional que se realice en los clientes que acceden a las bases

de datos de destino también se debe realizar en los clientes que acceden a la base de datos de origen para garantizar la equivalencia funcional.Instituto Tecnológico de Comitán

Si bien un resguardo es un último recurso, la implementación de un resguardo es esencial y debe tratarse como una migración de base de datos completa, lo que incluye pruebas.

Mitigación de errores de la migración

Pueden ocurrir problemas inesperados durante la migración de una base de datos. A continuación, se destacan algunas áreas que pueden requerir una planificación previa:

•       Capacidad de procesamiento insuficiente. Un sistema de migración puede no tener suficiente capacidad de procesamiento a pesar de las pruebas de carga. Este problema puede tener muchas causas, como un aumento imprevisto de la tasa de cambios en la base de datos de origen o una limitación de la red. Puedes prepararte para esta situación mediante recursos adicionales a fin de realizar un escalamiento vertical dinámico o un escalamiento horizontal de todos los componentes involucrados.

•       Inestabilidad de la base de datos. Las bases de datos de origen o de destino pueden presentar inestabilidad, lo que puede ralentizar los procesos de migración de datos o impedir el acceso de forma intermitente. Es posible que los procesos de migración de datos deban recuperarse con frecuencia. En este caso, un cambio intencional de HA o DR puede solucionar el problema. Un cambio modifica el entorno no funcional (máquinas y almacenamiento) y puede ayudar a mitigar el problema. En este caso, debes probar los procesos de cambios y de recuperación de la migración de bases de datos para asegurarte de que el cambio no produzca incoherencias de datos en las bases de datos de destino.

•       Agotamiento del tamaño del archivo de registro de transacciones. En algunos casos, los registros de transacciones se almacenan en archivos que tienen un límite superior. Es posible que se alcance este límite superior y que la migración de la base de datos falle. Es importante comprender qué partes de un sistema de bases de datos se pueden volver a configurar de forma dinámica para abordar las limitaciones de recursos a medida que surjan. Si ciertos aspectos no se pueden

configurar de forma dinámica, el tamaño inicial debe determinarse con cuidado.Instituto Tecnológico de Comitán

Si realizas pruebas realistas y completas por adelantado, es muy probable que encuentres problemas potenciales con anticipación.