Migración de sus bases de datos a Amazon Aurorad0.awsstatic.com/...Databases_to_Amazon_Aurora_ES.pdf · compatible con MySQL. Amazon Aurora es una base de datos nativa en la nube

Migración de sus bases de datos a Amazon Aurora

Junio de 2016

Amazon Web Services – Migración de sus bases de datos a Amazon Aurora Junio de 2016

Página 2 de 45

©2016, Amazon Web Services, Inc. o sus empresas afiliadas. Todos los derechos

reservados.

Avisos Este documento se suministra únicamente con fines informativos. Representa la

oferta actual de productos y prácticas de AWS a partir de la fecha de publicación

de este documento. Dichas prácticas y productos pueden modificarse sin previo

aviso. Los clientes son responsables de realizar sus propias evaluaciones

independientes de la información contenida en este documento y de cualquier

uso de los productos o servicios de AWS, cada uno de los cuales se ofrece

"como es", sin garantía de ningún tipo, ya sea explícita o implícita. Este

documento no constituye ninguna garantía, representación, compromiso

contractual o condición por parte de AWS, sus filiales, proveedores o licenciantes.

Las responsabilidades y obligaciones de AWS con sus clientes se rigen por los

acuerdos de AWS, y este documento no forma parte ni supone una modificación

de ningún acuerdo entre AWS y sus clientes.


Página 3 de 45

Contenido

Resumen 4

Introducción a AWS Database Migration Service Aurora 4

Consideraciones sobre la migración de bases de datos 6

Fases de la migración 6

Consideraciones sobre las aplicaciones 7

Consideraciones sobre la fragmentación y las réplicas de lectura 8

Consideraciones sobre la fiabilidad 9

Consideraciones sobre el costo y las licencias 9

Otras consideraciones sobre la migración 10

Planificación del proceso de migración de las bases de datos 10

Migración homogénea 11

Migración heterogénea 13

Migración de bases de datos grandes a Amazon Aurora 14

Consolidación de las particiones y fragmentos en Amazon Aurora 15

Resumen general de las opciones de migración 16

Migración de snapshots RDS 17

Migración del esquema de la base de datos 22

Migración de un esquema homogéneo 22

Migración de un esquema heterogéneo 24

Migración del esquema mediante la herramienta

de conversión de esquemas de AWS 25

Migración de los datos 33

Introducción y enfoque general a AWS DMS 33

Métodos de migración 34

Procedimiento de migración 35

Pruebas y cambio 41


Página 4 de 45

Comprobación de la migración 41

Cambio 42

Conclusión 43

Colaboradores 44

Documentación adicional 44

Notas 44

Resumen Amazon Aurora es un motor de bases de datos relacionales de clase empresarial

compatible con MySQL. Amazon Aurora es una base de datos nativa en la nube

que supera muchas de las limitaciones de los motores de bases de datos

relacionales tradicionales. El objetivo de este documento técnico es describir las

prácticas recomendadas para la migración de sus bases de datos existentes

a Amazon Aurora. En él se incluyen consideraciones sobre la migración y el

proceso paso a paso de migración de bases de datos comerciales y de código

abierto a Amazon Aurora con una interrupción mínima de las aplicaciones.

Introducción a Amazon Aurora Durante décadas, las bases de datos relacionales tradicionales han sido la

elección principal para el almacenamiento de datos y la persistencia. Estos

sistemas de bases de datos continúan utilizando arquitecturas monolíticas y no se

han diseñado para aprovechar la infraestructura de la nube. Estas arquitecturas

monolíticas presentan muchas deficiencias, especialmente en áreas como el

costo, la flexibilidad y la disponibilidad. Para abordar estas deficiencias, AWS ha

rediseñado la base de datos relacional para la infraestructura en la nube y ha

introducido Amazon Aurora.

Amazon Aurora es un motor de bases de datos relacionales compatible con

MySQL que combina la velocidad, la disponibilidad y la seguridad de las bases de

datos comerciales de tecnología avanzada con la sencillez y la rentabilidad de las

bases de datos de código abierto. Aurora proporciona un desempeño hasta cinco

veces superior a MySQL y comparable al de las bases de datos comerciales de

tecnología avanzada. El precio de Amazon Aurora es una décima parte del de los

motores comerciales.


Página 5 de 45

Amazon Aurora está disponible a través de la plataforma Amazon Relational

Database Service (Amazon RDS). Al igual que otras bases de datos de Amazon

RDS, Aurora es un servicio de base de datos totalmente administrado. Con la

plataforma de Amazon RDS, la mayoría de las tareas de administración de las

bases de datos, como el aprovisionamiento de hardware, la aplicación de parches

de software, la instalación, la configuración, la monitorización y los backups,

están totalmente automatizadas.

Amazon Aurora se ha diseñado para cargas de trabajo críticas y es un servicio de

alta disponibilidad de forma predeterminada. Un clúster de base de datos Aurora

abarca varias zonas de disponibilidad de una región, con lo que se consigue una

alta durabilidad y tolerancia a errores de los datos desde el primer momento en

todos los centros de datos físicos. Una zona de disponibilidad se compone de uno

o varios centros de datos altamente disponibles operados por Amazon. Las zonas

de disponibilidad están aisladas entre sí y conectadas a través de conexiones de

baja latencia. Cada segmento del volumen de base de datos se replica seis veces

en estas zonas de disponibilidad.

Los volúmenes del clúster de Aurora aumentan automáticamente conforme

se incrementa la cantidad de datos de la base de datos, sin que el desempeño

y la disponibilidad resulten afectados, por lo que no es necesario calcular

y aprovisionar por adelantado grandes cantidades de almacenamiento de base

de datos. Un volumen de un clúster de Aurora puede aumentar hasta un tamaño

máximo de 64 terabytes (TB). Solo se le cobrará el espacio que use en un volumen

de un clúster de Aurora.

La capacidad de backups automatizados de Aurora admite la recuperación de los

datos a un momento dado, lo que le permite restaurar su base de datos en

cualquier segundo del tiempo de retención, hasta los cinco últimos minutos. Los

backups automatizados se almacenan en Amazon Simple Storage Service

(Amazon S3), que se ha diseñado para una durabilidad del 99,999999999 %. Los

backups de Amazon Aurora son automáticos, incrementales y continuos, y no

afectan al desempeño de la base de datos.

Para las aplicaciones que necesitan réplicas de solo lectura, puede crear hasta

15 réplicas de Aurora para cada base de datos Aurora con un retraso de réplica

mínimo. Estas réplicas comparten el mismo almacenamiento subyacente que la

instancia de origen, lo que reduce los costos y evita la necesidad de realizar

operaciones de escritura en los nodos de las réplicas.


Página 6 de 45

Amazon Aurora es un servicio altamente seguro y le permite cifrar sus bases de

datos mediante claves que puede crear y controlar a través de AWS Key

Management Service (AWS KMS). En una instancia de base de datos

ejecutándose con cifrado de Amazon Aurora, los datos almacenados en reposo en

el almacenamiento subyacente están cifrados, al igual que los backups

automatizados, snapshots y réplicas del mismo clúster. Amazon Aurora usa SSL

(AES-256) para proteger los datos en tránsito.

Para obtener una lista completa de las características de Aurora, consulte la

página del producto Amazon Aurora.1 Debido a su amplio conjunto de

características y a su rentabilidad, Amazon Aurora se considera cada vez más la

base de datos ideal para las aplicaciones críticas.

Consideraciones sobre la migración de

bases de datos Una base de datos representa un componente crítico de la arquitectura de la

mayoría de las aplicaciones. Migrar la base de datos a una nueva plataforma es

un acontecimiento importante en el ciclo de vida de una aplicación y puede

repercutir en la funcionalidad, desempeño y fiabilidad de la aplicación. Antes de

embarcarse en el primer proyecto de migración a Amazon Aurora, debería tener

en cuenta algunas cuestiones importantes.

Fases de la migración Como las migraciones de bases de datos suelen ser complejas, le recomendamos

que adopte un enfoque iterativo por fases.

Figura 1: Fases de la migración

https://aws.amazon.com/rds/aurora/


Página 7 de 45

Consideraciones sobre las aplicaciones Evaluación de las características de Aurora

Aunque la mayoría de las aplicaciones se pueden diseñar para que funcionen con

muchos motores de bases de datos relacionales, debería asegurarse de que su

aplicación funciona con Amazon Aurora. Amazon Aurora se ha diseñado para que

sea compatible con MySQL 5.6. Por tanto, la mayoría del código, aplicaciones,

controladores y herramientas que se usan actualmente con las bases de datos

MySQL se pueden utilizar con Aurora con pocos o ningún cambio.

Sin embargo, algunas características de MySQL, como el motor de

almacenamiento MyISAM, no están disponibles con Amazon Aurora. Además,

debido a la naturaleza administrada del servicio Aurora, el acceso SSH a los nodos

de base de datos está restringido, lo que podría afectar a la capacidad de instalar

herramientas o complementos de otros fabricantes en el host de base de datos.

Consideraciones sobre el desempeño

El desempeño de la base de datos es una consideración importante cuando se

migra una base de datos a una nueva plataforma. Por consiguiente, muchos

proyectos de migración de bases de datos exitosos comienzan con la evaluación

del desempeño de la nueva plataforma de bases de datos. Aunque la ejecución de

los componentes de referencia Sysbench y TPC-C le ofrece una buena idea del

desempeño general de la base de datos, estas referencias no emulan los patrones

de acceso a los datos de sus aplicaciones. Para obtener resultados más útiles,

pruebe el desempeño de la base de datos para cargas de trabajo en las que el

tiempo es importante ejecutando las consultas (o un subconjunto de ellas)

directamente en la nueva plataforma.

