Cuestiones importantes antes de la migración de Aurora a Cloud SQL para MySQL

Aurora utiliza el conjunto de caracteres predeterminado latin1 (hasta la versión 5.7 de MySQL). Es distinta de la configuración predeterminada de Cloud SQL para bases de datos, tablas, procedimientos almacenados y funciones, que se crean con utf8 como el conjunto de caracteres predeterminado durante una migración.Esta situación puede ocasionar problemas de rendimiento.

Por ejemplo, un usuario puede acabar en una situación en la que las tablas se creen con el conjunto de caracteres latin1 y los procedimientos o funciones almacenados se creen con el conjunto de caracteres utf8 predeterminado de Cloud SQL. En estos casos, si la función o el procedimiento almacenado espera variables como parámetros utf8 y compara esa variable con el valor de la columna, que está en el conjunto de caracteres latin1, tendrá problemas de rendimiento por la comparación de dos conjuntos de caracteres y recopilaciones diferentes. 

Puedes comprobar el conjunto de caracteres de las rutinas con el siguiente comando:

mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES;

Si usabas el conjunto de caracteres predeterminado en Aurora (hasta la versión 5.7), que es latin1, el conjunto de caracteres predeterminado debe cambiarse de utf8 a latin1 en Cloud SQL antes de importar los datos.

Otra solución podría ser cambiar todo a utf8. En este caso, los usuarios deben probar la aplicación y el conjunto de datos completos, ya que los cambios en el conjunto de caracteres pueden provocar representaciones de datos inesperadas.

Los usuarios pueden editar este ajuste en la instancia de Cloud SQL, en la sección Flag, tal como se muestra a continuación.

Aurora MySQL 5.7 tiene muchas intercalaciones (por ejemplo, utf8mb4_0900_ai_ci para el conjunto de caracteres utf8mb4) que solo están disponibles en Cloud SQL para MySQL 8.0. Si usas estas intercalaciones e importas los datos en Cloud SQL para MySQL 5.7, aparecerá un mensaje de error similar a "Error 'Conjunto de caracteres '#255' no es un conjunto de caracteres compilado".

La solución es cambiar esas intercalaciones a intercalaciones disponibles en la versión 5.7 de MySQL.

A diferencia de Aurora, Cloud SQL para MySQL no es compatible con el motor MyISAM. Es recomendable convertir todas las tablas en InnoDB antes de iniciar la migración de Aurora a Cloud SQL. 

Si hay una tabla en un buscador que no sea InnoDB, los usuarios pueden cambiar el buscador de la tabla con el comando "ALTER":

mysql> alter table table_1 engine='Innodb' ;

Consulta correcta, 0 filas afectadas (2,89 segundos)

Records: 0 Duplicates: 0 Warnings: 0

Nota: El tiempo de consulta depende del tamaño de la tabla y puede bloquear otras operaciones en la misma tabla. También puedes usar herramientas online de cambio de esquema, como pt-online-schema-change o gh-ost, para modificar la tabla sin bloquear otras operaciones.

En Aurora, los usuarios pueden configurar varios lectores detrás de un solo endpoint; sin embargo, los usuarios de Cloud SQL para MySQL no disponen de esta función desde el primer momento. Cada réplica de lectura en Cloud SQL para MySQL tiene su propia IP y los usuarios deben utilizar algo parecido a ProxySQL para dividir el tráfico entre varias instancias de réplica de lectura.

Aquí tienes una guía en la que se muestra cómo utilizar el proxy SQL para enrutar el tráfico entre varias réplicas de lectura.

El búfer de cambio es una estructura de datos especial que almacena en caché los cambios en las páginas de índice secundarias cuando no están en el grupo de búfer y se fusionan más tarde cuando se cargan en otras páginas. Para obtener más información, consulta Cambiar el búfer.

Cuando la carga de trabajo tenga muchas escrituras en las tablas con índices secundarios, Aurora puede tener un rendimiento más lento que Cloud SQL para MySQL, que utiliza la función de búfer de cambio InnoDB predeterminada para posponer las actualizaciones. Los usuarios deben comparar el rendimiento con la carga de trabajo de su aplicación.

La caché de consulta almacena el comando seleccionado junto con su resultado en una capa de almacenamiento intermedia. Si se recibe una instrucción idéntica más adelante, el servidor comprueba y obtiene los resultados de la caché de consultas en lugar de volver a ejecutar el comando. La caché de consultas se comparte entre sesiones, por lo que todas las sesiones pueden beneficiarse de los resultados almacenados en caché mediante instrucciones ya ejecutadas de otras sesiones. Obtén más información sobre la caché de consultas.

Aurora habilita la caché de consultas de forma predeterminada. Sin embargo, la comunidad de MySQL ha inhabilitado la caché de consultas en la versión 5.7 y la ha eliminado por completo en la versión 8.0; Cloud SQL para MySQL también lo ha hecho. Si tus consultas se basan en la función de caché de consultas de Aurora, el rendimiento puede variar en Cloud SQL de MySQL. Se recomienda probar el rendimiento de las consultas en Cloud SQL para MySQL comparando el tiempo de ejecución con Aurora.

En el caso de las réplicas de lectura en una región, Aurora utiliza el concepto de volumen de clúster, que tiene copias de los datos en tres zonas de disponibilidad de esa región. El intervalo de replicación de Aurora suele ser muy inferior a 100 milisegundos, ya que la instancia principal y las réplicas del mismo clúster de bases de datos ven los datos del volumen de clústeres como un único volumen lógico. Además, en la réplica de lectura entre regiones, Aurora utiliza la sincronización de datos basada en discos en todas las regiones, en lugar de la replicación basada en registros binarios.

En resumen, la capa de almacenamiento de Aurora gestiona la replicación, mientras que en Cloud SQL para MySQL es el mecanismo estándar de replicación para transferir el registro binario a la instancia de la réplica. Después, se vuelven a reproducir instancias de MySQL de réplica. Puedes mejorar el rendimiento de la replicación configurando la replicación en paralelo en Cloud SQL. Consulta cómo configurar la replicación en paralelo.

Aunque el retraso de replicación depende de la cantidad de datos que cambian la aplicación y la red entre las instancias principal y de réplica, la mayoría de las aplicaciones funcionan correctamente sin retraso visible tanto en Aurora como en Cloud SQL para MySQL. Sin embargo, si la aplicación pesa mucho y lee desde las réplicas, te sugerimos que compares el retraso de replicación en AWS Aurora y CloudSQL para MySQL antes de la migración.

Cloud SQL para MySQL utiliza la replicación GTID, a diferencia de AWS Aurora, que utiliza la sincronización de datos basada en discos. Los usuarios deben comprobar los límites del GTID que se indican más adelante antes de la migración y hacer los cambios necesarios en sus aplicaciones si el flujo de trabajo de aplicaciones depende de cualquiera de esas funciones:

• CREATE TABLE ... No se permiten las instrucciones SELECT al usar la replicación basada en GTID.
• Las instrucciones CREATE TEMPORARY TABLE y DROP TEMPORARY TABLE no se admiten en transacciones, procedimientos, funciones ni activadores. Es posible utilizar estas instrucciones con GTIDs habilitados, pero solo fuera de cualquier transacción y solo con autocommit=1.

Consulta más información sobre las limitaciones basadas en GTID en el artículo Limitaciones en GTID.