Migrar de AWS a Google Cloud: migrar de Amazon RDS para SQL Server a Cloud SQL para SQL Server

Last reviewed 2024-06-28 UTC

Google Cloud proporciona herramientas, productos, guías y servicios profesionales para migrar de Amazon Relational Database Service (RDS) a Cloud SQL para SQL Server.

Este documento está dirigido a administradores de bases de datos y de la nube que quieran planificar, implementar y validar un proyecto de migración de bases de datos. También está dirigido a los responsables de la toma de decisiones que están evaluando la oportunidad de migrar y quieren ver un ejemplo de cómo podría ser una migración.

Este documento se centra en la migración de bases de datos homogénea, que es una migración en la que las bases de datos de origen y de destino tienen la misma tecnología. La fuente es Amazon RDS para SQL Server y el destino es Cloud SQL para SQL Server.

Este documento forma parte de una serie de artículos sobre la migración de AWS aGoogle Cloud , que incluye los siguientes documentos:

• Empezar
• Migrar de Amazon EC2 a Compute Engine
• Migrar de Amazon S3 a Cloud Storage
• Migrar de Amazon EKS a GKE
• Migrar de Amazon RDS y Amazon Aurora para MySQL a Cloud SQL para MySQL
• Migrar de Amazon RDS y Amazon Aurora para PostgreSQL a Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL
• Migrar de Amazon RDS para SQL Server a Cloud SQL para SQL Server (este documento)
• Migrar de AWS Lambda a Cloud Run

Para llevar a cabo esta migración a Google Cloud, te recomendamos que sigas el framework de migración descrito en el artículo Migrar a Google Cloud: primeros pasos.

En el siguiente diagrama se muestra el recorrido de tu migración.

Puedes migrar de tu entorno de origen a Google Cloud en una serie de iteraciones. Por ejemplo, puedes migrar algunas cargas de trabajo primero y otras más adelante. En cada iteración de migración independiente, debes seguir las fases del marco de migración general:

1. Evalúa e identifica tus cargas de trabajo y datos.
2. Planifica y construye una base sobre Google Cloud.
3. Migra tus cargas de trabajo y datos a Google Cloud.
4. Optimiza tu Google Cloud entorno.

Para obtener más información sobre las fases de este marco, consulta el artículo Migrar a Google Cloud: primeros pasos.

Para diseñar un plan de migración eficaz, te recomendamos que valides cada paso del plan y que tengas una estrategia de restauración. Para validar tu plan de migración, consulta el artículo Migrar a Google Cloud: prácticas recomendadas para validar un plan de migración.

Evaluar el entorno de origen

En la fase de evaluación, determinas los requisitos y las dependencias para migrar tu entorno de origen a Google Cloud.

La fase de evaluación es fundamental para que la migración se lleve a cabo correctamente. Debes conocer en profundidad las cargas de trabajo que quieres migrar, sus requisitos, sus dependencias y tu entorno actual. Para planificar y llevar a cabo una migración correctamente, debes conocer tu punto de partida. Google Cloud

La fase de evaluación consta de las siguientes tareas:

1. Crea un inventario completo de tus cargas de trabajo.
2. Cataloga tus cargas de trabajo según sus propiedades y dependencias.
3. Forma y educa a tus equipos sobre Google Cloud.
4. Crea experimentos y pruebas de concepto en Google Cloud.
5. Calcula el coste total de propiedad (CTP) del entorno de destino.
6. Elige la estrategia de migración de tus cargas de trabajo.
7. Elige las herramientas de migración.
8. Define el plan y la cronología de la migración.
9. Valida tu plan de migración.

Para obtener más información sobre la fase de evaluación y estas tareas, consulta el artículo Migración a Google Cloud: evaluar e identificar cargas de trabajo. Las siguientes secciones se basan en la información de ese documento.

La fase de evaluación de la base de datos te ayuda a elegir el tamaño y las especificaciones de la instancia de base de datos de Cloud SQL de destino que se adapten a la fuente para satisfacer necesidades de rendimiento similares. Presta especial atención al tamaño y al rendimiento del disco, a las IOPS y al número de vCPUs. Es posible que las migraciones tengan problemas o fallen debido a que el tamaño de la instancia de la base de datos de destino sea incorrecto. Si el tamaño no es el adecuado, la migración puede tardar mucho, y pueden producirse problemas de rendimiento de la base de datos, errores en la base de datos y problemas de rendimiento de la aplicación. Al elegir la instancia de Cloud SQL, ten en cuenta que el rendimiento del disco se basa en el tamaño del disco y en el número de vCPUs.

Las siguientes secciones se basan en el artículo Migración a Google Cloud: evaluar e identificar cargas de trabajo y se integran en él.

Crear un inventario de sus instancias de Amazon RDS

Para definir el ámbito de la migración, cree un inventario y recoja información sobre sus instancias de Amazon RDS. Lo ideal es que el proceso se automatice, ya que los enfoques manuales son propensos a errores y pueden dar lugar a suposiciones incorrectas.

Es posible que Amazon RDS y Cloud SQL no tengan las mismas funciones, especificaciones de instancia u operaciones. Es posible que algunas funciones se implementen de forma diferente o no estén disponibles. Entre las diferencias se pueden incluir la infraestructura, el almacenamiento, la autenticación y la seguridad, la replicación, la copia de seguridad, la alta disponibilidad, el modelo de capacidad de recursos y las integraciones y extensiones de funciones específicas del motor de la base de datos. En función del tipo de motor de base de datos, el tamaño de la instancia y la arquitectura, también hay diferencias en los valores predeterminados de los ajustes de los parámetros de la base de datos.

Las comparativas pueden ayudarte a comprender mejor las cargas de trabajo que se van a migrar y a definir la arquitectura adecuada del entorno de destino de la migración. Recoger información sobre el rendimiento es importante para ayudar a estimar las necesidades de rendimiento del entorno de destino. Google Cloud Los conceptos y las herramientas de las comparativas se detallan en la fase Realizar pruebas y validaciones del proceso de migración, pero también se aplican a la fase de creación del inventario.

Herramientas para las evaluaciones

Para obtener una evaluación inicial de tu infraestructura actual, te recomendamos que uses Migration Center de Google Cloud junto con otras herramientas especializadas de evaluación de bases de datos, como migVisor y Database Migration Assessment Tool (DMA).

Con Migration Center, puedes realizar una evaluación completa de tu entorno de aplicaciones y bases de datos, incluida la idoneidad técnica para migrar una base de datos a Google Cloud. Recibes recomendaciones sobre el tamaño y la configuración de cada base de datos de origen, y creas un informe de coste total de propiedad (TCO) de los servidores y las bases de datos.

Para obtener más información sobre cómo evaluar tu entorno de AWS con Migration Center, consulta Importar datos de otros proveedores de servicios en la nube.

Además de Migration Center, puedes usar la herramienta especializada migVisor, que admite varios motores de bases de datos y es especialmente adecuada para migraciones heterogéneas. Para obtener una introducción a migVisor, consulta la descripción general de migVisor.

migVisor puede identificar artefactos y funciones de bases de datos propietarias incompatibles que pueden provocar que la migración se realice de forma predeterminada, así como sugerir soluciones alternativas. migVisor también puede recomendar una solución de destino, incluida la arquitectura y el tamaño iniciales. Google Cloud

Los resultados de la evaluación de la base de datos de migVisor proporcionan lo siguiente:

• Descubrimiento y análisis exhaustivos de las implementaciones de bases de datos actuales.
• Informe detallado de la complejidad de la migración, basado en las funciones propietarias que usa tu base de datos.
• Informe financiero con detalles sobre los ahorros de costes tras la migración, los costes de la migración y el nuevo presupuesto operativo.
• Plan de migración por fases para mover bases de datos y aplicaciones asociadas con las mínimas interrupciones posibles en la empresa.

Para ver algunos ejemplos de resultados de la evaluación, consulta migVisor - Cloud migration assessment tool (migVisor: herramienta de evaluación de la migración a la nube).

Ten en cuenta que migVisor aumenta temporalmente la utilización del servidor de bases de datos. Normalmente, esta carga adicional es inferior al 3 % y se puede ejecutar durante las horas de menor actividad.

Los resultados de la evaluación de migVisor le ayudan a crear un inventario completo de sus instancias de RDS. El informe incluye propiedades genéricas (versión y edición del motor de la base de datos, CPUs y tamaño de la memoria), así como detalles sobre la topología de la base de datos, las políticas de copia de seguridad, la configuración de los parámetros y las personalizaciones especiales en uso.

Si prefieres usar herramientas de código abierto, puedes usar secuencias de comandos de recogida de datos con las herramientas mencionadas (o en lugar de ellas). Estas secuencias de comandos pueden ayudarle a recopilar información detallada (sobre cargas de trabajo, funciones, objetos de base de datos y código de base de datos) y a crear su inventario de bases de datos. Además, las secuencias de comandos suelen proporcionar una evaluación detallada de la migración de la base de datos, incluida una estimación del esfuerzo de migración.

Te recomendamos la herramienta de código abierto DMA, que han creado ingenieros de Google. Ofrece una evaluación completa y precisa de la base de datos, incluidas las funciones en uso, la lógica de la base de datos y los objetos de la base de datos (como esquemas, tablas, vistas, funciones, activadores y procedimientos almacenados).

Para usar DMA, descarga las secuencias de comandos de recogida de tu motor de base de datos desde el repositorio de Git y sigue las instrucciones. Envía los archivos de salida a Google Cloud para que los analice. Google Cloud crea y envía un informe de evaluación de la base de datos, y proporciona los pasos siguientes en el proceso de migración.

Identificar y documentar el alcance de la migración y el tiempo de inactividad asequible

En esta fase, se documenta la información esencial que influye en la estrategia y las herramientas de migración. Ahora puedes responder a las siguientes preguntas:

• ¿Tus bases de datos ocupan más de 5 TB?
• ¿Hay alguna tabla grande en tu base de datos? ¿Tienen un tamaño superior a 16 TB?
• ¿Dónde se encuentran las bases de datos (regiones y zonas) y cuál es su proximidad a las aplicaciones?
• ¿Con qué frecuencia cambian los datos?
• ¿Cuál es tu modelo de coherencia de datos?
• ¿Qué opciones hay para las bases de datos de destino?
• ¿Cómo de compatibles son las bases de datos de origen y de destino?
• ¿Los datos deben residir en alguna ubicación física?
• ¿Hay datos que se puedan comprimir y archivar o datos que no sea necesario migrar?

Para definir el alcance de la migración, decide qué datos quieres conservar y cuáles quieres migrar. Migrar todas tus bases de datos puede llevarte mucho tiempo y esfuerzo. Es posible que algunos datos permanezcan en las copias de seguridad de la base de datos de origen. Por ejemplo, puede que no se necesiten tablas de registro antiguas ni datos de archivo. También puedes decidir mover los datos después del proceso de migración, en función de tu estrategia y tus herramientas.