Considere estas estrategias:

Si su base de datos actual es MySQL, migre a Amazon Aurora con pruebas

de tiempo de inactividad o desempeño de su base de datos utilizando una

versión de prueba o ensayo de su aplicación o reemplazando la carga de

trabajo en producción.

Si usa un motor que no es compatible con MySQL, puede realizar una copia

de algunas de las tablas con más actividad a Amazon Aurora y probar sus

consultas en esas tablas. Esto le ofrecerá un buen punto de partida. Por

supuesto, las pruebas después de realizar la migración le proporcionarán

una perspectiva completa del desempeño real de su aplicación en la nueva

plataforma.

https://d0.awsstatic.com/product-marketing/Aurora/RDS_Aurora_Performance_Assessment_Benchmarking_v1-2.pdf

https://d0.awsstatic.com/product-marketing/Aurora/RDS_Aurora_Performance_Assessment_Benchmarking_v1-2.pdf


Página 8 de 45

Amazon Aurora ofrece un nivel de desempeño comparable al de los motores

comerciales y bastante superior al de MySQL. Esto es posible gracias a la estrecha

integración del motor de base de datos con una capa de almacenamiento

virtualizada basada en SSD diseñada para las cargas de trabajo de base de datos.

Esta integración reduce las operaciones de escritura en el sistema de

almacenamiento, minimiza la contención de bloqueo y elimina los retrasos

causados por los subprocesos de la base de datos. Nuestras pruebas con SysBench

en instancias r3.8xlarge demuestran que Amazon Aurora permite más de

585.000 operaciones de lectura y 107.000 operaciones de escritura por segundo:

una velocidad cinco veces mayor que MySQL ejecutando los mismos

componentes de referencia en el mismo hardware.

Un área donde Amazon Aurora muestra una mejora importante con respecto al

sistema MySQL tradicional son las cargas de trabajo con un alto grado de

simultaneidad. Para maximizar la velocidad de las cargas de trabajo en Amazon

Aurora, es recomendable que diseñe sus aplicaciones de forma que puedan

realizar un gran número de consultas simultáneas.

Consideraciones sobre la fragmentación y las réplicas

de lectura Si la base de datos actual está fragmentada en varios nodos, puede combinar

estos fragmentos en una sola base de datos de Aurora durante la migración. Una

sola instancia de Amazon Aurora se puede ampliar hasta 64 TB, admite miles de

tablas y permite un número bastante mayor de operaciones de lectura y escritura

que una base de datos MySQL estándar.

Si su aplicación realiza muchas operaciones de lectura y escritura, considere la

posibilidad de usar réplicas de lectura de Aurora para liberar al nodo maestro de

la base de datos de la carga de trabajo de solo lectura. De este modo, puede

mejorar la simultaneidad de las operaciones de escritura en la base de datos

principal y el desempeño general de las operaciones de lectura y escritura. El uso

de réplicas de lectura puede reducir también los costos de una configuración

Multi-AZ, ya que puede usar instancias más pequeñas para la instalación

principal y añadir capacidades de conmutación por error en su clúster de base de

datos. El tiempo de replicación de las réplicas de lectura de Aurora es

prácticamente nulo y puede crear hasta 15 réplicas de lectura.


Página 9 de 45

Consideraciones sobre la fiabilidad Un aspecto importante sobre las bases de datos que debe tenerse en cuenta es la

alta disponibilidad y la recuperación de desastres. Determine los requisitos de

objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación

(RPO) de su aplicación. Con Amazon Aurora, puede mejorar considerablemente

ambos factores.

Amazon Aurora reduce los tiempos de reinicio de la base de datos a menos de

60 segundos en la mayoría de las situaciones de bloqueo de la base de datos.

Aurora saca también la caché del búfer del proceso de la base de datos, que

vuelve a estar inmediatamente disponible después de reiniciar. En las contadas

ocasiones en que se producen errores en el hardware y la zona de disponibilidad,

la plataforma de la base de datos se encarga automáticamente de la recuperación.

Aurora se ha diseñado para proporcionar una recuperación de RPO cero dentro

de una región de AWS, lo que constituye una mejora importante frente a los

sistemas de bases de datos locales. Aurora mantiene seis copias de los datos en

las tres zonas de disponibilidad e intenta recuperar automáticamente la base de

datos en una zona de disponibilidad en buen estado sin pérdida de datos. En el

caso improbable de que sus datos no estén disponibles en el almacenamiento de

Amazon Aurora, puede restaurarlos desde una snapshot de base de datos

o realizar una operación de restauración en un punto en el tiempo en una

nueva instancia.

Consideraciones sobre el costo y las licencias Ser propietario y ejecutar las bases de datos conlleva gastos. Antes de planificar la

migración de una base de datos, es imprescindible realizar un análisis del costo

total de propiedad (TCO) de la nueva plataforma de bases de datos. La migración

a una plataforma de bases de datos debería reducir idealmente el costo total de

propiedad y proporcionar a sus aplicaciones características similares o mejores.

Si ejecuta un motor de bases de datos de código abierto (MySQL, Postgres), los

gastos provendrán especialmente del hardware, la administración del servidor

y las actividades de administración de las bases de datos. Sin embargo, si ejecuta

un motor de bases de datos comercial (Oracle, SQL Server, DB2, etc.), una parte

importante del gasto serán las licencias de la base de datos.


Página 10 de 45

Como Aurora está disponible por una décima parte del costo de los motores

comerciales, muchas aplicaciones que se migren a Aurora podrán reducir

considerablemente su TCO. Incluso si ejecuta un motor de código abierto

como MySQL o Postgres, con el alto desempeño y las réplicas de lectura de

doble finalidad de Aurora podrá disfrutar de un ahorro importante con la

migración a Amazon Aurora. Para obtener más información, visite la página de

precios de Amazon RDS for Aurora.2

Otras consideraciones sobre la migración Una vez que haya considerado los aspectos relativos a la idoneidad, desempeño,

TCO y fiabilidad de las aplicaciones, debería pensar en qué va a migrar a la nueva

plataforma.

Cálculo del esfuerzo de cambio de código

Es importante calcular la cantidad de cambios en el código y en el esquema que

necesita realizar antes de migrar la base de datos a Amazon Aurora. Cuando la

migración se realiza desde bases de datos compatibles con MySQL, los cambios

necesarios en el código son insignificantes. Pero cuando se migra desde bases de

datos que no son compatibles con MySQL, es posible que tenga que realizar

cambios en el esquema y en el código. La herramienta de conversión de esquemas

de AWS, que se describe más adelante en este documento, puede ayudarle

a calcular ese esfuerzo.

Disponibilidad de las aplicaciones durante la migración

Puede migrar a Amazon Aurora mediante un enfoque con un tiempo de inactividad

previsible de la aplicación o a través de un enfoque con un tiempo de inactividad

prácticamente inexistente. El enfoque que elija depende del tamaño de la base de

datos y de los requisitos de disponibilidad de las aplicaciones. En cualquier caso, es

aconsejable tener en cuenta el impacto del proceso de migración en la aplicación y en

el negocio antes de comenzar con la migración de las bases de datos. En las siguientes

secciones se explican detalladamente ambos enfoques.

Planificación del proceso de migración de

las bases de datos En las secciones anteriores se expusieron algunas de las consideraciones

principales que deben tenerse en cuenta al migrar las bases de datos a Amazon

Aurora. Una vez que haya determinado que Aurora es la opción adecuada para su

aplicación, el siguiente paso consiste en elegir el enfoque de migración preliminar

y crear un plan de migración de las bases de datos.

http://aws.amazon.com/rds/aurora/pricing/


Página 11 de 45

Migración homogénea Si la base de datos de origen es una base de datos compatible con MySQL 5.6

(MySQL, MariaDB, Percona, etc.), la migración a Aurora será bastante sencilla.

Migración homogénea con tiempo de inactividad

Si la aplicación puede acomodar un tiempo de inactividad previsible durante las

horas de menos tráfico, la migración con tiempo de inactividad es la opción más

sencilla y es el enfoque recomendado. La mayoría de los proyectos de migración

de bases de datos pertenecen a esta categoría, ya que la mayoría de las

aplicaciones tienen un período de mantenimiento claramente definido. Dispone

de las siguientes opciones para migrar la base de datos con tiempo de inactividad.

Migración de snapshots RDS. Si la base de datos de origen se ejecuta

en Amazon RDS MySQL 5.6, puede migrar una snapshot de esa base de

datos a Amazon Aurora. Para las migraciones con tiempo de inactividad,

tendrá que detener la aplicación o interrumpir las operaciones de escritura

en la base de datos mientras la snapshot y la migración están en curso.

El momento de migrar depende principalmente del tamaño de la base de

datos y se puede determinar antes de la migración en producción mediante

la ejecución de una migración de prueba. La opción de migración de una

snapshot se explica en la sección Migración de snapshots RDS. También

puede realizar una migración con un tiempo de inactividad prácticamente

inexistente utilizando la opción de migración de una snapshot y replicación

del binlog, que se describe en la siguiente sección.

Migración mediante las herramientas nativas de MySQL. Puede usar

las herramientas nativas de MySQL para migrar los datos y el esquema

a Aurora. Esta es una buena opción cuando necesita más control sobre

el proceso de migración de las bases de datos, se siente cómodo usando

las herramientas nativas de MySQL o cuando otros métodos de migración

no son tan adecuados para su caso de uso. Para conocer las prácticas

recomendadas de esta opción, descargue el documento técnico

Amazon RDS for Aurora Export/Import Performance Best Practices.3

Migración mediante el servicio AWS Database Migration Service

(AWS DMS). La migración puntual mediante AWS DMS es otra forma de

