Migra de AWS a Google Cloud: Migra de Amazon RDS y Amazon Aurora para PostgreSQL a Cloud SQL y AlloyDB para PostgreSQL

Google Cloud proporciona herramientas, productos, orientación y servicios profesionales para migrar de Amazon Relational Database Service (RDS) o Amazon Aurora a Cloud SQL para PostgreSQL o AlloyDB para PostgreSQL.

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 desean un ejemplo de cómo podría ser una migración.

En este documento, se aborda la migración homogénea de bases de datos, 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. En esta guía de migración, el origen es Amazon RDS o Amazon Aurora para PostgreSQL, y el destino es Cloud SQL para PostgreSQL o AlloyDB para PostgreSQL.

Este documento pertenece a 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 y AlloyDB para PostgreSQL (este documento)
• Migra de Amazon RDS para SQL Server a Cloud SQL para SQL Server
• 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:

1. Evalúa y descubre las cargas de trabajo y los datos.
2. Planifica y compila una base en Google Cloud.
3. Migra tus cargas de trabajo y datos a Google Cloud.
4. Optimiza tu entorno de Google Cloud .

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:

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

La fase de evaluación de la base de datos te ayuda a elegir el tamaño y las especificaciones de tu instancia de base de datos de Cloud SQL de destino que coincidan con la fuente para necesidades de rendimiento similares. Presta especial atención al tamaño y la capacidad de procesamiento del disco, las IOPS y la cantidad de CPU virtuales. Es posible que las migraciones tengan problemas o fallen debido a un tamaño incorrecto de la instancia de la base de datos de destino. Un tamaño incorrecto puede generar tiempos de migración prolongados, 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 Migra a Google Cloud: Evalúa y descubre tus cargas de trabajo y, además, integran la información de ese documento.

Crea un inventario de tus instancias de Amazon RDS o Amazon Aurora

Para definir el alcance de tu migración, crea un inventario y recopila información sobre tus instancias de Amazon RDS y Amazon Aurora. Lo ideal es que este sea un proceso automatizado, ya que los enfoques manuales son propensos a errores y pueden generar suposiciones incorrectas.

Es posible que Amazon RDS o Amazon Aurora y Cloud SQL para PostgreSQL o AlloyDB para PostgreSQL no tengan características, especificaciones de instancias ni operaciones similares. Es posible que algunas funciones se implementen de manera diferente o no estén disponibles. Las áreas de diferencias pueden incluir la infraestructura, el almacenamiento, la autenticación y la seguridad, la replicación, la copia de seguridad, la alta disponibilidad, el modelo de capacidad de recursos y las integraciones de funciones específicas del motor de base de datos, así como las extensiones. 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 los parámetros de la base de datos.

Las comparativas pueden ayudarte a comprender mejor las cargas de trabajo que se migrarán y contribuyen a definir la arquitectura adecuada 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 de destino. Los conceptos y las herramientas de comparativas se detallan en la sección Realiza pruebas y validaciones del proceso de migración, pero también se aplican a la etapa de creación del inventario.

Herramientas para evaluaciones

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

Con Migration Center, puedes realizar una evaluación completa de tu panorama de aplicaciones y bases de datos, incluida la adecuación técnica 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 del costo total de propiedad (TCO) para servidores y 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, que admite una variedad de motores de bases de datos y es especialmente adecuada para migraciones heterogéneas. Para obtener una introducción a migVisor, consulta la descripción general de migVisor.

migVisor puede identificar artefactos y funciones de bases de datos propietarias incompatibles que pueden causar la configuración predeterminada de la migración, y puede sugerir soluciones alternativas. migVisor también puede recomendar una solución de Google Cloud destino, 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 propias que usa tu base de datos.
• Informe financiero con detalles sobre el ahorro de costos después de la migración, los costos de migración y el nuevo presupuesto operativo.
• Plan de migración por fases para trasladar bases de datos y aplicaciones asociadas con una interrupción mínima para la empresa

Para ver algunos ejemplos de los resultados de la evaluación, consulta migVisor: herramienta de evaluación de la migración a la nube.

Ten en cuenta que migVisor aumenta temporalmente el uso del servidor de la base de datos. Por lo general, esta carga adicional es inferior al 3% y se puede ejecutar durante las horas no pico.

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 base de datos, CPU 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 recopilación de datos con las herramientas mencionadas (o en lugar de ellas). Estos lenguajes de secuencias de comandos pueden ayudarte a recopilar información detallada (sobre cargas de trabajo, funciones, objetos de bases de datos y código de bases de datos) y a crear tu inventario de bases de datos. Además, los scripts suelen proporcionar una evaluación detallada de la migración de la base de datos, incluida una estimación del esfuerzo de migración.

Recomendamos la herramienta de código abierto DMA, creada por ingenieros de Google. Ofrece una evaluación completa y precisa de la base de datos, incluidas las funciones en uso, la lógica de la base de datos y los objetos de la base de datos (incluidos esquemas, tablas, vistas, funciones, activadores y procedimientos almacenados).

Para usar DMA, descarga las secuencias de comandos de recopilación para tu motor de base de datos desde el repositorio de Git y sigue las instrucciones. Envía los archivos de salida a Google Cloud para su análisis. Google Cloud crea y entrega una lectura de la 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? ¿Son más grandes que 16 TB?
• ¿Dónde se encuentran las bases de datos (regiones y zonas) y qué tan cerca están de 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. Migrar 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 tablas de registro antiguas ni datos de archivo. Como alternativa, puedes decidir trasladar los datos después del proceso de migración, según tu estrategia y tus herramientas.

Establece referencias de migración de datos que te ayuden a comparar y evaluar tus resultados e impactos. Estos valores 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 la 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 del tiempo de inactividad? ¿Hay períodos de baja actividad en la base de datos durante los cuales menos usuarios se ven 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 que las solicitudes de solo lectura siguen atendidas.

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 deben adaptarse 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 para PostgreSQL y restringir los datos dentro de una VPC.

• 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 grupos de parámetros o grupos de opciones de Amazon. Es posible que tus herramientas de aprovisionamiento deban adaptarse para usar Cloud Storage o Secret Manager y leer esas listas de configuración personalizadas.

• Administra la infraestructura de supervisión y alertas. Las categorías de métricas para las instancias de la base de datos de origen de Amazon proporcionan observabilidad durante el proceso de migración. Las categorías de métricas pueden incluir Amazon CloudWatch, Performance Insights, Enhanced Monitoring y listas de procesos del SO.

Completa la evaluación

Después de compilar los inventarios de tu entorno de Amazon RDS o Amazon Aurora, 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:

• Admitir tus cargas de trabajo en tu entorno de Google Cloud
• Conecta 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:

1. Compila una jerarquía de recursos.
2. Configura Identity and Access Management (IAM) de Google Cloud.
3. Configura la facturación.
4. Configura la conectividad de red.
5. Endurece tu seguridad.
6. 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 compila tu base.

Si planeas usar Database Migration Service para la migración, consulta Métodos de redes para Cloud SQL para PostgreSQL para comprender las configuraciones de redes disponibles para las situaciones de migración.

Supervisión y alertas

Usa Cloud Monitoring de Google, que incluye paneles predefinidos para varios productos de Google Cloud , incluido un panel de supervisión de Cloud SQL. Como alternativa, puedes considerar usar soluciones de supervisión de terceros que estén 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 y Amazon Aurora para PostgreSQL a Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL

Para migrar tus instancias, haz lo siguiente:

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

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

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

4. Define las tareas de preparación que se deben realizar para garantizar que la herramienta de migración pueda funcionar correctamente.

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

6. Define situaciones de resguardo para cada tarea de ejecución.

7. Realiza pruebas y validaciones, que se pueden hacer en un entorno de pruebas independiente.

8. Realiza la migración.

9. Realiza la transición de producción.

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

11. Realiza ajustes y optimizaciones.