Establece valores de referencia de la migración de datos que te ayuden a comparar y evaluar los resultados y los impactos. Estas líneas de base son puntos de referencia que representan el estado de sus datos antes y después de la migración, y le ayudan a tomar decisiones. Es importante tomar medidas en el entorno de origen que puedan ayudarte a evaluar el éxito de la migración de datos. Entre estas mediciones se incluyen las siguientes:

• El tamaño y la estructura de sus datos.
• La integridad y la coherencia de tus datos.
• La duración y el rendimiento de las transacciones y los procesos empresariales más importantes.

Determina cuánto tiempo de inactividad puedes permitirte. ¿Qué repercusiones tiene el tiempo de inactividad en las empresas? ¿Hay periodos de poca actividad en la base de datos durante los cuales se ven afectados menos usuarios por el tiempo de inactividad? Si es así, ¿cuánto duran esos periodos y cuándo se producen? Considera la posibilidad de tener un tiempo de inactividad de escritura parcial, mientras se siguen atendiendo las solicitudes de solo lectura.

Evalúa tu proceso de implementación y administración

Una vez que hayas creado los inventarios, evalúa los procesos operativos y de implementación de tu base de datos para determinar cómo debes adaptarlos y facilitar la migración. Estos procesos son fundamentales para preparar y mantener tu entorno de producción.

Piensa en cómo completas las siguientes tareas:

• Define y aplica políticas de seguridad para tus instancias: por ejemplo, puede que tengas que sustituir los grupos de seguridad de Amazon. Puedes usar los roles de Gestión de Identidades y Accesos (IAM) de Google, las reglas de cortafuegos de VPC y los Controles de Servicio de VPC para controlar el acceso a tus instancias de Cloud SQL y acotar los datos en una VPC. Si tienes previsto usar la autenticación de Windows con Cloud SQL para SQL Server, debes implementar Microsoft AD gestionado y conectarte a tu infraestructura de Active Directory.
• Aplica parches y configura tus instancias: es posible que tengas que actualizar tus herramientas de implementación. Por ejemplo, puede que estés usando ajustes de configuración personalizados en grupos de parámetros o grupos de opciones de Amazon. Es posible que tengas que adaptar tus herramientas de aprovisionamiento para usar Google Cloud Storage o Secret Manager y leer esas listas de configuración personalizadas.
• Gestionar la infraestructura de monitorización y alertas: las categorías de métricas de las instancias de la base de datos de origen de Amazon proporcionan observabilidad durante el proceso de migración. Las categorías de métricas pueden incluir Amazon CloudWatch, Performance Insights, monitorización mejorada y listas de procesos del SO.

Completa la evaluación

Después de crear los inventarios a partir de tu entorno de Amazon RDS, completa el resto de las actividades de la fase de evaluación tal como se describe en Migrar a Google Cloud: evalúa y descubre tus cargas de trabajo.

Planifica y construye tu base

En la fase de planificación y creación, aprovisionas y configuras la infraestructura para hacer lo siguiente:

• Compatibilidad con tus cargas de trabajo en tu Google Cloud entorno.
• Conecta tu entorno de origen y tu entorno de Google Cloud para completar la migración.

La fase de planificación y creación se compone de las siguientes tareas:

1. Crea una jerarquía de recursos.
2. Configura la gestión de identidades y accesos (IAM) de Google Cloud.
3. Configura la facturación
4. Configura la conectividad de red.
5. Refuerza tu seguridad.
6. Configura el almacenamiento de registros, la monitorización y las alertas.

Para obtener más información sobre cada una de estas tareas, consulta el artículo Migrar a Google Cloud: planificar y crear la base.

Monitorización y alertas

Usa Cloud Monitoring de Google, que incluye paneles de control predefinidos para varios productos de Google Cloud , incluido un panel de control de monitorización de Cloud SQL. También puedes usar soluciones de monitorización de terceros integradas conGoogle Cloud, como Datadog y Splunk. Para obtener más información, consulta Información sobre la observabilidad de las bases de datos.

Migrar instancias de Amazon RDS para SQL Server a Cloud SQL para SQL Server

Para migrar tus instancias, haz lo siguiente:

1. Elige la estrategia de migración: replicación continua o mantenimiento programado.

2. Elige las herramientas de migración en función de la estrategia y los requisitos que hayas seleccionado.

3. Define el plan y el calendario de migración de cada base de datos, incluidas las tareas de preparación y ejecución.

4. Define las tareas de preparación que deben realizarse para que la herramienta de migración funcione correctamente.

5. Define las tareas de ejecución, que incluyen las actividades de trabajo que implementan la migración.

6. Define escenarios alternativos para cada tarea de ejecución.

7. Realiza pruebas y validaciones, que se pueden llevar a cabo en un entorno de staging independiente.

8. Realiza la migración.

9. Realiza el cambio a producción.

10. Limpia el entorno de origen y configura la instancia de destino.

11. Realiza ajustes y optimizaciones.

Cada fase se describe en las siguientes secciones.

Elegir la estrategia de migración

En este paso, tienes suficiente información para evaluar y seleccionar una de las siguientes estrategias de migración que mejor se adapte a tu caso práctico para cada base de datos:

• Mantenimiento programado (también llamado migración única o migración Big Bang): este enfoque es ideal si puedes permitirte un tiempo de inactividad. Esta opción tiene un coste y una complejidad relativamente bajos, ya que tus cargas de trabajo y servicios no requerirán mucha refactorización. Sin embargo, si la migración falla antes de completarse, tendrás que reiniciar el proceso, lo que prolongará el tiempo de inactividad.

• Replicación continua (también llamada migración online o migración gradual): en el caso de las bases de datos esenciales, esta opción ofrece un menor riesgo de pérdida de datos y un tiempo de inactividad casi nulo. Los esfuerzos se dividen en varios fragmentos, por lo que, si se produce un fallo, la reversión y la repetición tardan menos tiempo. Sin embargo, la configuración es más compleja y requiere más planificación y tiempo. También se requiere un esfuerzo adicional para refactorizar las aplicaciones que se conectan a tus instancias de base de datos. Considere una de las siguientes variaciones:

  • Con el método Y (escritura y lectura), que es una forma de migración paralela, se duplican los datos en las instancias de origen y de destino durante la migración.
  • Usar un microservicio de acceso a datos, lo que reduce el esfuerzo de refactorización necesario para el enfoque de Y (escritura y lectura).

Para obtener más información sobre las estrategias de migración de datos, consulta Evaluar los enfoques de migración de datos.

En el siguiente diagrama de flujo se muestran algunas preguntas que puedes hacerte a la hora de decidir la estrategia de migración de una sola base de datos:

En el diagrama de flujo anterior se muestran los siguientes puntos de decisión:

• ¿Puedes permitirte algún tiempo de inactividad?

  • Si no es así, adopta la estrategia de migración de replicación continua.
  • Si es así, continúa con el siguiente punto de decisión.

• ¿Puedes permitirte el tiempo de inactividad que representa la ventana de cambio mientras migras los datos? La ventana de cambio representa el tiempo necesario para crear una copia de seguridad de la base de datos, transferirla a Cloud SQL, restaurarla y, a continuación, cambiar tus aplicaciones.

  • Si no es así, adopta la estrategia de migración de replicación continua.
  • Si es así, adopta la estrategia de migración de mantenimiento programado.

Las estrategias pueden variar en función de la base de datos, aunque estén ubicadas en la misma instancia. Una combinación de estrategias puede dar resultados óptimos. Por ejemplo, puedes migrar bases de datos pequeñas y que no se usen con frecuencia mediante el mantenimiento programado, pero usar la replicación continua para las bases de datos esenciales en las que el tiempo de inactividad es costoso.

Por lo general, una migración se considera completada cuando se produce el cambio entre la instancia de origen inicial y la de destino. Se detiene cualquier replicación (si se usa) y todas las lecturas y escrituras se realizan en la instancia de destino. Si cambias cuando ambas instancias están sincronizadas, no se perderán datos y el tiempo de inactividad será mínimo.

Para obtener más información sobre las estrategias y las implementaciones de migración de datos, consulta Clasificación de las migraciones de bases de datos.

Minimizar el tiempo de inactividad y los impactos relacionados con la migración

Las configuraciones de migración que no provocan tiempos de inactividad de las aplicaciones requieren una configuración más compleja. Encuentra el equilibrio adecuado entre la complejidad de la configuración y el tiempo de inactividad programado durante las horas de menor tráfico.

Cada estrategia de migración tiene ventajas e inconvenientes, así como un impacto asociado al proceso de migración. Por ejemplo, los procesos de replicación implican una carga adicional en las instancias de origen y las aplicaciones pueden verse afectadas por la latencia de replicación. Es posible que las aplicaciones (y los clientes) tengan que esperar durante el tiempo de inactividad de la aplicación, al menos mientras dure el retraso de la replicación, antes de usar la nueva base de datos. En la práctica, los siguientes factores pueden aumentar el tiempo de inactividad:

• Las consultas de bases de datos pueden tardar unos segundos en completarse. En el momento de la migración, es posible que se cancelen las consultas en curso.
• La caché puede tardar un tiempo en llenarse si la base de datos es grande o tiene una memoria de búfer considerable.
• Las aplicaciones que se hayan detenido en la fuente y se hayan reiniciado en Google Cloudpueden tener un pequeño retraso hasta que se establezca la conexión con la instancia de la base de datos de Google Cloud.
• Las rutas de red a las aplicaciones deben redirigirse. En función de cómo se hayan configurado las entradas DNS, este proceso puede tardar un poco. Cuando actualices los registros DNS, reduce el TTL antes de la migración.

Las siguientes prácticas habituales pueden ayudar a minimizar el tiempo de inactividad y el impacto:

• Busca un periodo en el que el tiempo de inactividad tenga un impacto mínimo en tus cargas de trabajo. Por ejemplo, fuera del horario de apertura habitual, durante los fines de semana o en otras ventanas de mantenimiento programadas.
• Identifica las partes de tus cargas de trabajo que se pueden migrar y cambiar a producción en diferentes fases. Es posible que tus aplicaciones tengan diferentes componentes que se puedan aislar, adaptar y migrar sin que esto suponga ningún problema. Por ejemplo, front-ends, módulos de CRM, servicios de backend y plataformas de informes. Estos módulos pueden tener sus propias bases de datos, cuya migración se puede programar para antes o después en el proceso.
• Si puedes permitirte cierta latencia en la base de datos de destino, considera la posibilidad de implementar una migración gradual. Usa transferencias de datos incrementales por lotes y adapta parte de tus cargas de trabajo para que funcionen con los datos obsoletos de la instancia de destino.
• Te recomendamos que refactorices tus aplicaciones para que la migración tenga el menor impacto posible. Por ejemplo, adapta tus aplicaciones para que escriban en las bases de datos de origen y de destino, e implementa una replicación a nivel de aplicación.