mover la base de datos de origen a Amazon Aurora. Antes de usar AWS

DMS para mover los datos, necesita copiar el esquema de la base de datos

del origen al destino mediante las herramientas nativas de MySQL. Para

conocer el proceso paso a paso, consulte la sección Migración de los datos.

El uso de AWS DMS es una buena opción cuando no tiene experiencia con

las herramientas nativas de MySQL.

https://d0.awsstatic.com/product-marketing/Aurora/Aurora_Export_Import_Best_Practices_v1-3.pdf


Página 12 de 45

Migración homogénea con tiempo de inactividad prácticamente inexistente

En algunos casos puede ser conveniente migrar la base de datos a Aurora con un

tiempo de inactividad mínimo. A continuación se incluyen dos ejemplos:

Cuando la base de datos es bastante grande y el tiempo de la migración con

las opciones de tiempo de inactividad es mayor que el período de

mantenimiento de la aplicación

Cuando desea ejecutar las bases de datos de origen y destino en paralelo

para la realización de pruebas

En ambos casos, puede replicar los cambios de la base de datos de origen MySQL

en Aurora en tiempo real mediante la replicación. Puede elegir entre un par de

opciones:

Migración con un tiempo de inactividad prácticamente inexistente

mediante la replicación del binlog de MySQL. Amazon Aurora admite la

replicación del binlog de MySQL tradicional. Si ejecuta una base de datos

MySQL, es posible que ya esté familiarizado con la configuración clásica de

replicación del binlog. Si eso es así y desea más control sobre el proceso de

migración, la carga puntual de la base de datos mediante las herramientas

nativas junto con la replicación del binlog constituirá una ruta de

migración familiar a Aurora.

Migración con tiempo de inactividad prácticamente inexistente

mediante el servicio AWS Database Migration Service (AWS DMS).

Además

de admitir la migración puntual, AWS DMS también permite la replicación

de datos en tiempo real mediante la captura de datos de cambio (CDC) del

origen al destino. AWS DMS se ocupa de las tareas complejas relacionadas

con la copia inicial de datos configurando las instancias de replicación

y monitoreando la replicación. Una vez realizada la migración inicial

de la base de datos, la base de datos destino permanece sincronizada

con la de origen todo el tiempo que usted quiera. Si no está familiarizado

con la replicación del binlog, AWS DMS es la siguiente mejor opción

para las migraciones homogéneas con tiempo de inactividad

prácticamente inexistente a Amazon Aurora. Consulte la sección

Introducción y enfoque general a AWS DMS.


Página 13 de 45

Migración con tiempo de inactividad prácticamente inexistente

mediante la replicación de snapshots de RDS y la replicación del

binlog de MySQL. Si la base de datos de origen se ejecuta en Amazon RDS

MySQL 5.6, puede migrar una snapshot de esa base de datos a Amazon

Aurora e iniciar la replicación del binlog entre el origen y el destino

después de la migración de la snapshot. Para obtener información

detallada sobre esta opción de migración, consulte Replication with

Amazon Aurora en Amazon RDS User Guide.4

Migración heterogénea Si desea migrar una base de datos no compatible con MySQL (Oracle, SQL

Server, PostgresSQL, etc.) a Amazon Aurora, hay varias opciones que pueden

ayudarle a realizar esta migración rápida y fácilmente.

Migración del esquema

La migración de esquema de una base de datos no compatible con MySQL

a Amazon Aurora se puede realizar con la herramienta de conversión de

esquemas de AWS. Esta herramienta es una aplicación de escritorio que le ayuda

a convertir el esquema de una base de datos Oracle, Microsoft SQL Server

o PostgreSQL en una instancia de base de datos Amazon RDS MySQL o en un

clúster de base de datos Amazon Aurora. En aquellos casos en los que el esquema

de la base de datos de origen no se pueda convertir automática y completamente,

la herramienta de conversión de esquemas de AWS proporciona instrucciones

sobre cómo crear el esquema equivalente en la base de datos Amazon RDS

de destino. Para obtener información detallada, consulte la sección

Migración del esquema de base de datos.

Migración de los datos

Además de admitir las migraciones homogéneas con tiempo de inactividad

prácticamente inexistente, el servicio AWS Database Migration Service (AWS DMS)

admite también la replicación continua entre bases de datos heterogéneas, y es la

opción preferida para mover la base de datos de origen a la base de datos de destino

tanto para las migraciones con tiempo de inactividad como para las migraciones con

tiempo de inactividad prácticamente inexistente. Una vez iniciada la migración,

AWS DMS se encarga de todas las tareas complejas del proceso de migración como

la transformación del tipo de datos, la compresión y la transferencia paralela

(para las transferencias rápidas de datos), además de garantizar que los cambios de

datos en la base de datos de origen que se producen durante el proceso de migración

se repliquen automáticamente en el destino.

http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication

http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication


Página 14 de 45

Además de usar AWS DMS, puede utilizar algunas herramientas de terceros

como Attunity Replicate, Tungsten Replicator, Oracle Golden Gate, etc., para

migrar los datos a Amazon Aurora. Cualquiera que sea la herramienta que elija,

tenga en cuenta el desempeño y los costos de las licencias antes de seleccionar el

conjunto de herramientas definitivo para la migración.

Migración de bases de datos grandes a Amazon

Aurora La migración de conjuntos de datos grandes presenta desafíos únicos para

cualquier proyecto de migración de bases de datos. Muchos proyectos de

migración de bases de datos grandes de éxito usan una combinación de las

siguientes estrategias:

Migración con replicación continua. Las bases de datos grandes suelen

tener requisitos de tiempo de inactividad prolongado durante el

movimiento de los datos del origen al destino. Para reducir el tiempo de

inactividad, puede cargar primero los datos básicos del origen al destino

y después habilitar la replicación (mediante las herramientas nativas de

MySQL, AWS DMS o herramientas de terceros) para los cambios que

deben capturarse.

Copie primero las tablas estáticas. Si la base de datos utiliza tablas

estáticas de gran tamaño con datos de referencia, puede migrar estas tablas

a la base de datos de destino antes de migrar el conjunto de datos activo.

Puede utilizar AWS DMS para copiar las tablas de manera selectiva o

exportar e importar estas tablas manualmente.

Migración en varias fases. La migración de una base de datos grande con

miles de tablas se puede dividir en varias fases. Por ejemplo, puede mover

un conjunto de tablas sin consultas de uniones cruzadas cada fin de

semana hasta que la base de datos de origen se migre completamente a la

base de datos de destino. Tenga en cuenta que para realizar esta operación,

necesita realizar cambios en la aplicación de manera que se conecte a dos

bases de datos simultáneamente mientras el conjunto de datos esté en dos

nodos distintos. Aunque este no es un modelo de migración común,

sí puede ser una opción.


Página 15 de 45

Limpieza de la base de datos. Muchas bases de datos grandes contienen

datos y tablas que no se utilizan. En muchos casos, los desarrolladores

y administradores de bases de datos mantienen backups de las tablas en la

misma base de datos o simplemente olvidan eliminar las tablas que no se

usan. Cualquiera que sea el motivo, un proyecto de migración de bases de

datos ofrece la oportunidad de limpiar la base de datos existente antes de la

migración. Si algunas tablas no se están utilizando, puede borrarlas

o archivarlas en otra base de datos. También puede eliminar los datos

antiguos de las tablas grandes o archivarlos en archivos sin formato.

Consolidación de las particiones y fragmentos en

Amazon Aurora Si ejecuta varios fragmentos o particiones funcionales de la base de datos para

conseguir un alto desempeño, tiene la oportunidad de consolidar estas

particiones o fragmentos en una sola base de datos Aurora. Una sola instancia de

Amazon Aurora se puede ampliar hasta 64 TB, admite miles de tablas y permite

un número bastante mayor de operaciones de lectura y escritura que una base de

datos MySQL estándar. La consolidación de estas particiones en una sola

instancia de Aurora no solo reduce el costo total de propiedad y simplifica la

administración de la base de datos, sino que también mejora considerablemente

el desempeño de las consultas entre particiones.

Particiones funcionales. Las particiones funcionales sirven para tener

nodos diferentes dedicados a distintas tareas. Por ejemplo, en una

aplicación de comercio electrónico, podría tener un nodo de base de datos

que proporcione datos del catálogo de productos y otro nodo para capturar

y procesar los pedidos. Por consiguiente, estas particiones suelen tener

esquemas distintos no solapados.

Estrategia de consolidación. Migre cada partición funcional como un

esquema distinto a la instancia de Aurora de destino. Si la base de datos de

origen es compatible con MySQL, use las herramientas nativas de MySQL

para migrar el esquema y después utilice AWS DMS para migrar los datos,

una sola vez o de manera continuada mediante la replicación. Si la base de

datos de origen no es compatible con MySQL, use la herramienta de

conversión de esquemas de AWS para migrar los esquemas a Aurora

y utilice AWS DMS para la carga puntual o la replicación continua.


Página 16 de 45

Fragmentos de datos. Si tiene el mismo esquema con conjuntos de datos distintos en varios nodos, puede utilizar la fragmentación de la base de datos. Por ejemplo, un servicio de blog de alta actividad puede fragmentar la actividad y los datos de los usuarios en varios fragmentos de base de datos manteniendo el mismo esquema de tabla.