Cada fase se describe en las siguientes secciones.

Elige tu 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 o migración Big Bang): Este enfoque es ideal si puedes permitirte un tiempo de inactividad. Esta opción es relativamente más baja en costo y complejidad, 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 en línea o migración por goteo): En el caso de las bases de datos de servicio crítico, esta opción ofrece un menor riesgo de pérdida de datos y un tiempo de inactividad casi nulo. Los esfuerzos se dividen en varios fragmentos, por lo que, si se produce 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 bases de datos. Considera una de las siguientes variaciones:

  • Usar el enfoque Y (escritura y lectura), que es una forma de migración paralela, duplicando los datos en las instancias de origen y destino durante la migración
  • Usar un microservicio de acceso a los datos, lo 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 Evaluación de enfoques de migración de datos.

En el siguiente diagrama, se muestra un diagrama de flujo basado en preguntas de ejemplo que puedes 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 algún tiempo de inactividad?

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

• ¿Puedes permitirte el tiempo de inactividad que representa un período de migración mientras migras datos? El período de transferencia representa la cantidad de tiempo que se necesita para hacer una copia de seguridad de la base de datos, transferirla a Cloud SQL, restablecerla y, luego, transferir tus aplicaciones.

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

Las estrategias pueden variar para diferentes bases de datos, incluso cuando se encuentran en la misma instancia. Una combinación de estrategias puede producir resultados óptimos. Por ejemplo, migra las bases de datos pequeñas y que se usan con poca frecuencia con el enfoque de mantenimiento programado, pero usa la replicación continua para las bases de datos críticas para la misión en las que el tiempo de inactividad es costoso.

Por lo general, se considera que una migración se completó cuando se realiza el cambio entre la instancia de origen inicial y la instancia de destino. Se detiene cualquier replicación (si se usa) y todas las lecturas y escrituras se realizan en la instancia de destino. El cambio cuando ambas instancias están sincronizadas significa que no hay pérdida de datos y que el tiempo de inactividad es mínimo.

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

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 complicada. Encuentra el equilibrio adecuado entre la complejidad de la configuración y el tiempo de inactividad programado durante las horas comerciales de menor tráfico.

Cada estrategia de migración tiene una compensación y cierto 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 es posible que tus aplicaciones se vean 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 nueva base de datos. En la práctica, los siguientes factores pueden aumentar el tiempo de inactividad:

• Las consultas de la base de datos pueden tardar unos segundos en completarse. En el momento de la migración, es posible que se anulen las consultas en tránsito.
• Es posible que la caché tarde un tiempo en llenarse si la base de datos es grande o tiene una memoria de búfer considerable.
• Las aplicaciones detenidas en la fuente y reiniciadas en Google Cloudpueden tener un pequeño retraso hasta que se establezca la conexión a la instancia de la base de datos Google Cloud.
• Se deben redireccionar las rutas de red a las aplicaciones. Según cómo se configuren las entradas DNS, esto puede tardar un poco. Cuando actualices los registros DNS, reduce el TTL antes de la migración.

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

• Busca un 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 al corte de 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 cierta 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 obsoletos de la instancia de destino.
• Considera refactorizar tus aplicaciones para que admitan un impacto mínimo en la migración. Por ejemplo, adapta tus aplicaciones para que escriban en las bases de datos de origen y de destino, y, de este modo, implementa una replicación a nivel de la aplicación.

Elige tus herramientas de migración

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

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 tardará en migrarse 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 administrados pueden facilitar el proceso de traslado de datos, aplicaciones o incluso infraestructuras completas de un entorno a otro. Ejecutan la extracción de datos de las bases de datos de origen, transportan los datos de forma segura a las bases de datos de destino y, de manera opcional, pueden modificar los datos durante el tránsito. Con estas capacidades, encapsulan la lógica compleja de la migración y ofrecen capacidades de supervisión de la migración.

Los servicios de migración administrados 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 la seguridad de los datos: Los datos se transfieren de forma segura y confiable desde la fuente a la base de datos de destino.

• Proporciona una experiencia de migración coherente: Las diferentes técnicas y patrones de migración se pueden consolidar en una interfaz coherente y común con los 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 críticos. Para evitar errores de principiantes y problemas con las soluciones existentes, puedes usar herramientas de expertos experimentados en lugar de crear una solución personalizada.

• Optimizar 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 la herramienta de migración, que dependen de la estrategia de migración elegida.

Herramientas para migraciones de mantenimiento programadas

En las siguientes subsecciones, se describen las herramientas que se pueden usar para las migraciones únicas, junto con las limitaciones y las prácticas recomendadas de cada herramienta.

Para las migraciones únicas a Cloud SQL para PostgreSQL o a AlloyDB para PostgreSQL, te recomendamos que uses copias de seguridad del motor de base de datos para exportar los datos de tu instancia de origen y, luego, importarlos a tu instancia de destino. Database Migration Service no admite trabajos de migración únicos.

Copias de seguridad integradas del motor de base de datos

Cuando se acepta un tiempo de inactividad significativo y las bases de datos de origen son relativamente estáticas, puedes usar las capacidades integradas de volcado y carga del motor de base de datos (que a veces también se denominan copia de seguridad y restablecimiento).

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 ser 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 la 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 pueden no estar protegidos si las instantáneas no se administran correctamente.
• Las copias de seguridad no tienen las capacidades de supervisión adecuadas.
• Las copias de seguridad requieren esfuerzo para escalar cuando se migran muchas bases de datos.

Puedes usar las utilidades de copia de seguridad integradas de PostgreSQL, pg_dump y pg_dumpall, para migrar Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL. Sin embargo, las utilidades pg_dump y pg_dumapall tienen las siguientes limitaciones generales:

• Las utilidades de copia de seguridad integradas se deben usar para migrar bases de datos de 500 GB o menos. Volcar y restablecer bases de datos grandes puede llevar mucho tiempo y requerir una cantidad considerable de espacio en disco y memoria.
• La utilidad pg_dump no incluye usuarios ni roles. Para migrar estas cuentas y roles de usuario, puedes usar la utilidad pg_dumpall.
• Cloud Storage admite un tamaño máximo de hasta 5 terabytes (TB) para un solo objeto. Si tienes bases de datos de más de 5 TB, la operación de exportación a Cloud Storage falla. En ese caso, debes dividir tus archivos de exportación en segmentos más pequeños.

Si decides usar estas utilidades, ten en cuenta las siguientes restricciones y prácticas recomendadas:

• Comprime los datos para reducir los costos y la duración de la transferencia. Usa la opción --jobs con el comando pg_dump para ejecutar una cantidad determinada de trabajos de volcado de forma simultánea.
• Usa la opción -z con el comando pg_dump para especificar el nivel de compresión que se usará. Los valores aceptables para esta opción varían de 0 a 9. El valor predeterminado es comprimir en un nivel 6. Los valores más altos disminuyen el tamaño del archivo de volcado, pero pueden causar un alto consumo de recursos en el host del cliente. Si el host del cliente tiene suficientes recursos, los niveles de compresión más altos pueden reducir aún más el tamaño del archivo de volcado.
• Usa las marcas correctas cuando crees un archivo de volcado de SQL.
• Verifica la base de datos importada. Supervisa el resultado de la utilidad pg_restore para detectar mensajes de error durante el proceso de restablecimiento. Revisa los registros de PostgreSQL para detectar advertencias o errores durante el proceso de restablecimiento. Ejecuta consultas básicas y recuentos de tablas para verificar la integridad de tu base de datos.

Para obtener más información sobre las limitaciones y las prácticas recomendadas, consulta los siguientes recursos:

• Prácticas recomendadas para importar y exportar datos con Cloud SQL para PostgreSQL
• Problemas conocidos de Cloud SQL para PostgreSQL
• Cómo importar un archivo de DMP en AlloyDB para PostgreSQL
• Migra usuarios con credenciales a AlloyDB para PostgreSQL o a otra instancia de Cloud SQL

