Puedes migrar las bases de datos de MySQL a Cloud SQL usando los archivos de copia de seguridad de base de datos físicos que se crearon con la utilidad Percona XtraBackup para MySQL. Con la migración de archivos de copia de seguridad físicos, obtienes velocidades mejoradas de restauración de datos en comparación con las migraciones que usan archivos de copia de seguridad lógicos. Por ese motivo, son una excelente opción para trasladar bases de datos grandes que contienen varios terabytes de datos.
En ese flujo de migración, se incluyen las siguientes tareas:
Crear una copia de seguridad de tu instancia de MySQL de origen y preparar los archivos de copia de seguridad físicos con la utilidad Percona XtraBackup para MySQL
Subir tus archivos de copia de seguridad a un bucket de Cloud Storage.
Crear y ejecutar trabajos de migración en Database Migration Service.
Según tu situación, puedes crear la instancia de destino por tu cuenta o hacer que Database Migration Service la cree por ti como parte del flujo de creación del trabajo de migración. Para obtener más información, consulta el paso Configura y ejecuta el trabajo de migración.
Promocionar el trabajo de migración después de que los datos se migran por completo.
Migraciones sin conexión
En esta guía, se describen situaciones de migración para entornos en los que puedes garantizar la conectividad de red entre las instancias de base de datos de origen y de destino.
Es posible realizar una migración de prueba en la que Database Migration Service no se conecte a tu instancia de origen. En cambio, Database Migration Service solo lee los archivos de copia de seguridad que subes al bucket de Cloud Storage y replica su contenido en el destino de Cloud SQL para MySQL. No se recomienda un flujo de migración que no use conectividad de red para las migraciones de producción, ya que Database Migration Service no puede realizar la validación de datos por completo.
Si quieres intentar realizar una tarea de migración sin conexión, ajusta los procedimientos de la siguiente manera:
Cuando crees el perfil de conexión de origen, usa una dirección IP, un puerto, un nombre de usuario y una contraseña de muestra. Por ejemplo:
- IP:
0.0.0.0
- Puerto
1234
- Nombre de usuario de migración:
test-user
- IP:
Cuando crees el trabajo de migración, haz lo siguiente:
- Usa la conectividad de IP pública. No configures ninguna opción de red adicional.
- Usa el tipo de trabajo de migración único.
Limitaciones
En esta sección, se enumeran las limitaciones de las migraciones que usan archivos físicos de Percona XtraBackup:
No se admite la migración a MySQL 5.6 o 8.4 con un archivo de copia de seguridad física. Consulta Limitaciones conocidas.
Consideraciones sobre la compatibilidad entre versiones:
- Solo puedes migrar dentro de la misma versión principal de la base de datos, por ejemplo, de MySQL 8.0.30 a MySQL 8.0.35 o de MySQL 5.7.0 a MySQL 5.7.1.
No puedes migrar de MySQL 5.7 a MySQL 8.0.
La migración no es compatible con versiones principales o secundarias de bases de datos anteriores. Por ejemplo, no puedes migrar de MySQL 8.0 a 5.7 ni de MySQL 8.0.36 a 8.0.16.
Debes usar Percona XtraBackup para hacer una copia de seguridad de los datos en el bucket de Cloud Storage. No se admiten otras utilidades de copias de seguridad.
La migración de bases de datos desde un archivo físico de Percona XtraBackup solo es compatible con las bases de datos locales de MySQL o las bases de datos de MySQL autoadministradas de VM. No se admite la migración desde Amazon Aurora o MySQL en las bases de datos de Amazon RDS.
Solo puedes migrar desde una copia de seguridad completa. No se admiten otros tipos de copia de seguridad, como las copias de seguridad incrementales o parciales.
La migración de la base de datos no incluye usuarios ni privilegios de la base de datos.
Debes configurar el formato de registro binario como
ROW
. Si configuras el registro binario en cualquier otro formato, comoSTATEMENT
oMIXED
, la replicación podría fallar.No se admite ninguna base de datos con una tabla de más de 5 TB.
Cloud Storage limita el tamaño de un archivo que puedes subir a un bucket a 5 TB. Si tu archivo físico de Percona XtraBackup supera los 5 TB, debes dividir el archivo de copia de seguridad en archivos más pequeños.
Asegúrate de subir los archivos de copia de seguridad a una carpeta exclusiva de Cloud Storage que no tenga otros archivos.
Debes configurar el parámetro
innodb_data_file_path
con un solo archivo de datos que use el nombre de archivo de datos predeterminadoibdata1
. Si tu base de datos está configurada con dos archivos de datos o tiene un archivo de datos con un nombre diferente, no puedes migrar la base de datos mediante un archivo físico de Percona XtraBackup. Por ejemplo, una base de datos configurada coninnodb_data_file_path=ibdata01:50M:autoextend
no es compatible con la migración.El parámetro
innodb_page_size
en tu instancia de origen debe configurarse con el valor predeterminado16384
.No puedes migrar complementos desde tu base de datos externa.
Costos
Para las migraciones homogéneas a Cloud SQL, Database Migration Service se ofrece sin cargo adicional. Sin embargo, los precios de Cloud SQL y Cloud Storage se aplican a los cargos de red, así como a las entidades de Cloud SQL y Cloud Storage creadas con fines de migración.
En este documento, usarás los siguientes componentes facturables de Google Cloud:
- Cloud Storage
- Cloud SQL
Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.
Antes de comenzar
- Considera en qué región deseas crear la base de datos de destino. Database Migration Service es un producto completamente regional, lo que significa que todas las entidades relacionadas con tu migración (perfiles de conexión de origen y destino, trabajos de migración, bases de datos de destino y buckets de almacenamiento) se deben guardar en una sola región.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Enable the Database Migration Service, Compute Engine, and Cloud SQL Admin APIs.
Roles obligatorios
Para obtener los permisos que necesitas para realizar migraciones homogéneas de MySQL con archivos de copia de seguridad físicos, pídele a tu administrador que te otorgue los siguientes roles de IAM en tu proyecto:
-
Cuenta de usuario que realiza la migración:
-
Administrador de Database Migration (
roles/datamigration.admin
) -
Visualizador de objetos de almacenamiento (
roles/storage.objectViewer
) -
Editor de Cloud SQL (
roles/cloudsql.editor
)
-
Administrador de Database Migration (
Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.
Estos roles predefinidos contienen los permisos necesarios para realizar migraciones homogéneas de MySQL con archivos de copia de seguridad físicos. Para ver los permisos exactos que son necesarios, expande la sección Permisos requeridos:
Permisos necesarios
Se requieren los siguientes permisos para realizar migraciones homogéneas de MySQL con archivos de copia de seguridad físicos:
-
Cuenta de usuario que realiza la migración:
-
datamigration.*
-
resourcemanager.projects.get
-
resourcemanager.projects.list
-
cloudsql.instances.create
-
cloudsql.instances.get
-
cloudsql.instances.list
-
compute.machineTypes.list
-
compute.machineTypes.get
-
compute.projects.get
-
storage.buckets.create
-
storage.buckets.list
-
También puedes obtener estos permisos con roles personalizados o con otros roles predefinidos.
Paso 1: Ten en cuenta los requisitos de conectividad de red
Existen diferentes métodos de red que puedes usar para configurar la conectividad entre tu fuente y las instancias de destino de Cloud SQL. Según el método que uses, es posible que debas realizar pasos adicionales durante el proceso de migración.
Considera qué método de conectividad es adecuado para tu caso antes de continuar con los siguientes pasos, ya que tu elección podría afectar la configuración que debes usar. Para obtener más información, consulta Configura la conectividad.
Paso 2: Prepara los datos de origen
Para preparar los datos para la migración, realiza los siguientes pasos:
- Instala la versión correcta de la utilidad Percona XtraBackup en tu
instancia de origen. Debes usar una versión de Percona XtraBackup que sea igual o posterior a la versión de tu instancia de origen.
Para obtener más información, consulta la
comparación de la versión del servidor y la versión de copia de seguridad en la documentación de Percona XtraBackup.
- Para MySQL 5.7, instala Percona XtraBackup 2.4.
- Para MySQL 8.0, instala Percona XtraBackup 8.0.
- Exporta y prepara el archivo de copia de seguridad físico de tu instancia de origen con
Percona XtraBackup. Para obtener información completa sobre el uso de
Percona XtraBackup, consulta la
documentación de la herramienta. También puedes expandir la siguiente sección para ver un ejemplo de los pasos recomendados.
Muestra de pasos recomendados para crear y preparar archivos de copia de seguridad físicos con Percona XtraBackup
Antes de usar cualquiera de los datos de comando que se muestran a continuación, realiza los siguientes reemplazos:
TARGET_DIR por la ruta de acceso en la que deseas guardar el archivo de copia de seguridad de salida.USERNAME con un usuario que tenga el privilegioBACKUP_ADMIN
en la instancia de origenPASSWORD por la contraseña de la cuentaUSERNAME .
- Realiza una copia de seguridad física completa de tu instancia de origen. Ejecuta el siguiente comando:
xtrabackup --backup \ --target-dir=
TARGET_DIR \ --user=USERNAME \ --password=PASSWORD - Cuando el archivo de copia de seguridad esté listo, usa el comando
--prepare
para garantizar la coherencia del archivo. Ejecuta el siguiente comando:xtrabackup --prepare --target-dir=
TARGET_DIR
- Crea tu bucket para almacenar
los archivos de copia de seguridad. Asegúrate de usar la misma región que en la que querías crear tu
instancia de destino de Cloud SQL para MySQL.
Database Migration Service es un producto completamente regional, lo que significa que todas las entidades relacionadas con tu migración (perfiles de conexión de origen y destino, trabajos de migración, bases de datos de destino, buckets de almacenamiento para archivos de copia de seguridad) deben guardarse en una sola región.
- Sube los archivos de copia de seguridad a tu bucket de Cloud Storage. Asegúrate de subir los archivos de copia de seguridad a una carpeta exclusiva de Cloud Storage que no contenga otros archivos. Consulta Sube objetos desde un sistema de archivos en la documentación de Cloud Storage.
- Crea el perfil de conexión fuente para tu instancia de base de datos de origen.
Para crear un perfil de conexión de origen, sigue estos pasos:
- Ve a la página Perfiles de conexión en Google Cloud Console.
- Haga clic en Crear perfil.
- En la página Crear un perfil de conexión, en el menú desplegable Motor de base de datos, selecciona MySQL.
- En el campo Nombre del perfil de conexión, ingresa un nombre legible por humanos para tu perfil de conexión. Este valor se muestra en la lista de perfiles de conexión.
- Conserva el ID del perfil de conexión generado automáticamente.
- Ingresa un nombre de host o una dirección IP.
Si la base de datos de origen se aloja en Google Cloud, o si se usa un túnel SSH inverso para conectar la base de datos de destino a la base de datos de origen, especifica la dirección IP privada (interna) de la base de datos de origen. El destino de Cloud SQL podrá acceder a esta dirección. Para obtener más información, consulta Configura la conectividad mediante el intercambio de tráfico de VPC.
Para otros métodos de conectividad, como la lista de IP permitidas, proporciona la dirección IP pública.
- Ingresa el puerto que se usa para acceder al host. El puerto predeterminado de MySQL es 3306.
- Ingresa un nombre de usuario y una contraseña para la base de datos de destino. La cuenta de usuario debe tener los privilegios necesarios para acceder a tus datos. Para obtener más información, consulta Configura tu base de datos de origen.
- En la sección Región del perfil de conexión de la página, selecciona la región en la que deseas guardar el perfil de conexión.
Opcional: Si la conexión se realiza a través de una red pública (mediante listas de IP permitidas), te recomendamos usar la encriptación SSL/TLS para la conexión entre las bases de datos de origen y de destino.
Existen tres opciones para la configuración SSL/TLS que puedes seleccionar en la sección Protege tu conexión de la página:
- Ninguna: La instancia de destino de Cloud SQL se conecta a la base de datos de origen sin encriptación.
Autenticación solo de servidor: Cuando la instancia de destino de Cloud SQL se conecta a la base de datos de origen, la instancia autentica la fuente y se asegura de que la instancia se conecte al host correcto de forma segura. Esto evita los ataques de intermediario. En el caso de la autenticación solo del servidor, la fuente no autentica la instancia.
Para usar la autenticación solo del servidor, debes proporcionar el certificado codificado con PEM x509 de la autoridad certificadora (AC) que firmó el certificado del servidor externo.
- Autenticación servidor-cliente: Cuando la instancia de destino se conecta a la fuente, la instancia autentica la fuente y la fuente autentica la instancia.
La autenticación servidor-cliente proporciona la mayor seguridad. Sin embargo, si no quieres proporcionar el certificado y la clave privada del cliente cuando creas la instancia de destino de Cloud SQL, puedes usar la autenticación solo del servidor.
Para usar la autenticación servidor-cliente, debes proporcionar los siguientes elementos cuando crees el perfil de conexión de destino:
- El certificado de la AC que firmó el certificado del servidor de la base de datos de origen (el certificado de la AC).
- Es el certificado que usa la instancia para autenticarse en el servidor de la base de datos de origen (el certificado de cliente).
- La clave privada asociada con el certificado de cliente (la clave del cliente).
- Haz clic en Crear. Se creó tu perfil de conexión.
En este ejemplo, se usa la marca opcional
--no-async
para que todas las operaciones se realicen de forma síncrona. Esto significa que algunos comandos pueden tardar un poco en completarse. Puedes omitir la marca--no-async
para ejecutar comandos de forma asíncrona. Si es así, debes usar el comandogcloud database-migration operations describe
para verificar si la operación se realizó de forma correcta.Antes de usar cualquiera de los datos de comando a continuación, realiza los siguientes reemplazos:
CONNECTION_PROFILE_ID con un identificador legible por máquina para tu perfil de conexión.REGION con el identificador de la región en la que deseas guardar el perfil de conexión.HOST_IP_ADDRESS con la dirección IP a la que Database Migration Service puede acceder a tu instancia de base de datos de origen. Este valor puede variar según el metodo de conectividad que uses para la migración.PORT_NUMBER con el número de puerto en el que tu base de datos fuente acepta conexiones entrantes. El puerto predeterminado de MySQL es 3306.USERNAME con el nombre de la cuenta de usuario de la base de datos con la que deseas que Database Migration Service se conecte a tu instancia de base de datos de origen.PASSWORD por la contraseña de la cuenta de usuario de la base de datos.CONNECTION_PROFILE_NAME (opcional) con un nombre legible por humanos para tu perfil de conexión Este valor se muestra en la consola de Google Cloud.
Ejecuta el siguiente comando:
Linux, macOS o Cloud Shell
gcloud database-migration connection-profiles \ create mysql
CONNECTION_PROFILE_ID \ --no-async \ --region=REGION \ --host=HOST_IP_ADDRESS \ --port=PORT_NUMBER \ --username=USERNAME \ --password=PASSWORD \ --display-name=CONNECTION_PROFILE_NAME Windows (PowerShell)
gcloud database-migration connection-profiles ` create mysql
CONNECTION_PROFILE_ID ` --no-async ` --region=REGION ` --host=HOST_IP_ADDRESS ` --port=PORT_NUMBER ` --username=USERNAME ` --password=PASSWORD ` --display-name=CONNECTION_PROFILE_NAME Windows (cmd.exe)
gcloud database-migration connection-profiles ^ create mysql
CONNECTION_PROFILE_ID ^ --no-async ^ --region=REGION ^ --host=HOST_IP_ADDRESS ^ --port=PORT_NUMBER ^ --username=USERNAME ^ --password=PASSWORD ^ --display-name=CONNECTION_PROFILE_NAME Deberías recibir una respuesta similar a la que figura a continuación:
Waiting for connection profile [
CONNECTION_PROFILE_ID ] to be created with [OPERATION_ID ] Waiting for operation [OPERATION_ID ] to complete...done. Created connection profileCONNECTION_PROFILE_ID [OPERATION_ID ]
Paso 3: Configura y ejecuta el trabajo de migración
Cuando realices la migración con Percona XtraBackup, te recomendamos que crees la instancia de destino de Cloud SQL por tu cuenta o que Database Migration Service la creé por ti. Para obtener más información, consulta Descripción general de la creación de trabajos de migración.
Cada uno de estos enfoques requiere que sigas un conjunto de procedimientos ligeramente diferente. Usa el menú desplegable para mostrar los procedimientos relevantes para tu caso:
- Si deseas que Database Migration Service cree la base de datos de destino por ti, selecciona Migrar a una instancia de destino nueva.
- Si deseas migrar a una base de datos de destino creada fuera de Database Migration Service, selecciona Migrar a una instancia de destino existente.
- Selecciona una opción
- Cómo migrar a una nueva instancia de destino
- Cómo migrar a una instancia de destino existente
- No matches
Paso 4: Detén la migración (opcional)
Puedes detener y borrar tu trabajo de migración en cualquier momento si quieres cancelar el proceso de migración de datos. Puedes administrar el trabajo de migración en la consola de Google Cloud o con Google Cloud CLI.
Para obtener información sobre cómo administrar trabajos de migración en la consola de Google Cloud, consulta Cómo administrar trabajos de migración.
Para obtener información sobre cómo administrar tareas de migración con Google Cloud CLI, consulta la referencia de
gcloud database-migration migration-jobs
.
Paso 5: Finaliza la migración
Cuando el trabajo de migración se complete correctamente, realiza uno de los siguientes pasos para finalizarlo:
Para las migraciones únicas, el estado del trabajo de migración cambia a Completado. No se requieren más acciones. Puedes limpiar el trabajo de migración y los recursos del perfil de conexión.
Para migraciones continuas: Ascende el trabajo de migración para cambiar tu aplicación a la nueva instancia de base de datos.