Estrategia de consolidación. Como todos los fragmentos comparten el mismo esquema de base de datos, solo necesita crear el esquema de destino una sola vez. Si usa una base de datos compatible con MySQL, utilice las herramientas nativas para migrar el esquema de base de datos a Aurora. Si usa una base de datos no compatible con MySQL, utilice la herramienta de conversión de esquemas de AWS para migrar el esquema de base de datos a Aurora. Una vez migrado el esquema de base de datos, es aconsejable interrumpir las operaciones de escritura en los fragmentos de la base de datos y usar las herramientas nativas o la carga de datos puntual de AWS DMS para migrar los distintos fragmentos a Aurora. Si no es posible interrumpir las operaciones de escritura en la aplicación durante un tiempo prolongado, puede seguir usando AWS DMS con replicación, pero solo después de haber realizado una planificación y comprobación adecuadas.

Resumen general de las opciones de migración

Tipo de base de datos

de origen

Migración con tiempo de

inactividad

Migración con tiempo de inactividad

prácticamente inexistente

Amazon RDS MySQL Opción 1: Migración de snapshots

RDS

Opción 2: Migración manual con

herramientas nativas*

Opción 3: Migración del esquema

con herramientas nativas y carga de

datos mediante AWS DMS


herramientas nativas + replicación del

binlog

Opción 2: Migración de snapshots

RDS + replicación del binlog

Opción 3: Migración del esquema con

herramientas nativas + AWS DMS

para el movimiento de datos

MySQL Amazon EC2

o localmente

Opción 1: Migración con

herramientas nativas

Opción 2: Migración del esquema

con herramientas nativas + AWS

DMS para la carga de datos


herramientas nativas + replicación del

binlog

Opción 2: Migración del esquema con

herramientas nativas + AWS DMS

para mover los datos

Oracle/SQL server Opción 1: Herramienta de

conversión de esquemas de AWS +

AWS DMS (recomendada)

Opción 2: Manual o herramienta de

terceros para la conversión del

esquema + manual o herramienta

de terceros para la carga de datos

en la base de datos de destino

Opción 1: Herramienta de conversión

de esquemas de AWS + AWS DMS

(recomendada)

Opción 2: Manual o herramienta de


esquema + manual o herramienta de

terceros para la carga de datos en la

base de datos de destino + herramienta

de terceros para la replicación


Página 17 de 45

Tipo de base de datos

de origen

Migración con tiempo de

inactividad

Migración con tiempo de inactividad

prácticamente inexistente

Otras bases de datos

distintas de MySQL

Opción: Manual o herramienta de


esquema + manual o herramienta

de terceros para la carga de datos

en la base de datos de destino

Opción: Manual o herramienta de


esquema + manual o herramienta de

terceros para la carga de datos en la

base de datos de destino +

herramienta de terceros para la

replicación (GoldenGate, etc.)

*Herramientas nativas Mysql: mysqldump, SELECT INTO OUTFILE, herramientas de terceros como

mydumper/myloader

Migración de snapshots RDS Para usar la migración de snapshots RDS a Aurora, la base de datos MySQL se

debe estar ejecutando en Amazon RDS MySQL 5.6 y debe crear una snapshot RDS

de la base de datos. Este método de migración no funciona en bases de datos

locales ni en bases de datos que se ejecuten en Amazon Elastic Compute Cloud

(Amazon EC2). Además, si ejecuta la base de datos Amazon RDS MySQL en una

versión anterior a la 5.6, deberá actualizarla a la versión 5.6 como requisito previo.

La mayor ventaja de este método de migración es que es el más sencillo y el que

menos número de pasos requiere. En concreto, migra todos los objetos del

esquema, índices secundarios y procedimientos almacenados junto con todos los

datos de la base de datos.

Durante la migración de las snapshots sin la replicación del binlog, la base de

datos de origen debe estar desconectada o en modo de solo lectura, ya que no se

realiza ningún cambio en la base de datos de origen durante la migración. Para

calcular el tiempo de inactividad, puede usar la snapshot existente de la base de

datos para realizar una migración de prueba. Si el tiempo de la migración encaja

con sus requisitos de tiempo de inactividad, este podría ser el método más

adecuado. Tenga en cuenta que, en algunos casos, la migración mediante AWS

DMS o las herramientas de migración nativas puede ser más rápida que la

migración de snapshots.


Página 18 de 45

Si no puede tolerar un tiempo de inactividad prolongado, puede conseguir

igualmente una migración con un tiempo de inactividad prácticamente nulo

migrando primero una snapshot de la base de datos RDS a Amazon Aurora

y permitiendo que la base de datos de origen se siga actualizando. A continuación,

puede actualizar la base de datos mediante la replicación del binlog de MySQL de

MySQL a Aurora.

Puede migrar una snapshot de base de datos manual o automatizada. Los pasos

generales que debe realizar son los siguientes:

1. Determine la cantidad de espacio necesario para migrar la instancia de

Amazon RDS MySQL 5.6 a un clúster de base de datos de Aurora. Para

obtener más información, consulte la siguiente sección.

2. Utilice la consola de Amazon RDS para crear la snapshot en la región

donde se encuentra la instancia de Amazon RDS MySQL 5.6.

3. Use la característica Migrate Database (Migrar base de datos) de la

consola para crear un clúster de base de datos de Amazon Aurora que se

rellene mediante la snapshot de base de datos de la instancia de base de

datos original de MySQL 5.6.

Nota: Algunas tablas de MyISAM no se pueden convertir sin errores y podrían

requerir cambios manuales. Por ejemplo, el motor InnoDB no permite un campo

de incremento automático como parte de una clave compuesta. Asimismo, no se

admiten actualmente los índices espaciales.

Cálculo de los requisitos de espacio para la migración de la snapshot

Cuando migra una snapshot de una instancia de base de datos MySQL a un

clúster de base de datos de Aurora, Aurora usa un volumen Amazon Elastic Block

Store (Amazon EBS) para formatear los datos de la snapshot antes de migrarlos.

Hay algunos casos en los que se requiere espacio adicional para formatear los

datos que se van a migrar. Las dos características que podrían producir

problemas de espacio durante la migración son las tablas de MyISAM y el uso de

la opción ROW_FORMAT=COMPRESSED. Si no usa ninguna de estas características en la

base de datos de origen, puede saltarse esta sección, ya que no debería tener

problemas de espacio. Durante la migración, las tablas de MyISAM se convierten

en InnoDB y se descomprimen todas las tablas comprimidas. Por consiguiente,

debe haber suficiente espacio para las copias adicionales de estas tablas.


Página 19 de 45

El tamaño del volumen de migración se basa en el tamaño asignado de la base de

datos MySQL de origen desde la que se creó la snapshot. Por tanto, si tiene tablas

de MyISAM o tablas comprimidas que constituyen un pequeño porcentaje del

tamaño total de la base de datos y hay espacio disponible en la base de datos

original, la migración debería realizarse correctamente sin que surjan problemas

de espacio. Sin embargo, si la base de datos original no tiene espacio suficiente

para almacenar una copia de las tablas de MyISAM convertidas así como de otras

copias (sin comprimir) de las tablas comprimidas, el volumen de migración no

será lo suficientemente grande. En tal caso, tendrá que modificar la base de datos

Amazon RDS MySQL de origen para aumentar la asignación de tamaño de la

base de datos con el fin de disponer de espacio para las copias adicionales de

estas tablas, realizar una nueva snapshot de la base de datos y después migrar la

nueva snapshot.

Cuando migre los datos a un clúster de base de datos, tenga en cuenta las

siguientes directrices y limitaciones:

Aunque Amazon Aurora admite hasta 64 TB de almacenamiento, el

proceso de migración de una snapshot en un clúster de base de datos de

Aurora está limitado por el tamaño del volumen Amazon EBS de la

snapshot y, por tanto, está limitado a un tamaño máximo de 6 TB.

Las tablas distintas de MyISAM de la base de datos de origen pueden tener

un tamaño de hasta 6 TB. Sin embargo, debido a los requisitos de espacio

adicionales durante la conversión, asegúrese de que ninguna de las tablas

de MyISAM y comprimidas que se van a migrar desde la instancia de base

de datos MySQL tengan un tamaño superior a 3 TB.

Tal vez le convenga modificar el esquema de la base de datos (convirtiendo las

tablas MyISAM en InnoDB y quitando ROW_FORMAT=COMPRESSED) antes de migrarlo

a Amazon Aurora. Esto puede ser útil en los siguientes casos:

Desea acelerar el proceso de migración.

No está seguro de cuánto espacio necesita aprovisionar.

Ha intentado migrar los datos y la migración ha fallado debido a la falta de

espacio aprovisionado.

Asegúrese de que no realiza estos cambios en la base de datos Amazon RDS

MySQL en producción sino en una instancia de base de datos que se haya

restaurado de la snapshot de producción. Para obtener más información al

respecto, consulte Reducing the Amount of Space Required to Migrate Data into

Amazon Aurora en Amazon RDS User Guide.5

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Migrate.html#USER_ImportAurora.PreImport

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Migrate.html#USER_ImportAurora.PreImport


Página 20 de 45

Migración de una snapshot de base de datos mediante la consola

Puede migrar una snapshot de base de datos de una instancia de base de datos

Amazon RDS MySQL para crear un clúster de base de datos de Aurora. El nuevo

clúster de base de datos se rellena con los datos de la instancia de base de datos

Amazon RDS MySQL original. La snapshot de base de datos debe haberse creado

a partir de una instancia de base de datos RDS que ejecute MySQL 5.6 y no debe

estar encriptada. Para obtener información sobre cómo crear una snapshot de

base de datos, consulte Creating a DB Snapshot en Amazon RDS User Guide.6

Si la snapshot de base de datos no está en la región donde desea colocar su clúster

de base de datos de Aurora, use la consola de Amazon RDS para copiarla en esa

región. Para obtener información sobre cómo copiar una snapshot de base de

datos, consulte Copying a DB Snapshot en Amazon RDS User Guide.7

Para migrar una snapshot de base de datos MySQL 5.6 mediante la consola, siga

este procedimiento:

1. Inicie sesión en la consola de administración de AWS y abra la consola de

Amazon RDS en https://console.aws.amazon.com/rds/.

2. Elija Snapshots.

3. En la página Snapshots, elija la snapshot Amazon RDS MySQL 5.6 que

desee migrar a un clúster de base de datos de Aurora.

4. Elija Migrate Database (Migrar base de datos).

5. En la página Migrate Database, especifique los valores correspondientes

a su entorno y requisitos de procesamiento como se muestra en la siguiente

ilustración. Para obtener una descripción de estas opciones, consulte

Migrating a DB Snapshot by Using the Console en Amazon RDS User Guide.8

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html

https://console.aws.amazon.com/rds/

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Migrate.html#USER_ImportAuroraCluster.Console


Página 21 de 45

Figura 2: Migración de una snapshot

6. Haga clic en Migrate (Migrar) para migrar la snapshot de base de datos.

En la lista de instancias, haga clic en el icono de flecha correspondiente para mostrar los detalles del clúster de base de datos y monitorizar el progreso de la migración. En este panel de detalles se muestra el punto de enlace del clúster para conectar con la instancia principal del clúster de base de datos. Para obtener más información sobre cómo establecer una conexión con el clúster de base de datos de Amazon Aurora, consulte Connecting to an Amazon Aurora DB Cluster en Amazon RDS User Guide.9

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Connect.html


Página 22 de 45

Migración del esquema de la base de datos La migración de la snapshot de base de datos RDS migra el esquema completo

y los datos a la nueva instancia de Aurora. Sin embargo, si los requisitos de

ubicación de la base de datos de origen o de tiempo de actividad de la aplicación

no permiten el uso de la migración de la snapshot RDS, tendrá que migrar el

esquema de la base de datos de origen a la de destino antes de mover los datos

reales. Un esquema de base de datos es una estructura básica que representa la

vista lógica de toda la base de datos y normalmente incluye lo siguiente:

Objetos de almacenamiento de la base de datos: tablas, columnas, restricciones,

índices, secuencias, tipos definidos por el usuario y tipos de datos

Objetos de código de la base de datos: funciones, procedimientos,

paquetes, disparadores, vistas, vistas materializadas, eventos, funciones

escalares SQL, funciones insertadas SQL, funciones de tablas SQL,

atributos, variables, constantes, tipos de tablas, tipos públicos, tipos

privados, cursores, excepciones, parámetros y otros objetos

En la mayoría de los casos, el esquema de base de datos permanece relativamente

estático y no necesitará interrumpir las operaciones durante el paso de migración

de dicho esquema. El esquema de la base de datos de origen se puede extraer

mientras la base de datos está funcionando sin que esto afecte al desempeño.

Si la aplicación o los desarrolladores realizan cambios frecuentes en el esquema

de base de datos, asegúrese de que estos cambios se pongan en pausa mientras la

migración está en curso o se detengan durante el proceso de migración del esquema.

En función del tipo de la base de datos de origen, puede usar las técnicas que se

describen en las siguientes secciones para migrar el esquema de base de datos.

Como requisito previo a la migración del esquema, debe haber creado una base

de datos Aurora de destino, la cual debe estar disponible.

Migración de un esquema homogéneo Si la base de datos de origen es compatible con MySQL 5.6 y se ejecuta en

Amazon RDS, Amazon EC2 o fuera de AWS, puede usar las herramientas nativas

de MySQL para exportar e importar el esquema.


Página 23 de 45

Exportación del esquema de base de datos. Puede usar la utilidad

cliente mysqldump para exportar el esquema de base de datos. Para

ejecutar esta utilidad, necesita conectarse a la base de datos de origen

y redirigir la salida del comando mysqldump a un archivo sin formato. La

opción –no-data garantiza que solo se exporte el esquema de base de datos

sin datos reales de las tablas. Para obtener la referencia completa del

comando mysqldump, consulte mysqldumpA Database Backup Program.10

mysqldump –u source_db_username –p --no-data --routines --

triggers –databases source_db_name > DBSchema.sql

Importación del esquema de base de datos en Aurora. Para importar el

esquema en la instancia de Aurora, conéctese a la base de datos de Aurora

desde el cliente de línea de comandos de MySQL (o un cliente Windows

equivalente) y dirija el contenido del archivo de exportación a MySQL.

mysql –h aurora-cluster-endpoint -u username -p <

DBSchema.sql

Tenga en cuenta lo siguiente:

Si la base de datos de origen contiene procedimientos almacenados,

disparadores y vistas, tendrá que quitar DEFINER del archivo de volcado.

A continuación se incluye un sencillo comando Perl para realizar esta

operación. De esta manera, se crearán todos los disparadores, vistas

y procedimientos almacenados con el usuario actualmente conectado como

DEFINER. Asegúrese de evaluar las implicaciones de seguridad que esto

pudiera tener.

$perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < DBSchema.sql >

DBSchemaWithoutDEFINER.sql

https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html



Página 24 de 45

Amazon Aurora solo admite tablas de InnoDB. Si tiene tablas de MyISAM

en la base de datos de origen, Aurora cambia automáticamente el motor

a InnoDB cuando se ejecuta el comando CREATE TABLE.

Amazon Aurora no admite tablas comprimidas (es decir, tablas creadas con

ROW_FORMAT=COMPRESSED). Si tiene tablas comprimidas en la base de datos de

origen, Aurora cambia automáticamente ROW_FORMAT a COMPACT cuando se

ejecuta el comando CREATE TABLE.

Una vez importado correctamente el esquema en Amazon Aurora desde la base

de datos de origen compatible con MySQL 5.6, el siguiente paso consiste en

copiar los datos reales del origen al destino. Para obtener más información,

consulte la sección Introducción y enfoque general a AWS DMS más adelante en

este documento.

Migración de un esquema heterogéneo Si la base de datos de origen no es compatible con MySQL, debe convertir el

esquema a un formato compatible con Amazon Aurora. La conversión del

esquema de un motor de base de datos a otro no es una tarea trivial y puede

implicar la redefinición de algunas partes de la base de datos y del código de la

aplicación. Básicamente, tiene dos opciones para convertir y migrar el esquema

a Amazon Aurora:

Herramienta de conversión de esquemas de AWS. La herramienta de

conversión de esquemas de AWS simplifica las migraciones de bases de

datos heterogéneas al convertir automáticamente el esquema de la base de

datos de origen y la mayor parte del código personalizado, incluidas las

vistas, procedimientos almacenados y funciones, en un formato compatible

con la base de datos de destino.11 El código que no se puede convertir

automáticamente se marca claramente para que pueda convertirse

manualmente. Puede usar esta herramienta para convertir las bases de

datos de origen que se ejecuten en Oracle o Microsoft SQL Server a una

base de datos de destino Amazon Aurora, MySQL o PostgreSQL en Amazon

RDS o Amazon EC2. El uso de la herramienta de conversión de esquemas

de AWS para convertir el esquema Oracle, SQL Server o PostgreSQL a un

formato compatible con Aurora es el método preferido.

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/Welcome.html



Página 25 de 45

Migración manual de esquema y herramientas de terceros. Si la base

de datos de origen no es Oracle, SQL Server ni PostgreSQL, puede migrar

manualmente el esquema de la base de datos de origen a Aurora o usar

herramientas de terceros para migrar el esquema a un formato compatible

con MySQL 5.6. La migración manual del esquema puede ser un proceso

que requiera un alto grado de interacción en función del tamaño y

complejidad del esquema de origen. En la mayoría de los casos, sin

embargo, la conversión manual del esquema justificará el esfuerzo gracias

al ahorro de costos, los beneficios de desempeño y otras mejoras que

proporciona Amazon Aurora.

Migración del esquema mediante la herramienta de

conversión de esquemas de AWS La herramienta de conversión de esquemas de AWS proporciona una interfaz de

usuario basada en el proyecto para convertir automáticamente el esquema de la

base de datos de origen en un formato compatible con Amazon Aurora. Es

absolutamente recomendable que use la herramienta de conversión de esquemas

de AWS para evaluar la tarea de migración de la base de datos y el proyecto piloto

antes de la migración real a producción.

Las siguientes descripciones le guiarán por los pasos generales de esta

herramienta. Para obtener instrucciones detalladas, consulte la sección

Getting Started de AWS Schema Conversion Tool User Guide.12

1. En primer lugar, instale la herramienta. La herramienta de conversión de

esquemas de AWS está disponible para Microsoft Windows, Mac OS X,

Ubuntu Linux y Fedora Linux.

Encontrará instrucciones detalladas sobre la descarga e instalación en la

sección de instalación y actualización de la guía del usuario.13 El lugar donde

instala la herramienta de conversión de esquemas de AWS es importante. La

herramienta necesita conectarse directamente a las bases de datos de origen

y destino para convertir y aplicar el esquema. Asegúrese de que el escritorio

donde instale la herramienta de conversión de esquemas de AWS tenga

conexión de red con las bases de datos de origen y destino.

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.GettingStarted.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.Installing.html


Página 26 de 45

2. Instale los controladores JDBC. La herramienta de conversión de esquemas

de AWS usa controladores JDBC para conectarse a las bases de datos de

origen y destino. Para poder usar esta herramienta, debe descargar estos

controladores JDBC en su escritorio local. Encontrará instrucciones sobre

la descarga de controladores en Required Database Drivers en AWS

Schema Conversion Tool User Guide.14 Consulte también el foro de AWS

sobre la herramienta de conversión de esquemas de AWS para obtener

instrucciones sobre cómo instalar controladores JDBC para diferentes

motores de base de datos.15

3. Cree una base de datos de destino. Cree una base de datos de destino de