Otros enfoques para la migración de mantenimiento programado

Usar otros enfoques que no sean las utilidades de copia de seguridad integradas podría brindarte más control y flexibilidad en la migración de mantenimiento programado. Estos otros tipos de enfoques te permiten realizar transformaciones, verificaciones o cualquier otra operación en tus datos mientras realizas la migración. Puedes consolidar varias instancias o bases de datos en una sola instancia o base de datos. La consolidación de instancias puede ayudar a mitigar los costos operativos y aliviar los problemas de escalabilidad.

Una alternativa a las utilidades de copia de seguridad es usar archivos planos para exportar e importar tus datos. Para obtener más información sobre la importación de archivos planos, consulta Importa y exporta con archivos CSV para Cloud SQL para PostgreSQL.

Otra alternativa es usar una importación administrada para configurar la replicación desde una base de datos externa de PostgreSQL. Cuando usas una importación administrada, se realiza una carga de datos inicial desde la base de datos externa a la instancia de Cloud SQL para PostgreSQL. Esta carga inicial usa un servicio que extrae datos del servidor externo (la instancia de RDS o Aurora) y los importa directamente a la instancia de Cloud SQL para PostgreSQL. Si deseas obtener más información, consulta Usa una importación administrada para configurar la replicación desde bases de datos externas.

Una forma alternativa de realizar una migración única de tus datos es exportar las tablas de tu base de datos de PostgreSQL de origen a archivos CSV o SQL. Luego, puedes importar el archivo CSV o SQL a Cloud SQL para PostgreSQL o AlloyDB para PostgreSQL. Para exportar la fecha de tu instancia de origen, puedes usar la extensión aws_s3 para PostgreSQL. Como alternativa, puedes usar Amazon Database Migration Service y un bucket de S3 como destino. Para obtener información detallada sobre este enfoque, consulta los siguientes recursos:

• Instala la extensión aws_s3 para PostgreSQL
• Usa Amazon S3 como destino para Amazon Database Migration Service

También puedes importar datos de forma manual a una instancia de AlloyDB para PostgreSQL. Los formatos admitidos son los siguientes:

• CSV: Con este formato de archivo, cada archivo contiene el contenido de una tabla de la base de datos. Puedes cargar los datos en el archivo CSV con el programa de línea de comandos psql. Para obtener más información, consulta Cómo importar un archivo CSV.
• DMP: Este formato de archivo contiene el archivo de toda una base de datos de PostgreSQL. Para importar datos desde este archivo, usa la utilidad pg_restore. Para obtener más información, consulta Importa un archivo de DMP.
• SQL: Este formato de archivo contiene la reconstrucción de texto de una base de datos de PostgreSQL. Los datos de este archivo se procesan con la línea de comandos psql. Para obtener más información, consulta Cómo importar un archivo SQL.

Herramientas para migraciones de replicación continua

En el siguiente diagrama de flujo, se muestran 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 la respuesta es sí, ¿puedes permitirte unos segundos de inactividad de escritura mientras se lleva a cabo el paso de replicación?

    • Si es así, usa Database Migration Service.
    • De lo contrario, explora otras opciones de migración.

  • Si no es así, debes evaluar si se admite la replicación integrada del motor de base de datos:

    • Si es así, te recomendamos que uses 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 continuas, junto con sus limitaciones y prácticas recomendadas.

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

Database Migration Service proporciona un tipo de trabajo específico para las migraciones continuas. Estos trabajos de migración continua admiten migraciones de alta fidelidad a Cloud SQL para PostgreSQL y a AlloyDB para PostgreSQL.

Cuando usas Database Migration Service para migrar a Cloud SQL para PostgreSQL o AlloyDB para PostgreSQL, existen requisitos previos y limitaciones asociados con cada instancia de destino:

• Si migras a Cloud SQL para PostgreSQL, usa los siguientes recursos:

  • La lista completa de requisitos previos se proporciona en Configura tu fuente para PostgreSQL.
  • La lista completa de limitaciones se proporciona en Limitaciones conocidas de PostgreSQL.

• Si migras a AlloyDB para PostgreSQL, usa los siguientes recursos:

  • La lista completa de requisitos previos se proporciona en Configura tu fuente de PostgreSQL para AlloyDB para PostgreSQL.
  • La lista completa de limitaciones se proporciona en Limitaciones conocidas de PostgreSQL a AlloyDB para PostgreSQL.

Replicación integrada del motor de base de datos

La replicación integrada del motor de base de datos es una opción alternativa a Database Migration Service para una migración continua.

La replicación de bases de datos representa el proceso de copiar y distribuir datos de una base de datos llamada base de datos principal a otras bases de datos llamadas réplicas. Su objetivo es aumentar la accesibilidad a los datos y mejorar la tolerancia a errores y la confiabilidad de un sistema de bases de datos. Si bien la migración de bases de datos no es el propósito principal de la replicación de bases de datos, se puede usar con éxito como herramienta para lograr este objetivo. La replicación de la base de datos suele ser un proceso continuo que se produce en tiempo real a medida que se insertan, actualizan o borran datos en la base de datos principal. La replicación de la base de datos se puede realizar como una operación única o como una secuencia de operaciones por lotes.

La mayoría de los motores de bases de datos modernos implementan diferentes formas de lograr la replicación de bases de datos. Un tipo de replicación se puede lograr copiando y enviando el registro de escritura anticipada o el registro de transacciones de la instancia principal a sus réplicas. Este enfoque se denomina replicación física o binaria. Otros tipos de replicación funcionan distribuyendo las instrucciones SQL sin procesar que recibe una base de datos principal, en lugar de replicar los cambios a nivel del sistema de archivos. Estos tipos de replicación se denominan replicación lógica. En el caso de PostgreSQL, también hay extensiones de terceros, como pglogical, que implementan la replicación lógica basada en el registro de escritura anticipada (WAL).

Cloud SQL admite la replicación para PostgreSQL. Sin embargo, existen algunos requisitos previos y limitaciones.

A continuación, se indican las limitaciones y los requisitos previos de Cloud SQL para PostgreSQL:

• Se admiten las siguientes versiones de Amazon:

  • Amazon RDS 9.6.10 y versiones posteriores, 10.5 y versiones posteriores, 11.1 y versiones posteriores, 12, 13 y 14
  • Amazon Aurora 10.11 y versiones posteriores, 11.6 y versiones posteriores, 12.4 y versiones posteriores, y 13.3 y versiones posteriores

• El firewall del servidor externo debe configurarse para permitir el rango de IP interna que se asignó para el acceso privado a servicios de la red de VPC. La base de datos de réplica de Cloud SQL para PostgreSQL usa la red de VPC como su red privada.

• El firewall de la base de datos de origen debe configurarse para permitir todo el rango de IP interna que se asignó para la conexión de servicio privada de la red de VPC. La instancia de destino de Cloud SQL para PostgreSQL usa esta red de VPC en el campo privateNetwork de su configuración IpConfiguration.

• Cuando instales la extensión pglogical en una instancia de Cloud SQL para PostgreSQL, asegúrate de haber configurado la marca enable_pglogical en on (por ejemplo, cloudsql.enable_pglogical=on).

• Asegúrate de que el parámetro shared_preload_libraries incluya la extensión pglogical en tu instancia de origen (por ejemplo, shared_preload_libraries=pg_stat_statements,pglogical). Establece el parámetro rds.logical_replication en 1. Este parámetro de configuración habilita los registros de escritura anticipada a nivel lógico.

  Estos cambios requieren que se reinicie la instancia principal.

Para obtener más información sobre el uso de Cloud SQL para PostgreSQL para la replicación, consulta la lista de verificación del servidor externo en la sección de replicación para PostgreSQL y también Configura la replicación lógica y la decodificación para PostgreSQL en la documentación oficial de Cloud SQL.