Elige tus herramientas de migración

El factor más importante para que una migración tenga éxito es elegir la herramienta de migración adecuada. Una vez que se haya decidido la estrategia de migración, revisa y elige la herramienta de migración.

Hay muchas herramientas disponibles, cada una de ellas optimizada para determinados casos prácticos de migración. Estos son algunos de los usos:

• Estrategia de migración (mantenimiento programado o replicación continua).
• Motores y versiones de los motores de las bases de datos de origen y destino.
• Entornos en los que se encuentran las instancias de origen y de destino.
• Tamaño de la base de datos. Cuanto mayor sea la base de datos, más tiempo se tardará en migrar la copia de seguridad inicial.
• Frecuencia de los cambios en la base de datos.
• Disponibilidad para usar servicios gestionados para la migración.

Para garantizar una migración y un cambio sin problemas, puedes usar patrones de implementación de aplicaciones, orquestación de infraestructuras y aplicaciones de migración personalizadas. Sin embargo, hay herramientas especializadas llamadas servicios de migración gestionados que pueden facilitar el proceso de mover datos, aplicaciones o incluso infraestructuras completas de un entorno a otro. Ejecutan la extracción de datos de las bases de datos de origen, transportan los datos de forma segura a las bases de datos de destino y, opcionalmente, pueden modificar los datos durante el tránsito. Gracias a estas funciones, encapsulan la lógica compleja de la migración y ofrecen funciones de monitorización de la migración.

Los servicios de migración gestionados ofrecen las siguientes ventajas:

• Minimizar el tiempo de inactividad: los servicios usan las funciones de replicación integradas de los motores de bases de datos cuando están disponibles y realizan la promoción de réplicas.

• Garantizar la integridad y la seguridad de los datos: los datos se transfieren de forma segura y fiable de la base de datos de origen a la de destino.

• Ofrecer una experiencia de migración coherente: las diferentes técnicas y patrones de migración se pueden consolidar en una interfaz común y coherente mediante el uso de ejecutables de migración de bases de datos, que puede gestionar y monitorizar.

• Ofrecer modelos de migración resistentes y probados: las migraciones de bases de datos son eventos poco frecuentes, pero críticos. Para evitar errores de principiante y problemas con las soluciones actuales, puedes usar herramientas de expertos en lugar de crear una solución personalizada.

• Optimizar los costes: los servicios de migración gestionados pueden ser más rentables que aprovisionar servidores y recursos adicionales para soluciones de migración personalizadas.

En las siguientes secciones se describen las recomendaciones de la herramienta de migración, que dependen de la estrategia de migración elegida.

Herramientas para migraciones de mantenimiento programadas

En las siguientes subsecciones se describen las herramientas que se pueden usar para migraciones únicas, así como sus limitaciones y prácticas recomendadas.

Copias de seguridad de motores de bases de datos integradas

Si puedes permitir un tiempo de inactividad considerable y tus bases de datos de origen son relativamente estáticas, puedes usar las funciones de copia de seguridad y restauración integradas del motor de base de datos.

Se requiere cierto esfuerzo para la configuración y la sincronización, sobre todo si se trata de un gran número de bases de datos, pero las copias de seguridad del motor de base de datos suelen estar disponibles y son fáciles de usar. Este enfoque es adecuado para bases de datos de cualquier tamaño y suele ser más eficaz que otras herramientas para instancias grandes.

Las copias de seguridad del motor de base de datos tienen las siguientes limitaciones generales:

• Las copias de seguridad pueden dar lugar a errores, sobre todo si se realizan manualmente.
• Los datos no están protegidos si las copias de seguridad no se gestionan correctamente.
• Las copias de seguridad no tienen las funciones de monitorización adecuadas.

Si eliges este método, ten en cuenta las siguientes restricciones y prácticas recomendadas:

• Para hacer copias de seguridad de bases de datos de más de 5 TB, utiliza una copia de seguridad segmentada (una copia de seguridad de varios archivos).
• Cuando se usa una copia de seguridad segmentada, no se pueden crear copias de seguridad ni restaurar más de 10 archivos de copia de seguridad al mismo tiempo.
• Debes crear una copia de seguridad en un segmento de Amazon S3 que se encuentre en la misma región de Amazon que la instancia de la base de datos de origen.
• Las copias de seguridad no incluyen los inicios de sesión, los permisos ni los roles de servidor de SQL Server, ya que se encuentran a nivel de instancia. Para transferir este tipo de datos de la instancia de origen a la de destino, usa scripts de PowerShell o herramientas como DBAtools.

Para obtener información sobre las limitaciones y las prácticas recomendadas, consulta Prácticas recomendadas para importar y exportar datos con Cloud SQL para SQL Server y Problemas conocidos de Cloud SQL para SQL Server.

Otros enfoques para las migraciones de mantenimiento programado

Si utilizas otros métodos, tendrás más control y flexibilidad en el proceso de migración de mantenimiento programado.

Por ejemplo, si usas archivos sin formato para exportar e importar tus datos (o si usas secuencias de comandos personalizadas), puedes hacer lo siguiente:

• Realiza transformaciones, comprobaciones u otras operaciones en tus datos durante la migración. Por ejemplo, validaciones, agregaciones o normalizaciones y desnormalizaciones en los datos de origen.
• Elige qué estructuras quieres migrar y cuáles quieres dejar. Puede que decidas extraer solo un subconjunto de tus tablas en archivos sin formato para importarlas.
• Puede filtrar los datos por dominio, fuente, edad u otros criterios personalizados. Por ejemplo, puedes excluir los datos que alcancen un umbral de antigüedad y almacenarlos en archivos o en la copia de seguridad final de tu base de datos de origen antes de la migración.
• Refactoriza las estructuras de tu base de datos y sincroniza el tiempo de inactividad con el tiempo de inactividad de la migración.
• Consolida varias instancias o bases de datos en una sola instancia o base de datos para reducir los costes operativos y facilitar la resolución de los problemas de escalabilidad. Por ejemplo, puede que quieras cambiar tu enfoque de tener una instancia, una base de datos o un esquema por cliente a una estructura de base de datos única y optimizada para multitenencia.

Otros enfoques son los siguientes:

• Usar archivos CSV o JSON: con este método, extrae los datos de la base de datos en los archivos y, a continuación, importa los archivos a las instancias de destino.

  • Aunque suele ser más lento, este método te ayuda a migrar un subconjunto de tablas (o datos de una tabla concreta).
  • Muchos programas pueden leer los formatos CSV y JSON.
  • Si automatizas el proceso, puedes pasar a una migración de replicación continua por lotes.

• Usa el Asistente para importar y exportar de SQL Server de Microsoft: esta herramienta usa SQL Server Integration Services (SSIS) y te permite importar datos de varias fuentes, como otros motores de bases de datos o archivos sin formato.

• Usa el Asistente para generar y publicar scripts de SQL Server y la utilidad bcp: esta herramienta forma parte de Microsoft SQL Server Management Studio.

  • Este método te permite crear secuencias de comandos para todo el esquema de tu base de datos o solo para algunas partes.
  • La utilidad bcp te permite crear secuencias de comandos con los datos y exportarlos a archivos.

• Usa la replicación de instantáneas si tu fuente usa Amazon RDS Standard:

  • Con este método, restauras la copia de seguridad de SQL Server de la instancia de RDS en otra instancia independiente de SQL Server en Compute Engine. A continuación, usa la replicación de capturas para migrar a Cloud SQL para SQL Server.
  • La generación de la instantánea mantiene bloqueos en las tablas de origen, lo que puede afectar a tus cargas de trabajo.
  • La replicación de la instantánea puede introducir cargas adicionales en tu servidor Amazon RDS.
  • Sin embargo, puedes elegir qué objetos se migran o se replican, lo que te ofrece flexibilidad.
  • Para obtener más información, consulta el artículo Migrar datos de SQL Server 2017 a Cloud SQL para SQL Server mediante la replicación de capturas.

Herramientas para migraciones de replicación continua

En el siguiente diagrama de flujo se muestran las preguntas que pueden ayudarte a elegir la herramienta de migración para una sola base de datos cuando usas una estrategia de migración de replicación continua:

En el diagrama de flujo anterior se muestran los siguientes puntos de decisión:

• ¿Prefieres usar servicios de migración gestionados?

  • Si es así, continúa con la siguiente decisión. Si puedes permitirte un periodo de inactividad mínimo y no necesitas transformar los datos ni sincronizarlos en tiempo real, te recomendamos Database Migration Service. De lo contrario, busca opciones de terceros.
  • Si no es así, continúa con la siguiente decisión. Si se admite la replicación integrada del motor de base de datos, le recomendamos que utilice la replicación integrada. Si no es así, te recomendamos que explores otras opciones de migración.

• ¿Puedes permitirte un tiempo de inactividad mínimo y migrar sin transformación de datos ni sincronización en tiempo real?

  • Si es así, te recomendamos Database Migration Service.
  • Si no es así, busca opciones de terceros.

• ¿Se admite la replicación integrada específica del motor de base de datos?

  • Si es así, te recomendamos que uses la replicación integrada.
  • Si no es así, te recomendamos que explores otras opciones de migración.

En las siguientes secciones se describen las herramientas que se pueden usar para las migraciones de replicación continua, junto con sus limitaciones y prácticas recomendadas.

Database Migration Service para la migración de replicación continua

Database Migration Service admite migraciones homogéneas a Cloud SQL para SQL Server cuando el origen es Amazon RDS.

Database Migration Service es una herramienta rentable y sencilla. Recomendamos el servicio de migración de bases de datos en las siguientes situaciones:

• Puedes permitirte un tiempo de inactividad mínimo.
• No necesitas sincronización en tiempo real.
• No es necesario que transformes los datos durante la migración.

Si elige esta herramienta, tenga en cuenta las siguientes restricciones y prácticas recomendadas:

• El tiempo de inactividad depende de la frecuencia de las copias de seguridad del registro de transacciones.
• Las copias de seguridad no incluyen los inicios de sesión, los permisos ni los roles de servidor de SQL Server, ya que se encuentran en el nivel de instancia. Crea secuencias de comandos para ellos desde la instancia de origen y, a continuación, transfiérelos a la instancia de destino mediante secuencias de comandos de PowerShell o herramientas como DBAtools.

Para ver la lista completa de limitaciones, consulta Limitaciones conocidas.

Replicación integrada del motor de base de datos

Cloud SQL admite la replicación de SQL Server. Sin embargo, la instancia estándar de Amazon RDS para SQL Server solo puede ser un suscriptor. La replicación integrada de Amazon RDS Standard no está disponible. Solo se puede configurar Amazon RDS Custom para SQL Server como editor integrado.

