Compartir a través de

Procedimientos recomendados para una migración sin problemas a Azure Database for PostgreSQL.

  • Artículo

SE APLICA A: Azure Database for PostgreSQL con servidor flexible

En este artículo se explican los problemas comunes encontrados y los procedimientos recomendados para garantizar una migración fluida y correcta al servidor flexible de Azure Database for PostgreSQL.

Validación previa a la migración

Como primer paso de la migración, ejecute la validación previa a la migración antes de realizar una migración. Puede usar las opciones Validar y Validar y Migrar en la página Configuración de la migración. La validación previa a la migración realiza comprobaciones minuciosas con respecto a un conjunto de reglas predefinidas. El objetivo es identificar los posibles problemas y proporcionar información procesable para las acciones correctivas. Siga ejecutando la validación previa a la migración hasta que se produzca el estado Correcto. Para obtener más información, consulte Validaciones de premigración.

Configuración de servidor flexible de destino

Durante la copia base inicial de los datos, se ejecutan múltiples instrucciones de inserción en el destino, lo que genera WAL (registros de escritura anticipada). Hasta que se archiven estos WAL, los registros consumen almacenamiento en el destino y el almacenamiento requerido por la base de datos.

Para calcular el número, inicie sesión en la instancia de origen y ejecute este comando para que se migren todas las bases de datos:

SELECT pg_size_pretty( pg_database_size('dbname') );

Es aconsejable asignar suficiente almacenamiento en el servidor flexible, equivalente a 1,25 veces o 25 % más de almacenamiento que lo que se usa por la salida al comando anterior. También puede usar Crecimiento automático de almacenamiento.

Importante

El tamaño del almacenamiento no se puede reducir en la configuración manual ni en el crecimiento automático del almacenamiento. Cada paso en el espectro de configuración del almacenamiento se duplica en tamaño, por lo que es prudente calcular de antemano el almacenamiento necesario.

El inicio rápido para Crear una instancia de servidor flexible de Azure Database for PostgreSQL mediante el portal es un buen punto de partida. Para más información sobre cada configuración del servidor, consulte Las opciones de proceso y almacenamiento del servidor flexible de Azure Database for PostgreSQL.

Importante

Una vez creado el servidor flexible, asegúrese de cambiar el parámetro de servidor de password_encryption en el servidor flexible de SCRAM-SHA-256 a MD5 antes de indizar la migración. Esto es esencial para que las credenciales existentes en un solo servidor funcionen en el servidor flexible.

Escala de tiempo de migración

Cada migración tiene una duración máxima de siete días (168 horas) después de iniciarse y se agota el tiempo de espera después de siete días. Puede completar su migración y la transición de la aplicación después de que la validación de los datos y todas las comprobaciones se hayan completado para evitar que la migración agote el tiempo de espera. En migraciones en línea, una vez completada la copia base inicial, la ventana de transición tiene una duración de tres días (72 horas) antes de que se agote el tiempo de espera. En migraciones sin conexión, las aplicaciones deben dejar de escribir en la base de datos para evitar la pérdida de datos. Del mismo modo, para la migración en línea, mantenga el tráfico bajo durante toda la migración.

La mayoría de los servidores que no son de producción (desarrollo, pruebas de aceptación de usuario, prueba y almacenamiento provisional) se migran mediante migraciones sin conexión. Dado que estos servidores tienen menos datos que los servidores de producción, la migración es rápida. Para la migración del servidor de producción, debe saber el tiempo que tardaría en completarse la migración para planificarla de antemano.

El tiempo necesario para que se complete una migración depende de varios factores. Incluye el número de bases de datos, el tamaño, el número de tablas dentro de cada base de datos, el número de índices y la distribución de datos entre tablas. También depende de la SKU del servidor de destino y de las IOPS disponibles en la instancia de origen y en el servidor de destino. Con tantos factores que pueden afectar a la duración de la migración, es difícil calcular el tiempo total que tardará en completarse una migración. El mejor enfoque es realizar una migración de prueba con la carga de trabajo.