Amazon Aurora. Para obtener instrucciones sobre cómo crear una base de

datos de Amazon Aurora, consulte Creating an Amazon Aurora DB Cluster

en Amazon RDS User Guide.16

4. Abra la herramienta de conversión de esquemas de AWS e inicie el

asistente de nuevo proyecto.

Figura 3: Creación de un nuevo proyecto en la herramienta

de conversión de esquemas de AWS

5. Configure la base de datos de origen y pruebe la conectividad entre la

herramienta de conversión de esquemas de AWS y la base de datos de

origen. La base de datos de origen debe estar accesible desde el escritorio

para que esta herramienta funcione, así que asegúrese de que ha

configurado las opciones de red y firewall correctas.

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.Installing.html#CHAP_SchemaConversionTool.Installing.JDBCDrivers

https://forums.aws.amazon.com/forum.jspa?forumID=208


http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateInstance.html


Página 27 de 45

Figura 4: Asistente para crear un nuevo proyecto de migración de base de datos

6. En la siguiente pantalla, seleccione el esquema de la base de datos de

origen que desea convertir a Amazon Aurora.

Figura 5: Paso Seleccionar esquema del asistente de migración


Página 28 de 45

7. Ejecute el informe de evaluación de la migración de la base de datos. Este

informe proporciona información importante sobre la conversión del

esquema de la base de datos de origen a la instancia de Amazon Aurora de

destino. En él se resumen todas las tareas de conversión del esquema y se

detallan los elementos de acción de las partes del esquema que no se

pueden convertir automáticamente a Aurora. El informe incluye también

estimaciones de la cantidad de esfuerzo necesario para escribir el código

equivalente de la base de datos de destino que no se pudo convertir

automáticamente.

Haga clic en Next (Siguiente) para configurar la base de datos de destino.

Puede consultar de nuevo este informe de migración más tarde.

Figura 6: Informe de migración

8. Configure la base de datos de Amazon Aurora de destino y pruebe la

conectividad entre la herramienta de conversión de esquemas de AWS y la

base de datos de origen. La base de datos de destino debe estar accesible

desde el escritorio para que esta herramienta funcione, así que asegúrese

de que ha configurado las opciones de red y firewall correctas. Haga clic en

Finish (Finalizar) para ir a la ventana del proyecto.


Página 29 de 45

9. Cuando esté en la ventana del proyecto, ya tendrá una conexión establecida

con la base de datos de origen y de destino y estará listo para consultar el

informe detallado de evaluación y migrar el esquema.

10. En el panel de la izquierda que muestra el esquema de la base de datos de

origen, elija el objeto del esquema para el que desea crear un informe de

evaluación. Haga clic con el botón derecho en el objeto y elija Create Report

(Crear informe).

Figura 7: Creación del informe de migración

En la pestaña Summary (Resumen) se muestra la información resumida

del informe de evaluación de la migración de la base de datos. Se muestran

los elementos que se convirtieron automáticamente y los que no que se

pudieron convertir de forma automática.

Para los elementos del esquema que no se pudieron convertir

automáticamente en el motor de base de datos de destino, el resumen

incluye una estimación del esfuerzo necesario para crear un esquema

equivalente al de la base de datos de origen en la instancia de base de datos

de destino. En el informe, el tiempo estimado para convertir estos

elementos del esquema se clasifica en los siguientes grupos:

Simple: acciones que se pueden realizar en menos de una hora.

Medium: acciones que son más complejas y se pueden realizar en

el plazo de una a cuatro horas.

Significant: acciones que son muy complejas y requieren más de

cuatro horas.


Página 30 de 45

Figura 8: Informe de migración

Importante: Si va a evaluar el esfuerzo necesario para el proyecto de

migración de su base de datos, este informe de evaluación es un recurso

importante. Examínelo detalladamente para determinar qué cambios de

código se requieren en el esquema de base de datos y qué impacto podrían

tener los cambios en la funcionalidad y diseño de la aplicación.

11. El siguiente paso es convertir el esquema. El esquema convertido no se

aplica inmediatamente a la base de datos de destino, sino que se

almacena localmente hasta que aplique explícitamente el esquema

convertido a la base de datos de destino. Para convertir el esquema de la

base de datos de origen, elija el objeto del esquema que desea convertir

en el panel izquierdo del proyecto. Haga clic con el botón derecho en el

proyecto y elija Convert schema (Convertir esquema), como se

muestra en la siguiente ilustración.


Página 31 de 45

Figura 9: Convertir esquema

Esta acción añade el esquema convertido al panel derecho de la ventana del

proyecto y muestra los objetos que la herramienta de conversión de

esquemas de AWS no convirtió automáticamente.

12. Puede responder a los elementos de acción del informe de evaluación de

diferentes formas:

Añada un esquema equivalente manualmente. Puede escribir la parte del

esquema que se puede convertir automáticamente en la instancia de base

de datos de destino eligiendo Apply to database (Aplicar a base de datos)

en el panel derecho del proyecto. El esquema que se escribe en la instancia

de base de datos de destino no contendrá los elementos que se pudieron

convertir automáticamente. Estos elementos se indican en el informe de

evaluación de la migración de la base de datos.

Después de aplicar el esquema a la instancia de base de datos de destino,

puede crear manualmente el esquema en dicha instancia para los

elementos que no se pudieron convertir automáticamente. En algunos

casos, no podrá crear un esquema equivalente en la instancia de base de

datos de destino. Tal vez tenga que rediseñar una parte de la aplicación y de

la base de datos para usar la funcionalidad disponible en el motor de base

de datos para la instancia de base de datos de destino. En otros casos,

puede omitir simplemente el esquema que no se pueda convertir

automáticamente.


Página 32 de 45

Atención: Si crea manualmente el esquema en la instancia de base de

datos de destino, no elija Apply to database (Aplicar a base de datos)

hasta que haya guardado una copia del trabajo manual realizado. Al aplicar

el esquema del proyecto a la instancia de base de datos de destino se

sobrescribe el esquema del mismo nombre en dicha instancia, y perderá

todas las actualizaciones que haya añadido manualmente.

Modifique el esquema de base de datos de origen y actualice el esquema en

su proyecto. Para algunos elementos, podría ser conveniente modificar el

esquema de la base de datos de origen de manera que sea compatible con la

arquitectura de la aplicación y que pueda convertirse automáticamente en

el motor de base de datos de la instancia de base de datos de destino.

Después de actualizar el esquema de la base de datos de origen y verificar

que las actualizaciones son compatibles con la aplicación, elija Refresh

from Database (Actualizar desde la base de datos) en el panel izquierdo

del proyecto para actualizar el esquema de la base de datos de origen.

A continuación, puede convertir el esquema actualizado y generar de nuevo

el informe de evaluación de la migración de la base de datos. El elemento

de acción del esquema actualizado ya no volverá a aparecer.

13. Cuando esté listo para aplicar el esquema convertido a la instancia de

Aurora de destino, elija el elemento del esquema en el panel derecho del

proyecto. Haga clic con el botón derecho en el elemento del esquema y elija

Apply to database (Aplicar a base de datos), como se muestra en la

siguiente figura.

Figura 10: Aplicar esquema a la base de datos


Página 33 de 45

Nota: La primera vez que se aplica el esquema convertido a la instancia de

base de datos de destino, la herramienta de conversión de esquemas de

base de datos añade un esquema adicional (AWS_ORACLE_EXT

o AWS_SQLSERVER_EXT) a dicha instancia. Este esquema implementa las

funciones del esquema de la base de datos que son necesarias a la hora de

escribir el esquema convertido en la instancia de base de datos de destino.

No modifique este esquema ya que podría encontrarse resultados

imprevistos en el esquema convertido creado en la instancia de base de

datos de destino. Cuando el esquema se migre totalmente a la instancia de

base de datos de destino y ya no necesite la herramienta de conversión de

esquemas de AWS, puede eliminar el esquema AWS_ORACLE_EXT

o AWS_SQLSERVER_EXT.

La herramienta de conversión de esquemas de AWS es un complemento fácil de

usar del conjunto de herramientas de migración. Para conocer otras prácticas

recomendadas relacionadas con la herramienta de conversión de esquemas de

AWS, consulte el tema Best Practices en AWS Schema Conversion Tool User Guide.17

Migración de los datos Una vez copiado el esquema de base de datos de la base de datos de origen a la

base de datos Aurora de destino, el siguiente paso consiste en migrar los datos

reales del origen al destino. Aunque la migración de los datos se puede realizar

con distintas herramientas, le recomendamos que mueva los datos con el servicio

AWS Database Migration Service(AWS DMS), ya que además de ser fácil de usar

proporciona las características necesarias para esta tarea.

Introducción y enfoque general a AWS DMS El servicio AWS Database Migration Service (AWS DMS) permite a los clientes

migrar fácilmente bases de datos de producción a AWS con un tiempo de

inactividad mínimo. Puede mantener sus aplicaciones en ejecución mientras

migra la base de datos. Asimismo, el servicio AWS Database Migration Service

garantiza que los cambios de datos en la base de datos de origen que se

produzcan durante y después de la migración se repliquen continuamente en la

base de datos de destino. Las tareas de migración se pueden configurar en solo

unos minutos en la consola de administración de AWS. El servicio AWS Database

Migration Service puede migrar datos en ambos sentidos en plataformas

comúnmente utilizadas, como Oracle, SQL Server, MySQL, PostgreSQL, Amazon

Aurora, MariaDB y Amazon Redshift.

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_SchemaConversionTool.BestPractices.html


Página 34 de 45

El servicio admite migraciones homogéneas como de Oracle a Oracle, así como

migraciones heterogéneas entre diferentes plataformas de base de datos, como de

Oracle a Amazon Aurora o de SQL Server a MySQL. Puede realizar migraciones