Para consultar una lista de las funciones compatibles y no compatibles en Amazon RDS, consulta Amazon RDS para Microsoft SQL Server.

Otros enfoques para la migración de replicación continua

Otros enfoques de migración con replicación continua son los siguientes:

• Refactoriza tus aplicaciones para que realicen Y (escritura y lectura) o usa un microservicio de acceso a datos.

  • Tus aplicaciones realizan la replicación continua.
  • La migración se centra en la refactorización o el desarrollo de herramientas que se conectan a tus instancias de bases de datos.
  • Las aplicaciones de lectura se refactorizan y se implementan gradualmente para usar la instancia de destino.

• Implementa funciones que consulten periódicamente los datos de tu instancia de origen, filtren solo los datos nuevos y escriban los datos en archivos CSV, JSON o Parquet.

  • Estos archivos se almacenan en un segmento de Google Cloud Storage.
  • Puedes escribir los archivos inmediatamente en la instancia de base de datos de destino mediante funciones de Cloud Run.
  • Las funciones de captura de datos de cambios (CDC) pueden ayudarte a llevar a cabo una migración de replicación casi en tiempo real.
  • Puedes transmitir CDC a un lago de datos de Amazon S3 en formato Parquet con AWS Database Migration Service (AWS DMS).
  • Puedes tener una implementación personalizada para leer los archivos y escribir su contenido en Cloud SQL.

Herramientas de terceros para migraciones de replicación continua

En algunos casos, puede ser mejor usar una herramienta de terceros para la mayoría de los motores de bases de datos. Esto puede ocurrir si prefieres usar un servicio de migración gestionado y necesitas asegurarte de que la base de datos de destino esté siempre sincronizada con la de origen en tiempo casi real, o si necesitas transformaciones más complejas, como la limpieza, la reestructuración y la adaptación de los datos durante el proceso de migración.

Si decides usar una herramienta de terceros, elige una de las siguientes recomendaciones, que puedes usar con la mayoría de los motores de bases de datos.

Striim es una plataforma integral en memoria para recoger, filtrar, transformar, enriquecer, agregar, analizar y enviar datos en tiempo real:

• Ventajas:

  • Gestiona grandes volúmenes de datos y migraciones complejas.
  • Captura de datos de cambios integrada para SQL Server.
  • Plantillas de conexión preconfiguradas y flujos de trabajo sin código.
  • Puede gestionar bases de datos grandes y esenciales que operan con una carga transaccional elevada.
  • Entrega una sola vez.

• Inconvenientes:

  • No es de código abierto.
  • Puede resultar caro, sobre todo en el caso de las migraciones largas.
  • Algunas limitaciones en la propagación de operaciones del lenguaje de definición de datos (DDL). Para obtener más información, consulta las operaciones de DDL admitidas y las notas y limitaciones de la evolución del esquema.

Para obtener más información sobre Striim, consulta Ejecutar Striim en Google Cloud.

Debezium es una plataforma distribuida de código abierto para CDC que puede transmitir cambios de datos a suscriptores externos:

• Ventajas:

  • De código abierto.
  • Gran apoyo de la comunidad.
  • Rentable.
  • Control pormenorizado de filas, tablas o bases de datos.
  • Especializada en la captura de cambios en tiempo real de los registros de transacciones de bases de datos.

• Inconvenientes:

  • Se requiere experiencia específica con Kafka y ZooKeeper.
  • Las entregas de cambios de datos se realizan al menos una vez, lo que significa que debe gestionar los duplicados.
  • Configuración manual de la monitorización con Grafana y Prometheus.
  • No se admite la replicación incremental por lotes.

Para obtener más información sobre las migraciones de Debezium, consulta Replicación de datos casi en tiempo real con Debezium.

Fivetran es una plataforma de transferencia de datos automatizada que permite mover datos desde y entre plataformas de datos en la nube.

• Ventajas:

  • Plantillas de conexión preconfiguradas y flujos de trabajo sin código.
  • Propaga los cambios de esquema del origen a la base de datos de destino.
  • Entrega de los cambios de datos exactamente una vez, lo que significa que no es necesario gestionar los duplicados.

• Inconvenientes:

  • No es de código abierto.
  • La compatibilidad con la transformación de datos complejos es limitada.

Definir el plan y la cronología de la migración

Para que la migración de la base de datos y el cambio a producción se lleven a cabo correctamente, te recomendamos que prepares un plan de migración completo y bien definido. Para reducir el impacto en tu empresa, te recomendamos que crees una lista con todos los elementos de trabajo necesarios.

Definir el ámbito de la migración revela las tareas que debes realizar antes, durante y después del proceso de migración de la base de datos. Por ejemplo, si decides no migrar determinadas tablas de una base de datos, es posible que tengas que realizar tareas previas o posteriores a la migración para implementar este filtrado. También debes asegurarte de que la migración de la base de datos no afecte al acuerdo de nivel de servicio ni al plan de continuidad de negocio que tengas.

Te recomendamos que incluyas los siguientes documentos en la documentación de planificación de la migración:

• Documento de diseño técnico (DDT)
• Matriz RACI
• Cronología (por ejemplo, un plan de cuenta atrás)

Las migraciones de bases de datos son un proceso iterativo y las primeras migraciones suelen ser más lentas que las posteriores. Por lo general, las migraciones bien planificadas se ejecutan sin problemas, pero pueden surgir problemas imprevistos. Te recomendamos que siempre tengas un plan de reversión. Como práctica recomendada, sigue las directrices de Migrar a: prácticas recomendadas para validar un plan de migración Google Cloud.

TDD

El documento de diseño técnico recoge todas las decisiones técnicas que se deben tomar en el proyecto. Incluye lo siguiente en el TDD:

• Requisitos y criticidad de la empresa
• Objetivo de tiempo de recuperación (RTO)
• Objetivo de punto de recuperación (RPO)
• Detalles de la migración de bases de datos
• Estimaciones del esfuerzo de migración
• Recomendaciones para validar la migración

Matriz RACI

Algunos proyectos de migración requieren una matriz RACI, que es un documento de gestión de proyectos habitual que define qué personas o grupos son responsables de las tareas y los resultados del proyecto de migración.

Cronología

Prepara una cronología para cada base de datos que deba migrarse. Incluye todas las tareas de trabajo que se deben realizar, así como las fechas de inicio y de finalización estimadas.

Te recomendamos que crees un plan de cuenta atrás para cada entorno de migración. Un plan de cuenta atrás se estructura como una programación de cuenta atrás y enumera todas las tareas necesarias para completar el proyecto de migración, junto con los grupos responsables y la duración estimada.

La cronología debe tener en cuenta no solo las tareas de preparación previas a la migración, sino también las tareas de validación, auditoría o prueba que se lleven a cabo después de la transferencia de datos.

La duración de las tareas de migración suele depender del tamaño de la base de datos, pero también hay otros aspectos que se deben tener en cuenta, como la complejidad de la lógica empresarial, el uso de la aplicación y la disponibilidad del equipo.

Un plan de cuenta atrás podría tener este aspecto:

Fecha	Fase	Categoría	Tasks	Rol	T menos	Estado
01/11/2023	Antes de la migración	Evaluación	Crear un informe de evaluación	Equipo de Discovery	-21	Completado
7/11/2023	Antes de la migración	Preparación de los objetivos	Diseñar el entorno de destino tal como se describe en el documento de diseño	Equipo de migración	-14	Completado
15/11/2023	Antes de la migración	Gobierno de la empresa	Fecha de migración y aprobación de T-Minus	Liderazgo	-6	Completado
18/11/2023	Migración	Configurar DMS	Crear perfiles de conexión	Ingeniero de migración a la nube	-3	Completado
19/11/2023	Migración	Configurar DMS	Crear e iniciar tareas de migración	Ingeniero de migración a la nube	-2	No iniciado
19/11/2023	Migración	Monitorizar DMS	Monitorizar los trabajos de DMS y los cambios de DDL en la instancia de origen	Ingeniero de migración a la nube	-2	No iniciado
21/11/2023	Migración	Migración de DMS	Promocionar réplica de DMS	Ingeniero de migración a la nube	0	No iniciado
21/11/2023	Migración	Validación de la migración	Validación de la migración de bases de datos	Equipo de migración	0	No iniciado
21/11/2023	Migración	Prueba de aplicación	Realizar pruebas de rendimiento y funciones	Equipo de migración	0	No iniciado
22/11/2023	Migración	Gobierno de la empresa	Validación de la migración: OK o NO	Equipo de migración	1	No iniciado
23/11/2023	Después de la migración	Validar la monitorización	Configurar supervisión	Equipo de infraestructura	2	No iniciado
25/11/2023	Después de la migración	Seguridad	Quitar una cuenta de usuario de DMS	Equipo de seguridad	4	No iniciado

Migraciones de varias bases de datos

Si tienes varias bases de datos que migrar, tu plan de migración debe incluir tareas para todas las migraciones.

Te recomendamos que empieces el proceso migrando una base de datos más pequeña y, a ser posible, que no sea crítica. Este enfoque puede ayudarte a adquirir conocimientos y confianza en el proceso de migración y en las herramientas. También puedes detectar cualquier fallo en el proceso en las primeras fases de la programación general de la migración.

Si tienes varias bases de datos que migrar, las cronologías se pueden paralelizar. Por ejemplo, para acelerar el proceso de migración, puedes migrar un grupo de bases de datos pequeñas, estáticas o menos importantes al mismo tiempo, como se muestra en el siguiente diagrama.

En el ejemplo que se muestra en el diagrama, las bases de datos del 1 al 4 son un grupo de bases de datos pequeñas que se migran al mismo tiempo.

Definir las tareas de preparación

Las tareas de preparación son todas las actividades que debes completar para cumplir los requisitos previos de la migración. Si no completas las tareas de preparación, no se podrá llevar a cabo la migración o la base de datos migrada podría quedar inutilizable.

Las tareas de preparación se pueden clasificar de la siguiente manera:

• Preparativos y requisitos previos de la instancia de Amazon RDS
• Preparación de la base de datos de origen y requisitos previos
• Configuración de Cloud SQL
• Configuración específica de la migración

Preparación de la instancia de Amazon RDS y requisitos previos

Ten en cuenta las siguientes tareas de configuración y requisitos previos habituales:

• En función de la ruta de migración, es posible que tengas que permitir las conexiones remotas en tus instancias de RDS. Si tu instancia de RDS está configurada como privada en tu VPC, debe haber conectividad privada RFC 1918 entre Amazon y Google Cloud.

