Blog de Amazon Web Services (AWS)

Cómo migrar bases de datos a soluciones en la nube

Por Angie Nobre, Arquitecta de Soluciones Senior para Database da AWS

 

Las migraciones de bases de datos a la nube se han convertido en una prioridad en muchas empresas, impulsadas en gran medida por factores como:

  • Las actualizaciones de hardware y software son laboriosas y, a menudo, requieren proyectos a largo plazo.
  • Mantenerse al día con las limitaciones de «end of life» de los productos también es un desafío debido a la falta de soporte de software, la falta de acceso a los parches del producto y la incompatibilidad con las aplicaciones de las versiones más recientes.
  • En la nube, los entornos que no están en uso durante largos períodos, como los entornos de homologación y desarrollo, se pueden detener durante los fines de semana y los períodos sin actividad, lo que reduce el costo de uso.
  • Agilidad para adaptarse a la carga de trabajo impuesta en la base de datos, lo que permite escalar vertical y horizontalmente.
  • Las actualizaciones de bases de datos suelen requerir áreas de maniobra para una ejecución segura, por ejemplo, una actualización de la versión, tanto en el almacenamiento como en la capacidad informática. En un entorno local, es necesario comprar nuevos equipos para permitir un mantenimiento seguro. En la nube, es posible utilizar el entorno de maniobra para una tarea que implica un mayor riesgo, solo durante el período de mantenimiento necesario, sin la necesidad de comprar nuevos equipos.
  • Necesita una solución de base de datos con mejor escalabilidad y agilidad para las aplicaciones que también necesitan soluciones nativas de la nube.

Estrategias de migración:

Los entornos de bases de datos son complejos y es esencial evaluar también la capa de aplicación y la mejor manera de migrar preferiblemente los dos niveles (base de datos y aplicación) juntos a la nube.

Normalmente, el mercado utiliza soluciones locales basadas en bases de datos, tales como:

  • Oracle
  • Microsoft SQL Server
  • PostgreSQL
  • MySQL

Para elegir la mejor estrategia y solución de base de datos, es fundamental mapear los siguientes aspectos:

  • ¿Cuáles son los requisitos de disponibilidad que la aplicación debe cumplir para respaldar el negocio?
  • ¿El entorno actual cumple con estos requisitos?
  • ¿La capa de aplicación está en una arquitectura compatible para ejecutarse en la nube o necesita conversión?
  • Según la compatibilidad de las aplicaciones, ¿es necesario mantener la base de datos en su software de base de datos actual o se puede convertir en una solución nativa de la nube?
  • Qué método o herramienta se ajustará mejor al tipo de migración requerida.

A continuación, analizaremos algunos tipos de migración de bases de datos de una manera práctica y objetiva.

¿Cómo elige la mejor estrategia para migrar el entorno de base de datos?

En base a los factores de toma de decisiones para elegir la estrategia de migración, queda decidir entre las siguientes opciones:

  • El software de base de datos actual cumple con los requisitos de la aplicación y si debe mantenerse exactamente igual. Por ejemplo, si la aplicación no se puede convertir a otra base de datos y la mejor alternativa de migración es mantener el software de base de datos.
  • La aplicación puede someterse a un proceso de modernización y las estructuras de tablas, índices y otros códigos (en funciones, procedimientos o disparadores, por ejemplo) se pueden convertir en una nueva estructura. Por ejemplo, la estructura de la base de datos se puede convertir de Oracle a PostgreSQL, por lo que mediante las herramientas de soporte es posible definir un plan de conversión y migración.
  • Valide que un servicio administrado, como RDS, cumpla mejor con el rendimiento y la disponibilidad de las aplicaciones y reduzca la carga administrativa y operativa, o si la aplicación requiere la base de datos en una instancia EC2.