Las siguientes fases se consideran para calcular el tiempo de inactividad total para realizar la migración del servidor de producción:

  • Migración de restauración a un momento dado: la mejor manera de obtener una buena estimación sobre el tiempo necesario para migrar el servidor de bases de datos de producción es tomar una restauración a un momento dado (PITR) del servidor de producción y ejecutar la migración sin conexión en este servidor recién restaurado.

  • Migración del búfer: después de completar el paso anterior, puede planificar la migración de producción real durante un periodo de tiempo en el que el tráfico de la aplicación es bajo. Esta migración se puede planificar el mismo día o probablemente con una semana de antelación. En este momento, es posible que el tamaño del servidor de origen haya aumentado. Actualice el tiempo de migración estimado para el servidor de producción en función del aumento que se haya producido. Si es significativo, considere la posibilidad de realizar otra prueba mediante el servidor de restauración a un momento dado. Pero para la mayoría de los servidores, el aumento del tamaño no debe ser lo suficientemente significativo.

  • Validación de datos: una vez completada la migración para el servidor de producción, debe comprobar si los datos del servidor flexible son una copia exacta de la instancia de origen. Puede usar herramientas de código abierto o de terceros o puede realizar la validación manualmente. Prepare los pasos de validación que desea realizar antes de la migración real. La validación puede incluir lo siguiente:

    • Coincidencia del recuento de filas para todas las tablas implicadas en la migración.

    • Coincidencia de los recuentos para todos los objetos de base de datos (tablas, secuencias, extensiones, procedimientos e índices).

    • Comparación de id. máximos o mínimos de las columnas clave relacionadas con la aplicación.

      Nota:

      El tamaño comparativo de las bases de datos no es la métrica adecuada para la validación. La instancia de origen podría tener sobredimensionamientos o tuplas inactivas, lo que puede aumentar el tamaño de la instancia de origen. Es normal tener diferencias de tamaño entre las instancias de origen y los servidores de destino. Un problema en los tres pasos anteriores de validación indica un problema con la migración.

  • Migración de la configuración del servidor: los parámetros de servidor personalizados, las reglas de firewall (si procede), las etiquetas y las alertas deben copiarse manualmente de la instancia de origen al destino.

  • Cambio de cadenas de conexión: la aplicación debe cambiar sus cadenas de conexión a un servidor flexible después de la validación correcta. Esta actividad se coordina con el equipo de la aplicación para cambiar todas las referencias de las cadenas de conexión que apuntan a la instancia de origen. En el servidor flexible, el parámetro user se puede usar en el formato user=username en la cadena de conexión.

Por ejemplo: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1

Aunque una migración se ejecuta a menudo sin ningún problema, se recomienda planear contingencias si se necesita más tiempo para la depuración o si es necesario reiniciar una migración.

Puntos de referencia de la velocidad de migración

En la tabla siguiente se muestra el tiempo necesario para realizar migraciones para bases de datos de varios tamaños mediante el servicio de migración. La migración se realizó mediante un servidor flexible con la SKU siguiente: Standard_D4ds_v4 (4 núcleos y 16 GB de memoria).

Tamaño de base de datos Tiempo aproximado necesario (HH:MM)
1 GB 00:01
5 GB 00:03
10 GB 00:08
50 GB 00:35
100 GB 01:00
500 GB 04:00
1000 GB 07:00

Los números anteriores proporcionan una aproximación del tiempo necesario para completar la migración. Se recomienda encarecidamente ejecutar una migración de prueba con la carga de trabajo para obtener un valor preciso para migrar el servidor.

Importante

Aunque la SKU ampliable no es una limitación, se recomienda elegir una SKU superior para que el servidor flexible realice migraciones más rápidas. El servidor flexible de Azure Database for PostgreSQL admite un escalado de proceso e IOPS de tiempo de inactividad casi nulo, por lo que la SKU puede actualizarse con un tiempo de inactividad mínimo. Siempre puede cambiar la SKU para que coincida con las necesidades de la aplicación después de la migración.