• Es posible que tengas que configurar un nuevo grupo de seguridad para permitir las conexiones remotas en los puertos necesarios.

  • De forma predeterminada, en AWS, el acceso a la red está desactivado para las instancias de base de datos.
  • Puede especificar reglas en un grupo de seguridad que permitan el acceso desde un intervalo de direcciones IP, un puerto o un grupo de seguridad. Se aplican las mismas reglas a todas las instancias de base de datos asociadas a ese grupo de seguridad.

• Para la replicación continua (cambios de streaming a través de CDC), debes usar una instancia de RDS completa y no una réplica de lectura, con CDC habilitado. Para obtener más información, consulta Usar la captura de datos de cambios con SQL Server.

• Si usas herramientas de terceros, normalmente se requieren ajustes y configuraciones iniciales antes de usar la herramienta. Consulta la documentación de la herramienta de terceros.

Preparación de la base de datos de origen y requisitos previos

• Asegúrate de que la base de datos de origen tenga almacenamiento en búfer y memoria disponibles durante las operaciones de migración. Por ejemplo, si usas archivos de copia de seguridad del registro de transacciones, monitoriza el uso del almacenamiento y asegúrate de tener espacio de almacenamiento adicional.
• Documenta los ajustes de los parámetros de tu base de datos y aplícalos en tu instancia de destino antes de hacer las pruebas y la validación de la migración.

• Toma medidas de referencia en tu entorno de origen en uso de producción. Ten en cuenta lo siguiente:

  • Mide el tamaño de tus datos, así como el rendimiento de tu carga de trabajo. ¿Cuánto tiempo tardan de media las consultas o transacciones importantes? ¿Cuánto tiempo durante las horas punta?
  • Documenta las mediciones de referencia para compararlas más adelante y así decidir si la fidelidad de la migración de tu base de datos es satisfactoria. Decide si puedes cambiar tus cargas de trabajo de producción y retirar tu entorno de origen, o si aún lo necesitas para casos de fallo.

Configuración de Cloud SQL

Elige cuidadosamente el tamaño y las especificaciones de la instancia de base de datos de Cloud SQL de destino para que coincidan con los de la fuente y así satisfacer las necesidades de rendimiento. Presta especial atención al tamaño y al rendimiento del disco, a las IOPS y al número de vCPUs. Si el tamaño es incorrecto, los tiempos de migración pueden ser largos y pueden producirse problemas de rendimiento de la base de datos, errores de la base de datos y problemas de rendimiento de la aplicación.

Asegúrate de que el destino sea el adecuado. Es importante tener en cuenta que las opciones de configuración de Amazon RDS pueden variar con respecto a Cloud SQL. Si Cloud SQL no cumple tus requisitos, puedes usar bases de datos en Compute Engine.

Debes confirmar las siguientes propiedades y requisitos antes de crear tus instancias de Cloud SQL, ya que no se pueden cambiar más adelante sin volver a crearlas.

• Elige con cuidado el proyecto y la región de las instancias de Cloud SQL de destino. Las instancias de Cloud SQL no se pueden migrar entre proyectos y regiones sin transferir datos. Google Cloud

• Migra a una versión principal coincidente en Cloud SQL. Por ejemplo, si tu fuente usa SQL Server 15.0, migra a Cloud SQL para SQL Server 15.0. Si las versiones son diferentes, el ajuste del nivel de compatibilidad debe ser el mismo para asegurar que las funciones del motor sean las mismas.

• Replica la información de los usuarios por separado si usas copias de seguridad del motor de base de datos integrado o Database Migration Service. Para obtener más información, consulta las limitaciones que se indican en la sección Copias de seguridad específicas del motor de base de datos.

• Revisa las marcas de configuración específicas del motor de base de datos y compara los valores de las instancias de origen y de destino. Asegúrate de entender su impacto y si deben ser iguales o no. Por ejemplo, te recomendamos que compares los valores de la vista sys.configurations de tu base de datos de origen con los de la instancia de Cloud SQL. Ten en cuenta que no todas las marcas tienen que ser iguales y que no se permiten todos los cambios de marcas en una instancia de Cloud SQL.

Para obtener más información sobre la configuración de Cloud SQL, consulta lo siguiente:

• Prácticas recomendadas generales para SQL Server
• Opciones de configuración de instancias de SQL Server
• Marcas específicas del motor de base de datos de SQL Server

Configuración específica de la migración

Si utilizas la exportación e importación de archivos para migrar o la herramienta de migración de Database Migration Service, debes crear un segmento de Cloud Storage. El segmento almacena los archivos de copia de seguridad de la base de datos y del registro de transacciones. Para obtener más información sobre cómo usar Database Migration Service, consulta Almacenar archivos de copia de seguridad en un segmento de Cloud Storage.

Si usas la replicación, debes asegurarte de que la réplica de Cloud SQL tenga acceso a tu base de datos principal. Esto se puede hacer mediante las opciones de conectividad documentadas.

En función de tu situación y de la criticidad, es posible que tengas que implementar un escenario de respaldo, que suele incluir la inversión de la dirección de la replicación. En este caso, es posible que necesites un mecanismo de replicación adicional de Cloud SQL a tu instancia de Amazon de origen.

En la mayoría de las herramientas de terceros, debes aprovisionar recursos específicos para la migración. Por ejemplo, en el caso de Striim, debes usar Google Cloud Marketplace para empezar. Después, para configurar tu entorno de migración en Striim, puedes usar Flow Designer para crear y cambiar aplicaciones, o bien seleccionar una plantilla predefinida. Las aplicaciones también se pueden codificar con el lenguaje de programación Tungsten Query Language (TQL). Con un panel de control de validación de datos, puedes obtener una representación visual de los datos que gestiona tu aplicación Striim.

Puedes retirar los recursos que conectan tu entorno de Amazon y Google Cloud una vez que se haya completado y validado la migración.

Definir las tareas de ejecución

Las tareas de ejecución implementan el trabajo de migración propiamente dicho. Las tareas dependen de la herramienta de migración que elijas, tal como se describe en las siguientes subsecciones.

Copias de seguridad de motores de bases de datos integradas

Para obtener más información e instrucciones sobre copias de seguridad específicas de bases de datos, consulta Importar datos de un archivo BAK a Cloud SQL para SQL Server y Exportar datos de RDS para SQL Server. Para obtener más información sobre cómo automatizar las subidas de archivos de registro de transacciones, consulta Programar subidas de archivos de registro de transacciones para Amazon RDS.

Tareas de migración de Database Migration Service

Define y configura tareas de migración en Database Migration Service para migrar datos de una instancia de origen a la base de datos de destino. Las tareas de migración se conectan a la instancia de base de datos de origen a través de perfiles de conexión definidos por el usuario.

Prueba todos los requisitos previos para asegurarte de que el trabajo se puede ejecutar correctamente. Elige un momento en el que tus cargas de trabajo puedan permitirse un breve tiempo de inactividad para la migración y el cambio a producción.

El proceso de migración suele implicar las siguientes tareas:

• Exporta una copia de seguridad completa de la base de datos de origen y, a continuación, súbela a un segmento de Cloud Storage.
• Crea una copia de seguridad de los archivos de registro de transacciones y, a continuación, súbela al mismo segmento de Cloud Storage. Para obtener más información sobre cómo automatizar este proceso, consulta Programar subidas de archivos de registro de transacciones en Amazon RDS.
• En Database Migration Service, puedes monitorizar el procesamiento de las copias de seguridad del registro de transacciones.
• Dejar de escribir en la base de datos de origen.
• Espera a que se sincronicen el origen y el destino, es decir, a que se procese la copia de seguridad final del registro de transacciones.
• Detén la replicación en curso y promueve la tarea de migración.Al promover una tarea de migración, la instancia de Cloud SQL de destino se desconecta de la instancia de base de datos de origen y, a continuación, se convierte en una instancia principal.
• Implementa las aplicaciones que apuntan a la nueva base de datos de destino.

Para obtener información detallada sobre el proceso de configuración de la migración, consulta Migrar bases de datos de SQL Server a Cloud SQL para SQL Server.

Replicación integrada del motor de base de datos

Si usas Amazon RDS Standard, puede que primero tengas que migrar a la versión Amazon RDS Custom y, después, replicar en Cloud SQL.

Cloud SQL admite la replicación de SQL Server. Para obtener más información sobre la replicación desde un servidor externo, consulta el artículo Migrar datos de SQL Server 2017 a Cloud SQL para SQL Server mediante la replicación de capturas.

Herramientas de terceros

Define las tareas de ejecución de la herramienta de terceros que hayas elegido. Por ejemplo, si decides usar Striim, debes crear aplicaciones en tu espacio de nombres y configurar el lector de CDC para que se conecte a la instancia de Amazon. Para obtener más información, consulta la configuración de SQL Server en la documentación de Striim.

Definir escenarios de respaldo

Define tareas alternativas para cada tarea de ejecución de la migración, de modo que se puedan llevar a cabo si surgen problemas imprevistos durante el proceso de migración. Las tareas de reserva suelen depender de la estrategia de migración y de las herramientas que se utilicen.

La alternativa puede requerir un esfuerzo considerable. Como práctica recomendada, no hagas el cambio a producción hasta que los resultados de las pruebas sean satisfactorios. Tanto la migración de la base de datos como el escenario de respaldo deben probarse correctamente para evitar una interrupción grave.

Define los criterios de éxito y limita el tiempo de todas las tareas de ejecución de la migración. Hacer una prueba de migración le ayuda a recoger información sobre los tiempos previstos de cada tarea. Por ejemplo, en una migración de mantenimiento programado, puedes permitirte el tiempo de inactividad representado por la ventana de cambio. Sin embargo, es importante que planifiques tu próxima acción por si la tarea de migración única o la restauración de la copia de seguridad falla a mitad de proceso. En función del tiempo de inactividad planificado que haya transcurrido, es posible que tengas que posponer la migración si la tarea no finaliza en el tiempo previsto.

Un plan de respaldo suele referirse a revertir la migración después de realizar el cambio a producción, si aparecen problemas en la instancia de destino. Si implementas un plan de respaldo, recuerda que debe tratarse como una migración completa de la base de datos, incluidas la planificación y las pruebas.

Si decides no tener un plan de respaldo, asegúrate de que entiendes las posibles consecuencias. No tener un plan de respaldo puede suponer un esfuerzo imprevisto y provocar interrupciones evitables en el proceso de migración.

Aunque la opción de recuperación es el último recurso y la mayoría de las migraciones de bases de datos no la utilizan, te recomendamos que siempre tengas una estrategia de recuperación.

Respaldo sencillo

En esta estrategia de respaldo, vuelves a cambiar tus aplicaciones a la instancia de base de datos de origen. Adopta esta estrategia si puedes permitirte un tiempo de inactividad cuando vuelvas a la versión anterior o si no necesitas que las transacciones se confirmen en el nuevo sistema de destino.

