Migración de datos de un entorno local de MySQL a Azure Database for MySQL: Test Plans
El desarrollo de planes de prueba completos es fundamental para migrar bases de datos MySQL desde entornos locales a Azure Database for MySQL. En este artículo se proporciona una visión detallada de los componentes esenciales de los planes de prueba eficaces, lo que garantiza que el proceso de migración se desarrolle sin problemas y con éxito. Puede mitigar los riesgos mediante la esquematización de estrategias de prueba clave, la identificación de posibles problemas, el establecimiento de criterios de validación claros y la garantía de que las bases de datos migradas funcionan de forma óptima en el entorno de Azure. Si se centra en pruebas funcionales, pruebas de rendimiento o pruebas de seguridad, esta guía le proporciona los conocimientos y los procedimientos recomendados necesarios para crear planes de prueba sólidos que admitan una migración sin problemas.
Requisitos previos
Migración de una instancia local de MySQL a Azure Database for MySQL: métodos de migración
Información general
WWI creó un plan de prueba que incluía un conjunto de tareas de IT y de negocio. Las migraciones correctas requieren que se ejecuten todas las pruebas.
Pruebas:
Asegúrese de que la base de datos migrada es coherente con las tablas locales (los mismos recuentos de registros y resultados de consultas).
Asegúrese de que el rendimiento es aceptable (debe coincidir con el mismo rendimiento que si se estuviera ejecutando en el entorno local).
Asegúrese de que el rendimiento de las consultas de destino cumple los requisitos indicados.
Asegúrese de que la conectividad entre la red local y la red de Azure es aceptable.
Asegúrese de que todas las aplicaciones y usuarios identificados pueden conectarse a la instancia de datos migrada.
WWI ha identificado un fin de semana de migración y una ventana de tiempo que se inició a las 22:00 y finalizó a las 02:00, hora del Pacífico. Si la migración no se completó antes del objetivo de las 02:00 (objetivo de tiempo de inactividad de 4 horas) con todas las pruebas superadas, se iniciaron los procedimientos de reversión. Se documentaron problemas para futuros intentos de migración. Todas las ventanas de migraciones se reenviaron y reprogramaron en función de escalas de tiempo empresariales aceptables.
Consultas de ejemplo
Se ejecutaron una serie de consultas en el origen y el destino para comprobar que la migración de la base de datos se ha ejecutado correctamente. Las siguientes consultas y scripts ayudan a determinar si las acciones de migración han movido todos los objetos de base de datos necesarios del origen al destino.
Filas de la tabla
Puede usar esta consulta para obtener todas las tablas y un recuento estimado de filas:
SELECT SUM(TABLE_ROWS)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '{SchemaName}';
Nota
La tabla INFORMATION_SCHEMA proporciona un conjunto estimado de valores entre las tablas. Para obtener una vista más precisa de las métricas, como el tamaño de la tabla, aumente el tamaño del ejemplo de página con el parámetro de servidor innodb_stats_transient_sample_pages. Aumentar este valor de servidor obliga a analizar más páginas y proporcionará resultados más precisos.
Ejecute la instrucción SQL count(*) en cada tabla para obtener un recuento preciso de filas. La ejecución de este comando puede tardar una gran cantidad de tiempo en tablas grandes. El siguiente script genera un conjunto de instrucciones SQL que se pueden ejecutar para obtener los recuentos exactos:
SELECT CONCAT(
'SELECT "',
table_name,
'" AS table_name, COUNT(*) AS exact_row_count FROM `',
table_schema,
'`.`',
table_name,
'` UNION '
)
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = '**my_schema**';
Fragmentación de tablas
Es probable que las tablas de datos sigan creciendo con el uso continuado de la aplicación. En algunos casos, es posible que los datos no crezcan, pero cambian constantemente a través de eliminaciones y actualizaciones. Si es así, es posible que haya mucha fragmentación en los archivos de base de datos. La instrucción OPTIMIZE TABLE de MySQL puede reducir las necesidades de espacio de almacenamiento físico y mejorar la eficacia de E/S.
Puede optimizar las tablas de MySQL ejecutando lo siguiente:
optimize table TABLE_NAME
Objetos de base de datos
Use la consulta siguiente para asegurarse de que se tienen en cuenta todos los demás objetos de base de datos. Aunque estas consultas pueden calcular los recuentos de filas de la tabla, es posible que no tengan en cuenta la versión del objeto de base de datos concreto. Por ejemplo, aunque podría existir un procedimiento almacenado, podría haber cambiado entre el inicio y el final de la migración. Se recomienda inmovilizar el desarrollo de objetos de base de datos durante la migración.
Usuarios
SELECT DISTINCT
USER
FROM
mysql.user
WHERE
user <> '' order by user
Índices
SELECT DISTINCT
INDEX_NAME
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Restricciones
SELECT DISTINCT
CONSTRAINT_NAME
FROM
information_schema.TABLE_CONSTRAINTS
WHERE
CONSTRAINT_SCHEMA = '{SchemaName}'
Vistas
SELECT
TABLE_NAME
FROM
information_schema.VIEWS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Procedimientos almacenados
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'FUNCTION' and
ROUTINE_SCHEMA = '{SchemaName}'
Funciones
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'PROCEDURE' and
ROUTINE_SCHEMA = '{SchemaName}'
Eventos
SELECT
EVENT_NAME
FROM
INFORMATION_SCHEMA.EVENTS
WHERE
EVENT_SCHEMA = '{SchemaName}'
Estrategias de reversión
Las consultas anteriores proporcionan una lista de nombres de objetos y recuentos usados en una decisión de reversión. Los usuarios de la migración pueden realizar el primer paso de comprobación de objetos comprobando los recuentos de los objetos de origen y de destino. Una discrepancia en los recuentos de objetos podría no significar necesariamente que se necesite una reversión. La realización de una evaluación detallada podría indicar que la diferencia es leve y fácil de recuperar. La solución podría ser una migración manual de algunos objetos con errores. Por ejemplo, si se migraron todas las tablas y filas de datos y solo se omitieron algunas de las funciones, corrija esos objetos con errores y finalice la migración. Si la base de datos es relativamente pequeña, puede borrarse la instancia de Azure Database for MySQL y reiniciar la migración. Es posible que las bases de datos de gran tamaño necesiten más tiempo del que está disponible en la ventana de migración para determinar los objetos que faltan. La migración debe detenerse y revertirse.
La identificación de los objetos de la base de datos que faltan debe producirse rápidamente durante una ventana de migración. Recuentos cada minuto. Una opción podría ser exportar los nombres de objetos del entorno a un archivo y usar una herramienta de comparación de datos para identificar rápidamente los objetos que faltan. Otra opción podría ser exportar los nombres de objetos de la base de datos de origen e importar los datos a una tabla temporal del entorno de base de datos de destino. Compare los datos mediante una instrucción SQL con script y probada. La precisión y la velocidad de comprobación de los datos son fundamentales para el proceso de migración. No se dependa de leer y comprobar manualmente una larga lista de objetos de base de datos durante una ventana de migración. La posibilidad de errores humanos es demasiado grande. Sería mejor si administra por excepciones con herramientas.
Escenario de WWI
El responsable de información de WWI recibió un informe de confirmación de que todos los objetos de base de datos se migraron de la base de datos local a la instancia de Azure Database for MySQL. El equipo de base de datos ejecutó las consultas anteriores en la base de datos antes del comienzo de la migración y guardó todos los resultados en una hoja de cálculo.
La información del esquema de la base de datos de origen se usó para comprobar la fidelidad del objeto de migración de destino.
Lista de comprobación de planes de prueba
Tenga consultas de prueba con script, probadas y listas para ejecutarse.
Debe saber cuánto tiempo pueden tardar en ejecutarse las consultas de prueba y convertirlas en parte de la escala de tiempo de migración documentada.
Tenga una estrategia de mitigación y reversión lista para los diferentes resultados posibles.
Tenga una escala de tiempo bien definida de eventos para la migración.