Mejora de la velocidad de migración: migración paralela de tablas

Se recomienda una SKU eficaz para el destino, ya que el servicio de migración de PostgreSQL se ejecuta fuera de un contenedor en el servidor flexible. Una SKU eficaz permite migrar más tablas en paralelo. Puede volver a escalar el SKU a la configuración preferida después de la migración. Esta sección contiene pasos para mejorar la velocidad de migración en caso de que la distribución de datos entre las tablas tenga que ser más equilibrada o una SKU más eficaz no afecte significativamente a la velocidad de migración.

Si la distribución de datos en la fuente está muy desequilibrada, con la mayor parte de los datos presentes en una tabla, la capacidad de procesamiento asignada para la migración debe utilizarse por completo, lo que crea un cuello de botella. Por lo tanto, divida tablas grandes en fragmentos más pequeños que se migrarán en paralelo. Esta característica se aplica a las tablas con más de 1 000 000 (1 m) tuplas. Es posible dividir la tabla en fragmentos más pequeños si se cumple una de las condiciones siguientes:

  • La tabla debe tener una columna con una clave principal simple (no compuesta) o un índice único de tipo int o significant int.

    Nota:

    En el caso de los enfoques primero y segundo, el usuario debe evaluar cuidadosamente las implicaciones de agregar una columna de índice única al esquema de origen. Solo debe continuar con los cambios tras confirmar que agregar una columna de índice única no afectará a la aplicación.

  • Si la tabla no tiene una clave principal simple o un índice único de tipo int o significant int, pero tiene una columna que cumple los criterios de tipo de datos, la columna se puede convertir en un índice único mediante el comando siguiente. Este comando no requiere un bloqueo en la tabla.

        create unique index concurrently partkey_idx on <table name> (column name);

  • Si la tabla no tiene una clave principal simple int/big int ni un índice único ni ninguna columna que cumpla los criterios de tipo de datos, puede agregar dicha columna mediante simple intALTER/ y quitarla tras la migración. La ejecución del comando ALTER requiere un bloqueo en la tabla.

        alter table <table name> add column <column name> big serial unique;

Si se alguna de las condiciones anteriores, la tabla se migra en varias particiones en paralelo, lo que debe proporcionar un aumento en la velocidad de migración.

Funcionamiento

  • El servicio de migración busca el valor entero máximo y mínimo del índice principal o único de la tabla que se debe dividir y migrar en paralelo.
  • Si la diferencia entre el valor mínimo y máximo es superior a 1 000 000 (1 m), la tabla se divide en varias partes y cada parte se migra en paralelo.

En resumen, el servicio de migración de PostgreSQL migra una tabla en subprocesos paralelos y reduce el tiempo de migración si:

  • La tabla tiene una columna con una clave principal simple o un índice único de tipo int o int significativo.
  • La tabla tiene al menos 1 000 000 (1 m) filas para que la diferencia entre el valor mínimo y máximo de la clave principal sea superior a 1 000 000 (1 m).
  • La SKU usada tiene núcleos inactivos que se pueden usar para migrar la tabla en paralelo.

Vaciado del sobredimensionamiento en la base de datos PostgreSQL

Con el tiempo, a medida que se agregan, actualizan y eliminan datos, PostgreSQL puede acumular filas muertas y espacio de almacenamiento desperdiciado. Este sobredimensionamiento puede provocar un aumento de los requisitos de almacenamiento y una disminución del rendimiento de las consultas. El vaciado es una tarea de mantenimiento crucial que ayuda a recuperar este espacio desaprovechado y asegura el funcionamiento eficaz de la base de datos. El vaciado soluciona problemas como filas muertas y sobredimensionamiento de tablas, para garantizar un uso eficaz del almacenamiento. También ayuda a garantizar una migración más rápida porque el tiempo de migración es una función del tamaño de la base de datos.