Una vez definidos estos factores, para planificar la migración necesitamos:

  • Comprobar las métricas de uso del entorno (CPU, memoria e IOPS) para definir el tamaño de instancia correcto.
  • Identifique los requisitos de disponibilidad de la base de datos, en caso de una falla en el entorno de base de datos, dentro de cuánto tiempo debe estar disponible nuevamente para la aplicación (RTO). Y si se produce este fallo, cuánto tiempo se acepta perder transacciones (RPO).
  • Identifique el tamaño de la base de datos y el tiempo de inactividad que puede manejar la aplicación.
  • Identifique la herramienta o técnica de migración adecuada.
  • Mapee los criterios de éxito para el funcionamiento de la base de datos en la nube.
  • Planifique pruebas de migración de bases de datos y aplicaciones para validar la estrategia de migración y el rendimiento de las aplicaciones. Esto garantiza que el proceso adoptado satisfaga adecuadamente las necesidades del medio ambiente.
  • Después de realizar las pruebas, identifique las correcciones y los ajustes del proceso de migración.

Estos son algunos escenarios, como la modernización de los entornos de bases de datos locales a la nube, la separación de las migraciones homogéneas (donde no hay cambios en el software de la base de datos) y las migraciones heterogéneas (donde el software de base de datos cambia) en dos tipos.

Migraciones homogéneas:

  • Oracle local para Oracle en AWS
  • SQL Server local para SQL Server en AWS
  • PostgreSQL local para Amazon RDS PostgreSQL o Aurora PostgreSQL
  • MySQL local para RDS MySQL o Aurora MySQL

Migraciones heterogéneas:

  • Oracle local para Amazon RDS PostgreSQL o Aurora PostgreSQL
  • SQL Server local para Amazon Aurora MySQL o Amazon Aurora PostgreSQL

 

Migraciones homogéneas

En las migraciones en las que no habrá cambios en la solución de base de datos y la elección generalmente se basa en si será un servicio administrado o si se debe utilizar la base de datos de EC2, las herramientas nativas de cada solución son las mejores formas de replicar y migrar la base de datos.

Cómo migrar Oracle local a AWS:

La migración de la base de datos local de Oracle a Oracle en AWS es una buena alternativa en algunas condiciones, por ejemplo:

  • La aplicación no se puede convertir a otro tipo de base de datos debido a la compatibilidad y/o la versión.
  • Mayor flexibilidad y escalabilidad con respecto a los tipos de instancias y almacenamiento de información, y puede aumentar o reducir los recursos asignados a la instancia con mayor facilidad y reducir los impactos en los costos.
  • Automatice las tareas de Managed Service (RDS Oracle), tales como parches, copias de seguridad automáticas, creación de réplicas de lectura, conmutación por error automática a una instancia en espera (Multi-AZ) en caso de fallas.

Puede usar Oracle en AWS de dos maneras:

  • En una instancia EC2, donde tendrá el control y la administración totales de la instancia, las bibliotecas del sistema operativo y la instalación del software de base de datos.
  • En RDS Oracle, donde creará el esquema que utilizará la aplicación y tendrá disponible la automatización de tareas de un servicio administrado.

La siguiente documentación proporciona recomendaciones sobre cómo elegir la mejor alternativa para su entorno Oracle en AWS:
https://docs.thinkwithwp.com/whitepapers/latest/oracle-database-aws-best-practices/choosing-between-amazon-rds-amazon-ec2-or-vmware-cloud-on-aws-for-your-oracle-database.html

Para identificar si la mejor opción es usar RDS u Oracle en EC2, es importante evaluar:

  • Evalúe las métricas de uso de la base de datos, como CPU, memoria, IOPS y rendimiento, y luego busque el tipo de instancia adecuado para admitir la carga de trabajo. Si es necesario, consulte a uno de nuestros arquitectos de soluciones para obtener asistencia.
  • Valide si la aplicación utiliza configuraciones adicionales de la versión Enterprise Edition, como particionamiento, compresión avanzada, paralelo, entre otras, que se pueden validar de la lista:

https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html#GUID-B6113390-9586-46D7-9008-DCC9EDA45AB4
Para las aplicaciones que no requieren opciones de Enterprise Edition y la cantidad de funciones son adecuadas hasta 16 vCPU, una buena opción es Oracle Standard Edition Two.

  • Requisitos de solicitud
      1. ¿La aplicación requiere acceso a las bibliotecas del sistema operativo y a los archivos de instalación de la base de datos? Si es así, no es posible usar RDS, ya que es un servicio administrado que no ofrece esta opción.
      2. ¿La aplicación requiere acceso a los usuarios SYS y/o SYSTEM de la base de datos Oracle? Si es así, no es posible usar RDS, ya que es un servicio administrado que no ofrece esta opción.
      3. ¿Qué es el RTO de la aplicación si se produce un cambio por error de una instancia de base de datos? ¿Resiste entre 1 y 2 minutos? Si es así, el RDS cumple con este requisito.

En el siguiente enlace, puede consultar las versiones, funciones y restricciones compatibles:
https://docs.thinkwithwp.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html

Una vez que se hayan definido los recursos necesarios (CPU, memoria, IOPS y rendimiento), puede comprobar qué tipo de instancia se adapta mejor a la carga de trabajo:
https://thinkwithwp.com/rds/oracle/instance-types/

En este quickstart, encontrará una guía completa para implementar Oracle en EC2:
https://aws-quickstart.github.io/quickstart-oracle-database/

En esta referencia a continuación encontrará la guía para implementar Oracle RDS:
https://docs.thinkwithwp.com/AmazonRDS/latest/UserGuide/CHAP_GettingStarted.CreatingConnecting.Oracle.html

Métodos para migrar Oracle local a AWS:

Para planificar posibles estrategias de migración, es importante identificar la versión, la plataforma y el tamaño de la base de datos de Oracle en el entorno local.


Origen

Destino

Método posible

COMPLEJIDAD

Tiempo de inactividad

requisito

Versiones de Oracle
Oracle en Linux x86-64 Oracle en EC2 Linux Backup y restore convencionales de Oracle mediante rman o archivos de datos de backup y mantener la sincronización a través de archivos de registro archivados sencillo pequeño Debe mantener exactamente la misma versión de Oracle en el origen y el destino. A partir de la versión 11.2.0.4
Oracle en Windows Oracle en EC2 Windows Backup y restore convencionales de Oracle mediante rman o archivos de datos de backup y mantener la sincronización a través de archivos de registro archivados sencillo pequeño Debe mantener exactamente la misma versión de Oracle en el origen y el destino. A partir de la versión 11.2.0.4
Oracle en plataformas que presentan formato big endian:
Solaris
AIX
HP-UX
Serie Z de IBM
Oracle en EC2 Linux Transportable tablespaces con Rman
Documento de referencia My Oracle Support Doc ID 371556.1
Mediano Medio

Admite copias de seguridad incrementales
Documento de referencia Reducir el tiempo de inactividad del transportable tablespaces mediante el respaldo incremental multiplataforma (ID de documento MOS 2471245.1)

A partir de la versión 12.1
Oracle en todas las plataformas, incluido x86-64 Oracle RDS u Oracle en EC2 Datapump sencillo Varía según el tamaño del banco, entre transferencia e importación puede ser un período prolongado Datapump se puede generar en una versión inferior e importarse en una versión superior Oracle RDS admite las versiones 12.1, 12.2 y 19
Oracle en todas las plataformas (IBM Power, HP-UX, Solaris Sparc), incluido x86-64 Oracle RDS u Oracle en EC2 Datapump + AWS DMS Complejo pequeño Datapump se puede generar en una versión inferior e importarse en una versión superior Oracle RDS admite las versiones 12.1, 12.2 y 19

¿Cuáles son los escenarios recomendados para realizar la migración a AWS? 

  1. Origen de Oracle en Linux o Windows x86-64: destino de Oracle en Linux o Windows EC2:

Los entornos Oracle en Linux x86-64 o Windows tienen compatibilidad de plataforma con Oracle en EC2, por lo que puede generar una copia de seguridad del entorno de origen (mediante rman o copia de archivos de datos) y mantener la sincronización a través de archivos de registro archivados (incluido Oracle Data Guard).

  1. Oracle Source (todas las plataformas) – Oracle RDS Target:

Datapump es un formato de copia de seguridad compatible en todas las plataformas. Es un método ampliamente conocido por los expertos y relativamente fácil de usar. Si se asocia con DMS, el método puede reducir el tiempo de inactividad de la migración.

https://thinkwithwp.com/blogs/database/migrating-oracle-databases-with-near-zero-downtime-using-aws-dms/

 

En este documento se describen en detalle cada uno de los métodos de migración:
https://d1.awsstatic.com/whitepapers/migrating-oracle-database-workloads-to-oracle-linux-on-aws.pdf

Migración de SQL Server local a SQL Server en AWS

Cuando planeamos migrar SQL Server local a AWS, debemos tener en cuenta los siguientes factores:

  • ¿Necesito un servicio administrado o necesito acceso sin restricciones a todas las estructuras de bases de datos?
  • ¿Qué cantidad de recursos necesitaré para acomodar la carga de trabajo de las aplicaciones que voy a migrar?
  • ¿Cuál es la forma de la concesión de licencias?

Puede usar SQL Server en AWS de dos maneras:

  • Instale SQL Server en instancias de Windows en Amazon EC2, para tener el control total.
  • El uso de Amazon RDS SQL Server como un servicio administrado, de modo que, desde la instalación del sistema operativo, el software de la base de datos y las tareas administrativas, como la automatización de copias de seguridad, la aplicación de parches, la activación de la alta disponibilidad y la configuración de la supervisión, ahora están disponibles en la plataforma y están listas para usar.

¿Cómo elegir la mejor alternativa de migración para la carga de trabajo en cuestión?

  • A continuación se presentan los factores importantes para elegir SQL Server en EC2:
      • Requiere el control total de la instancia de base de datos y el sistema operativo.
      • La administración del backup y la replicación debe ser controlada por equipos locales.
      • La administración de clústeres debe ser controlada por equipos locales.
      • Requiere acceso al rol de administrador del sistema
  • Y factores para elegir RDS SQL Server:
      • Preferencia por la base de datos nativa de la nube.
      • Mayor enfoque en las actividades relacionadas con el negocio.
      • Mayor enfoque en tareas de ajuste de rendimiento de alto nivel.
      • Mayor enfoque en la optimización del esquema de base de datos.
      • Requiere menos capacitación relacionada con la tecnología de base de datos utilizada.

¿Qué versiones de SQL Server están disponibles en AWS?

Versión compatible RDS para SQL Server SQL Server en EC2
Versiones compatibles 2012, 2014, 2016, 2017, 2019 Todos
Ediciones compatibles Express, Web, Standard, Enterprise Todos

En la siguiente referencia, puede realizar un seguimiento de las actualizaciones de la versión de SQL Server de RDS:
https://docs.thinkwithwp.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html

La documentación a continuación proporciona la guía completa para instalar SQL Server en Amazon EC2:
https://thinkwithwp.com/premiumsupport/knowledge-center/ec2-windows-launch-sql-server/

La siguiente documentación proporciona una guía para implementar Amazon RDS SQL Server:
https://thinkwithwp.com/getting-started/hands-on/create-microsoft-sql-db/?nc1=h_ls

 

¿Cuáles son las formas de usar licencias de SQL Server en AWS?

  • Licencia incluida (LI): en SQL Server en Amazon EC2 y Amazon RDS SQL Server.
  • Use su propia licencia (BYOL – Bring Your Own License): SQL Server en Amazon EC2.

El documento a continuación describe en detalle cada una de as dos alternativas:
https://thinkwithwp.com/windows/resources/licensing/?nc1=h_ls

¿Qué métodos de migración están disponibles desde una base de datos de Microsoft SQL Server local a AWS?