puntuales o puede mantener una replicación continua entre las bases de datos sin

que el cliente tenga que instalar o configurar software complejo.

AWS DMS funciona con bases de datos instaladas localmente, que se ejecutan en

Amazon EC2 o que se ejecutan en Amazon RDS. Sin embargo, AWS DMS no

funciona en aquellas situaciones en las que la base de datos de origen y la base de

datos de destino están instaladas localmente; uno de los puntos de enlace debe

estar en AWS.

AWS DMS admite versiones específicas de Oracle, SQL Server, Amazon Aurora,

MySQL y PostgreSQL. Para conocer las versiones admitidas actualmente,

consulte el documento AWS Database Migration Service User Guide.18 Sin

embargo, este documento técnico se centra solamente en Amazon Aurora como

destino de la migración.

Métodos de migración AWS DMS ofrece tres métodos para migrar los datos:

Migrar los datos existentes. Este método crea las tablas en la base de datos de

destino, define automáticamente los metadatos necesarios en el destino y rellena

las tablas con datos de la base de datos de origen (proceso denominado también

"carga completa"). Los datos de las tablas se cargan en paralelo para mejorar la

eficacia. Las tablas solo se crean en el caso de las migraciones homogéneas,

y AWS DMS no crea automáticamente los índices secundarios. Siga leyendo

para obtener más información.

Migrar los datos existentes y replicar los cambios continuos. Este método

realiza una carga completa, como la que se ha descrito arriba, y además captura

los cambios continuos que se realizan en la base de datos de origen durante la

carga completa y los almacena en la instancia de replicación. Una vez realizada la

carga completa, los cambios almacenados se aplican a la base de datos de destino

hasta que se actualizan con la base de datos de origen. Asimismo, todos los

cambios continuos que se realizan en la base de datos de origen se siguen

replicando en la base de datos de destino para mantener ambas bases de datos

sincronizadas. Este método de migración es muy útil cuando desea realizar una

migración de la base de datos con un tiempo de inactividad mínimo.

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.html


Página 35 de 45

Replicar solo los cambios en los datos. Este método solo lee los cambios en el

archivo log de recuperación de la base de datos de origen y aplica estos cambios

a la base de datos de destino de manera continuada. Si la base de datos de destino

no está disponible, los cambios se almacenan temporalmente en la instancia de

replicación hasta que el destino vuelve a estar disponible.

Cuando AWS DMS realiza una migración de carga completa, el proceso aplica

una carga a las tablas de la base de datos de origen, lo que podría afectar al

desempeño de las aplicaciones que tienen acceso a la base de datos al mismo

tiempo. Si esto es un problema y no puede cerrar las aplicaciones durante la

migración, puede considerar los siguientes enfoques:

Ejecutar la migración en un momento en que la carga que suponen las

aplicaciones para la base de datos esté en su punto mínimo

Crear una réplica de lectura de la base de datos de origen y después realizar

la migración de AWS DMS desde dicha réplica

Procedimiento de migración El esquema general de uso de AWS DMS es el siguiente:

1. Cree una base de datos de destino.

2. Copie el esquema.

3. Cree una instancia de replicación de AWS DMS.

4. Defina los puntos de enlace de origen y destino de la base de datos.

5. Cree y ejecute una tarea de migración.

Crear la base de datos de destino

Cree el clúster de base de datos de Amazon Aurora mediante el procedimiento que

se describe en Creating an Amazon Aurora DB Cluster en Amazon RDS User

Guide.19 Debe crear la base de datos de destino en la región y con el tipo de

instancia adecuados a los requisitos del negocio. Además, para mejorar el

desempeño de la migración, verifique que la base de datos de destino no tiene una

implementación Multi-AZ habilitada; podrá habilitarla cuando termine la carga.



Página 36 de 45

Copiar el esquema

Asimismo, debe crear el esquema en esta base de datos de destino. AWS DMS

admite la migración básica del esquema, incluida la creación de tablas y claves

principales. Sin embargo, AWS DMS no crea automáticamente índices secundarios,

claves externas, procedimientos almacenados, cuentas de usuario, etc., en la base de

datos de destino. Para obtener información detallada sobre la migración del

esquema completo, consulte la sección Migración del esquema de base de datos.

Crear una instancia de replicación de AWS DMS

Para poder usar el servicio AWS DMS, debe crear una instancia de replicación de

AWS DMS que se ejecute en su VPC. Esta instancia lee los datos de la base de

datos de origen, realiza las correspondencias de tablas especificadas y escribe los

datos en la base de datos de destino. En general, el uso de un tamaño de instancia

de replicación mayor agiliza la migración de la base de datos (si bien la migración

puede verse restringida por otros factores como la capacidad de las bases de

datos de origen y destino, la latencia de la conexión, etc.). Asimismo, la instancia

de replicación se puede detener una vez realizada la migración de la base de datos.

Figura 11: AWS Database Migration Service

AWS DMS admite actualmente las clases de instancias T2 y C4 para las instancias

de replicación. Las clases de instancias T2 son instancias estándar de bajo costo

diseñadas para proporcionar un nivel básico de desempeño de la CPU con la

capacidad de ampliar ese nivel básico. Estas instancias son adecuadas para

desarrollar, configurar y probar el proceso de migración de la base de datos, así

como para las tareas periódicas de migración de datos que puedan beneficiarse

de la capacidad de ampliación de la velocidad de la CPU. Las clases de instancias

C4 se han diseñado para proporcionar el mayor nivel de desempeño del

procesador y conseguir la mayor velocidad de paquetes por segundo (PPS),

reducir la inestabilidad de la red y reducir la latencia de la red. Debería usar

clases de instancias C4 si va a migrar bases de datos grandes y desea acortar el

tiempo de migración.


Página 37 de 45

Normalmente, una carga completa no requiere una cantidad importante de

almacenamiento de la instancia en la instancia de replicación de AWS DMS. Sin

embargo, si va a realizar la replicación junto con la carga completa, los cambios

en la base de datos de origen se almacenan en la instancia de replicación de AWS

DMS mientras se realiza la carga completa. Por tanto, si va a migrar una base de

datos de origen muy grande que recibe además muchas actualizaciones mientras

la migración está en curso, se podría consumir una cantidad importante de

almacenamiento de la instancia. La familia de instancias C4 incluye 100 GB de

almacenamiento de la instancia y la familia de instancias T2 incluye 50 GB.

Normalmente, estas cantidades de almacenamiento deberían ser más que

suficientes para la mayoría de los escenarios de migración.

Además, en casos extremos en los que se vayan a migrar bases de datos muy

grandes con velocidades de transacción muy altas y con la replicación habilitada,

es posible que la replicación de AWS DMS no se pueda realizar a tiempo. En esta

situación, podría ser necesario detener los cambios en la base de datos de origen

durante algunos minutos para que se realice la replicación antes de redirigir la

aplicación a la base de datos Aurora de destino.

Figura 12: Página de creación de la instancia de

replicación en la consola de AWS DMS


Página 38 de 45

Definir los puntos de enlace de origen y destino de la base de datos

La instancia de replicación utiliza un punto de enlace de la base de datos para

conectarse a una base de datos. Para realizar una migración de base de datos,

debe crear tanto un punto de enlace con la base de datos de origen como uno con

la destino. Los puntos de enlace de base de datos especificados pueden ser

locales, ejecutarse en Amazon EC2 o ejecutarse en Amazon RDS, pero el origen

y el destino no pueden estar instalados localmente.

Es absolutamente recomendable que pruebe la conexión con el punto de enlace

de base de datos una vez definido. La misma página usada para crear un punto de

enlace de base de datos se puede usar para probarlo, como se explica más

adelante en este documento.

Nota: Si tiene restricciones de clave externa en el esquema de origen, cuando cree

el punto de enlace de destino tendrá que especificar lo siguiente para Extra

connection attributes (Atributos adicionales de conexión) en la sección

Advanced (Avanzadas):

initstmt=SET FOREIGN_KEY_CHECKS=0

De esta manera, deshabilitará las comprobaciones de clave externa mientras se

cargan las tablas de destino. Esto a su vez impide que se interrumpa la carga

debido a comprobaciones de clave externa fallidas en tablas cargadas

parcialmente.


Página 39 de 45

Figura 13: Página de creación del punto de enlace

de la base de datos en la consola de AWS DMS

Crear y ejecutar una tarea de migración Ahora que ha creado y probado el punto de enlace de la base de datos de origen y de la base de datos de destino, puede crear una tarea para que realice la migración de datos. Cuando cree una tarea, tendrá que especificar la instancia de replicación que ha creado, el tipo de método de migración de la base de datos (descrito anteriormente), el punto de enlace de la base de datos de origen y el punto de enlace de la base de datos de destino para el clúster de base de datos de Amazon Aurora.

Además, en Task Settings (Configuración de la tarea), si ya ha creado el esquema completo en la base de datos de destino, debería cambiar Target table preparation mode (Modo de preparación de la tabla de destino) a Do nothing (No hacer nada) en lugar de usar el valor de Drop tables on target (Borrar tablas en el destino). Este último valor podría hacer que se perdieran algunos aspectos de la definición del esquema como las restricciones de clave externa al borrar y volver a crear las tablas.


Página 40 de 45

Cuando cree una tarea, puede crear las correspondencias de tablas que

especifican el esquema de origen junto con las tablas correspondientes que se van

a migrar al punto de enlace de destino. El método de correspondencia

predeterminado migra todas las tablas de origen a las tablas de destino del

mismo nombre si existen. En caso contrario, crea las tablas de origen en el

destino (en función de la configuración de la tarea). Asimismo, puede crear

correspondencias personalizadas (mediante un archivo JSON) si solo desea