Si necesitas todos los datos escritos en tu base de datos de destino y puedes permitirte un tiempo de inactividad, puedes detener las escrituras en tu instancia de base de datos de destino, crear copias de seguridad integradas y restaurarlas en tu instancia de origen. Después, vuelve a conectar tus aplicaciones a la instancia de base de datos de origen inicial. En función de la naturaleza de tu carga de trabajo y de la cantidad de datos escritos en la instancia de base de datos de destino, puedes incorporarla a tu sistema de base de datos de origen inicial más adelante, sobre todo si tus cargas de trabajo no dependen de ninguna hora de creación de registros específica ni de ninguna restricción de orden cronológico.

Replicación inversa

En esta estrategia, se replican las escrituras que se producen en la nueva base de datos de destino después de la puesta en marcha de la producción en la base de datos de origen inicial. De esta forma, mantienes la fuente original sincronizada con la nueva base de datos de destino y las escrituras se realizan en la nueva instancia de base de datos de destino. Su principal desventaja es que no puedes probar el flujo de replicación hasta que cambies a la instancia de base de datos de destino, por lo que no permite realizar pruebas integrales y tiene un breve periodo sin opción de revertir los cambios.

Elige este método si puedes conservar la instancia de origen durante un tiempo y vas a migrar mediante la migración de replicación continua.

Replicación directa

Esta estrategia es una variación de la replicación inversa. Replicas las escrituras de tu nueva base de datos de destino en una tercera instancia de base de datos de tu elección. Puedes dirigir tus aplicaciones a esta tercera base de datos, que se conecta al servidor y ejecuta consultas de solo lectura mientras el servidor no está disponible. Puedes usar cualquier mecanismo de replicación, en función de tus necesidades. La ventaja de este enfoque es que se puede probar de principio a fin.

Adopta esta estrategia si quieres que haya una alternativa en todo momento o si debes descartar la base de datos de origen inicial poco después de la puesta en marcha.

Operaciones de escritura duplicadas

Si eliges una estrategia de migración de microservicios de lectura y escritura (Y) o de acceso a datos, este plan de respaldo ya estará configurado. Esta estrategia es más complicada, ya que tienes que refactorizar las aplicaciones o desarrollar herramientas que se conecten a tus instancias de base de datos.

Tus aplicaciones escriben en las instancias de la base de datos de origen y de destino iniciales, lo que te permite llevar a cabo un cambio gradual a producción hasta que solo uses las instancias de la base de datos de destino. Si hay algún problema, puedes volver a conectar tus aplicaciones a la fuente inicial sin que haya tiempo de inactividad. Puedes descartar la fuente inicial y el mecanismo de escritura duplicado cuando consideres que la migración se ha realizado sin problemas.

Recomendamos este enfoque cuando sea fundamental que no haya tiempo de inactividad durante la migración, cuando tengas una alternativa fiable y cuando tengas tiempo y recursos para refactorizar la aplicación.

Realizar pruebas y validaciones

Los objetivos de este paso son probar y validar lo siguiente:

• Migración correcta de los datos de la base de datos.
• Integración con aplicaciones que ya existen después de que se cambien para usar la nueva instancia de destino.

Define los factores de éxito clave, que son subjetivos en tu migración. Estos son algunos ejemplos de factores subjetivos:

• Qué datos quieres migrar. En algunas cargas de trabajo, puede que no sea necesario migrar todos los datos. Puede que no quieras migrar datos que ya estén agregados, que sean redundantes, que estén archivados o que sean antiguos. Puedes archivar esos datos en un segmento de Cloud Storage como copia de seguridad.
• Un porcentaje aceptable de pérdida de datos. Esto se aplica especialmente a los datos utilizados en cargas de trabajo de analíticas, en las que la pérdida de una parte de los datos no afecta a las tendencias generales ni al rendimiento de las cargas de trabajo.
• Criterios de calidad y cantidad de datos que puedes aplicar a tu entorno de origen y comparar con el entorno de destino después de la migración.
• Criterios de rendimiento. Es posible que algunas transacciones empresariales sean más lentas en el entorno de destino, pero el tiempo de procesamiento sigue estando dentro de los límites definidos.

Es posible que las configuraciones de almacenamiento de tu entorno de origen no se correspondan directamente con losGoogle Cloud entornos de destino. Por ejemplo, las configuraciones de los volúmenes SSD de uso general (gp2 y gp3) con rendimiento de ráfaga de IOPS o SSD de IOPS aprovisionadas. Para comparar y dimensionar correctamente las instancias de destino, compara las instancias de origen en las fases de evaluación y validación.

En el proceso de creación de comparativas, se aplican secuencias de operaciones similares a las de producción a las instancias de la base de datos. Durante este tiempo, se recogen y procesan métricas para medir y comparar el rendimiento relativo de los sistemas de origen y de destino.

En las configuraciones convencionales basadas en servidores, utilice las mediciones pertinentes observadas durante las cargas máximas. En el caso de los modelos de capacidad de recursos flexibles, como Aurora Serverless, te recomendamos que consultes el historial de datos de métricas para observar tus necesidades de escalado.

Puedes usar las siguientes herramientas para probar, validar y comparar bases de datos:

• HammerDB una herramienta de código abierto para realizar pruebas de carga y comparativas de bases de datos. Admite cargas de trabajo analíticas y transaccionales complejas basadas en estándares del sector en varios motores de bases de datos (tanto TPROC-C como TPROC-H). HammerDB tiene documentación detallada y una amplia comunidad de usuarios. Puede compartir y comparar resultados en varios motores de bases de datos y configuraciones de almacenamiento. Para obtener más información, consulta Pruebas de carga de SQL Server con HammerDB y Comparar el rendimiento de Amazon RDS SQL Server con HammerDB.
• Herramienta de evaluación comparativa DBT2: evaluación comparativa especializada para MySQL. Un conjunto de kits de carga de trabajo de bases de datos imita una aplicación de una empresa que tiene almacenes y que implica una combinación de transacciones de lectura y escritura. Usa esta herramienta si quieres usar una prueba de carga de procesamiento de transacciones online (OLTP) prediseñada.
• DbUnit una herramienta de prueba unitaria de código abierto que se usa para probar las interacciones de bases de datos relacionales en Java. La configuración y el uso son sencillos, y admite varios motores de bases de datos (MySQL, PostgreSQL, SQL Server y otros). Sin embargo, la ejecución de la prueba puede ser lenta en ocasiones, en función del tamaño y la complejidad de la base de datos. Recomendamos esta herramienta cuando la sencillez es importante.
• DbFit un framework de pruebas de bases de datos de código abierto que admite el desarrollo de código basado en pruebas y las pruebas automatizadas. Utiliza una sintaxis básica para crear casos de prueba y ofrece pruebas basadas en datos, control de versiones e informes de resultados de pruebas. Sin embargo, la compatibilidad con consultas y transacciones complejas es limitada y no cuenta con una gran comunidad ni con documentación extensa, en comparación con otras herramientas. Recomendamos esta herramienta si tus consultas no son complejas y quieres realizar pruebas automatizadas e integrarlas en tu proceso de integración y entrega continuas.

Para realizar una prueba integral, incluida la del plan de migración, siempre debes hacer una prueba de migración. Una prueba de ejecución realiza la migración de la base de datos a gran escala sin cambiar ninguna carga de trabajo de producción y ofrece las siguientes ventajas:

• Te permite asegurarte de que todos los objetos y configuraciones se migren correctamente.
• Te ayuda a definir y ejecutar tus casos de prueba de migración.
• Ofrece información valiosa sobre el tiempo necesario para la migración real, de modo que puedas ajustar tu cronología.
• Representa una oportunidad para probar, validar y adaptar el plan de migración. A veces no puedes planificar todo con antelación, por lo que esta función te ayuda a detectar cualquier laguna.

Las pruebas de datos se pueden realizar en un pequeño conjunto de las bases de datos que se van a migrar o en todo el conjunto. En función del número total de bases de datos y de las herramientas que se utilicen para implementar su migración, puedes adoptar un enfoque basado en el riesgo. Con este método, se valida un subconjunto de bases de datos migradas con la misma herramienta, sobre todo si se trata de un servicio de migración gestionado.

Para hacer pruebas, debes tener acceso a las bases de datos de origen y de destino, y realizar las siguientes tareas:

• Comparar los esquemas de origen y de destino. Comprueba si existen todas las tablas y los ejecutables. Comprueba el número de filas y compara los datos a nivel de base de datos.
• Ejecuta secuencias de comandos de validación de datos personalizadas.
• Comprueba que los datos migrados también se vean en las aplicaciones que hayan cambiado a la base de datos de destino (los datos migrados se leen a través de la aplicación).
• Realiza pruebas de integración entre las aplicaciones cambiadas y la base de datos de destino probando varios casos prácticos. Estas pruebas incluyen la lectura y la escritura de datos en las bases de datos de destino a través de las aplicaciones para que las cargas de trabajo admitan por completo los datos migrados junto con los datos recién creados.
• Prueba el rendimiento de las consultas de bases de datos más usadas para observar si hay alguna degradación debido a configuraciones incorrectas o a un tamaño inadecuado.

Lo ideal es que todos estos casos de prueba de migración estén automatizados y se puedan repetir en cualquier sistema de origen. El conjunto de casos de prueba automatizados se adapta para realizar pruebas en las aplicaciones cambiadas.

Si usas Database Migration Service como herramienta de migración, consulta Verificar una migración.

Herramienta de validación de datos

Para validar los datos, le recomendamos que utilice la herramienta de validación de datos (DVT). DVT es una herramienta de CLI de Python de código abierto respaldada por Google que proporciona una solución automatizada y repetible para la validación en diferentes entornos.

La herramienta de validación de datos puede ayudar a agilizar el proceso de validación de datos ofreciendo funciones de validación multinivel personalizadas para comparar tablas de origen y de destino a nivel de tabla, columna y fila. También puedes añadir reglas de validación.

La DVT abarca muchas Google Cloud fuentes de datos, como AlloyDB para PostgreSQL, BigQuery, Cloud SQL, Spanner y archivos JSON y CSV en Cloud Storage. También se puede integrar con funciones de Cloud Run y Cloud Run para la activación y la orquestación basadas en eventos.

La herramienta de validación de datos admite los siguientes tipos de validaciones:

• Comparaciones a nivel de esquema
• Columna (incluidas "AVG", "COUNT", "SUM", "MIN", "MAX", "GROUP BY" y "STRING_AGG")
• Fila (incluidas la hash y la coincidencia exacta en las comparaciones de campos)
• Comparación de resultados de consultas personalizadas

Para obtener más información sobre la herramienta de validación de datos, consulte el repositorio de Git y el artículo Validar datos es fácil con la herramienta de validación de datos de Google Cloud.

Realizar la migración

Las tareas de migración incluyen las actividades necesarias para llevar a cabo la transferencia de un sistema a otro.