Los métodos de migración que utilizan las herramientas nativas de las bases de datos son los que requieren menor esfuerzo de configuración. Es esencial en la fase de planificación identificar el mejor método de acuerdo con las características del entorno.

Método de migración Destino
Backup e restore nativos Amazon EC2
Amazon RDS
Log shipping Amazon EC2
Amazon RDS
Database mirroring Amazon EC2
Always On availability groups Amazon EC2
Basic Always On availability groups Amazon EC2
Distributed availability groups Amazon EC2
Transactional replication Amazon EC2
Amazon RDS
AWS Snowball Edge Amazon EC2
CloudEndure Migration Amazon EC2
AWS DMS Amazon EC2
Amazon RDS
Bulk copy program (bcp) Amazon EC2
Detach and attach Amazon EC2
Import/export Amazon EC2

Consulte el documento a continuación para cada método en detalle y también considere el caso de uso:
https://docs.thinkwithwp.com/prescriptive-guidance/latest/migration-sql-server/methods.html

Cómo migrar una base de datos MySQL a AWS:

La mejor manera de migrar una base de datos que tiene el mismo motor en la nube, como es el caso de MySQL, es usar herramientas nativas como mysqldump. Amazon Aurora MySQL también admite Percona XtraBackup

El siguiente documento describe en detalle cómo usar mysqldump para migrar su MySQL local a AWS:

https://docs.thinkwithwp.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html

Y este otro documento describe cómo migrar la base de datos MySQL a Amazon Aurora MySQL mediante Percona XtraBackup:

https://thinkwithwp.com/es/blogs/aws-spanish/como-migrar-la-base-de-datos-mysql-a-amazon-aurora/

Cómo migrar una base de datos de PostgreSQL a AWS:

La mejor manera de migrar una base de datos que tiene el mismo motor en la nube, como es el caso de PostgreSQL, es utilizar herramientas nativas.

Los servicios administrados de Amazon RDS PostgreSQL y Amazon Aurora PostgreSQL y Amazon Aurora PostgreSQL admiten pg_dump, pg_restore, herramientas de replicación lógica y el comando copy.

En el documento siguiente se describe en detalle cómo utilizar estas herramientas:

https://thinkwithwp.com/blogs/database/best-practices-for-migrating-PostgreSQL-databases-to-amazon-rds-and-amazon-aurora/

 

Migraciones heterogéneas

En un proceso de modernización de bases de datos, la pauta para buscar soluciones de código abierto está creciendo significativamente. En la actualidad, las soluciones de base de datos de «código abierto» ya superan a las licencias comerciales

 

 

Fuente: https://db-engines.com/en/ranking_osvsc

Los factores que impulsan este cambio en las soluciones son:

  • Alto costo de las licencias comerciales.
  • Avance en el nivel de madurez de las soluciones de código abierto, proporcionando alta disponibilidad y resiliencia.
  • Disponibilidad de herramientas que ayudan con la conversión de estructuras de bases de datos y códigos fuente y, en consecuencia, pueden mapear el esfuerzo requerido y reducir el esfuerzo de conversión.
  • Disponibilidad de herramientas para la migración de datos entre diferentes distribuciones de bases de datos.

 

Cómo migrar una base de datos Oracle local a Amazon RDS PostgreSQL o Aurora PostgreSQL

Para diferentes soluciones de base de datos, debe usar herramientas de conversión de estructuras y luego usar una solución para migrar los datos entre el origen y el destino.

  1. Convierta la estructura originalmente en Oracle a PostgreSQL:

Para la conversión de objetos, AWS proporciona la herramienta Amazon SCT (Herramienta de conversión de esquemas), que está disponible para Windows, Ubuntu y Fedora en el enlace de descarga https://docs.thinkwithwp.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Installing.html.

Para el proceso de conversión, deberá crear una base de datos PostgreSQL o Amazon Aurora PostgreSQL de RDS y seguir las instrucciones del manual https://docs.thinkwithwp.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Converting.html.

  1. Migrar los datos almacenados en tablas de Oracle a PostgreSQL:

AWS proporciona como servicio administrado, la herramienta Amazon DMS (Database Migration Service). DMS se conecta a diferentes fuentes y destinos, realiza la carga inicial (carga completa) y mantiene el CDC (captura de datos de cambio) para una actualización continua entre el origen y el destino.

El blog a continuación muestra en detalle cómo proceder con la migración: https://thinkwithwp.com/blogs/database/how-to-migrate-your-oracle-database-to-PostgreSQL/.

Cómo migrar una base de datos de Microsoft SQL Server local a Amazon Aurora PostgreSQL y Aurora MySQL

Para diferentes soluciones de base de datos, debe usar herramientas de conversión de estructuras y luego usar una solución para migrar los datos entre el origen y el destino. La primera parte que se ocupa de la conversión a través de la herramienta SCT y se aplica a ambos casos.

La segunda parte es específica del motor MySQL o PostgreSQL.

  1. Convierta la estructura originalmente a SQL Server for MySQL:

Para la conversión de objetos, AWS proporciona la herramienta Amazon SCT (Herramienta de conversión de esquemas), que está disponible para Windows, Ubuntu y Fedora en el enlace de descarga https://docs.thinkwithwp.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Installing.html.

Para el proceso de conversión, deberá crear una base de datos MySQL de Amazon Aurora y seguir las instrucciones del manual https://docs.thinkwithwp.com/pt_br/SchemaConversionTool/latest/userguide/CHAP_Converting.html.

  1. Migre los datos almacenados en las tablas de SQL Server a Aurora:

AWS proporciona como servicio administrado, la herramienta Amazon DMS (Database Migration Service). El DMS se conecta a diferentes fuentes y destinos, realiza la carga inicial (carga completa) y mantiene el CDC (captura de datos de cambio) para una actualización continua entre el origen y el destino.

2.1. El documento a continuación demuestra en detalle cómo proceder con la migración de SQL Server a Aurora PostegreSQL:

https://d1.awsstatic.com/whitepapers/Migration/sql-server-database-amazon-aurora-postgresql-migration-playbook-12.4.pdf

2.2 El blog a continuación demuestra en detalle cómo proceder con la migración a Aurora MySQL:

https://docs.thinkwithwp.com/pt_br/prescriptive-guidance/latest/patterns/migrate-a-microsoft-sql-server-database-to-aurora-mysql-by-using-aws-dms-and-aws-sct.html.

Babelfish y Aurora PostgreSQL:

La conversión del código desde bases de datos de motores distintos puede requerir mucho tiempo y recursos.

Babelfish és una solución que entiende los comandos T-SQL (el dialecto SQL propietario de Microsoft SQL Server) y los convierte a los comandos del Aurora PostgreSQL, como resultado se reduce el esfuerzo para trasladar las aplicaciones que originalmente corren en SQL Server.

Para conocer un poco más del Babelfish:

https://thinkwithwp.com/es/blogs/database/migrate-from-sql-server-to-amazon-aurora-using-babelfish/

 

Resumen:

La administración de bases de datos locales es una tarea que requiere tiempo, recursos y profesionales especializados. Y las empresas han adoptado cada vez más la estrategia de buscar utilizar sus bases de datos en la nube como una primera opción.

La disponibilidad de soluciones de base de datos compatibles con sus aplicaciones actuales y las estrategias de migración apropiadas ciertamente ayudarán a acelerar el proceso de adopción de la nube.

 

Este artículo fue traducido del Blog de AWS en Portugues.

 


Sobre los autores e revisores

Angie Nobre Cocharero es arquitecta de soluciones senior, especialista en migración de bases de datos en AWS.

 

 

 

 

 

Leonardo Ciccone es consultor senior de bases de datos en el equipo de Proserv en AWS.

 

 

 

 

 

Fabricio Quiles es arquitecto de soluciones senior especialista en analítica en AWS.

 

 

 

 

 

Daniel Soto es arquitecto de soluciones asociado en AWS.