migrar algunas tablas o si desea tener mayor control sobre el proceso de

correspondencia de campos y tablas. También puede elegir migrar solamente un

esquema o todos los esquemas del punto de enlace de origen.

Figura 14: Página de creación de la tarea de la consola de AWS DMS

Puede usar la consola de administración de AWS para monitorizar el progreso de

las tareas del servicio AWS Database Migration Service (AWS DMS). También

puede monitorizar los recursos y la conexión de red utilizados. La consola de

AWS DMS muestra estadísticas básicas para cada tarea, como el estado de la

tarea, el porcentaje completado, el tiempo transcurrido y las estadísticas de las

tablas, como se muestra en la siguiente imagen.


Página 41 de 45

Asimismo, puede seleccionar una tarea y mostrar sus métricas de desempeño,

incluida la velocidad, los registros migrados por segundo, el uso de disco

y memoria y la latencia.

Figura 15: Estado de la tarea en la consola de AWS DMS

Pruebas y cambio Una vez migrados correctamente el esquema y los datos de la base de datos de

origen a Amazon Aurora, ahora está listo para realizar una prueba completa del

proceso de migración. La estrategia de pruebas debe ajustarse después de cada

migración de prueba, y el plan de migración final debe incluir un plan de pruebas

que garantice la comprobación adecuada de la base de datos migrada.

Comprobación de la migración

Clase de prueba Finalidad

Pruebas básicas de

aceptación

Estas pruebas previas al cambio deben ejecutarse automáticamente al

finalizar el proceso de migración de los datos. Su objetivo principal es verificar

si la migración de los datos se ha realizado correctamente. A continuación se

incluyen algunos resultados comunes de estas pruebas:

• Número total de elementos procesados

• Número total de elementos importados

• Número total de elementos omitidos

• Número total de advertencias

• Número total de errores

Si alguno de estos totales registrados por las pruebas se desvían de los

valores previstos, significa que la migración no se realizó correctamente

y que deben solucionarse los problemas antes de continuar con el

siguiente paso del proceso o la siguiente ronda de pruebas.

Pruebas funcionales Estas pruebas previas al cambio sirven para comprobar la funcionalidad

de la aplicación o aplicaciones utilizando Aurora para el almacenamiento

de datos. Incluyen una combinación de pruebas automáticas y manuales.

El objetivo principal de las pruebas funcionales es identificar los problemas

en la aplicación causados por la migración de los datos a Aurora.

Pruebas no funcionales Estas pruebas previas al cambio evalúan las características no funcionales de

la aplicación, como el desempeño con varios niveles de carga.


Página 42 de 45

Clase de prueba Finalidad

Pruebas de aceptación del

usuario

Estas pruebas posteriores al cambio deben ejecutarlas los usuarios

finales de la aplicación una vez que se han migrado definitivamente los

datos y se ha realizado el cambio. El objetivo de estas pruebas es que los

usuarios finales decidan si la aplicación sirve para satisfacer su función

principal en la organización.

Cambio Una vez completada la migración final y las pruebas, es el momento de apuntar la

aplicación a la base de datos de Amazon Aurora. Esta fase de migración recibe el

nombre de cambio. Si la fase de planificación y pruebas se ha realizado

correctamente, el cambio no debería dar lugar a problemas imprevistos.

Acciones previas al cambio

Elija un período de cambio: identifique un plazo de tiempo en el que pueda

realizar el cambio a la nueva base de datos con la mínima interrupción del

negocio. Normalmente, debería elegir un período de baja actividad de la

base de datos (generalmente, por la noche o los fines de semana).

Asegúrese de que se capturan los cambios: si se ha usado un enfoque de

migración con un tiempo de inactividad prácticamente nulo para replicar

los cambios de la base de datos de origen a la de destino, asegúrese de que

se recogen todos los cambios de la base de datos y de que la base de datos

de destino no presenta un retraso importante con respecto a la base de

datos de origen.

Prepare scripts para crear los cambios de configuración de la aplicación:

para realizar el cambio, necesita modificar los detalles de conexión de la

base de datos en los archivos de configuración de la aplicación. Las

aplicaciones grandes y complejas pueden requerir actualizaciones de los

detalles de conexión en varios lugares. Asegúrese de que tiene los scripts

necesarios listos para actualizar la configuración de conexión rápidamente

y de manera fiable.

Detenga la aplicación: detenga los procesos de la aplicación en la base de

datos de origen y ponga esta base de datos en modo de solo lectura para

que no se realicen nuevas operaciones de escritura. Si los cambios de la

base de datos de origen no están totalmente recogidos en la base de datos

de destino, espere algún tiempo mientras estos cambios se propagan

totalmente a la base de datos de destino.


Página 43 de 45

Ejecute las pruebas previas al cambio: ejecute las pruebas automatizadas

previas al cambio para asegurarse de que la migración de los datos se ha

realizado correctamente.

Cambio

Ejecute el cambio: si las comprobaciones previas al cambio se han realizado

correctamente, ahora puede apuntar la aplicación a Amazon Aurora.

Ejecute los scripts creados en la fase previa al cambio para cambiar la

configuración de la aplicación de forma que apunte a la nueva base de

datos Aurora.

Inicie la aplicación: en este punto, puede iniciar la aplicación. Si puede

impedir que los usuarios tengan acceso a la aplicación mientras esta se

ejecuta, hágalo hasta que haya ejecutado las comprobaciones previas al

cambio.

Comprobaciones posteriores al cambio

Ejecute las pruebas posteriores al cambio: ejecute casos de prueba

automáticos o manuales predefinidos para asegurarse de que la aplicación

funciona según lo previsto con la nueva base de datos. Es una buena idea

probar primero la funcionalidad de solo lectura de la base de datos antes de

ejecutar pruebas que escriban en la base de datos.

Conceda a los usuarios acceso a la aplicación para que la examinen

detalladamente: si los casos de prueba se han ejecutado correctamente,

puede otorgar a los usuarios acceso a la aplicación para completar el

proceso de migración. En este momento deben examinarse detenidamente

tanto la aplicación como la base de datos.

Conclusión Amazon Aurora es una base de datos de clase empresarial de alto desempeño y

alta disponibilidad diseñada para la nube. El uso de Amazon Aurora puede

mejorar el desempeño y la disponibilidad con respecto a otras bases de datos de

código abierto, a un precio menor que el de la mayoría de las bases de datos

comerciales. En este documento se proponen estrategias para identificar el mejor

método de migrar bases de datos a Amazon Aurora y se describen los

procedimientos para planificar y ejecutar estas migraciones. En concreto, se

recomiendan el servicio AWS Database Migration Service(AWS DMS) y la

herramienta de conversión de esquemas de AWS para los escenarios de

migraciones heterogéneas. Estas eficaces herramientas pueden reducir

considerablemente el costo y la complejidad de las migraciones de bases de datos.


Página 44 de 45

Colaboradores En este documento han participado las siguientes personas y organizaciones:

Puneet Agarwal, arquitecto de soluciones, Amazon Web Services

Scott Williams, arquitecto de soluciones, Amazon Web Services

Documentación adicional Para obtener ayuda adicional, consulte las siguientes fuentes (pueden estar en inglés):

Detalles del producto Amazon Aurora

Preguntas más frecuentes sobre Amazon Aurora

Servicio Amazon Database Migration

Preguntas más frecuentes sobre el servicio Amazon Database Migration

Notas

1 https://aws.amazon.com/rds/aurora/

2 http://aws.amazon.com/rds/aurora/pricing/

3 https://d0.awsstatic.com/product-

marketing/Aurora/Aurora_Export_Import_Best_Practices_v1-3.pdf

4 http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/

Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication

5 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/

Aurora.Migrate.html#USER_ImportAurora.PreImport

6 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html

7 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html

8 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/

Aurora.Migrate.html#USER_ImportAuroraCluster.Console

9 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Connect.html

http://aws.amazon.com/rds/aurora/details/

http://aws.amazon.com/rds/aurora/faqs/

https://aws.amazon.com/dms/

https://aws.amazon.com/dms/faqs/

https://aws.amazon.com/rds/aurora/

http://aws.amazon.com/rds/aurora/pricing/



http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/%20Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication

http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/%20Aurora.Replication.html#Aurora.Overview.Replication.MySQLReplication

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/%20Aurora.Migrate.html#USER_ImportAurora.PreImport

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/%20Aurora.Migrate.html#USER_ImportAurora.PreImport

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/%20Aurora.Migrate.html#USER_ImportAuroraCluster.Console

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/%20Aurora.Migrate.html#USER_ImportAuroraCluster.Console

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Connect.html


Página 45 de 45

10 https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html

11 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/Welcome.html

12 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/

CHAP_SchemaConversionTool.GettingStarted.html


CHAP_SchemaConversionTool.Installing.html

14 http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide

/CHAP_SchemaConversionTool.Installing.html#CHAP_SchemaConversionTool.Installing

.JDBCDrivers

15 https://forums.aws.amazon.com/forum.jspa?forumID=208

16 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateInstance.html


CHAP_SchemaConversionTool.BestPractices.html

18 http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.html

19 http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.CreateInstance.html



http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.GettingStarted.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.GettingStarted.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.Installing.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.Installing.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide%20/CHAP_SchemaConversionTool.Installing.html#CHAP_SchemaConversionTool.Installing.JDBCDrivers





http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.BestPractices.html

http://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/%20CHAP_SchemaConversionTool.BestPractices.html

http://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.html


Documents

Migración de sus bases de datos a Amazon Aurorad0.awsstatic.com/...Databases_to_Amazon_Aurora_ES.pdf · compatible con MySQL. Amazon Aurora es una base de datos nativa en la nube