AlloyDB para PostgreSQL admite la replicación a través de la extensión pglogical. Para habilitar la extensión pglogical para la replicación, puedes usar el comando CREATE EXTENSION. Antes de usar ese comando, primero debes establecer las marcas de base de datos alloydb.enable_pglogical y alloydb.logical_decoding en on en la instancia de AlloyDB para PostgreSQL en la que deseas usar la extensión. Para configurar estas marcas, debes reiniciar la instancia.

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

Puedes usar Datastream para replicar los cambios casi en tiempo real de tu instancia de PostgreSQL de origen. Datastream usa la captura de datos modificados (CDC) y la replicación para replicar y sincronizar datos. Luego, puedes usar Datastream para la replicación continua desde Amazon RDS y Amazon Aurora. Usarás Datastream para replicar los cambios de tu instancia de PostgreSQL en BigQuery o Cloud Storage. Luego, esos datos replicados se pueden incorporar a tu instancia de Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL con Dataflow usando una plantilla flexible de Dataflow o con Dataproc.

Para obtener más información sobre el uso de Datastream y Dataflow, consulta los siguientes recursos:

• Configura una base de datos de Amazon RDS para PostgreSQL en Datastream
• Configura una base de datos de Amazon Aurora PostgreSQL en Datastream
• Trabaja con archivos de registro WAL de la base de datos de PostgreSQL
• Transmite cambios a los datos en tiempo real con Datastream
• Descripción general de Dataflow
• Plantilla flexible de Dataflow para subir datos por lotes de Google Cloud Storage a AlloyDB para PostgreSQL (y Postgres)

Herramientas de terceros para la migración 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 darse si prefieres usar un servicio de migración administrado y necesitas asegurarte de que la base de datos de destino esté siempre sincronizada casi 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 integral en memoria para recopilar, filtrar, transformar, enriquecer, agregar, analizar y entregar datos en tiempo real:

• Ventajas:

  • Maneja 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 bajo una carga transaccional pesada.
  • Entrega “exactamente una vez”.

• Desventajas:

  • No es de código abierto.
  • Puede resultar costoso, en especial para 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 admitidas y Notas y limitaciones de la evolución del esquema.

Para obtener más información sobre Striim, consulta Ejecuta 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
  • Es rentable.
  • Control detallado sobre filas, tablas o bases de datos
  • Especializado para la captura de cambios en tiempo real a partir de registros de transacciones de bases de datos.

• Desventajas:

  • Se requiere experiencia específica con Kafka y ZooKeeper.
  • Entrega de cambios de datos al menos una vez, lo que significa que debes controlar los duplicados
  • Configuración manual de la supervisión con Grafana y Prometheus
  • No se admite la replicación incremental por lotes.

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

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

• Ventajas:

  • Plantillas de conexión preconfiguradas y canalizaciones sin código
  • Propaga cualquier cambio de esquema de la base de datos de origen a la de destino.
  • Entrega exactamente una vez de los cambios en tus datos, lo que significa que no necesitas controlar duplicados.

• Desventajas:

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

Define el plan y el cronograma de migración

Para que la migración de la base de datos y el cambio 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 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) existente ni tu plan de continuidad comercial.

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

• Documento de diseño técnico (TDD)
• Matriz RACI
• Cronograma (como un plan de cuenta regresiva)

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

TDD

El 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 los entregables dentro del proyecto de migración.

Cronograma

Prepara un cronograma para cada base de datos que se deba migrar. Incluye todas las tareas laborales que se deben realizar, así como las fechas de inicio definidas y las fechas de finalización estimadas.

Para cada entorno de migración, te recomendamos que crees un plan de cuenta regresiva. 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.

La cronología 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 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-Minus podría verse de la siguiente manera:

Fecha	Fase	Categoría	Tasks	Rol	Cuenta regresiva	Estado
1/11/2023	Antes de la migración	Evaluación	Crea un informe de evaluación	Equipo de Discovery	-21	Completado
7/11/2023	Antes de la migración	Preparación del objetivo	Diseña el entorno de destino según 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-Minus	Directivos	-6	Completado
18/11/2023	Migración	Configura el DMS	Crea perfiles de conexión	Ingeniero de migración a la nube	-3	Completado
19/11/2023	Migración	Configura el DMS	Compila e inicia trabajos de migración	Ingeniero de migración a la nube	-2	Sin iniciar
19/11/2023	Migración	Supervisa el DMS	Supervisa los trabajos de DMS y los cambios en el DDL en la instancia de origen	Ingeniero de migración a la nube	-2	Sin iniciar
21/11/2023	Migración	Migración de sistemas de DMS	Asciende la 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 capacidades	Equipo de migración	0	Sin iniciar
22/11/2023	Migración	Administración de la empresa	Validación de la migración: APROBADA o RECHAZADA	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

Varias 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 no crítica para la misión. Este enfoque puede ayudarte a aumentar tus conocimientos y confianza en el proceso de migración y las herramientas. También puedes detectar cualquier falla en el proceso en las primeras etapas del programa de migración general.

Si tienes varias bases de datos para migrar, los cronogramas pueden ejecutarse en paralelo. 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 críticas para la misión al mismo tiempo, como se muestra en el siguiente diagrama.

En el ejemplo que se muestra en el diagrama, las bases de datos 1 a 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. Sin las tareas de preparación, no se puede realizar la migración o esta da como resultado una base de datos migrada en un estado inutilizable.

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

• Preparativos y requisitos previos para una instancia de Amazon RDS o Amazon Aurora
• Preparación y requisitos previos de la base de datos de origen
• Configuración de instancias de Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL
• Configuración específica de la migración

Preparación y requisitos previos de instancias de Amazon RDS o Amazon Aurora

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

• Según la ruta de migración, es posible que debas permitir conexiones remotas en tus instancias de RDS. Si tu instancia de RDS está configurada como privada en tu VPC, debe existir 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 y aplicar el grupo de seguridad a tu instancia de Amazon RDS o Amazon Aurora:

  • De forma predeterminada, en AWS, el acceso a la red está desactivado 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.

• Si migras desde Amazon RDS, asegúrate de tener suficiente espacio libre en el disco para almacenar en búfer los registros de escritura anticipada durante la operación de carga completa en tu instancia de Amazon RDS.

• Para la replicación en curso (transmisión de cambios a través de CDC), debes usar una instancia de RDS completa y no una réplica de lectura.

• Si usas la replicación integrada, debes configurar tu instancia de Amazon RDS o Amazon Aurora para la replicación de PostgreSQL. La replicación integrada o las herramientas que usan la replicación integrada necesitan la replicación lógica para PostgreSQL.

• Si usas herramientas de terceros, por lo general, se requieren parámetros de configuración iniciales antes de usar la herramienta. Consulta la documentación de la herramienta de terceros.

Para obtener más información sobre la preparación de la instancia y los requisitos previos, consulta Configura el servidor externo para la replicación en PostgreSQL.

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

• Si decides usar Database Migration Service, configura tu base de datos de origen antes de conectarte a ella. Para obtener más información, consulta Configura tu fuente para PostgreSQL y Configura tu fuente de PostgreSQL para AlloyDB para PostgreSQL.

• En el caso de las tablas que no tienen claves primarias, después de que Database Migration Service migre la copia de seguridad inicial, solo se migrarán las sentencias INSERT a la base de datos de destino durante la fase de CDC. Las instrucciones DELETE y UPDATE no se migran para esas tablas.

• Ten en cuenta que Database Migration Service no puede replicar objetos grandes, ya que la función de decodificación lógica en PostgreSQL no admite la decodificación de cambios en objetos grandes.

• Si eliges usar la replicación integrada, ten en cuenta que la replicación lógica tiene ciertas limitaciones con respecto a los comandos del lenguaje de definición de datos (DDL), las secuencias y los objetos grandes. Las claves primarias deben existir o agregarse en las tablas que se habilitarán para las CDC y que reciben muchas actualizaciones.

