Estrategias de migración de bases de datos

En un nivel superior, hay dos opciones para migrar una base de datos de SQL Server de las instalaciones alAWSNube: o bien permanecer en SQL Server (migraciones homogéneas) o salir de SQL Server (migraciones heterogéneas). En una migración homogénea, no se cambia el motor de la base de datos. Es decir, la base de datos de destino también es una base de datos de SQL Server. En una migración heterogénea, se cambian las bases de datos de SQL Server a un motor de base de datos de código abierto, como MySQL, PostgreSQL o MariaDB, o a unAWSBase de datos nativa de la nube, como Amazon Aurora, Amazon DynamoDB o Amazon Redshift.

Existen tres estrategias comunes para migrar las bases de datos de SQL Server aAWS: realojar, reorganizar y rediseñar (refactorizar). Son parte del7 R de las estrategias de migración de aplicacionesy se describe en la siguiente tabla.

Strategy (Estrategia)	Tipo	Cuándo elegir	Ejemplo
Realojar	Homogéneo	Desea migrar la base de datos de SQL Server tal cual, con o sin cambiar el sistema operativo, el software de la base de datos o la configuración.	De SQL Server a Amazon EC2 (BrowsePatrones de realojamiento)
Cambio de plataforma	Homogéneo	Desea reducir el tiempo que dedica a administrar instancias de bases de datos mediante el uso de una oferta de base de datos totalmente administrada.	De SQL Server a Amazon RDS for SQL Server (BrowsePatrones de replataforma)
Rediseñar (refactorizar)	Heterogéneo	Desea reestructurar, reescribir y rediseñar su base de datos y aplicación para aprovechar las funciones de base de datos de código abierto y nativas de la nube.	De SQL Server a Amazon Aurora PostgreSQL, MySQL o MariaDB NavegarRediseñar patrones)

Si está intentando decidir entre volver a alojar o cambiar la plataforma de las bases de datos de SQL Server, consulteElección entre Amazon EC2 y Amazon RDSmás adelante en esta guía para obtener una side-by-side comparación de las funciones admitidas.

Elección de la estrategia migratoria adecuada

La elección de la estrategia correcta depende de los requisitos de su negocio, las restricciones de recursos, el plazo de migración y las consideraciones de costos. El siguiente diagrama muestra el esfuerzo y la complejidad involucrados en las migraciones, incluidas las siete estrategias.

Refactorizar la base de datos de SQL Server y migrar a un servidor de código abierto oAWSLas bases de datos nativas de la nube, como Edición compatible con Amazon Aurora PostgreSQL o Edición compatible con Aurora MySQL, pueden ayudarlo a modernizar y optimizar su base de datos. Al cambiar a una base de datos de código abierto, puede evitar licencias costosas (lo que reduce los costos), períodos de bloqueo de proveedores y auditorías. Sin embargo, según la complejidad de la carga de trabajo, la refactorización de la base de datos de SQL Server puede ser un esfuerzo complicado, lento y que requiere muchos recursos.

Para reducir la complejidad, en lugar de migrar la base de datos en un solo paso, puede considerar un enfoque por etapas. En la primera fase, puede centrarse en la funcionalidad principal de la base de datos. En la siguiente fase, puede integrarAWSservicios en su entorno de nube, para reducir costos y optimizar el rendimiento, la productividad y el cumplimiento. Por ejemplo, si su objetivo es reemplazar la base de datos de SQL Server local por una compatible con Aurora MySQL, podría considerar volver a alojar la base de datos en Amazon EC2 o cambiar la plataforma de la base de datos en Amazon RDS for SQL Server en la primera fase y, a continuación, refactorizar la base de datos para que sea compatible con Aurora MySQL en una fase posterior. Este enfoque ayuda a reducir los costos, los recursos y los riesgos durante la fase de migración y se centra en la optimización y la modernización en la segunda fase.

Migración online y offline

Puede utilizar dos métodos para migrar la base de datos de SQL Server desde un entorno local u otro entorno en la nube alAWSNube, en función de su cronograma de migración y del tiempo de inactividad que puede permitir: migración fuera de línea o migración en línea.

• Migración sin conexión de Este método se utiliza cuando la aplicación puede permitirse un tiempo de inactividad planificado. En la migración sin conexión, la base de datos de origen está desconectada durante el período de migración. Mientras la base de datos de origen está fuera de línea, se migra a la base de datos de destino enAWS. Una vez finalizada la migración, se realizan comprobaciones de validación y verificación para garantizar la coherencia de los datos con la base de datos de origen. Cuando la base de datos pasa todas las comprobaciones de validación, se realiza una transición aAWSconectando su aplicación a la base de datos de destino enAWS.

• Migración online: Este método se utiliza cuando la aplicación requiere un tiempo de inactividad cercano a cero o mínimo. En la migración en línea, la base de datos de origen se migra en varios pasos aAWS. En los pasos iniciales, los datos de la base de datos de origen se copian en la base de datos de destino mientras la base de datos de origen sigue en ejecución. En pasos posteriores, todos los cambios desde la base de datos de origen se propagan a la base de datos de destino. Cuando las bases de datos de origen y de destino se sincronizan, están listas para la transición. Durante la transición, la aplicación cambia sus conexiones a la base de datos de destino enAWSsin dejar conexiones a la base de datos de origen. Puede usarAWS Database Migration Service(AWS DMS) o herramientas disponibles enAWS Marketplace(como Attunity) para sincronizar las bases de datos de origen y destino.