Ten en cuenta las siguientes prácticas recomendadas para migrar tus datos:

• Informa a los equipos implicados cada vez que empiece y termine un paso del plan.
• Si alguno de los pasos tarda más de lo previsto, compara el tiempo transcurrido con el tiempo máximo asignado a ese paso. Publica actualizaciones intermedias periódicas a los equipos implicados cuando esto ocurra.
• Si el intervalo de tiempo es superior al tiempo máximo reservado para cada paso del plan, considera la posibilidad de volver a la versión anterior.
• Toma decisiones sobre si se puede continuar o no en cada paso del plan de migración y cambio.
• Ten en cuenta las acciones de reversión o los escenarios alternativos para cada uno de los pasos.

Realiza la migración siguiendo las tareas de ejecución definidas y consulta la documentación de la herramienta de migración que hayas seleccionado.

Realizar el cambio a producción

El proceso de cambio a producción de alto nivel puede variar en función de la estrategia de migración que elijas. Si puedes permitir que tus cargas de trabajo tengan un tiempo de inactividad, la migración comienza deteniendo las escrituras en tu base de datos de origen.

En las migraciones de replicación continua, normalmente se siguen estos pasos generales en el proceso de cambio:

• Dejar de escribir en la base de datos de origen.
• Agotar la fuente.
• Detén el proceso de replicación.
• Implementa las aplicaciones que apuntan a la nueva base de datos de destino.

Una vez que se hayan migrado los datos con la herramienta de migración elegida, valide los datos en la base de datos de destino. Confirmas que la base de datos de origen y las bases de datos de destino están sincronizadas y que los datos de la instancia de destino cumplen los estándares de éxito de la migración que has elegido.

Una vez que la validación de datos cumpla tus criterios, podrás realizar el cambio a nivel de aplicación. Despliega las cargas de trabajo que se han refactorizado para usar la nueva instancia de destino. Despliega las versiones de tus aplicaciones que apuntan a la nueva instancia de base de datos de destino. Los despliegues se pueden llevar a cabo mediante actualizaciones continuas, lanzamientos progresivos o con un patrón de despliegue azul-verde. Es posible que se produzca un tiempo de inactividad de la aplicación.

Sigue las prácticas recomendadas para la migración a producción:

• Monitoriza las aplicaciones que funcionan con la base de datos de destino después del cambio.
• Define un periodo de monitorización para determinar si necesitas implementar tu plan de respaldo.
• Ten en cuenta que es posible que tengas que reiniciar tu instancia de Cloud SQL o AlloyDB para PostgreSQL si cambias algunas marcas de base de datos.
• Ten en cuenta que el esfuerzo necesario para revertir la migración puede ser mayor que el que se requiere para solucionar los problemas que aparecen en el entorno de destino.

Limpiar el entorno de origen y configurar la instancia de Cloud SQL

Una vez completado el cambio, puedes eliminar las bases de datos de origen. Te recomendamos que realices las siguientes acciones importantes antes de limpiar tu instancia de origen:

• Crea una copia de seguridad final de cada base de datos de origen. Estas copias de seguridad te proporcionan el estado final de las bases de datos de origen. También es posible que se necesiten copias de seguridad en algunos casos para cumplir determinadas normativas sobre datos.

• Recoge los ajustes de los parámetros de la base de datos de tu instancia de origen. También puedes comprobar que coincidan con los que has recogido en la fase de creación del inventario. Ajusta los parámetros de la instancia de destino para que coincidan con los de la instancia de origen.

• Recoge estadísticas de la base de datos de la instancia de origen y compáralas con las de la instancia de destino. Si las estadísticas son dispares, es difícil comparar el rendimiento de la instancia de origen y la de destino.

En un escenario de fallback, puede que quieras implementar la replicación de tus escrituras en la instancia de Cloud SQL en tu base de datos de origen original. La configuración se parece al proceso de migración, pero se ejecutaría al revés: la base de datos de origen inicial se convertiría en el nuevo destino.

Como práctica recomendada para mantener actualizadas las instancias de origen después del cambio, replica las escrituras realizadas en las instancias de Cloud SQL de destino en la base de datos de origen. Si necesitas revertir el proceso, puedes volver a tus instancias de origen antiguas con una pérdida de datos mínima.

Además de limpiar el entorno de origen, debes realizar las siguientes configuraciones críticas en tus instancias de Cloud SQL:

• Configura una ventana de mantenimiento para tu instancia principal y controla cuándo se pueden producir actualizaciones disruptivas.
• Configura el almacenamiento de la instancia para que tengas al menos un 20 % de espacio disponible para las operaciones de mantenimiento críticas de la base de datos que pueda realizar Cloud SQL. Para recibir una alerta si el espacio en disco disponible es inferior al 20%, crea una política de alertas basada en métricas para la métrica de utilización del disco.

No inicies una operación administrativa antes de que se haya completado la anterior.

Para obtener más información, consulta las siguientes secciones:

• Información sobre el mantenimiento de las instancias de Cloud SQL
• Ajustes específicos del motor de SQL Server

Optimizar el entorno después de la migración

La optimización es la última fase de la migración. En esta fase, repites las tareas de optimización hasta que tu entorno de destino cumpla los requisitos de optimización. Los pasos de cada iteración son los siguientes:

1. Evalúa tu entorno, tus equipos y tu bucle de optimización actuales.
2. Establezca sus requisitos y objetivos de optimización.
3. Optimiza tu entorno y tus equipos.
4. Ajusta el bucle de optimización.

Repite esta secuencia hasta que hayas alcanzado tus objetivos de optimización.

Para obtener más información sobre cómo optimizar tu entorno, consulta los artículos Migrar a Google Cloud: optimizar tu entorno y Google Cloud Well-Architected Framework: optimización del rendimiento. Google Cloud

Establecer los requisitos de optimización

Consulta los siguientes requisitos de optimización de tu entorno de Google Cloud y elige los que mejor se adapten a tus cargas de trabajo.

Aumentar la fiabilidad y la disponibilidad de tu base de datos

Con Cloud SQL, puedes implementar una estrategia de alta disponibilidad y recuperación tras fallos que se ajuste a tu objetivo de tiempo de recuperación (RTO) y a tu objetivo de punto de recuperación (RPO). Para aumentar la fiabilidad y la disponibilidad, ten en cuenta lo siguiente:

• En el caso de cargas de trabajo con muchas lecturas, añade réplicas de lectura para descargar el tráfico de la instancia principal.
• Para las cargas de trabajo de misión crítica, usa la configuración de alta disponibilidad, las réplicas para la conmutación por error regional y una configuración de recuperación tras fallos sólida.
• Para las cargas de trabajo menos críticas, las copias de seguridad automáticas y bajo demanda pueden ser suficientes.
• Para evitar que se eliminen instancias por error, usa la protección contra eliminación de instancias.
• Habilita la recuperación a un momento dado (PITR) en tu instancia de Cloud SQL para SQL Server.
• Automatiza las copias de seguridad de bases de datos SQL mediante planes de mantenimiento.

Aumentar la rentabilidad de tu infraestructura de base de datos

Para que tus cargas de trabajo tengan un impacto económico positivo, deben usar los recursos y servicios disponibles de forma eficiente. Dispone de estas opciones:

• Proporciona a la base de datos la capacidad de almacenamiento mínima necesaria haciendo lo siguiente:

  • Para escalar la capacidad de almacenamiento automáticamente a medida que aumentan los datos, habilita los aumentos automáticos de almacenamiento. Sin embargo, asegúrate de configurar tus instancias para que tengan algo de margen en las cargas de trabajo máximas. Recuerda que las cargas de trabajo de las bases de datos suelen aumentar con el tiempo.

• Identifica los recursos que se hayan sobreestimado:

  • Si ajustas el tamaño de tus instancias de Cloud SQL, puedes reducir el coste de la infraestructura sin añadir riesgos adicionales a la estrategia de gestión de la capacidad.
  • Cloud Monitoring proporciona paneles de control predefinidos que ayudan a identificar el estado y la utilización de la capacidad de muchos Google Cloud componentes, incluido Cloud SQL. Para obtener más información, consulta el artículo Crear y gestionar paneles de control personalizados.

• Identifica las instancias que no requieren configuraciones de alta disponibilidad o recuperación tras desastres y elimínalas de tu infraestructura.

• Elimina las tablas y los objetos que ya no necesites. Puedes almacenarlos en una copia de seguridad completa o en un segmento de Cloud Storage de archivo.

• Evalúa el tipo de almacenamiento más rentable (SSD o HDD) para tu caso práctico.

  • En la mayoría de los casos prácticos, las unidades SSD son la opción más eficiente y rentable.
  • Si sus conjuntos de datos son grandes (10 TB o más), no son sensibles a la latencia o se accede a ellos con poca frecuencia, puede que los discos duros sean más adecuados.
  • Para obtener más información, consulta el artículo Elegir entre almacenamiento SSD y HDD.

• Compra descuentos por compromiso de uso para cargas de trabajo cuyas necesidades de recursos sean predecibles.

• Usa Active Assist para obtener estadísticas y recomendaciones sobre los costes.

  Para obtener más información y opciones, consulta el artículo Aprovecha al máximo tus recursos: presentamos las recomendaciones de optimización de costes de Cloud SQL con Active Assist.

Para reducir los costes de licencias, especialmente en Cloud SQL para SQL Server, ten en cuenta lo siguiente:

• Migra a SQL Server Standard Edition si los SLAs se ajustan a tus requisitos.
• Desactiva el multihilo simultáneo (SMT) y añade un 25% más de núcleos. Los núcleos adicionales pueden compensar cualquier impacto en el rendimiento que se produzca al desactivar SMT. Esta estrategia puede ayudarle a reducir los costes de las licencias, pero podría afectar al rendimiento de su instancia. Te recomendamos que hagas pruebas de carga en tu instancia para asegurarte de que no se vean afectados tus SLAs.
• Considera la posibilidad de realizar una migración heterogénea de Cloud SQL para SQL Server a Cloud SQL para PostgreSQL o AlloyDB para PostgreSQL, en función de tu carga de trabajo.

Aumentar el rendimiento de la infraestructura de tu base de datos

Los problemas de rendimiento leves relacionados con las bases de datos suelen tener el potencial de afectar a toda la operación. Para mantener y mejorar el rendimiento de tu instancia de Cloud SQL, ten en cuenta las siguientes directrices:

• Si tienes un gran número de tablas de bases de datos, pueden afectar al rendimiento y la disponibilidad de la instancia, así como provocar que la instancia pierda la cobertura de su acuerdo de nivel de servicio.