• Algunas herramientas de migración de terceros requieren que todas las columnas de objetos grandes sean anulables. Las columnas de objetos grandes que sean NOT NULL deben tener esa restricción quitada durante la migración.

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

  • Mide el tamaño de tus datos y el rendimiento de tu carga de trabajo. ¿Cuánto tardan, en promedio, las búsquedas o transacciones importantes? ¿Cuánto tiempo durante las horas pico?
  • Documenta las mediciones 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 retirar tu entorno de origen, o si aún lo necesitas para fines de resguardo.

Configuración de instancias de Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL

Para que tu instancia de destino alcance niveles de rendimiento similares a los de tu instancia de origen, elige el tamaño y las especificaciones de tu instancia de base de datos de PostgreSQL de destino para que coincidan con los de la instancia de origen. Presta especial atención al tamaño y la capacidad de procesamiento del disco, las operaciones de entrada y salida por segundo (IOPS) y la cantidad de CPU virtuales (vCPU). Un tamaño incorrecto puede generar tiempos de migración prolongados, 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 para PostgreSQL o AlloyDB para PostgreSQL usar, ten en cuenta que el rendimiento del disco se basa en el tamaño del disco y la cantidad de CPU virtuales.

Debes confirmar las siguientes propiedades y requisitos antes de crear tus instancias de Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL. Si deseas cambiar estas propiedades y requisitos más adelante, deberás volver a crear las instancias.

• Elige con cuidado el proyecto y la región de tus instancias de destino de Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL. Las instancias 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 para PostgreSQL y AlloyDB para PostgreSQL. Por ejemplo, si usas PostgreSQL 14.x en Amazon RDS o Amazon Aurora, debes migrar a Cloud SQL o AlloyDB para PostgreSQL para la versión 14.x de PostgreSQL.

• 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 Copias de seguridad específicas del motor de base de datos.

• Revisa las marcas de configuración específicas del motor de base de datos y compara los valores de las instancias de origen y destino. Asegúrate de comprender su impacto y si deben ser iguales o no. Por ejemplo, cuando trabajas con PostgreSQL, te recomendamos que compares los valores de la tabla pg_settings en tu base de datos de origen con los de la instancia de Cloud SQL y AlloyDB para PostgreSQL. Actualiza la configuración de las marcas según sea necesario en la instancia de la base de datos de destino para replicar la configuración de origen.

• Según la naturaleza de tu carga de trabajo, es posible que debas habilitar extensiones específicas para admitir tu base de datos. Si tu carga de trabajo requiere estas extensiones, revisa las extensiones de PostgreSQL admitidas y cómo habilitarlas en Cloud SQL y AlloyDB para PostgreSQL.

Para obtener más información sobre la configuración de Cloud SQL para PostgreSQL, consulta las opciones de configuración de instancias, las marcas específicas del motor de base de datos y las extensiones compatibles.

Para obtener más información sobre la configuración de AlloyDB para PostgreSQL, consulta las marcas de bases de datos compatibles y las extensiones compatibles.

Configuración específica de la migración

Si puedes permitirte un tiempo de inactividad, puedes importar archivos de volcado de SQL a Cloud SQL y AlloyDB para PostgreSQL. En esos casos, es posible que debas crear un bucket de Cloud Storage para almacenar el volcado de la base de datos.

Si usas la replicación, debes asegurarte de que la réplica de Cloud SQL y AlloyDB para PostgreSQL tenga acceso a tu base de datos principal (de origen). Se puede obtener este acceso con las opciones de conectividad documentadas.

Según tu caso de uso y su criticidad, es posible que debas implementar una situación de resguardo, que suele incluir la inversión de la dirección de la replicación. En este caso, es posible que necesites un mecanismo de replicación adicional desde tu instancia de Cloud SQL y AlloyDB para PostgreSQL de destino hasta tu instancia de Amazon de origen.

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.

Si migras a AlloyDB para PostgreSQL, considera usar una instancia de Cloud SQL para PostgreSQL como posible destino para tus situaciones de resguardo. Usa la extensión pglogical para configurar la replicación lógica en esa instancia de Cloud SQL.

Para obtener más información, consulta los siguientes recursos:

• Recomendaciones para la importación y exportación de datos
• Conectividad para PostgreSQL y PostgreSQL a AlloyDB para PostgreSQL en Database Migration Service

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 subsecciones.

Copias de seguridad integradas del motor de base de datos

Usa la utilidad pg_dump para crear una copia de seguridad. Para obtener más información sobre el uso de esta utilidad para importar y exportar datos, consulta los siguientes recursos:

• Página de documentación de la utilidad pg_dump
• Importa datos a Cloud SQL para PostgreSQL
• Cómo importar un archivo de DMP a AlloyDB para PostgreSQL

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 el trabajo 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 el cambio a producción.

En Database Migration Service, la migración comienza con la volcado y la restauración del esquema inicial sin índices ni restricciones, seguidos de la operación de copia de datos. Una vez que se completa la copia de datos, se restablecen los índices y las restricciones. Por último, se inicia la replicación continua de los cambios de la instancia de la base de datos de origen a la de destino.

Database Migration Service usa la extensión pglogical para la replicación desde tu instancia de base de datos de origen a la de destino. Al comienzo de la migración, esta extensión configura la replicación solicitando bloqueos exclusivos a corto plazo en todas las tablas de tu instancia de origen de Amazon RDS o Amazon Aurora. Por este motivo, te recomendamos que inicies la migración cuando la base de datos esté menos ocupada y que evites las instrucciones en la fuente durante la fase de volcado y replicación, ya que las instrucciones DDL no se replican. Si debes realizar operaciones de DDL, usa las funciones de "pglogical" para ejecutar instrucciones DDL en tu instancia de origen o ejecuta manualmente las mismas instrucciones DDL en la instancia de destino de la migración, pero solo después de que finalice la etapa de volcado inicial.

El proceso de migración con Database Migration Service finaliza con la operación de promoción. Cuando se promueve una instancia de base de datos, se desconecta la base de datos de destino del flujo de cambios provenientes de la base de datos de origen y, luego, la instancia de destino independiente se promueve a una instancia principal. Este enfoque también se denomina "cambio de producción".

Para obtener un proceso de configuración de migración completamente detallado, consulta las guías de inicio rápido para PostgreSQL y PostgreSQL a AlloyDB para PostgreSQL.

Replicación integrada del motor de base de datos

Cloud SQL admite dos tipos de replicación lógica: la replicación lógica integrada de PostgreSQL y la replicación lógica a través de la extensión pglogical. En el caso de AlloyDB para PostgreSQL, recomendamos usar la extensión pglogical para la replicación. Cada tipo de replicación lógica tiene sus propias funciones y limitaciones.

La replicación lógica integrada tiene las siguientes características y limitaciones:

• Está disponible en PostgreSQL 10 y versiones posteriores.
• Se replican todos los cambios y las columnas. Las publicaciones se definen a nivel de la tabla.
• Los datos solo se replican de tablas base a tablas base.
• No realiza la replicación de secuencias.
• Es el tipo de replicación recomendado cuando hay muchas tablas que no tienen clave primaria. Configura la replicación lógica integrada de PostgreSQL. En el caso de las tablas sin clave primaria, aplica el formulario REPLICA IDENTITY FULL para que la replicación integrada use toda la fila como identificador único en lugar de una clave primaria.

La replicación lógica de pglogical tiene las siguientes características y limitaciones:

• Está disponible en todas las versiones de PostgreSQL y ofrece compatibilidad entre versiones.
• El filtrado de filas está disponible en la fuente.
• No replica las tablas UNLOGGED y TEMPORARY.
• Se requiere una clave primaria o única en las tablas para capturar los cambios de UPDATE y DELETE.
• La replicación de secuencias está disponible.
• Es posible que la replicación se retrase.
• Proporciona detección de conflictos y resolución configurable si hay varios publicadores o conflictos entre los datos replicados y los cambios locales.

