Google Cloud proporciona herramientas, productos, orientación y servicios profesionales para migrar de Amazon Relational Database Service (RDS) a Cloud SQL para SQL Server.
Este documento está dirigido a los administradores de bases de datos y de la nube que deseen planificar, implementar y validar un proyecto de migración de bases de datos. También está dirigido a los encargados de tomar decisiones que evalúan la oportunidad de migrar y que desean un ejemplo de cómo podría ser una migración.
En este documento, se enfoca en una 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 de base de datos. La fuente es Amazon RDS para SQL Server y el destino es Cloud SQL para SQL Server.
Este documento es parte de una serie de varias partes sobre la migración de AWS aGoogle Cloud que incluye los siguientes documentos:
- Comenzar
- Migra de Amazon EC2 a Compute Engine
- Migra de Amazon S3 a Cloud Storage
- Migra de Amazon EKS a GKE
- Migra de Amazon RDS y Amazon Aurora para MySQL a Cloud SQL para MySQL
- Migra de Amazon RDS y Amazon Aurora para PostgreSQL a Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL
- Migra de Amazon RDS para SQL Server a Cloud SQL para SQL Server (este documento)
- Migra de AWS Lambda a Cloud Run
Para esta migración a Google Cloud, te recomendamos que sigas el framework de migración que se describe en Migra a Google Cloud: Comienza ahora.
En el siguiente diagrama, se ilustra la ruta del 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 tarde. Para cada iteración de migración independiente, debes seguir las fases del framework de migración general:
- Evalúa y descubre las cargas de trabajo y los datos.
- Planifica y compila una base en Google Cloud.
- Migra tus cargas de trabajo y datos a Google Cloud.
- Optimiza tu Google Cloud entorno.
Para obtener más información sobre las fases de este framework, consulta Migra a Google Cloud: Comienza ahora.
Para diseñar un plan de migración eficaz, te recomendamos que valides cada paso del plan y te asegures de tener una estrategia de reversión. Para ayudarte a validar tu plan de migración, consulta Migra a Google Cloud: prácticas recomendadas para validar un plan de migración.
Evalúa el entorno de origen|
En la fase de evaluación, determinarás los requisitos y las dependencias para migrar tu entorno de origen a Google Cloud.
La fase de evaluación es fundamental para el éxito de la migración. Debes obtener un conocimiento profundo sobre las cargas de trabajo que deseas migrar, sus requisitos, sus dependencias y tu entorno actual. Debes saber cuál es tu punto de partida para planificar y ejecutar de forma correcta una migración de Google Cloud.
La fase de evaluación consta de las siguientes tareas:
- Crea un inventario completo de tus aplicaciones.
- Cataloga tus cargas de trabajo según sus propiedades y dependencias.
- Capacita y educa a tus equipos sobre Google Cloud.
- Crea experimentos y pruebas de concepto en Google Cloud.
- Calcula el costo total de propiedad (TCO) del entorno de destino.
- Elige la estrategia de migración para tus cargas de trabajo.
- Elige tus herramientas de migración.
- Define el plan y el cronograma de migración.
- Valida tu plan de migración.
Para obtener más información sobre la fase de evaluación y estas tareas, consulta Migra a Google Cloud: Evalúa y descubre tus 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 coincida con la fuente para necesidades de rendimiento similares. Presta especial atención al tamaño del disco y la capacidad de procesamiento, IOPS y la cantidad de CPU virtuales. Es posible que las migraciones tengan problemas o fallen debido al tamaño incorrecto de la instancia de la base de datos de destino. Un tamaño incorrecto puede generar tiempos de migración largos, problemas de rendimiento de la base de datos, errores de la base de datos y problemas de rendimiento de la aplicación. Cuando decidas qué instancia de Cloud SQL usar, ten en cuenta que el rendimiento del disco se basa en el tamaño del disco y la cantidad de CPU virtuales.
Las siguientes secciones se basan en Migración a Google Cloud: Evalúa y descubre tus cargas de trabajo, y también integran la información de ese documento.
Crea un inventario de tus instancias de Amazon RDS
Para definir el alcance de la migración, crea un inventario y recopila información sobre tus instancias de Amazon RDS. Idealmente, el proceso debería estar automatizado, ya que los enfoques manuales son propensos a errores y pueden generar suposiciones incorrectas.
Es posible que Amazon RDS y Cloud SQL no tengan funciones, especificaciones ni operaciones similares. Es posible que algunas funciones se implementen de manera diferente o no estén disponibles. Las áreas de diferencia pueden incluir la infraestructura, el almacenamiento, la autenticación y la seguridad, la replicación, las copias de seguridad, la alta disponibilidad, el modelo de capacidad de recursos y las integraciones y extensiones específicas de funciones del motor de base de datos. Según el 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 la configuración de parámetros de la base de datos.
Las comparativas pueden ayudarte a comprender mejor las cargas de trabajo que se migrarán y a definir la arquitectura correcta del entorno de destino de la migración. Recopilar información sobre el rendimiento es importante para ayudar a estimar las necesidades de rendimiento del Google Cloud entorno objetivo. Los conceptos y las herramientas de comparativas se detallan en la fase Realizar pruebas y validación del proceso de migración, pero también se aplican a la etapa de compilación del inventario.
Herramientas para las evaluaciones
Para obtener una evaluación general inicial de tu infraestructura actual, te recomendamos que uses el Centro de migraciones de Google Cloud junto con otras herramientas especializadas de evaluación de bases de datos, como migVisor y la herramienta de evaluación de migración de bases de datos (DMA).
Con Migration Center, puedes realizar una evaluación completa de tu aplicación y el panorama de bases de datos, incluido el ajuste técnico para una migración de bases de datos a Google Cloud. Recibirás recomendaciones de tamaño y configuración para cada base de datos de origen y crearás un informe de costo total de propiedad (TCO) para 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 Importa datos de otros proveedores de servicios en la nube.
Además del Centro de migraciones, puedes usar la herramienta especializada migVisor. migVisor admite una variedad de motores de bases de datos y es particularmente 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 causar que la migración se establezca de forma predeterminada y puede indicar soluciones alternativas. migVisor también puede recomendar una solución Google Cloud objetivo, incluido el tamaño y la arquitectura iniciales.
El resultado de la evaluación de la base de datos de migVisor proporciona lo siguiente:
- Descubrimiento y análisis integrales de las implementaciones de bases de datos actuales.
- Informe detallado de la complejidad de la migración, basado en las funciones proprietarias que usa tu base de datos.
- Informe financiero con detalles sobre los ahorros en costos después de la migración, los costos de migración y el nuevo presupuesto operativo.
- Plan de migración por fases para mover bases de datos y aplicaciones asociadas con una interrupción mínima para la empresa
Para ver algunos ejemplos de resultados de la evaluación, consulta migVisor: Herramienta de evaluación de migración a la nube.
Ten en cuenta que migVisor aumenta temporalmente el uso del servidor de base de datos. Por lo general, esta carga adicional es inferior al 3% y se puede ejecutar durante las horas de menor demanda.
El resultado de la evaluación de migVisor te ayuda a crear un inventario completo de tus 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 parámetros y las personalizaciones especiales en uso.
Si prefieres usar herramientas de código abierto, puedes usar secuencias de comandos de recopilador de datos con las herramientas mencionadas (o en su lugar). Estas secuencias de comandos pueden ayudarte a recopilar información detallada (sobre cargas de trabajo, funciones, objetos y código de bases de datos) y a compilar el inventario de tu base de datos. Además, las secuencias de comandos suelen proporcionar una evaluación detallada de la migración de bases de datos, incluida una estimación del esfuerzo de migración.
Recomendamos la herramienta de código abierto DMA, que crearon los ingenieros de Google. Ofrece una evaluación completa y precisa de la base de datos, incluidos los atributos en uso, la lógica de la base de datos y los objetos de la base de datos (incluidos los esquemas, las tablas, las vistas, las funciones, los activadores y los procedimientos almacenados).
Para usar DMA, descarga las secuencias de comandos de recopilación de tu motor de base de datos del repositorio de Git y sigue las instrucciones. Envía los archivos de salida a Google Cloud para su análisis. Google Cloud crea y entrega una lectura de evaluación de la base de datos y proporciona los próximos pasos en el proceso de migración.
Identifica y documenta el alcance de la migración y el tiempo de inactividad asequible
En esta etapa, documentas la información esencial que influye en tu estrategia y herramientas de migración. A estas alturas, puedes responder las siguientes preguntas:
- ¿Tus bases de datos superan los 5 TB?
- ¿Hay tablas grandes en tu base de datos? ¿Superan los 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?
- ¿Cuáles son las opciones para las bases de datos de destino?
- ¿Qué tan compatibles son las bases de datos de origen y de destino?
- ¿Los datos deben residir en algunas ubicaciones físicas?
- ¿Hay datos que se puedan comprimir y archivar, o hay datos que no necesitan migración?
Para definir el alcance de la migración, decide qué datos conservar y cuáles migrar. La migración de todas tus bases de datos puede requerir mucho tiempo y esfuerzo. Es posible que algunos datos permanezcan en las copias de seguridad de tu base de datos de origen. Por ejemplo, es posible que no se necesiten las tablas de registro antiguas ni los datos de archivo. Como alternativa, puedes decidir mover los datos después del proceso de migración, según tu estrategia y herramientas.
Establece modelos de referencia de migración de datos que te ayuden a comparar y evaluar tus resultados y los impactos. Estos modelos de referencia son puntos de referencia que representan el estado de tus datos antes y después de la migración y te 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. Estas mediciones incluyen lo siguiente:
- El tamaño y la estructura de tus datos
- La integridad y coherencia de tus datos.
- La duración y el rendimiento de las transacciones y los procesos comerciales más importantes
Determina cuánto tiempo de inactividad puedes permitirte. ¿Cuáles son los impactos comerciales de los tiempos de inactividad? ¿Hay períodos de baja actividad de la base de datos, durante los cuales hay menos usuarios afectados por el tiempo de inactividad? Si es así, ¿cuánto duran esos períodos y cuándo ocurren? Considera tener un tiempo de inactividad parcial de solo escritura mientras se siguen entregando las solicitudes de solo lectura.
Evalúa tu proceso de implementación y administración
Después de crear los inventarios, evalúa los procesos operativos y de implementación de tu base de datos para determinar cómo debes adaptarlos para facilitar la migración. Estos procesos son fundamentales para preparar y mantener tu entorno de producción.
Considera cómo completar las siguientes tareas:
- Define y aplica políticas de seguridad para tus instancias: Por ejemplo, es posible que debas reemplazar los grupos de seguridad de Amazon. Puedes usar los roles de IAM de Google, las reglas de firewall de VPC y los Controles del servicio de VPC para controlar el acceso a tus instancias de Cloud SQL y restringir los datos dentro de una VPC. Si planeas usar la autenticación de Windows con Cloud SQL para SQL Server, debes implementar Microsoft AD administrado y conectarte a tu infraestructura de Active Directory existente.
- Aplica parches y configura tus instancias: Es posible que debas actualizar tus herramientas de implementación existentes. Por ejemplo, es posible que uses parámetros de configuración personalizados en los grupos de parámetros o de opciones de Amazon. Es posible que tus herramientas de aprovisionamiento deban adaptarse para usar Google Cloud Storage o Secret Manager para leer esas listas de configuración personalizadas.
- Administra la infraestructura de supervisión y alertas: Las categorías de métricas de las instancias de la base de datos de origen de Amazon proporcionan visibilidad durante el proceso de migración. Las categorías de métricas pueden incluir Amazon CloudWatch, informes de rendimiento, supervisión mejorada y listas de procesos del SO.
Completa la evaluación
Después de compilar los inventarios de tu entorno de Amazon RDS, completa el resto de las actividades de la fase de evaluación como se describe en Migra a Google Cloud: Evalúa y descubre tus cargas de trabajo.
Planifica y compila tu base
En la fase de planificación y compilación, aprovisionarás y configurarás la infraestructura para hacer lo siguiente:
- Admite tus cargas de trabajo en tu entorno de Google Cloud .
- Conectar tu entorno de origen y tu entorno de Google Cloud para completar la migración
La fase de planificación y compilación se compone de las siguientes tareas:
- Compila una jerarquía de recursos.
- Configura la administración de identidades y accesos (IAM) de Google Cloud.
- Configura la facturación.
- Configura la conectividad de red.
- Endurece tu seguridad.
- Configurar el registro, la supervisión y las alertas
Para obtener más información sobre cada una de estas tareas, consulta Migra a Google Cloud: planifica y construye tu base.
Supervisión y alertas
Usa Cloud Monitoring de Google, que incluye paneles predefinidos para varios productos de Google Cloud Google Cloud, incluido un panel de supervisión de Cloud SQL. Como alternativa, puedes usar soluciones de supervisión de terceros integradas enGoogle Cloud, como Datadog y Splunk. Para obtener más información, consulta Acerca de la observabilidad de la base de datos.
Migra instancias de Amazon RDS para SQL Server a Cloud SQL para SQL Server
Para migrar tus instancias, haz lo siguiente:
Elige la estrategia de migración: replicación continua o mantenimiento programado.
Elige las herramientas de migración según la estrategia y los requisitos que hayas elegido.
Define el plan de migración y el cronograma para cada migración de base de datos, incluidas las tareas de preparación y ejecución.
Define las tareas de preparación que se deben realizar para garantizar que la herramienta de migración funcione correctamente.
Define las tareas de ejecución, que incluyen actividades de trabajo que implementan la migración.
Define situaciones de resguardo para cada tarea de ejecución.
Realiza pruebas y validaciones, que se pueden realizar en un entorno de pruebas separado.
Realiza la migración.
Realiza la transición a producción.
Limpia el entorno de origen y configura la instancia de destino.
Realizar el ajuste y la optimización
Cada fase se describe en las siguientes secciones.
Elige 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 de uso para cada base de datos:
- Mantenimiento programado (también llamado migración única): Este enfoque es ideal si puedes permitirte el tiempo de inactividad. Esta opción tiene un costo y una complejidad relativamente más 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, debes reiniciar el proceso, lo que prolonga el tiempo de inactividad.
Replicación continua (también llamada migración gradual): Para 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 segmentos, por lo que, si se produce una falla, 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. Considera una de las siguientes variaciones:
- Usar el enfoque Y (escritura y lectura), que es una forma de migración paralela, duplica los datos en las instancias de origen y de destino durante la migración.
- Usar un microservicio de acceso a datos, que reduce el esfuerzo de refactorización que requiere el enfoque Y (escritura y lectura).
Para obtener más información sobre las estrategias de migración de datos, consulta Cómo evaluar los enfoques de migración de datos.
En el siguiente diagrama, se muestra un diagrama de flujo basado en preguntas de ejemplo que podrías tener cuando decidas la estrategia de migración para una sola base de datos:
En el diagrama de flujo anterior, se muestran los siguientes puntos de decisión:
¿Puedes permitirte el tiempo de inactividad?
- De lo contrario, 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 el período de migración mientras migras datos? La ventana de migración representa la cantidad de tiempo que se necesita para crear una copia de seguridad de la base de datos, transferirla a Cloud SQL, restablecerla y, luego, cambiar tus aplicaciones.
- De lo contrario, 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 para diferentes bases de datos, incluso cuando se encuentran en la misma instancia. Una combinación de estrategias puede producir resultados óptimos. Por ejemplo, usa el enfoque de mantenimiento programado para migrar bases de datos pequeñas y que se usan con poca frecuencia, pero usa la replicación continua para las bases de datos esenciales, en las que tener tiempo de inactividad es costoso.
Por lo general, se considera que una migración se completó cuando se produce el cambio entre la instancia de origen inicial y la instancia de destino. Se detiene cualquier replicación (si se usa) y se realizan todas las operaciones de lectura y escritura en la instancia de destino. Cambiar cuando ambas instancias están sincronizadas significa que no se pierden datos y se minimiza el tiempo de inactividad.
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.
Minimiza el tiempo de inactividad y los impactos relacionados con la migración
Las configuraciones de migración que no proporcionan tiempo de inactividad de la aplicación 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 trabajo con poco tráfico.
Cada estrategia de migración tiene una compensación y un impacto asociado con el proceso de migración. Por ejemplo, los procesos de replicación implican una carga adicional en tus instancias de origen, y tus aplicaciones podrían verse afectadas por el retraso de la replicación. Es posible que las aplicaciones (y los clientes) deban esperar durante el tiempo de inactividad de la aplicación, al menos mientras dure el retraso de replicación antes de usar la base de datos nueva. En la práctica, los siguientes factores podrían aumentar el tiempo de inactividad:
- Las consultas a la base de datos pueden tardar unos segundos en completarse. En el momento de la migración, es posible que se aborten las consultas en tránsito.
- La caché puede tardar un tiempo en llenarse si la base de datos es grande o tiene una memoria de búfer sustancial.
- Es posible que las aplicaciones que se detuvieron en la fuente y se reiniciaron en Google Cloud tengan un pequeño retraso hasta que se establezca la conexión a la instancia de la base de datos Google Cloud.
- Se deben volver a enrutar las rutas de red a las aplicaciones. Según la configuración de las entradas de DNS, esto puede tardar un poco. Cuando actualices los registros DNS, reduce el TTL antes de la migración.
Las siguientes prácticas comunes pueden ayudar a minimizar el tiempo de inactividad y el impacto:
- Busca un período en el que el tiempo de inactividad tenga un impacto mínimo en tus cargas de trabajo. Por ejemplo, fuera del horario de atención habitual, durante los fines de semana o en otros períodos de mantenimiento programados.
- Identifica las partes de tus cargas de trabajo que pueden someterse a la migración y la migración a producción en diferentes etapas. Tus aplicaciones pueden tener diferentes componentes que se pueden aislar, adaptar y migrar sin ningún impacto. Por ejemplo, frontends, módulos de CRM, servicios de backend y plataformas de informes. Estos módulos podrían tener sus propias bases de datos que se pueden programar para la migración antes o después en el proceso.
- Si puedes permitirte una latencia en la base de datos de destino, considera 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 inactivos en la instancia de destino.
- Considera refactorizar tus aplicaciones para admitir un impacto mínimo de migración. Por ejemplo, adapta tus aplicaciones para escribir en las bases de datos de origen y de destino y, por lo tanto, implementa una replicación a nivel de la aplicación.
Elige tus herramientas de migración
El factor más importante para que una migración sea exitosa es elegir la herramienta de migración correcta. Una vez que se decida la estrategia de migración, revisa y elige la herramienta de migración.
Existen muchas herramientas disponibles, cada una optimizada para ciertos casos de uso de migración. Los casos de uso pueden incluir lo siguiente:
- Estrategia de migración (mantenimiento programado o replicación continua)
- Motores y versiones de los motores de bases de datos de origen y destino
- Son los entornos en los que se encuentran las instancias de origen y de destino.
- Tamaño de la base de datos Cuanto más grande sea la base de datos, más tiempo llevará migrar la copia de seguridad inicial.
- Frecuencia de los cambios en la base de datos.
- Disponibilidad para usar servicios administrados para la migración
Para garantizar una migración y una transición sin problemas, puedes usar patrones de implementación de aplicaciones, organización de la infraestructura y aplicaciones de migración personalizadas. Sin embargo, las herramientas especializadas llamadas servicios de migración administrada pueden facilitar el proceso de traslado de datos, aplicaciones o incluso infraestructuras completas de un entorno a otro. Ejecutan la extracción de datos desde las bases de datos de origen, transportan los datos de forma segura a las bases de datos de destino y, de manera opcional, pueden modificar los datos durante el envío. Con estas funciones, encapsulan la lógica compleja de la migración y ofrecen capacidades de supervisión de la migración.
Los servicios de migración administrada proporcionan las siguientes ventajas:
Minimiza el tiempo de inactividad: Los servicios usan las capacidades 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 seguridad de los datos: Los datos se transfieren de forma segura y confiable de la fuente a la base de datos de destino.
Proporciona una experiencia de migración coherente: Se pueden consolidar diferentes técnicas y patrones de migración en una interfaz coherente y común mediante ejecutables de migración de bases de datos, que puedes administrar y supervisar.
Ofrece modelos de migración resilientes y probados: Las migraciones de bases de datos son eventos poco frecuentes, pero fundamentales. Para evitar errores de principiantes y problemas con las soluciones existentes, puedes usar herramientas de expertos con experiencia, en lugar de crear una solución personalizada.
Optimiza los costos: Los servicios de migración administrados 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 herramientas de migración, que dependen de la estrategia de migración elegida.
Herramientas para migraciones de mantenimiento programadas
En las siguientes sub secciones, se describen las herramientas que se pueden usar para las migraciones únicas, junto con sus limitaciones y prácticas recomendadas.
Copias de seguridad del motor de base de datos integradas
Cuando se acepta un tiempo de inactividad significativo y tus bases de datos de origen son relativamente estáticas, puedes usar las funciones integradas de copia de seguridad y restablecimiento del motor de base de datos.
Se requiere cierto esfuerzo para la configuración y la sincronización, en especial para una gran cantidad 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 cualquier tamaño de base de datos y, por lo general, es 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 ser propensas a errores, en especial si se realizan de forma manual.
- Los datos no están protegidos si las copias de seguridad no se administran correctamente.
- Las copias de seguridad carecen de capacidades de supervisión adecuadas.
Si eliges este enfoque, ten en cuenta las siguientes restricciones y prácticas recomendadas:
- Para las copias de seguridad de bases de datos de más de 5 TB, usa una copia de seguridad con rayas (una copia de seguridad de varios archivos).
- Cuando usas una copia de seguridad segmentada, no puedes crear copias de seguridad ni restablecer desde más de 10 archivos de copia de seguridad al mismo tiempo.
- Debes crear una copia de seguridad en un bucket de Amazon S3 en la misma región de Amazon de la instancia de la base de datos de origen.
- Las copias de seguridad no incluyen los accesos, los permisos ni los roles de servidor de SQL Server, ya que se encuentran a nivel de la instancia. Para transferir este tipo de datos de la instancia de origen a la instancia de destino, usa secuencias de comandos de PowerShell o herramientas como DBAtools.
Para obtener detalles 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
El uso de otros enfoques podría proporcionar más control y flexibilidad en tu proceso de migración de mantenimiento programado.
Por ejemplo, si usas archivos planos para exportar e importar tus datos (o si usas secuencias de comandos personalizadas), puedes hacer lo siguiente:
- Realizar transformaciones, verificaciones y otras operaciones en tus datos durante la migración Por ejemplo, validaciones, agregaciones o normalización y desnormalización en tus datos de origen.
- Elige las estructuras que deseas migrar y las que quieres conservar. Puedes extraer solo un subconjunto de tus tablas en archivos planos para la importación.
- Elige filtrar los datos según el dominio, la fuente, la edad o cualquier otro criterio personalizado. Por ejemplo, puedes excluir los datos que alcanzan 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 incurrido 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 mitigar los costos operativos y facilitar los problemas de escalabilidad. Por ejemplo, es posible que desees cambiar tu enfoque de tener una instancia, una base de datos o un esquema por cliente a una sola estructura de base de datos optimizada para multitenancy.
Otros enfoques incluyen los siguientes:
Usa archivos CSV o JSON: Con este enfoque, extraes los datos de la base de datos en los archivos y, luego, los importas a tus instancias de destino.
- Si bien, por lo general, es más lento, este método te ayuda a migrar un subconjunto de tablas (o datos dentro de una tabla determinada).
- Muchas herramientas comprenden los formatos CSV y JSON.
- Si automatizas el proceso, tienes la opción de migrar a una replicación continua por lotes.
Usa el Asistente de importación y exportación 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 planos.
Usa el Asistente para generar y publicar secuencias de comandos de SQL Server y la utilidad bcp: Esta herramienta forma parte de Microsoft SQL Server Management Studio.
- Este enfoque te permite crear secuencias de comandos para todo el esquema de la base de datos o solo para partes de ella.
- La utilidad bcp te permite crear secuencias de comandos para los datos y exportarlos a archivos.
Usa la replicación de instantáneas si tu fuente usa Amazon RDS Standard:
- Con este enfoque, restableces la copia de seguridad de SQL Server de la instancia de RDS a otra instancia independiente de SQL Server en Compute Engine. Luego, usa la replicación de instantáneas para migrar a Cloud SQL para SQL Server.
- La generación de instantáneas mantiene bloqueos en las tablas fuente, lo que puede afectar tus cargas de trabajo.
- La replicación de instantáneas puede generar cargas adicionales en tu servidor de Amazon RDS.
- Sin embargo, puedes elegir qué objetos se migran o replican, lo que proporciona flexibilidad.
- Para obtener más información, consulta Migra datos de SQL Server 2017 a Cloud SQL para SQL Server mediante la replicación de instantáneas.
Herramientas para migraciones de replicación continua
En el siguiente diagrama, se muestra un diagrama de flujo con 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 administrados?
- Si es así, continúa con la siguiente decisión. Si puedes permitirte un tiempo de inactividad mínimo y no necesitas transformación de datos ni sincronización en tiempo real, te recomendamos Database Migration Service. De lo contrario, explora las opciones de terceros.
- De lo contrario, continúa con la siguiente decisión. Si se admite la replicación integrada del motor de base de datos, te recomendamos que uses la replicación integrada. De lo contrario, 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.
- De lo contrario, explora las opciones de terceros.
¿Se admite la replicación integrada específica del motor de base de datos?
- Si es así, te recomendamos usar la replicación integrada.
- De lo contrario, 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 continuas, 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 la fuente es Amazon RDS.
Database Migration Service es una herramienta rentable y sencilla. Recomendamos Database Migration Service para las siguientes situaciones:
- Puedes permitirte un tiempo de inactividad mínimo.
- No necesitas sincronización en tiempo real.
- No es necesario que realices transformaciones de datos durante la migración.
Si eliges esta herramienta, ten en cuenta las siguientes restricciones y prácticas recomendadas:
- La cantidad de 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 a nivel de la instancia. Escríbelos desde la instancia de origen y, luego, transfiérelos a la instancia de destino con secuencias de comandos de PowerShell o herramientas como DBAtools.
Para obtener una lista completa de limitaciones, consulta Limitaciones conocidas.
Replicación integrada del motor de base de datos
Cloud SQL admite la replicación para SQL Server. Sin embargo, Amazon RDS estándar para SQL Server solo puede ser un suscriptor. La replicación integrada de Amazon RDS Standard no está disponible. Solo Amazon RDS Custom para SQL Server se puede configurar como editor integrado.
Para obtener 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
Entre otros enfoques de migración de replicación continua, se incluyen los siguientes:
Refactoriza tus aplicaciones para realizar Y (escritura y lectura) o usa un microservicio de acceso a datos.
- Tus aplicaciones realizan la replicación continua.
- El esfuerzo de migración se enfoca en la refactorización o el desarrollo de herramientas que se conectan a tus instancias de bases de datos.
- Luego, las aplicaciones de lectura se refactorizan y se implementan de forma gradual para usar la instancia de destino.
Implementa funciones que consulten datos de forma periódica en tu instancia fuente, filtren solo los datos nuevos y escriban datos en archivos CSV, JSON o Parquet.
- Estos archivos se almacenan en un bucket de Google Cloud Storage.
- Los archivos se pueden escribir de inmediato en la instancia de base de datos de destino con funciones de Cloud Run.
- Las capacidades de la captura de datos modificados (CDC) pueden ayudarte a lograr 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. Estos casos pueden ser si prefieres usar un servicio de migración administrado y necesitas asegurarte de que la base de datos de destino siempre esté sincronizada en tiempo real con la fuente, o si necesitas transformaciones más complejas, como limpieza, reestructuración y adaptación de datos durante el proceso de migración.
Si decides usar una herramienta de terceros, elige una de las siguientes recomendaciones, que puedes usar para la mayoría de los motores de bases de datos.
Striim es una plataforma completa en memoria para recopilar, filtrar, transformar, enriquecer, agregar, analizar y entregar datos en tiempo real:
Ventajas:
- Controla grandes volúmenes de datos y migraciones complejas.
- Captura de datos modificados integrada para SQL Server
- Plantillas de conexión preconfiguradas y canalizaciones sin código
- Puede controlar bases de datos grandes y esenciales que operan con una carga transaccional pesada.
- Entrega “exactamente una vez”.
Desventajas:
- No es de código abierto.
- Puede ser costoso, en especial para 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 Operaciones de DDL compatibles y Notas y limitaciones de la evolución del esquema.
Para obtener más información sobre Striim, consulta Cómo ejecutar Striim en Google Cloud.
Debezium es una plataforma distribuida de código abierto para la CDC y puede transmitir cambios de datos a suscriptores externos:
Ventajas:
- Es de código abierto.
- Gran asistencia de la comunidad
- Rentabilidad.
- Control detallado de filas, tablas o bases de datos
- Se especializa en la captura de cambios en tiempo real a partir de registros de transacciones de bases de datos.
Desventajas:
- Requiere experiencia específica con Kafka y ZooKeeper.
- Entrega de cambios de datos al menos una vez, lo que significa que necesitas controlar los duplicados.
- Configuración de supervisión manual con Grafana y Prometheus
- No se admite la replicación por lotes incremental.
Para obtener más información sobre las migraciones de Debezium, consulta Replicación de datos en tiempo casi real con Debezium.
Fivetran es una plataforma de transferencia de datos automatizada para transferir datos desde y entre plataformas de datos en la nube.
Ventajas:
- Plantillas de conexión preconfiguradas y canalizaciones sin código
- Propagan los cambios de esquema de la fuente a la base de datos de destino.
- Entrega de tus datos exactamente una vez, lo que significa que no necesitas controlar los duplicados.
Desventajas:
- No es de código abierto.
- La compatibilidad con la transformación de datos complejos es limitada.
Define el plan y el cronograma de migración
Para que la migración de la base de datos y la migración a producción se realicen correctamente, te recomendamos que prepares un plan de migración integral y bien definido. Para reducir el impacto en tu empresa, te recomendamos que crees una lista de todos los elementos de trabajo necesarios.
Definir el alcance de la migración revela las tareas de trabajo que debes realizar antes, durante y después del proceso de migración de la base de datos. Por ejemplo, si decides no migrar ciertas tablas de una base de datos, es posible que necesites tareas previas o posteriores a la migración para implementar este filtrado. También te aseguras de que la migración de la base de datos no afecte tu Acuerdo de Nivel de Servicio (ANS) y tu plan de continuidad del negocio existentes.
Te recomendamos que tu documentación de planificación de migración incluya los siguientes documentos:
- Documento de diseño técnico (TDD)
- Matriz RACI
- Cronograma (como un plan de T menos)
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, aunque pueden surgir problemas imprevistos. Te recomendamos que siempre tengas un plan de rollback. Como práctica recomendada, sigue las instrucciones de Migra a Google Cloud: Prácticas recomendadas para validar un plan de migración.
TDD
La TDD documenta todas las decisiones técnicas que se deben tomar para el proyecto. Incluye lo siguiente en la TDD:
- Requisitos y criticidad del negocio
- 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 la validación de la migración
Matriz RACI
Algunos proyectos de migración requieren una matriz RACI, que es un documento común de administración de proyectos que define qué personas o grupos son responsables de las tareas y entregas dentro del proyecto de migración.
Cronograma
Prepara un cronograma para cada base de datos que se deba migrar. Incluye todas las tareas de trabajo que se deben realizar, y las fechas de inicio y finalización estimadas.
Para cada entorno de migración, te recomendamos que crees un plan para el día de la migración. Un plan de cuenta regresiva se estructura como un cronograma de cuenta regresiva y enumera todas las tareas necesarias para completar el proyecto de migración, junto con los grupos responsables y la duración estimada.
El cronograma debe tener en cuenta no solo la ejecución de las tareas de preparación previas a la migración, sino también las tareas de validación, auditoría o prueba que se realizan después de que se realiza 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 T menos podría verse de la siguiente manera:
Fecha | Fase | Categoría | Tasks | Rol | T menos | Estado |
---|---|---|---|---|---|---|
1/11/2023 | Antes de la migración | Evaluación | Crea un informe de evaluación | Equipo de descubrimiento | -21 | Completado |
7/11/2023 | Antes de la migración | Preparación del objetivo | Diseña el entorno de destino como se describe en el documento de diseño | Equipo de migración | -14 | Completado |
15/11/2023 | Antes de la migración | Administración de la empresa | Fecha de migración y aprobación de T-menos | Directivos | -6 | Completado |
18/11/2023 | Migración | Configura DMS | Cómo crear perfiles de conexión | Ingeniero de migración a la nube | -3 | Completado |
19/11/2023 | Migración | Configura DMS | Compila y, luego, inicia trabajos de migración | Ingeniero de migración a la nube | -2 | Sin iniciar |
19/11/2023 | Migración | Supervisa DMS | Supervisa los trabajos de DMS y los cambios de DDL en la instancia de origen | Ingeniero de migración a la nube | -2 | Sin iniciar |
21/11/2023 | Migración | DMS de migración de sistemas | Cómo ascender una réplica de DMS | Ingeniero de migración a la nube | 0 | Sin iniciar |
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 | Sin iniciar |
21/11/2023 | Migración | Prueba de la aplicación | Ejecuta pruebas de rendimiento y funciones | Equipo de migración | 0 | Sin iniciar |
22/11/2023 | Migración | Administración de la empresa | Validación de la migración: Aprobación o rechazo | Equipo de migración | 1 | Sin iniciar |
23/11/2023 | Después de la migración | Valida la supervisión | Configura la supervisión | Equipo de infraestructura | 2 | Sin iniciar |
25/11/2023 | Después de la migración | Seguridad | Cómo quitar la cuenta de usuario de DMS | Equipo de seguridad | 4 | Sin iniciar |
Múltiples migraciones de bases de datos
Si tienes varias bases de datos para migrar, tu plan de migración debe contener tareas para todas las migraciones.
Te recomendamos que comiences el proceso migrando una base de datos más pequeña, idealmente, que no sea fundamental. Este enfoque puede ayudarte a desarrollar tu conocimiento y confianza en el proceso y las herramientas de migración. También puedes detectar cualquier falla en el proceso en las primeras etapas del programa general de migración.
Si tienes varias bases de datos para migrar, los cronogramas se pueden paralelizar. Por ejemplo, para acelerar el proceso de migración, puedes optar por migrar un grupo de bases de datos pequeñas, estáticas o menos esenciales 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.
Define las tareas de preparación
Las tareas de preparación son todas las actividades que debes completar para cumplir con los requisitos previos de la migración. Si no completas las tareas de preparación, la migración no se puede realizar o la base de datos migrada podría no ser utilizable como resultado.
Las tareas de preparación se pueden categorizar de la siguiente manera:
- Preparación y requisitos previos de las instancias de Amazon RDS
- Preparación y requisitos previos de la base de datos de origen
- Configuración de Cloud SQL
- Configuración específica de la migración
Preparación de instancias de Amazon RDS y requisitos previos
Ten en cuenta las siguientes tareas comunes de configuración y requisitos previos:
- Según tu ruta de migración, es posible que debas permitir conexiones remotas en tus instancias de RDS. Si tu instancia de RDS está configurada para ser privada en tu VPC, debe existir una conectividad privada RFC 1918 entre Amazon y Google Cloud.
Es posible que debas configurar un nuevo grupo de seguridad para permitir conexiones remotas en los puertos requeridos.
- De forma predeterminada, en AWS, el acceso a la red está apagado para las instancias de bases de datos.
- Puedes especificar reglas en un grupo de seguridad que permitan el acceso desde un rango de direcciones IP, un puerto o un grupo de seguridad. Las mismas reglas se aplican a todas las instancias de base de datos asociadas con ese grupo de seguridad.
Para la replicación continua (transmisión de cambios a través de CDC), debes usar una instancia de RDS completa y no una réplica de lectura, con el CDC habilitado. Para obtener más información, consulta Cómo usar la captura de datos de cambios con SQL Server.
Si usas herramientas de terceros, por lo general, se requiere la configuración inicial antes de usarlas. Revisa la documentación de la herramienta de terceros.
Preparación y requisitos previos de la base de datos de origen
- 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, supervisa el uso del almacenamiento y asegúrate de tener espacio de almacenamiento adicional en el búfer.
- Documenta la configuración de los parámetros de la base de datos y aplícala en tu instancia de destino antes de realizar pruebas y validaciones de migración.
Realiza mediciones 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 tardan, en promedio, las consultas o transacciones importantes? ¿Cuánto tiempo durante las horas pico?
- Documenta las mediciones del modelo de referencia para compararlas más adelante y ayudarte a 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 dar de baja tu entorno de origen, o si aún lo necesitas para fines de resguardo.
Configuración de Cloud SQL
Elige cuidadosamente el tamaño y las especificaciones de la instancia de base de datos de Cloud SQL objetivo para que coincidan con la fuente y tengan necesidades de rendimiento similares. Presta especial atención al tamaño del disco y la capacidad de procesamiento, las IOPS y la cantidad de CPU virtuales. El tamaño incorrecto puede provocar tiempos de migración largos, 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 según Cloud SQL. En caso de que Cloud SQL no cumpla con tus requisitos, considera las opciones que incluyen 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 cuidadosamente el proyecto y la región de tus instancias de Cloud SQL objetivo. Las instancias de Cloud SQL no se pueden migrar entre proyectos y regiones de Google Cloud sin transferencia de datos.
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, la configuración del nivel de compatibilidad debe ser la misma para garantizar las mismas capacidades del motor.
Replica la información del usuario por separado si usas copias de seguridad del motor de base de datos integradas o Database Migration Service. Para obtener más información, consulta las limitaciones en la sección Respaldos específicos 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 destino. Asegúrate de comprender 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 valores de la instancia de Cloud SQL. Ten en cuenta que no todas las marcas deben 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 los siguientes vínculos:
- Prácticas recomendadas generales para SQL Server
- Opciones de configuración de instancias para SQL Server
- Marcas específicas del motor de base de datos para SQL Server
Configuración específica de la migración
Si usas la exportación y la importación de archivos para migrar, o bien la herramienta de migración de Database Migration Service, debes crear un bucket de Cloud Storage. El bucket almacena los archivos de copia de seguridad de la base de datos y del registro de transacciones. Para obtener más información sobre el uso del Servicio de migración de bases de datos, consulta Almacena archivos de copia de seguridad en un bucket 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 lograr a través de las opciones de conectividad documentadas.
Según tu situación y criticidad, es posible que debas implementar un caso de resguardo, que suele incluir revertir 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.
Para la mayoría de las herramientas de terceros, debes aprovisionar recursos específicos de migración. Por ejemplo, para Striim, debes usar Google Cloud Marketplace para comenzar. Luego, para configurar tu entorno de migración en Striim, puedes usar el diseñador de flujos para crear y cambiar aplicaciones, o bien puedes seleccionar una plantilla preexistente. Las aplicaciones también se pueden codificar con el lenguaje de programación Tungsten Query Language (TQL). Con un panel de validación de datos, puedes obtener una representación visual de los datos que controla tu aplicación de Striim.
Puedes retirar de servicio los recursos que conectan tu entorno de Amazon yGoogle Cloud después de que se complete y valide la migración.
Define las tareas de ejecución
Las tareas de ejecución implementan el trabajo de migración en sí. Las tareas dependen de la herramienta de migración que elijas, como se describe en las siguientes sub secciones.
Copias de seguridad del motor de base de datos integradas
Para obtener más información y las instrucciones para las copias de seguridad específicas de la base de datos, consulta Importa datos de un archivo BAK a Cloud SQL para SQL Server y Exporta datos de RDS para SQL Server. Para obtener más información sobre cómo automatizar las cargas de archivos de registro de transacciones, consulta Cómo programar cargas de archivos de registro de transacciones para Amazon RDS.
Trabajos de migración de Database Migration Service
Define y configura trabajos de migración en Database Migration Service para migrar datos de una instancia de origen a la base de datos de destino. Los trabajos 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 la tarea se pueda ejecutar correctamente. Elige un momento en el que tus cargas de trabajo puedan permitirse un pequeño tiempo de inactividad para la migración y la migración a producción.
El proceso de migración suele incluir las siguientes tareas:
- Exporta una copia de seguridad completa de la base de datos de origen y, luego, súbela a un bucket de Cloud Storage.
- Crea una copia de seguridad de los archivos de registro de transacciones y, luego, súbela al mismo bucket de Cloud Storage. Para obtener más información sobre cómo automatizar este proceso, consulta Cómo programar cargas de archivos de registro de transacciones para Amazon RDS.
- En Database Migration Service, supervisas el procesamiento de las copias de seguridad del registro de transacciones.
- Detén las operaciones de escritura en la base de datos de origen.
- Espera a que se sincronicen la fuente y el destino, que es cuando se procesa la copia de seguridad final del registro de transacciones.
- Detén la replicación en curso y promociona el trabajo de migración.Cuando se promociona un trabajo de migración, la instancia de Cloud SQL de destino se desconecta de la instancia de base de datos de origen y, luego, se promociona a una instancia principal.
- Implementa las aplicaciones que apuntan a la nueva base de datos de destino.
Para obtener un proceso de configuración de migración detallado, consulta Cómo migrar tus 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, es posible que debas migrar primero a la versión personalizada de Amazon RDS y, luego, replicar en Cloud SQL.
Cloud SQL admite la replicación para SQL Server. Para obtener más información sobre la replicación desde un servidor externo, consulta Migra datos de SQL Server 2017 a Cloud SQL para SQL Server mediante la replicación de instantáneas.
Herramientas de terceros
Define las tareas de ejecución para la herramienta de terceros que elegiste. Por ejemplo, si decides usar Striim, debes crear apps 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.
Define situaciones de resguardo
Define elementos de acción de resguardo para cada tarea de ejecución de migración para protegerte contra problemas imprevistos que puedan ocurrir durante el proceso de migración. Las tareas de resguardo suelen depender de la estrategia de migración y las herramientas que se usan.
El resguardo puede requerir un esfuerzo significativo. Como práctica recomendada, no realices la migración a producción hasta que los resultados de la prueba sean satisfactorios. Tanto la migración de la base de datos como la situación de resguardo deben probarse correctamente para evitar una interrupción grave.
Define los criterios de éxito y establece un tiempo límite para todas las tareas de ejecución de la migración. Realizar una prueba de migración ayuda a recopilar información sobre los tiempos esperados para cada tarea. Por ejemplo, en el caso de una migración de mantenimiento programada, puedes permitirte el tiempo de inactividad que representa el período de migración. Sin embargo, es importante planificar tu próxima acción en caso de que el trabajo de migración único o el restablecimiento de la copia de seguridad falle a mitad de camino. Según cuánto tiempo haya transcurrido del tiempo de inactividad planificado, es posible que debas posponer la migración si la tarea de migración no finaliza en el tiempo esperado.
Por lo general, un plan de resguardo hace referencia a revertir la migración después de realizar la migración a producción, si aparecen problemas en la instancia de destino. Si implementas un plan de resguardo, recuerda que debe tratarse como una migración de base de datos completa, lo que incluye la planificación y las pruebas.
Si decides no tener un plan de resguardo, asegúrate de comprender las posibles consecuencias. No tener un plan de resguardo puede agregar esfuerzo imprevisto y causar interrupciones evitables en el proceso de migración.
Si bien un resguardo es un último recurso, y la mayoría de las migraciones de bases de datos no terminan usándolo, te recomendamos que siempre tengas una estrategia de resguardo.
Resguardo simple
En esta estrategia de resguardo, vuelves a cambiar tus aplicaciones a la instancia original de la base de datos de origen. Adopta esta estrategia si puedes permitirte el tiempo de inactividad cuando realices el resguardo o si no necesitas que las transacciones se confirmen en el nuevo sistema de destino.
Si necesitas todos los datos escritos en la base de datos de destino y puedes permitirte un tiempo de inactividad, puedes considerar detener las operaciones de escritura en la instancia de la base de datos de destino, crear copias de seguridad integradas y restablecerlas en la instancia de origen, y, luego, volver a conectar tus aplicaciones a la instancia inicial de la base de datos de origen. Según la naturaleza de tu carga de trabajo y la cantidad de datos escritos en la instancia de la base de datos de destino, puedes transferirla a tu sistema de base de datos de origen inicial más adelante, en especial, si tus cargas de trabajo no dependen de un tiempo específico de creación de registros ni de ninguna restricción de orden de tiempo.
Replicación inversa
En esta estrategia, replicarás las operaciones de escritura que se realizan en la nueva base de datos de destino después de la migración a producción en tu base de datos de origen inicial. De esta manera, mantienes la fuente original sincronizada con la nueva base de datos de destino y se realizan las operaciones de escritura en la nueva instancia de la base de datos de destino. Su principal desventaja es que no puedes probar el flujo de replicación hasta después de la migración a la instancia de la base de datos de destino, por lo que no permite pruebas de extremo a extremo y tiene un pequeño período sin resguardo.
Elige este enfoque cuando aún puedas conservar tu instancia de origen durante algún tiempo y realices la migración con la migración de replicación continua.
Reenvío de replicación
Esta estrategia es una variación de la replicación inversa. Replicas las escrituras en tu nueva base de datos de destino en una tercera instancia de base de datos que elijas. 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, según tus necesidades. La ventaja de este enfoque es que se puede probar de extremo a extremo.
Adopta este enfoque cuando quieras tener un resguardo en todo momento o cuando debas descartar tu base de datos de origen inicial poco después de la migración a producción.
Operaciones de escritura duplicadas
Si eliges una estrategia de migración de microservicios de acceso a datos o Y (escritura y lectura), este plan de resguardo ya está configurado. Esta estrategia es más complicada, ya que debes refactorizar aplicaciones o desarrollar herramientas que se conecten a tus instancias de bases de datos.
Tus aplicaciones escriben en las instancias iniciales de la base de datos de origen y de destino, lo que te permite realizar una migración 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 tiempo de inactividad. Puedes descartar la fuente inicial y el mecanismo de escritura duplicado cuando consideres que la migración se realizó sin observar problemas.
Recomendamos este enfoque cuando es fundamental no tener tiempo de inactividad durante la migración, tener un resguardo confiable y cuando tienes tiempo y recursos para realizar la refactorización de la aplicación.
Realiza pruebas y validación
Los objetivos de este paso son probar y validar lo siguiente:
- Migración correcta de los datos en la base de datos
- Integración con aplicaciones existentes después de que se cambien para usar la nueva instancia de destino
Define los factores clave de éxito, que son subjetivos para tu migración. Los siguientes son ejemplos de factores subjetivos:
- Qué datos migrar Para algunas cargas de trabajo, es posible que no sea necesario migrar todos los datos. Es posible que no quieras migrar datos que ya están agregados, duplicados, archivados o son antiguos. Puedes archivar esos datos en un bucket de Cloud Storage, como copia de seguridad.
- Un porcentaje aceptable de pérdida de datos Esto se aplica en particular a los datos que se usan para las cargas de trabajo de análisis, en las que perder parte de los datos no afecta las tendencias generales ni el rendimiento de tus 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 comerciales sean más lentas en el entorno de destino, pero el tiempo de procesamiento sigue dentro de las expectativas definidas.
Es posible que las configuraciones de almacenamiento de tu entorno de origen no se asignen directamente a los destinos del entorno deGoogle Cloud . Por ejemplo, configuraciones de los volúmenes de SSD de uso general (gp2 y gp3) con rendimiento de ráfaga de IOPS o SSD con IOPS aprovisionados. Para comparar y ajustar correctamente el tamaño de las instancias de destino, compara las instancias de origen, tanto en las fases de evaluación como de validación.
En el proceso de comparativa, aplicas secuencias de operaciones similares a las de producción a las instancias de la base de datos. Durante este tiempo, capturas y procesas métricas para medir y comparar el rendimiento relativo de los sistemas de origen y destino.
Para las configuraciones convencionales basadas en servidores, usa las mediciones relevantes que se observaron durante las cargas máximas. En el caso de los modelos de capacidad de recursos flexibles, como Aurora sin servidores, considera consultar los datos históricos de las métricas para observar tus necesidades de escalamiento.
Las siguientes herramientas se pueden usar para las pruebas, la validación y las comparativas de bases de datos:
- HammerDB: Es una herramienta de comparativas y pruebas de carga de bases de datos de código abierto. Admite cargas de trabajo transaccionales y analíticas complejas, basadas en estándares de la industria, en varios motores de bases de datos (TPROC-C y TPROC-H). HammerDB tiene documentación detallada y una amplia comunidad de usuarios. Puedes compartir y comparar los resultados en varios motores de bases de datos y parámetros de configuración de almacenamiento. Para obtener más información, consulta Pruebas de carga de SQL Server con HammerDB y Comparación del rendimiento de Amazon RDS SQL Server con HammerDB.
- DBT2 Benchmark Tool: comparativa especializada para MySQL Un conjunto de kits de cargas de trabajo de bases de datos imita una aplicación para una empresa que posee almacenes y que implica una combinación de transacciones de lectura y escritura. Usa esta herramienta si deseas usar una prueba de carga de procesamiento de transacciones en línea (OLTP) prediseñada.
- DbUnit: Es una herramienta de prueba de unidades de código abierto que se usa para probar interacciones de bases de datos relacional 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 a veces, según el tamaño y la complejidad de la base de datos. Recomendamos esta herramienta cuando la simplicidad es importante.
- DbFit: Es 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. Usa una sintaxis básica para crear casos de prueba y cuenta con pruebas basadas en datos, control de versión y generación de informes de resultados de pruebas. Sin embargo, la compatibilidad con consultas y transacciones complejas es limitada y no tiene una gran compatibilidad con la comunidad ni una documentación extensa, en comparación con otras herramientas. Te recomendamos esta herramienta si tus consultas no son complejas y deseas realizar pruebas automatizadas y, luego, integrarlas a tu proceso de integración y entrega continua.
Para ejecutar una prueba de extremo a extremo, incluidas las pruebas del plan de migración, siempre realiza un ejercicio de prueba de migración. Una ejecución de prueba realiza la migración de bases de datos de alcance completo sin cambiar ninguna carga de trabajo de producción y ofrece las siguientes ventajas:
- Te permite asegurarte de que todos los objetos y parámetros de configuración se migren correctamente.
- Te ayuda a definir y ejecutar tus casos de prueba de migración.
- Ofrece estadísticas sobre el tiempo necesario para la migración real, de modo que puedas ajustar tu cronograma.
- Representa una oportunidad para probar, validar y adaptar el plan de migración. A veces, no puedes planificar todo con anticipación, por lo que esto te ayuda a detectar cualquier brecha.
Las pruebas de datos se pueden realizar en un conjunto pequeño de las bases de datos que se migrarán o en todo el conjunto. Según la cantidad total de bases de datos y las herramientas que se usen para implementar su migración, puedes decidir adoptar un enfoque basado en riesgos. Con este enfoque, realizas la validación de datos en un subconjunto de bases de datos que se migraron con la misma herramienta, en especial si esta es un servicio de migración administrado.
Para realizar pruebas, debes tener acceso a las bases de datos de origen y de destino, y realizar las siguientes tareas:
- Compara los esquemas de origen y de destino. Verifica si existen todas las tablas y los ejecutables. Verifica los recuentos de filas y compara los datos a nivel de la base de datos.
- Ejecuta secuencias de comandos de validación de datos personalizadas.
- Prueba que los datos migrados también sean visibles en las aplicaciones que cambiaron para usar 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 conmutadas y la base de datos de destino probando varios casos de uso. 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 la base de datos más usadas para observar si hay alguna degradación debido a parámetros de configuración incorrectos o un tamaño incorrecto.
Lo ideal es que todas estas situaciones de prueba de migración sean automatizadas y repetibles en cualquier sistema de origen. El paquete de casos de prueba automatizados se adapta para realizar pruebas en las aplicaciones conmutadas.
Si usas Database Migration Service como herramienta de migración, consulta Cómo verificar una migración.
Herramienta de validación de datos
Para realizar la validación de datos, te recomendamos que uses la Herramienta de validación de datos (DVT). La 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 DVT puede ayudar a optimizar el proceso de validación de datos, ya que ofrece funciones de validación personalizadas y de varios niveles para comparar las tablas de origen y destino a nivel de la tabla, la columna y la fila. También puedes agregar reglas de validación.
La DVT abarca muchas Google Cloud fuentes de datos, como AlloyDB para PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON y archivos CSV en Cloud Storage. También se puede integrar con Cloud Run Functions y Cloud Run para la activación y orquestación basadas en eventos.
La DVT admite los siguientes tipos de validaciones:
- Comparaciones a nivel del esquema
- Columna (incluidos "AVG", "COUNT", "SUM", "MIN", "MAX", "GROUP BY" y "STRING_AGG")
- Fila (incluye hash y concordancia exacta en las comparaciones de campos)
- Comparación de resultados de búsqueda personalizados
Para obtener más información sobre la DVT, consulta el repositorio de Git y Cómo facilitar la validación de datos con la herramienta de validación de datos de Google Cloud.
Realice la migración
Las tareas de migración incluyen las actividades para admitir la transferencia de un sistema a otro.
Ten en cuenta las siguientes prácticas recomendadas para la migración de datos:
- Informa a los equipos involucrados cada vez que comience y finalice un paso del plan.
- Si alguno de los pasos tarda más de lo esperado, compara el tiempo transcurrido con la cantidad máxima de tiempo asignado para ese paso. Cuando esto suceda, envía actualizaciones periódicas a los equipos involucrados.
- Si el período es mayor que la cantidad máxima de tiempo reservada para cada paso del plan, considera revertir el proceso.
- Toma decisiones de “adelante o atrás” para cada paso del plan de migración y de cambio.
- Considera acciones de reversión o situaciones alternativas para cada uno de los pasos.
Para realizar la migración, sigue las tareas de ejecución definidas y consulta la documentación de la herramienta de migración que seleccionaste.
Realiza la transición a producción
El proceso de cambio a producción de alto nivel puede variar según la estrategia de migración que elijas. Si puedes tener tiempo de inactividad en tus cargas de trabajo, la conversión de migración comienza deteniendo las operaciones de escritura en tu base de datos de origen.
En el caso de las migraciones de replicación continua, por lo general, se realizan los siguientes pasos de alto nivel en el proceso de cambio:
- Detén las operaciones de escritura en la base de datos de origen.
- Desvía la fuente.
- Detén el proceso de replicación.
- Implementa las aplicaciones que apuntan a la nueva base de datos de destino.
Después de migrar los datos con la herramienta de migración elegida, debes validarlos 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 con los estándares de éxito de migración que elegiste.
Una vez que la validación de datos cumpla con tus criterios, puedes realizar la migración de sistemas a nivel de la aplicación. Implementa las cargas de trabajo que se refactorizaron para usar la nueva instancia de destino. Implementas las versiones de tus aplicaciones que apuntan a la nueva instancia de base de datos de destino. Las implementaciones se pueden realizar a través de actualizaciones progresivas, lanzamientos en etapas o con un patrón de implementación azul-verde. Es posible que se genere un tiempo de inactividad de la aplicación.
Sigue las prácticas recomendadas para la migración a producción:
- Supervisa tus aplicaciones que funcionan con la base de datos de destino después de la conversión.
- Define un período de supervisión para considerar si necesitas implementar o no tu plan de resguardo.
- Ten en cuenta que es posible que tu instancia de Cloud SQL o AlloyDB para PostgreSQL necesite un reinicio si cambias algunas marcas de base de datos.
- Ten en cuenta que el esfuerzo de revertir la migración podría ser mayor que el de corregir los problemas que aparecen en el entorno de destino.
Limpia el entorno de origen y configura la instancia de Cloud SQL
Una vez que se complete la migración, puedes borrar 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 un estado final de las bases de datos de origen. Es posible que las copias de seguridad también sean necesarias en algunos casos para cumplir con algunas reglamentaciones de datos.
Recopila la configuración de parámetros de la base de datos de tu instancia de origen. Como alternativa, verifica que coincidan con los que recopilaste en la fase de compilación del inventario. Ajusta los parámetros de la instancia de destino para que coincidan con los de la instancia de origen.
Recopila 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 caso de resguardo, te recomendamos implementar la replicación de tus escrituras en la instancia de Cloud SQL a tu base de datos de origen original. La configuración se asemeja al proceso de migración, pero se ejecutaría a la inversa: la base de datos de origen inicial se convertiría en el nuevo destino.
Como práctica recomendada para mantener las instancias de origen actualizadas después de la migración, replica las operaciones de escritura realizadas en las instancias de Cloud SQL de destino en la base de datos de origen. Si necesitas revertir el proceso, puedes usar las instancias de origen anteriores con una pérdida de datos mínima.
Además de la limpieza del entorno de origen, se deben realizar las siguientes configuraciones críticas para tus instancias de Cloud SQL:
- Configura un período de mantenimiento para tu instancia principal a fin de controlar cuándo pueden ocurrir las actualizaciones con interrupciones.
- Configura el almacenamiento en la instancia para que tengas al menos un 20% de espacio disponible para alojar cualquier operación crítica de mantenimiento de base de datos que Cloud SQL pueda realizar. Para recibir una alerta si el espacio disponible en el disco es inferior al 20%, crea una política de alertas basada en métricas para la métrica de uso del disco.
No inicies una operación administrativa antes de que se complete la operación anterior.
Para obtener más información, consulta lo siguiente:
- Acerca del mantenimiento de instancias de Cloud SQL.
- Parámetros de configuración específicos del motor de SQL Server
Optimiza tu entorno después de la migración
La optimización es la última fase de la migración. En esta fase, iteras en tareas de optimización hasta que tu entorno de destino cumpla con tus requisitos de optimización. Los pasos de cada iteración son los siguientes:
- Evalúa tu entorno actual, los equipos y el ciclo de optimización.
- Establece tus requisitos y objetivos de optimización.
- Optimiza el entorno y los equipos.
- Ajustar 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 de Google Cloud , consulta Migra a Google Cloud: Optimiza tu entorno y Marco de trabajo de la arquitectura deGoogle Cloud : Optimización del rendimiento.
Establece tus requisitos de optimización
Revisa los siguientes requisitos de optimización para tu entorno de Google Cloud y elige los que mejor se adapten a tus cargas de trabajo.
Aumenta la confiabilidad y disponibilidad de tu base de datos
Con Cloud SQL, puedes implementar una estrategia de alta disponibilidad y recuperación ante desastres que se alinee con tu objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO). Para aumentar la confiabilidad y la disponibilidad, ten en cuenta lo siguiente:
- En el caso de cargas de trabajo con alto contenido de lectura, agrega réplicas de lectura para aliviar el tráfico de la instancia principal.
- Para las cargas de trabajo esenciales, usa la configuración de alta disponibilidad, las réplicas para la conmutación por error regional y una configuración sólida de recuperación ante desastres.
- Para cargas de trabajo menos críticas, las copias de seguridad automáticas y a pedido pueden ser suficientes.
- Para evitar la eliminación accidental de instancias, usa la protección contra la eliminación de instancias.
- Habilita la recuperación de un momento determinado (PITR) para tu instancia de Cloud SQL para SQL Server.
- Automatiza las copias de seguridad de la base de datos de SQL con los planes de mantenimiento.
Aumenta la rentabilidad de tu infraestructura de bases de datos
Para tener un impacto económico positivo, tus cargas de trabajo deben usar los recursos y servicios disponibles de manera eficiente. Considera las siguientes opciones:
Para proporcionarle a la base de datos la capacidad de almacenamiento mínima requerida, haz lo siguiente:
- Para escalar la capacidad de almacenamiento de forma automática a medida que los datos crecen, habilita los aumentos de almacenamiento automáticos. Sin embargo, asegúrate de configurar tus instancias para que tengan un búfer en las cargas de trabajo máximas. Recuerda que las cargas de trabajo de la base de datos suelen aumentar con el tiempo.
Identifica posibles recursos sobreestimados:
- Ajustar el tamaño de tus instancias de Cloud SQL puede reducir el costo de la infraestructura sin agregar riesgos adicionales a la estrategia de administración de la capacidad.
- Cloud Monitoring proporciona paneles predefinidos que ayudan a identificar el estado y el uso de la capacidad de muchos Google Cloud componentes, incluido Cloud SQL. Para obtener más información, consulta Crea y administra paneles personalizados.
Identifica las instancias que no requieren configuraciones de alta disponibilidad ni de recuperación ante desastres, y quítalas de tu infraestructura.
Quita las tablas y los objetos que ya no sean necesarios. Puedes almacenarlos en una copia de seguridad completa o en un bucket de Cloud Storage de archivo.
Evalúa el tipo de almacenamiento más rentable (SSD o HDD) para tu caso de uso.
- En la mayoría de los casos de uso, el SSD es la opción más eficiente y rentable.
- Si tus conjuntos de datos son grandes (10 TB o más), no son sensibles a la latencia o se accede a ellos con poca frecuencia, es posible que el HDD sea más adecuado.
- Para obtener más información, consulta Elige entre el almacenamiento SSD y HDD.
Compra descuentos por compromiso de uso para cargas de trabajo con necesidades de recursos predecibles.
Usa Active Assist para obtener estadísticas y recomendaciones sobre los costos.
Para obtener más información y opciones, consulta Haz más con menos: Presentamos las recomendaciones de optimización de costos de Cloud SQL con Active Assist.
Para reducir los costos de licencias, específicamente para Cloud SQL para SQL Server, ten en cuenta lo siguiente:
- Migra a la edición estándar de SQL Server si los ANS coinciden con tus requisitos.
- Desactiva los multisubprocesos simultáneos (SMT) y agrega un 25% más de núcleos. Los núcleos adicionales podrían compensar cualquier impacto en el rendimiento que se produzca si se desactiva SMT. Esta estrategia puede ayudar a reducir los costos de licencias, pero podría afectar el rendimiento de tu instancia. Te recomendamos que realices pruebas de carga en tu instancia para asegurarte de que tus ANS no se vean afectadas.
- Considera una migración heterogénea de Cloud SQL para SQL Server a Cloud SQL para PostgreSQL o AlloyDB para PostgreSQL, según tu carga de trabajo.
Aumenta el rendimiento de tu infraestructura de bases de datos
Los problemas de rendimiento menores relacionados con la base de datos suelen tener el potencial de afectar a toda la operación. Para mantener y aumentar el rendimiento de tu instancia de Cloud SQL, ten en cuenta los siguientes lineamientos:
- Si tienes una gran cantidad de tablas de base de datos, estas pueden afectar el rendimiento y la disponibilidad de la instancia, y hacer que esta pierda su cobertura del ANS.
Asegúrate de que tu instancia no esté restringida en la memoria o la CPU.
- Para las cargas de trabajo de rendimiento intensivo, asegúrate de que tu instancia tenga al menos 60 GB de memoria.
- Para inserciones de base de datos, actualizaciones o eliminaciones lentas, verifica las ubicaciones del escritor y de la base de datos. El envío de datos a larga distancia genera latencia.
Mejora el rendimiento de las consultas con el panel predefinido de Estadísticas de consultas en Cloud Monitoring (o funciones integradas similares del motor de base de datos). Identifica los comandos más costosos y trata de optimizarlos.
Evita que los archivos de la base de datos se vuelvan demasiado grandes. Configura
autogrow
en MB, en lugar de como un porcentaje, con incrementos apropiados para el requisito.Verifica la ubicación del lector y de la base de datos. La latencia afecta el rendimiento de la lectura más que el de la escritura.
Evita la fragmentación de datos y de índices. Establece un programa para volver a compilar tus índices en SQL Server, según la frecuencia con la que cambien tus datos.
Cambia la configuración específica del motor de SQL Server para que funcione de manera óptima en Cloud SQL.
Para el mantenimiento de índices y estadísticas, consulta Solución de mantenimiento de SQL Server.
Actualiza las estadísticas con regularidad en Cloud SQL para SQL Server.
Considera realizar operaciones de ETL en una réplica de lectura, ya que podrían afectar la caché de tu instancia.
Para obtener más información sobre cómo aumentar el rendimiento, consulta Rendimiento en "Cómo diagnosticar problemas" y Cloud SQL: Análisis de rendimiento y optimización de consultas de SQL Server.
Aumenta las capacidades de observabilidad de la base de datos
El diagnóstico y la solución de problemas en aplicaciones que se conectan a instancias de bases de datos pueden ser desafiantes y llevar tiempo. Por este motivo, es fundamental contar con un lugar central en el que todos los miembros del equipo puedan ver lo que sucede a nivel de la base de datos y la instancia. Puedes supervisar instancias de Cloud SQL de las siguientes maneras:
Cloud SQL usa agentes personalizados de memoria integrados para recopilar telemetría de consultas.
- Usa Cloud Monitoring para recopilar mediciones de tu servicio y los Google Cloud recursos que usas. Cloud Monitoring incluye paneles predefinidos para varios Google Cloud productos, incluido un panel de supervisión de Cloud SQL.
- Puedes crear paneles personalizados que te ayuden a supervisar las métricas y configurar políticas de alertas para que puedas recibir notificaciones oportunas.
- Como alternativa, puedes considerar usar soluciones de supervisión de terceros integradas en Google Cloud, como Datadog y Splunk.
Cloud Logging recopila datos de registro de componentes de aplicaciones comunes.
Cloud Trace recopila datos de latencia y planes de consultas ejecutados de las aplicaciones para ayudarte a hacer un seguimiento de cómo se propagan las solicitudes a través de tus aplicaciones.
Database Center proporciona una descripción general centralizada y asistida por IA de la flota de bases de datos. Puedes supervisar el estado de tus bases de datos, la configuración de disponibilidad, la protección de datos, la seguridad y el cumplimiento de la industria.
Consulta y ve 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 generales y lineamientos operativos de Cloud SQL
Aplica las prácticas recomendadas de Cloud SQL para configurar y ajustar la base de datos.
A continuación, se mencionan algunas recomendaciones generales importantes de Cloud SQL:
- Si tienes instancias grandes, te recomendamos que las dividas en instancias más pequeñas, cuando sea posible.
- Configura el almacenamiento para adaptar el mantenimiento fundamental de la base de datos. Asegúrate de tener al menos un 20% de espacio disponible para alojar cualquier operación crítica de mantenimiento de base de datos que Cloud SQL pueda realizar.
- Tener demasiadas tablas de base de datos puede afectar el tiempo de actualización de la base de datos. Lo ideal es tener menos de 10,000 tablas por instancia.
- Elige el tamaño adecuado para tus instancias para que se tome en cuenta la retención del registro de transacciones (binario), en especial para las instancias con alta actividad de escritura.
Para poder controlar de manera eficiente cualquier problema de rendimiento de la base de datos que puedas encontrar, usa los siguientes lineamientos hasta que se resuelva el problema:
Ajustar la escala de la infraestructura: Aumenta los recursos (como la capacidad de procesamiento del disco, la CPU virtual y la RAM). Según la urgencia y la disponibilidad y experiencia de tu equipo, el escalamiento vertical de tu instancia puede resolver la mayoría de los problemas de rendimiento. Más adelante, puedes investigar en detalle la causa raíz del problema en un entorno de prueba y considerar opciones para eliminarlo.
Realiza y programa operaciones de mantenimiento de la base de datos: Desfragmentación de índices, actualizaciones de estadísticas, análisis de limpieza y reindexación de tablas muy actualizadas. Verifica si se realizaron estas operaciones de mantenimiento por última vez y cuándo, sobre todo, en los objetos afectados (tablas, índices). Averigua si hubo un cambio en las actividades normales de la base de datos. Por ejemplo, agregar una columna nueva recientemente o tener muchas actualizaciones en una tabla.
Realiza la optimización y el ajuste de la base de datos: ¿Las tablas de tu base de datos están estructuradas correctamente? ¿Las columnas tienen los tipos de datos correctos? ¿Tu modelo de datos es adecuado para el tipo de carga de trabajo? Investiga tus consultas lentas y sus planes de ejecución. ¿Están usando los índices disponibles? Verifica si hay análisis de índices, bloqueos y esperas en otros recursos. Considera agregar índices para admitir tus consultas fundamentales. Elimina los índices y las claves externas que no sean esenciales. Considera reescribir las consultas y las uniones complejas. El tiempo que se tarda en resolver el problema depende de la experiencia y la disponibilidad de tu equipo, y puede variar de horas a días.
Escala tus operaciones de lectura: Considera tener réplicas de lectura. Cuando el escalamiento vertical no es suficiente para tus necesidades y las medidas de optimización y ajuste de la base de datos no ayudan, considera escalar de forma horizontal. Enrutar 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, es posible que se requiera un esfuerzo adicional para cambiar tus aplicaciones para que se conecten a la réplica de lectura.
Reacondicionamiento de la base de datos: Considera particionar y indexar la base de datos. Esta operación requiere mucho más esfuerzo que el ajuste y 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 generar problemas de rendimiento, que se pueden compensar parcialmente con la escala vertical. Sin embargo, un modelo de datos adecuado es una corrección a largo plazo. Considera particionar tus tablas. Si es posible, archiva los datos que ya no se necesiten. Normaliza la estructura de tu base de datos, pero recuerda que la desnormalización también puede mejorar el rendimiento.
Fragmentación de bases de datos: Puedes escalar tus operaciones de escritura fragmentando la base de datos. La fragmentación es una operación complicada que implica volver a diseñar la arquitectura de tu base de datos y tus aplicaciones de una manera específica, y realizar la migración de datos. Para dividir tu instancia de base de datos en varias instancias más pequeñas, usa criterios de particionamiento específicos. Los criterios pueden basarse en el cliente o en el tema. Esta opción te permite escalar horizontalmente tus operaciones de lectura y escritura. Sin embargo, aumenta la complejidad de las cargas de trabajo de tu base de datos y aplicación. También podría generar fragmentos desequilibrados llamados hotspots, que superarán el beneficio del fragmentación.
Específicamente para Cloud SQL para SQL Server, ten en cuenta las siguientes prácticas recomendadas:
- Para actualizar la configuración de SQL Server y obtener un rendimiento óptimo con Cloud SQL, consulta Configuración de SQL Server.
- Determina la capacidad del subsistema de E/S antes de implementar SQL Server.
Si tienes instancias grandes, divídelas en instancias más pequeñas, de ser posible:
- Un disco de 4 TB o más proporciona más capacidad de procesamiento y también IOPS.
- Una CPU virtual más alta proporciona más IOPS y capacidad de procesamiento. Cuando uses una CPU virtual más alta, supervisa la espera de la base de datos en busca de paralelismo, que también podría aumentar.
Desactiva SMT si el rendimiento disminuye 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 lo controla de manera eficaz.
Establece un programa para reorganizar o volver a compilar tus índices, según la frecuencia con la que cambien tus datos.
Establece un factor de relleno adecuado para reducir la fragmentación. Supervisa SQL Server para detectar índices faltantes que podrían ofrecer un mejor rendimiento.
Evita que los archivos de la base de datos se vuelvan demasiado grandes. Configura
autogrow
en MB, en lugar de como un porcentaje, con incrementos apropiados para el requisito. Además, administra de forma proactiva el crecimiento de la base de datos antes de que se alcance el umbral deautogrow
.Para escalar la capacidad de almacenamiento de forma automática, habilita los aumentos de almacenamiento automáticos. Cloud SQL puede agregar espacio de almacenamiento si la base de datos y la instancia se quedan sin espacio.
Asegúrate de comprender los requisitos de configuración regional, el orden y la distinción de acentos y entre mayúsculas y minúsculas de los datos con los que trabajas. Cuando seleccionas una intercalación para tu servidor, base de datos, columna o expresión, asignas ciertas características a tus datos.
Las uniones de hash o rescates de hash recurrentes hacen que el rendimiento sea menor en un servidor. Si ves muchos eventos de advertencia de hash en un seguimiento, actualiza las estadísticas en las columnas que se unen. Para obtener más información, consulta Clase de evento de advertencia de hash.
Para obtener más detalles, consulta las prácticas recomendadas generales y los lineamientos operativos de Cloud SQL para SQL Server.
¿Qué sigue?
- Obtén información sobre otros recorridos de migración de AWS a Google Cloud .
- Obtén más información para comparar los servicios de AWS y Azure con Google Cloud.
- Obtén información sobre cuándo encontrar ayuda para tus migraciones.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.
Colaboradores
Autores:
- Alex Cârciu | Arquitecto de soluciones
- Marco Ferrari | Arquitecto de soluciones de nube
Otros colaboradores:
- Derek Downey | Ingeniero de relaciones con desarrolladores
- Paweł Krentowski | Escritor técnico
- Matthew Smith | Ingeniero estratégico de Cloud
- Somdyuti Paul | Especialista en administración de datos
- Zach Seils | Especialista en herramientas de redes