PostgreSQL proporciona el comando VACUUM para reclamar el almacenamiento ocupado por filas inactivas. La opción ANALYZE también recopila estadísticas para optimizar aún más el planeamiento de consultas. En el caso de las tablas con actividad de escritura intensiva, el proceso de VACUUM puede ser más agresivo mediante VACUUM FULL, pero requiere más tiempo para ejecutarse.

  • Vaciado estándar

    VACUUM your_table;

  • Vaciado con análisis

    VACUUM ANALYZE your_table;

  • Vaciado agresivo para tablas de escritura intensiva

    VACUUM FULL your_table;

En este ejemplo, sustituya your_table por el nombre real de la tabla. El comando VACUUM sin FULL recupera espacio de forma eficaz, mientras que VACUUM ANALYZE optimiza la planificación de consultas. La opción VACUUM FULL debe usarse con criterio debido a su mayor impacto en el rendimiento.

Algunas bases de datos almacenan objetos grandes, como imágenes o documentos, que pueden contribuir al sobredimensionamiento de la base de datos a lo largo del tiempo. El comando VACUUMLO está diseñado para objetos grandes en PostgreSQL.

  • Vaciado de objetos grandes

    VACUUMLO;

La incorporación regular de estas estrategias de vaciado asegura un buen mantenimiento de la base de datos PostgreSQL.

Consideración especial

Hay condiciones especiales que normalmente hacen referencia a circunstancias, configuraciones o requisitos previos únicos que debe tener en cuenta antes de continuar con un tutorial o módulo. Estas condiciones podrían incluir versiones de software específicas, requisitos de hardware o herramientas adicionales necesarias para completar correctamente el contenido de aprendizaje.

Migración en línea

La migración en línea hace uso de pgcopydb follow y se aplican algunas de las restricciones de decodificación lógica. También le recomendamos que tenga una clave principal en todas las tablas de una base de datos sometida a migración en línea. Si la clave principal no está presente, la deficiencia da lugar a que solo se reflejen las operaciones de insert durante la migración, excluyendo las actualizaciones o eliminaciones. Agregue una clave principal temporal a las tablas pertinentes antes de continuar con la migración en línea.

Nota:

En el caso de la migración en línea de tablas sin una clave principal, solo se reproducen las operaciones insert en el destino. Esto puede introducir incoherencias en la base de datos si los registros actualizados o eliminados en el origen no se reflejan en el destino.

Una alternativa consiste en usar el comando ALTER TABLE donde la acción es REPLICA IDENTIY con la opción FULL. La opción FULL registra los valores antiguos de todas las columnas de la fila para que, incluso en ausencia de una clave principal, todas las operaciones CRUD se reflejen en el destino durante la migración en línea. Si ninguna de estas opciones funciona, realice una migración sin conexión como alternativa.

Base de datos con extensión postgres_fdw

El módulo postgres_fdw proporciona el contenedor de datos externos postgres_fdw, que se puede usar para acceder a los datos almacenados en servidores externos de PostgreSQL. Si la base de datos usa esta extensión, se deben realizar los pasos siguientes para garantizar una migración correcta.

  1. Quite temporalmente (desvincular) el contenedor de datos externos en la instancia de origen.
  2. Realice la migración de datos en reposo mediante el servicio de migración.
  3. Restaure los roles de contenedor de datos externos, el usuario y los vínculos al destino después de la migración.

Base de datos con extensión postGIS

La extensión postGIS tiene cambios importantes o problemas de compatibilidad entre diferentes versiones. Si migra a un servidor flexible, la aplicación debe comprobarse con la versión postGIS más reciente para asegurarse de que la aplicación no se ve afectada o que se deben realizar los cambios necesarios. Las noticias de postGIS y las notas de la versión son un buen punto de partida para comprender los cambios importantes entre versiones.

Limpieza de la conexión de base de datos

A veces, podría producirse este error al iniciar una migración:

CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.

En este caso, puede conceder permisos a migration user para cerrar todas las conexiones activas a la base de datos o cerrar las conexiones manualmente antes de volver a intentar la migración.

Contenido relacionado