Para obtener instrucciones sobre cómo configurar la replicación lógica integrada de PostgreSQL desde un servidor externo, como Amazon RDS o Amazon Aurora para PostgreSQL, consulta los siguientes recursos:

• Configura la replicación lógica integrada de PostgreSQL
• Configura la replicación lógica con pglogical

Herramientas de terceros

Define las tareas de ejecución para la herramienta de terceros que elegiste.

En esta sección, nos enfocamos en Striim como ejemplo. Striim usa aplicaciones que adquieren datos de varias fuentes, los procesan y, luego, los entregan a otras aplicaciones o destinos.

Usas uno o más flujos para organizar estos procesos de migración dentro de tus aplicaciones personalizadas. Para codificar tus aplicaciones personalizadas, puedes usar una herramienta de programación gráfica o el lenguaje de programación Tungsten Query Language (TQL).

Para obtener más información sobre cómo usar Striim, consulta los siguientes recursos:

• Conceptos básicos de Striim: Conceptos de Striim

• Striim en la Google Cloud guía de inicio rápido: Cómo ejecutar Striim en Google Cloud

• Parámetros de configuración para la replicación continua: PostgreSQL y SQL Server

• Guía de prácticas recomendadas: Cómo cambiar de una carga inicial a una replicación continua

Si decides usar Striim para migrar tus datos, consulta las siguientes guías sobre cómo usar Striim para migrar datos a Google Cloud:

• Tutoriales de Striim Migration Service Google Cloud
• Cómo migrar bases de datos transaccionales a AlloyDB para PostgreSQL

Define situaciones de resguardo

Define elementos de acción de respaldo para cada tarea de ejecución de la migración, a fin de protegerte contra problemas imprevistos que puedan ocurrir durante el proceso de migración. Las tareas de respaldo suelen depender de la estrategia de migración y las herramientas que se usen.

La alternativa puede requerir un esfuerzo significativo. Como práctica recomendada, no realices el cambio 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 respaldo deben probarse correctamente para evitar una interrupción grave.

Define los criterios de éxito y establece límites de tiempo 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 la restauración de la copia de seguridad fallen a mitad del proceso. Según la cantidad de tiempo de inactividad planificado que haya transcurrido, 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 reversión se refiere a revertir la migración después de realizar el cambio de 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 contingencia, 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.

Respaldo simple

En esta estrategia de resguardo, vuelves a cambiar tus aplicaciones a la instancia de la base de datos de origen original. Adopta esta estrategia si puedes permitirte un tiempo de inactividad cuando recurras a la copia de seguridad o si no necesitas que se confirmen las transacciones en el nuevo sistema de destino.

Si necesitas todos los datos escritos en tu base de datos de destino y puedes permitirte un tiempo de inactividad, puedes considerar detener las escrituras en la instancia de la base de datos de destino, crear copias de seguridad integradas y restablecerlas en tu instancia de origen, y, luego, volver a conectar tus aplicaciones a la instancia de la base de datos de origen inicial. 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, podrías incorporarla a tu sistema de base de datos de origen inicial en un momento posterior, en especial si tus cargas de trabajo no dependen de ninguna hora de creación de registros específica ni de ninguna restricción de ordenación temporal.

Replicación inversa

En esta estrategia, replicas las escrituras que se producen en tu nueva base de datos de destino después de la transició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 los procesos de escritura se realizan 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 realizar 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 período breve sin respaldo.

Elige este enfoque cuando puedas conservar tu instancia de origen durante un tiempo y migres con la migración de replicación continua.

Replicación de reenvío

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 de tu elección. Puedes dirigir tus aplicaciones a esta tercera base de datos, que se conecta al servidor y ejecuta consultas de solo lectura mientras el servidor no está disponible. Puedes usar cualquier mecanismo de replicación, según tus necesidades. La ventaja de este enfoque es que se puede probar de extremo a extremo.

Adopta este enfoque cuando desees tener una alternativa en todo momento o cuando debas descartar tu base de datos fuente inicial poco después del cambio a producción.

Escrituras duplicadas

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

Tus aplicaciones escriben en las instancias de la base de datos de origen y de destino iniciales, lo que te permite realizar una transición gradual a la 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 problemas.

Recomendamos este enfoque cuando es fundamental no tener tiempo de inactividad por migración, tener una alternativa confiable y cuando tienes tiempo y recursos para refactorizar la aplicación.

Realiza pruebas y validaciones

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 las aplicaciones existentes después de que se cambian 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:

• Datos que se migrarán Para algunas cargas de trabajo, tal vez no sea necesario migrar todos los datos. Es posible que no desees migrar datos que ya estén agregados, sean redundantes, estén archivados o sean 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 particularmente 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 en 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 IOPS en ráfagas o SSD de IOPS aprovisionadas. Para comparar y dimensionar correctamente las instancias de destino, realiza pruebas comparativas de tus instancias de origen en las fases de evaluación y validación.

En el proceso de comparativas, aplicas secuencias de operaciones similares a las de producción en 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 pertinentes observadas durante las cargas máximas. Para los modelos de capacidad de recursos flexibles, como Aurora Serverless, considera consultar los datos históricos de las métricas para observar tus necesidades de ajuste de escala.

Se pueden usar las siguientes herramientas para realizar pruebas, validaciones y comparativas de bases de datos:

• HammerDB: Herramienta de código abierto para pruebas comparativas y de carga de bases de datos. Admite cargas de trabajo analíticas y transaccionales complejas, basadas en estándares de la industria, en varios motores de bases de datos (tanto TPROC-C como 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 configuraciones 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.
• Herramienta de comparativas DBT2: Comparativas especializadas para MySQL. Un conjunto de kits de carga de trabajo de la base de datos simula 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 utilizar una prueba de carga de procesamiento de transacciones en línea (OLTP) lista para usar.
• DbUnit: Es una herramienta de prueba de unidades de código abierto que se usa para probar las interacciones de base 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 a veces puede ser lenta, según el tamaño y la complejidad de la base de datos. Te 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. Utiliza una sintaxis básica para crear casos de prueba y ofrece 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 comunidad de asistencia ni documentación extensa, en comparación con otras herramientas. Te recomendamos esta herramienta si tus consultas no son complejas y deseas realizar pruebas automatizadas e integrarlas en tu proceso de integración y entrega continuas.

Para ejecutar una prueba de extremo a extremo, incluida la prueba del plan de migración, siempre realiza un ejercicio de prueba de migración. Una ejecución de prueba realiza la migración de la base 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 las configuraciones 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 calibrar tu cronograma.
• Representa una ocasión 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 pequeño conjunto 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 el riesgo. Con este enfoque, realizas la validación de datos en un subconjunto de bases de datos migradas a través de la misma herramienta, en especial si esta herramienta es un servicio de migración administrado.

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

• Compara los esquemas de origen y destino. Verifica si existen todas las tablas y los archivos ejecutables. Verifica los recuentos de filas y compara los datos a nivel de la base de datos.
• Ejecutar secuencias de comandos de validación de datos personalizadas
• Comprueba que los datos migrados también se vean 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 cambiadas 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, de modo que las cargas de trabajo admitan por completo los datos migrados junto con los datos recién creados.
• Prueba el rendimiento de las consultas de bases de datos más usadas para observar si hay alguna degradación debido a configuraciones incorrectas o a un tamaño inadecuado.

Idealmente, todas estas situaciones de prueba de migración deben ser automatizadas y repetibles en cualquier sistema fuente. El paquete de casos de prueba automatizados se adapta para realizar pruebas en las aplicaciones cambiadas.

Si usas Database Migration Service como herramienta de migración, consulta la versión de PostgreSQL o PostgreSQL a AlloyDB para PostgreSQL del tema "Verifica 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). 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 multinivel personalizadas para comparar las tablas de origen y destino a nivel de tabla, columna y fila. También puedes agregar reglas de validación.

La DVT abarca muchas Google Cloud fuentes de datos, incluidos 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 la organización basadas en eventos.

La DVT admite los siguientes tipos de validaciones:

• Comparaciones a nivel del esquema
• Columna (incluidas "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úsquedas personalizadas

Para obtener más información sobre la DVT, consulta el repositorio de Git y La herramienta de validación de datos de Google Cloudfacilita la validación de datos.

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 el tiempo máximo asignado para ese paso. Cuando esto suceda, envía actualizaciones intermedias periódicas a los equipos involucrados.
• Si el período es mayor que la cantidad máxima de tiempo reservado para cada paso del plan, considera revertir la acción.
• Toma decisiones de "sí o no" para cada paso del plan de migración y cambio.
• Considera acciones de reversión o situaciones alternativas para cada uno de los pasos.

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

Realiza la transición de producción

El proceso de corte de producción de alto nivel puede diferir según la estrategia de migración que elijas. Si puedes tener tiempo de inactividad en tus cargas de trabajo, la migración comienza deteniendo las escrituras en tu base de datos de origen.

En el caso de las migraciones de replicación continua, por lo general, debes seguir estos pasos generales en el proceso de transición:

• 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 que la herramienta de migración elegida haya migrado los datos, valida los datos en la base de datos de destino. Confirmas que la base de datos de origen y las bases de datos de destino están sincronizadas, y que los datos de la instancia de destino cumplen con los estándares de éxito de la 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. Implementa 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 produzca un tiempo de inactividad de la aplicación.

Sigue las prácticas recomendadas para el cambio de producción:

• Supervisa las aplicaciones que funcionan con la base de datos de destino después del cambio.
• Define un período de supervisión para determinar si necesitas implementar 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 o AlloyDB para PostgreSQL

Una vez que se completa 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. En algunos casos, también es posible que se requieran copias de seguridad para cumplir con algunas reglamentaciones de datos.

• Recopila la configuración de los parámetros de la base de datos de tu instancia de origen. También puedes verificar que coincidan con los que recopilaste en la fase de creación del inventario. Ajusta los parámetros de la instancia de destino para que coincidan con los de la instancia de origen.

• 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 instancia de destino.

En una situación de respaldo, es posible que desees implementar la replicación de tus escrituras en la instancia de Cloud SQL de vuelta 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 actualizadas las instancias de origen después de la migración, replica las escrituras realizadas en las instancias de Cloud SQL de destino en la base de datos de origen. Si necesitas revertir el proceso, puedes volver a tus instancias de origen anteriores con una pérdida de datos mínima.

Como alternativa, puedes usar otra instancia y replicar tus cambios en ella. Por ejemplo, cuando AlloyDB para PostgreSQL es un destino de migración, considera configurar la replicación en una instancia de Cloud SQL para PostgreSQL para situaciones de fallback.

Además de la limpieza del entorno de origen, se deben realizar las siguientes configuraciones críticas para tus instancias de Cloud SQL para PostgreSQL:

• 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 de modo 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 haya finalizado la operación anterior.

Para obtener más información sobre el mantenimiento y las prácticas recomendadas en las instancias de Cloud SQL para PostgreSQL y AlloyDB para PostgreSQL, consulta los siguientes recursos:

• Acerca del mantenimiento en instancias de Cloud SQL para PostgreSQL
• Acerca de la configuración de instancias en instancias de Cloud SQL para PostgreSQL
• Acerca del mantenimiento en AlloyDB para PostgreSQL
• Configura las marcas de base de datos de una instancia de AlloyDB para PostgreSQL

Para obtener más información sobre el mantenimiento y las prácticas recomendadas, consulta Información sobre el mantenimiento en instancias de Cloud SQL.

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:

1. Evalúa tu entorno actual, los equipos y el ciclo de optimización.
2. Establece tus requisitos y objetivos de optimización.
3. Optimiza el entorno y los equipos.
4. 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 la optimización de tu entorno de Google Cloud , consulta Migra a Google Cloud: Optimiza tu entorno y Google Cloud Well-Architected Framework: Optimización del rendimiento.

Establece tus requisitos de optimización

Revisa los siguientes requisitos de optimización para tu Google Cloudentorno 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 tu objetivo de punto de recuperación (RPO). Para aumentar la confiabilidad y la disponibilidad, ten en cuenta lo siguiente:

• En casos de cargas de trabajo con alto contenido de lectura, agrega réplicas de lectura para descargar 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 de recuperación ante desastres sólida.
• Para las 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.

• Cuando migres a Cloud SQL para PostgreSQL, considera usar la edición Enterprise Plus de Cloud SQL para aprovechar la mayor disponibilidad, la retención de registros y el mantenimiento planificado con un tiempo de inactividad casi nulo. Para obtener más información sobre Cloud SQL Enterprise Plus, consulta Introducción a las ediciones de Cloud SQL y Mantenimiento planificado con un tiempo de inactividad casi nulo.

  Para obtener más información sobre cómo aumentar la confiabilidad y la disponibilidad de tu base de datos de Cloud SQL para PostgreSQL, consulta los siguientes documentos:

  • Cómo ascender réplicas para la migración regional o la recuperación ante desastres
  • Recuperación ante desastres de base de datos de Cloud SQL
  • Acerca de las copias de seguridad de Cloud SQL
  • Documentación para evitar el borrado de una instancia

• Cuando migres a AlloyDB para PostgreSQL, configura planes de copias de seguridad y considera usar el proxy de autenticación de AlloyDB para PostgreSQL. Considera crear clústeres secundarios y trabajar con ellos para la replicación entre regiones.

  Para obtener más información sobre cómo aumentar la confiabilidad y la disponibilidad de tu base de datos de AlloyDB para PostgreSQL, consulta los siguientes documentos:

  • Funcionamiento interno de AlloyDB para PostgreSQL: continuidad empresarial
  • Acerca del proxy de autenticación de AlloyDB para PostgreSQL
  • Trabaja con la replicación entre regiones

Aumentar 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 proporcionar 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 tienden a aumentar con el tiempo.

• Identifica los posibles recursos sobreestimados:

  • Ajustar el tamaño adecuado de tus instancias de Cloud SQL puede reducir el costo de infraestructura sin agregar riesgos adicionales a la estrategia de administración de capacidad.
  • Cloud Monitoring proporciona paneles predefinidos que ayudan a identificar el estado y la utilización de la capacidad de muchos componentes de Google Cloud, 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 o recuperación ante desastres, y quítalas de tu infraestructura.

• Quita las tablas y los objetos que ya no son 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.

  • Para 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, el HDD podría ser más adecuado.
  • Para obtener más detalles, 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.

• Cuando migras a Cloud SQL para PostgreSQL, puedes reducir las instancias con aprovisionamiento excesivo y, también, identificar las instancias inactivas de Cloud SQL para PostgreSQL.

  Para obtener más información sobre cómo aumentar la rentabilidad de tu instancia de base de datos de Cloud SQL para PostgreSQL, consulta los siguientes documentos:

  • Habilita los aumentos de almacenamiento automáticos para Cloud SQL
  • Identifica instancias de Cloud SQL inactivas
  • Reduce las instancias de Cloud SQL sobreaprovisionadas
  • Optimiza consultas con un uso de memoria alto
  • Crea y administra paneles personalizados
  • Elige entre el almacenamiento SSD y HDD
  • Descuentos por compromiso de uso
  • Active Assist

• Cuando usas AlloyDB para PostgreSQL, puedes hacer lo siguiente para aumentar la rentabilidad:

  • Usar el motor columnar para realizar de manera eficiente ciertas consultas analíticas, como funciones de agregación o análisis de tablas
  • Usa el recomendador de cuota de almacenamiento del clúster de AlloyDB para PostgreSQL para detectar los clústeres que corren el riesgo de alcanzar la cuota de almacenamiento.

  Para obtener más información sobre cómo aumentar la rentabilidad de tu infraestructura de bases de datos de AlloyDB para PostgreSQL, consulta las siguientes secciones de la documentación:

  • Acerca del motor de columnas de AlloyDB para PostgreSQL
  • Optimiza los clústeres de AlloyDB para PostgreSQL con capacidad insuficiente
  • Aumenta la cuota de almacenamiento del clúster para AlloyDB para PostgreSQL
  • Supervisa las consultas activas

Aumenta el rendimiento de la infraestructura de tu base de datos

Los problemas de rendimiento menores relacionados con la base de datos suelen tener el potencial de afectar toda la operación. Para mantener y aumentar el rendimiento de tu instancia de Cloud SQL, considera los siguientes lineamientos:

• Si tienes una gran cantidad de tablas de bases de datos, estas pueden afectar el rendimiento y la disponibilidad de la instancia, y hacer que 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, actualizaciones o eliminaciones lentas de la base de datos, verifica las ubicaciones del escritor y de la base de datos. El envío de datos a larga distancia provoca 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.

Cuando migres de Amazon RDS y Aurora para PostgreSQL a Cloud SQL para PostgreSQL, ten en cuenta los siguientes lineamientos:

• Usa el almacenamiento en caché para mejorar el rendimiento de lectura. Inspecciona las diversas estadísticas de la vista pg_stat_database. Por ejemplo, la proporción de blks_hit / (blks_hit + blks_read) debería ser superior al 99%. Si esta proporción no es superior al 99%, considera aumentar el tamaño de la RAM de tu instancia. Para obtener más información, consulta Recopilador de estadísticas de PostgreSQL.
• Recupera espacio y evita el bajo rendimiento del índice. Según la frecuencia con la que cambian tus datos, establece un programa para ejecutar el comando VACUUM en tu instancia de Cloud SQL para PostgreSQL.
• Usa la edición Enterprise Plus de Cloud SQL para aumentar los límites de configuración de la máquina y la caché de datos. Para obtener más información sobre Cloud SQL Enterprise Plus, consulta Introducción a las ediciones de Cloud SQL.
• Cambia a AlloyDB para PostgreSQL. Si cambias, puedes tener compatibilidad total con PostgreSQL, mejor procesamiento transaccional y cargas de trabajo de análisis transaccionales rápidas admitidas en tu base de datos de procesamiento. También recibirás una recomendación para crear índices nuevos a través de la función del asesor de índices.

Para obtener más información sobre cómo aumentar el rendimiento de tu infraestructura de bases de datos de Cloud SQL para PostgreSQL, consulta la documentación sobre la mejora del rendimiento de Cloud SQL para PostgreSQL.

Cuando migres de Amazon RDS y Aurora para PostgreSQL a AlloyDB para PostgreSQL, ten en cuenta los siguientes lineamientos para aumentar el rendimiento de tu instancia de base de datos de AlloyDB para PostgreSQL:

• Usa el motor de columnas de AlloyDB para PostgreSQL para acelerar tus consultas analíticas.
• Usa el asesor de índices en AlloyDB para PostgreSQL. El asesor de índices hace un seguimiento de las consultas que se ejecutan con regularidad en tu base de datos y las analiza periódicamente para recomendar índices nuevos que pueden aumentar su rendimiento.
• Mejora el rendimiento de las consultas con las estadísticas de consultas en AlloyDB para PostgreSQL.

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 difíciles y lentos. Por este motivo, es fundamental contar con un lugar centralizado en el que todos los miembros del equipo puedan ver lo que sucede a nivel de la base de datos y de 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 recursos de Google Cloudque usas. Cloud Monitoring incluye paneles predefinidos para varios productos de Google Cloud , 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 que estén 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 tu aplicación.

• Database Center proporciona una descripción general centralizada de la flota de bases de datos asistida por IA. 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 las normas de la industria.

Para obtener más información sobre cómo aumentar la observabilidad de tu infraestructura de bases de datos, consulta las siguientes secciones de la documentación:

• Supervisa instancias de Cloud SQL para PostgreSQL
• Supervisa instancias con AlloyDB para PostgreSQL

Prácticas recomendadas y lineamientos operativos generales de Cloud SQL y AlloyDB para PostgreSQL

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

A continuación, se incluyen algunas recomendaciones generales importantes sobre 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 de modo que se tenga en cuenta la retención del registro de transacciones (binario), en especial para las instancias con alta actividad de escritura.

Para poder abordar 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:

Escalar verticalmente la infraestructura: Aumenta los recursos (como el 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 más a fondo 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 vacío y reindexación de tablas muy actualizadas. Verifica si se realizaron estas operaciones de mantenimiento y cuándo se hicieron por última vez, en especial en los objetos afectados (tablas, índices). Descubre si hubo un cambio en las actividades normales de la base de datos. Por ejemplo, si agregaste recientemente una columna nueva o si una tabla tiene muchas actualizaciones.

Realiza ajustes y optimizaciones en 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, bloqueos y esperas de índice en otros recursos. Considera agregar índices para admitir tus consultas críticas. Elimina los índices y las claves externas no críticos. Considera reescribir las consultas y las uniones complejas. El tiempo que lleva resolver tu problema depende de la experiencia y la disponibilidad de tu equipo, y puede variar de horas a días.

Escala horizontalmente tus lecturas: 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 el escalamiento 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 y conectarlas a la réplica de lectura.

Reestructuración de la base de datos: Considera la posibilidad de particionar e 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. En ocasiones, un diseño deficiente del modelo de datos puede generar problemas de rendimiento, que se pueden compensar parcialmente con el escalamiento vertical. Sin embargo, un modelo de datos adecuado es una solució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 horizontalmente tus escrituras fragmentando tu 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. Dividir la instancia de la base de datos en varias instancias más pequeñas con criterios de partición específicos Los criterios pueden basarse en el cliente o el asunto. Esta opción te permite escalar horizontalmente tus operaciones de lectura y escritura. Sin embargo, aumenta la complejidad de las cargas de trabajo de la base de datos y la aplicación. También podría generar fragmentos desequilibrados llamados puntos de acceso, lo que superaría el beneficio de la fragmentación.

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

• Para aliviar el tráfico de la instancia principal, agrega réplicas de lectura. También puedes usar un balanceador de cargas, como HAProxy, para administrar el tráfico hacia las réplicas. Sin embargo, evita usar demasiadas réplicas, ya que esto dificulta la operación de VACUUM. Para obtener más información sobre el uso de HAProxy, consulta el sitio web oficial de HAProxy.
• Optimiza la operación VACUUM aumentando la memoria del sistema y el parámetro maintenance_work_mem. Aumentar la memoria del sistema significa que se pueden procesar más tuplas por lotes en cada iteración.
• Dado que los índices más grandes consumen una cantidad significativa de tiempo para el análisis del índice, establece el parámetro INDEX_CLEANUP en OFF para limpiar y congelar rápidamente los datos de la tabla.
• Cuando uses AlloyDB para PostgreSQL, usa el panel de Estadísticas del sistema de AlloyDB para PostgreSQL y los registros de auditoría. El panel de Estadísticas del sistema de AlloyDB para PostgreSQL muestra las métricas de los recursos que usas y te permite supervisarlos. Para obtener más detalles, consulta los lineamientos del tema Supervisa instancias en la documentación de AlloyDB para PostgreSQL.

Obtén más información en los vínculos siguientes:

• Sección de prácticas recomendadas generales y Lineamientos operativos para Cloud SQL para PostgreSQL
• Acerca del mantenimiento y Descripción general de AlloyDB para PostgreSQL

¿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

Otro colaborador: Somdyuti Paul | Especialista en administración de datos