• Asegúrate de que tu instancia no tenga limitaciones de memoria o CPU.

  • En el caso de las cargas de trabajo que requieren un alto rendimiento, asegúrate de que tu instancia tenga al menos 60 GB de memoria.
  • Si las inserciones, actualizaciones o eliminaciones de la base de datos son lentas, compruebe las ubicaciones del escritor y de la base de datos. El envío de datos a largas distancias introduce latencia.

• Mejora el rendimiento de las consultas mediante el panel de control predefinido de Query Insights en Cloud Monitoring (o funciones integradas similares del motor de base de datos). Identifica los comandos más caros e intenta optimizarlos.

• Evita que los archivos de la base de datos sean innecesariamente grandes. Defina autogrow en MB en lugar de como porcentaje, con incrementos adecuados al requisito.

• Comprueba la ubicación del lector y de la base de datos. La latencia afecta al rendimiento de lectura más que al de escritura.

• Evita la fragmentación de datos e índices. Programa una tarea para recompilar los índices en SQL Server en función de la frecuencia con la que cambien tus datos.

• Cambia los ajustes específicos del motor de SQL Server para que funcionen de forma óptima en Cloud SQL.

• Para obtener información sobre el mantenimiento de índices y estadísticas, consulta Solución de mantenimiento de SQL Server.

• Actualiza las estadísticas periódicamente en Cloud SQL para SQL Server.

• Te recomendamos que realices operaciones de ETL en una réplica de lectura, ya que pueden afectar a la caché de tu instancia.

Para obtener más información sobre cómo aumentar el rendimiento, consulta la sección Rendimiento de "Diagnosticar problemas" y el artículo Análisis del rendimiento y ajuste de consultas de Cloud SQL para SQL Server.

Aumentar las funciones de observabilidad de bases de datos

Diagnosticar y solucionar problemas en aplicaciones que se conectan a instancias de bases de datos puede ser difícil y llevar mucho tiempo. Por este motivo, es fundamental contar con un lugar centralizado donde todos los miembros del equipo puedan ver lo que ocurre a nivel de base de datos e instancia. Puede monitorizar las instancias de Cloud SQL de las siguientes formas:

• Cloud SQL usa agentes personalizados de memoria integrados para recoger telemetría de consultas.

  • Usa Cloud Monitoring para recoger mediciones de tu servicio y de los Google Cloudrecursos que utilices. Cloud Monitoring incluye paneles de control predefinidos para varios productos de Google Cloud , incluido un panel de control de monitorización de Cloud SQL.
  • Puedes crear paneles de control personalizados que te ayuden a monitorizar métricas y configurar políticas de alertas para recibir notificaciones oportunas.
  • También puedes usar soluciones de monitorización de terceros integradas con Google Cloud, como Datadog y Splunk.

• Cloud Logging recoge datos de registro de componentes de aplicaciones comunes.

• Cloud Trace recoge datos de latencia y planes de consulta ejecutados de las aplicaciones para ayudarte a monitorizar cómo se propagan las solicitudes por tu aplicación.

• Database Center proporciona una vista general centralizada de la flota de bases de datos asistida por IA. Puedes monitorizar el estado de tus bases de datos, la configuración de la disponibilidad, la protección de datos, la seguridad y el cumplimiento de normativas del sector.

• Ver y consultar los registros de tu instancia de Cloud SQL.

• Observa el estado de tus bases de datos para mejorar el rendimiento de tu entorno y solucionar posibles problemas.

Prácticas recomendadas y directrices operativas generales de Cloud SQL

Aplica las prácticas recomendadas de Cloud SQL para configurar y optimizar la base de datos.

Estas son algunas recomendaciones generales importantes de Cloud SQL:

• Si tienes instancias grandes, te recomendamos que las dividas en instancias más pequeñas siempre que sea posible.
• Configura el almacenamiento para que se adapte al mantenimiento crítico de la base de datos. Asegúrate de tener al menos un 20% de espacio disponible para las operaciones de mantenimiento críticas de la base de datos que pueda realizar Cloud SQL.
• Si hay demasiadas tablas de bases de datos, el tiempo de actualización de la base de datos puede verse afectado. Lo ideal es que haya menos de 10.000 tablas por instancia.
• Elige el tamaño adecuado para tus instancias para tener en cuenta la conservación de los registros de transacciones (binarios), sobre todo en el caso de las instancias con una alta actividad de escritura.

Para poder gestionar de forma eficiente cualquier problema de rendimiento de la base de datos que pueda surgir, siga estas directrices hasta que se resuelva el problema:

Escalar verticalmente la infraestructura: aumenta los recursos (como el rendimiento del disco, la vCPU y la RAM). En función de la urgencia, la disponibilidad y la experiencia de tu equipo, puedes resolver la mayoría de los problemas de rendimiento escalando verticalmente tu instancia. Más adelante, puedes investigar más a fondo la causa principal del problema en un entorno de prueba y plantearte opciones para eliminarlo.

Realizar y programar operaciones de mantenimiento de bases de datos: desfragmentación de índices, actualizaciones de estadísticas, análisis de vacío y reindexación de tablas que se hayan actualizado mucho. Comprueba si se han realizado estas operaciones de mantenimiento y cuándo, sobre todo en los objetos afectados (tablas e índices). Descubre si ha habido algún cambio en las actividades normales de la base de datos. Por ejemplo, si has añadido una columna recientemente o si una tabla tiene muchas actualizaciones.

Ajustar y optimizar la base de datos: ¿las tablas de tu base de datos están estructuradas correctamente? ¿Las columnas tienen los tipos de datos correctos? ¿Es el modelo de datos adecuado para el tipo de carga de trabajo? Investiga tus consultas lentas y sus planes de ejecución. ¿Están usando los índices disponibles? Comprueba si hay análisis de índices, bloqueos y esperas en otros recursos. Te recomendamos que añadas índices para admitir tus consultas críticas. Elimina los índices y las claves externas no críticos. Considera la posibilidad de reescribir consultas y uniones complejas. El tiempo que se tarda en resolver tu problema depende de la experiencia y la disponibilidad de tu equipo, y puede variar de horas a días.

Escala horizontalmente las lecturas: considera la posibilidad de tener réplicas de lectura. Si el escalado vertical no es suficiente para tus necesidades y las medidas de ajuste y optimización de la base de datos no te ayudan, considera la posibilidad de usar el escalado horizontal. Dirigir las consultas de lectura de tus aplicaciones a una réplica de lectura mejora el rendimiento general de la carga de trabajo de tu base de datos. Sin embargo, puede que tengas que hacer más ajustes para que tus aplicaciones se conecten a la réplica de lectura.

Reestructuración de la base de datos: plantéate particionar e indexar la base de datos. Esta operación requiere mucho más esfuerzo que la optimización de la base de datos y puede implicar una migración de datos, pero puede ser una solución a largo plazo. A veces, un diseño deficiente del modelo de datos puede provocar problemas de rendimiento, que se pueden compensar parcialmente con un escalado vertical. Sin embargo, un modelo de datos adecuado es una solución a largo plazo. Considera la posibilidad de crear particiones en tus tablas. Archiva los datos que ya no necesites, si es posible. Normaliza la estructura de tu base de datos, pero recuerda que la desnormalización también puede mejorar el rendimiento.

Partición de bases de datos: puedes escalar las escrituras particionando tu base de datos. El particionado es una operación compleja que implica rediseñar la arquitectura de tu base de datos y tus aplicaciones de una forma específica, así como migrar los datos. Divide tu instancia de base de datos en varias instancias más pequeñas mediante un criterio de partición específico. Los criterios pueden basarse en el cliente o en el asunto. Esta opción te permite escalar horizontalmente tanto las escrituras como las lecturas. Sin embargo, aumenta la complejidad de las cargas de trabajo de la base de datos y de las aplicaciones. También puede provocar que se creen particiones desequilibradas, llamadas puntos de acceso, que superen las ventajas de la partición.

En el caso de Cloud SQL para SQL Server, ten en cuenta las siguientes prácticas recomendadas:

• Para actualizar la configuración de SQL Server y optimizar el rendimiento con Cloud SQL, consulta la sección Configuración de SQL Server.
• Determina la capacidad del subsistema de E/S antes de implementar SQL Server.

• Si tiene instancias grandes, divídalas en instancias más pequeñas siempre que sea posible:

  • Un tamaño de disco de 4 TB o más proporciona más rendimiento y IOPS.
  • Cuanto mayor sea el número de vCPUs, mayor será el número de IOPS y el rendimiento. Cuando se usa una vCPU superior, se deben monitorizar las esperas de la base de datos para el paralelismo, que también pueden aumentar.

• Desactiva SMT si el rendimiento se reduce en algunas situaciones. Por ejemplo, si una aplicación ejecuta subprocesos que se convierten en un cuello de botella y la arquitectura de la CPU no gestiona esta situación de forma eficaz.

• Programa una tarea para reorganizar o volver a generar los índices en función de la frecuencia con la que cambien tus datos.

• Establece un factor de relleno adecuado para reducir la fragmentación. Monitoriza SQL Server para detectar índices que falten y que puedan mejorar el rendimiento.

• Evita que los archivos de la base de datos sean innecesariamente grandes. Defina autogrow en MB en lugar de como porcentaje, con incrementos adecuados al requisito. Además, gestiona de forma proactiva el crecimiento de la base de datos antes de que se alcance el umbral de autogrow.

• Para escalar la capacidad de almacenamiento automáticamente, habilita los aumentos automáticos de almacenamiento. Cloud SQL puede añadir espacio de almacenamiento si la base de datos y la instancia se quedan sin espacio.

• Asegúrese de que conoce los requisitos de configuración regional, el orden de clasificación y la sensibilidad a las mayúsculas y minúsculas y a los acentos de los datos con los que trabaja. Cuando seleccionas una intercalación para tu servidor, base de datos, columna o expresión, asignas determinadas características a tus datos.

• Las combinaciones de hash recursivas o los errores de hash provocan una reducción del rendimiento en un servidor. Si ves muchos eventos de advertencia de hash en un rastreo, actualiza las estadísticas de las columnas que se están combinando. Para obtener más información, consulta Clase de evento de advertencia de hash.

Para obtener más información, consulta las prácticas recomendadas generales y las directrices operativas de Cloud SQL para SQL Server.

Siguientes pasos

• Consulta información sobre otros procesos de migración de AWS Google Cloud .
• Consulta cómo comparar los servicios de AWS y Azure con Google Cloud.
• Consulta cuándo pedir ayuda para tus migraciones.
• Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.

Colaboradores

Autores:

• Alex Cârciu | Arquitecto de soluciones
• Marco Ferrari | Arquitecto de soluciones en la nube

Otros colaboradores:

• Derek Downey | Ingeniero de relaciones con desarrolladores
• Paweł Krentowski | Redactor técnico
• Matthew Smith | Ingeniero estratégico de Cloud
• Somdyuti Paul | Especialista en gestión de datos
• Zach Seils | Especialista en redes