(Versión preliminar) Migrar en línea, desde un servidor Google AlloyDB for PostgreSQL a Azure Database for PostgreSQL, con el servicio de migración

Este artículo le guía en la migración de una instancia de PostgreSQL desde máquinas virtuales (VM) locales o de Azure a Azure Database for PostgreSQL en modo en línea.

El servicio de migración de Azure Database for PostgreSQL es un servicio totalmente administrado integrado en Azure Portal y la CLI de Azure. Simplifica el recorrido de migración al servidor flexible de Azure Database for PostgreSQL.

• Prerrequisitos
• Realización de la migración
• Supervisión de la migración
• Inicio de la transición
• Comprobación de la migración cuando se complete

Prerrequisitos

Para comenzar la migración, necesita los siguientes requisitos previos:

Antes de iniciar la migración con el servicio de migración de Azure Database for PostgreSQL, es importante cumplir los siguientes requisitos previos, específicamente diseñados para escenarios de migración en línea.

• Comprobación de la versión de origen
• Instalación de test_decoding: configuración de origen
• Configuración de la configuración de destino
• Habilitación de CDC como origen
• Configuración de la configuración de red
• Habilitación de extensiones
• Comprobación de los parámetros del servidor
• Comprobación de usuarios y roles

Comprobación de la versión de origen

La versión del servidor PostgreSQL de origen debe ser 9.5 o posterior.

Si la versión de PostgreSQL de origen es inferior a la 9.5, actualícela a la versión 9.5 o posterior antes de iniciar la migración.

Nota:

El servicio de migración de Azure Database for PostgreSQL admite conexiones mediante la dirección IP para el origen de Google AlloyDB for PostgreSQL. No se admite el formato myproject:myregion:myinstance.

Instalación de test_decoding: configuración de origen

• test_decoding recibe WAL a través del mecanismo de descodificación lógica y lo descodifica en representaciones de texto de las operaciones realizadas.
• En Google AlloyDB for PostgreSQL, el complemento test_decoding está preinstalado y listo para la replicación lógica. Esto le permite configurar fácilmente ranuras de replicación lógicas y transmitir los cambios de WAL, lo que facilita casos de uso como la captura de datos de cambios (CDC) o la replicación en sistemas externos.
• Para más información sobre el complemento de descodificación de prueba, consulte la documentación de PostgreSQL

Configuración de la configuración de destino

• Antes de migrar, se debe crear el servidor flexible de Azure Database for PostgreSQL.
• SKU aprovisionada para Azure Database for PostgreSQL: el servidor flexible debe coincidir con el origen.
• Para crear una nueva instancia de Azure Database for PostgreSQL, visite Creación de un servidor flexible de Azure Database for PostgreSQL.

Habilitación de CDC como origen

• test_decoding El complemento de descodificación lógica captura los registros modificados del origen.
• Para asegurar que el usuario de la migración tenga los privilegios de replicación necesarios, ejecute el siguiente comando SQL:

ALTER USER <user> WITH REPLICATION;

• Vaya a la instancia de PostgreSQL de Google AlloyDB en google Cloud Console, seleccione el nombre de la instancia para abrir su página de detalles, seleccione el botón Editar y, en la sección Marcas, modifique las marcas siguientes:

  • Configura bandera alloydb.logical_decoding = on
  • Establezca la marca max_replication_slots en un valor mayor que uno; el valor debe ser mayor que el número de bases de datos seleccionadas para la migración.
  • Establezca la marca max_wal_senders en un valor mayor que uno. Debe ser al menos igual que max_replication_slots, además del número de remitentes que ya se han usado en la instancia.
  • La bandera wal_sender_timeout finaliza las conexiones de replicación inactivas que duran más tiempo que el número especificado de milisegundos. Establecer el valor en 0 (cero) deshabilita el mecanismo de tiempo de espera y es una configuración válida para la migración.

• En el servidor flexible de destino, para evitar que la migración en línea se quede sin espacio de almacenamiento para los registros, asegúrese de tener suficiente espacio de tablas mediante un disco administrado aprovisionado. Para ello, deshabilite el parámetro de servidor azure.enable_temp_tablespaces_on_local_ssd durante la migración y restáurelo al estado original después de la migración.

Configuración de la configuración de red

La configuración de red es fundamental para que el servicio de migración funcione correctamente. Asegúrese de que el servidor PostgreSQL de origen puede comunicarse con el servidor de Azure Database for PostgreSQL de destino. Las siguientes configuraciones de red son esenciales para una migración correcta.

Para obtener información sobre la configuración de red, visite Guía de red para el servicio de migración.

Habilitación de extensiones

Para asegurarse de que la migración se realiza correctamente usando el servicio de migración en Azure Database for PostgreSQL, es posible que tenga que comprobar las extensiones de la instancia de PostgreSQL de origen. Las extensiones proporcionan funcionalidades y características que podrían ser necesarias para la aplicación. Asegúrese de comprobar las extensiones en la instancia de PostgreSQL de origen antes de iniciar el proceso de migración.

En la instancia de destino del servidor flexible de Azure Database for PostgreSQL, habilite las extensiones admitidas identificadas en la instancia de PostgreSQL de origen.

Para obtener más información, consulte Extensiones y módulos.

Comprobación de los parámetros del servidor

Estos parámetros no se migran automáticamente al entorno de destino y deben configurarse manualmente.

• Haga coincidir los valores de parámetros del servidor de la base de datos de PostgreSQL de origen con Azure Database for PostgreSQL; para ello, acceda a la sección "Parámetros del servidor" en Azure Portal y actualice manualmente los valores según corresponda.

• Guarde los cambios de los parámetros y reinicie Azure Database for PostgreSQL para aplicar la nueva configuración si es necesario.

Comprobación de usuarios y roles

Al migrar a Azure Database for PostgreSQL, es esencial abordar la migración de usuarios y roles por separado, ya que requieren intervención manual:

• Migración manual de usuarios y roles: los usuarios y sus roles asociados deben migrarse manualmente a Azure Database for PostgreSQL. Para facilitar este proceso, puede usar la utilidad pg_dumpall con la marca --globals-only para exportar objetos globales, como roles y cuentas de usuario. Ejecute el comando siguiente, reemplazando <<username>> por el nombre de usuario real y <<filename>> por el nombre de archivo de salida deseado:

  pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
  

• Restricción en roles de superusuario: Azure Database for PostgreSQL no admite roles de superusuario. Por lo tanto, los usuarios con privilegios de superusuario deben tener esos privilegios eliminados antes de la migración. Asegúrese de ajustar los permisos y los roles según corresponda.

Si sigue estos pasos, puede asegurarse de que las cuentas de usuario y los roles se migran correctamente a Azure Database for PostgreSQL sin experimentar problemas relacionados con las restricciones de superusuario.

Deshabilitación de la alta disponibilidad (fiabilidad) y las réplicas de lectura en el destino

• Deshabilitar la alta disponibilidad (fiabilidad) y las réplicas de lectura en el entorno de destino es esencial. Estas características deben habilitarse solo una vez completada la migración.

• Al seguir estas instrucciones, puede ayudar a garantizar un proceso de migración fluido sin las variables agregadas que introducen la alta disponibilidad y las réplicas de lectura. Una vez que se completa la migración y la base de datos es estable, puede continuar con la habilitación de estas características para mejorar la disponibilidad y escalabilidad del entorno de base de datos en Azure.

Realización de la migración

Puede migrar mediante Azure Portal o la CLI de Azure.

Portal

Este artículo le guía a través del uso de Azure Portal para migrar la base de datos postgreSQL desde un servidor google AlloyDB for PostgreSQL a una instancia de Azure Database for PostgreSQL. Azure Portal permite realizar varias tareas, incluida la migración de bases de datos. Siguiendo los pasos descritos en este tutorial, puede transferir sin problemas la base de datos a Azure y aprovechar sus eficaces características y escalabilidad.

Configuración de la tarea de migración

El servicio de migración incluye una experiencia sencilla basada en un asistente en el portal de Azure.

Mediante Azure Portal:

1. Seleccione su servidor flexible de Azure Database for PostgreSQL.

2. En el menú de recursos, seleccione Migración.

   

3. Seleccione Crear para pasar por una serie de pestañas basadas en el asistente para realizar una migración a un servidor flexible desde una máquina virtual local o de Azure.

   Nota:

   La primera vez que utilice el servicio de migración aparecerá una cuadrícula vacía con un mensaje para comenzar la primera migración.

   Si ya se han creado migraciones al destino de servidor flexible, la cuadrícula ahora contiene información sobre los intentos de migración.

   

Configuración

Debe proporcionar varios detalles relacionados con la migración, como el nombre de la migración, el tipo de servidor de origen, la opción y el modo.

• El nombre de la migración es el identificador único de cada migración a este destino de servidor flexible. Este campo solo acepta caracteres alfanuméricos y no acepta ningún carácter especial excepto un guión (-). El nombre no puede empezar por un guion y debe ser único en un servidor de destino. Ninguna de las dos migraciones al mismo destino de servidor flexible puede tener el mismo nombre.

• Tipo de servidor de origen: en función del origen de PostgreSQL, puede seleccionar Máquina virtual de Azure o servidor local.

• Opción de migración : permite realizar validaciones antes de desencadenar una migración. Puede elegir cualquiera de las siguientes opciones:

  • Validar: comprueba la preparación del servidor y de la base de datos para la migración al destino.
  • Validar y migrar : realiza la validación antes de desencadenar una migración. Si no hay errores de validación, se inicia la migración.

Elegir la opción Validar o Validar y migrar siempre es un procedimiento recomendado para realizar validaciones de premigración antes de ejecutar la migración.

Para obtener más información sobre la validación de la migración previa, visite Migración previa.

• El modo de migración le permite elegir el modo para la migración. Sin conexión es la opción predeterminada. En este caso, lo cambiaremos a En línea.

Seleccione Siguiente: Servidor en tiempo de ejecución.

Servidor en tiempo de ejecución

El servidor en tiempo de ejecución de migración es una característica especializada dentro del servicio de migración en Azure Database for PostgreSQL, diseñada para actuar como servidor intermediario durante la migración. Se trata de una instancia de servidor flexible de Azure Database for PostgreSQL independiente que no es el servidor de destino, pero se usa para facilitar la migración de bases de datos desde un entorno de origen al que solo se puede acceder a través de una red privada.

Para obtener más información sobre el servidor en tiempo de ejecución, visite Servidor en tiempo de ejecución de migración.

Servidor de origen

La pestaña Servidor de origen le pide que proporcione detalles relacionados con el origen seleccionado en la pestaña Configuración , que es el origen de las bases de datos.

• Nombre del servidor: proporcione el nombre del host o la dirección IP del servidor postgreSQL de origen.
• Puerto : número de puerto del servidor de origen.
• Inicio de sesión del administrador : nombre del usuario administrador del servidor postgreSQL de origen.
• Contraseña : contraseña del inicio de sesión de administrador proporcionado para conectarse al servidor postgreSQL de origen.
• Modo SSL : los valores admitidos son preferred y required. Cuando el SSL en el servidor PostgreSQL de origen es OFF, use prefer. Si el SSL en el servidor de origen es ON, use el require. Los valores SSL se pueden determinar en el archivo postgresql.conf del servidor de origen.
• Conexión de prueba : realiza la prueba de conectividad entre el destino y el origen. Una vez que la conexión se haya realizado correctamente, puede continuar con la pestaña siguiente. Estas pruebas tienen como objetivo identificar cualquier problema de conectividad que pueda existir entre los servidores de destino y de origen, incluida la comprobación de la autenticación mediante las credenciales proporcionadas. El establecimiento de una conexión de prueba tarda unos segundos.

Después de la conexión de prueba correcta, seleccione Siguiente: Servidor de destino.

Servidor de destino

La pestaña Servidor de destino muestra metadatos para el destino de servidor flexible, como el nombre de la suscripción, el grupo de recursos, el nombre del servidor, la ubicación y la versión de PostgreSQL.

• Inicio de sesión del administrador: nombre del usuario administrador del servidor postgreSQL de destino.
• Contraseña : contraseña del inicio de sesión de administrador proporcionado para conectarse al servidor postgreSQL de destino.
• FQDN personalizado o dirección IP: el campo de dirección IP o FQDN personalizado es opcional y se puede usar cuando el destino está detrás de un servidor DNS personalizado o tiene espacios de nombres DNS personalizados, lo que hace que solo sea accesible a través de FQDN o direcciones IP específicas. Por ejemplo, esto podría incluir entradas como production-flexible-server.example.com, 198.1.0.2o un FQDN de PostgreSQL, como production-flexible-server.postgres.database.azure.com, si el servidor DNS personalizado contiene la zona postgres.database.azure.com DNS o las consultas reenviadas de esta zona a 168.63.129.16, donde el FQDN se resuelve en la zona DNS pública o privada de Azure.
• Conexión de prueba : realiza la prueba de conectividad entre el origen y el destino. Una vez que la conexión se haya realizado correctamente, puede continuar con la pestaña siguiente. Estas pruebas tienen como objetivo identificar cualquier problema de conectividad que pueda existir entre los servidores de origen y de destino, incluida la comprobación de la autenticación mediante las credenciales proporcionadas. El establecimiento de una conexión de prueba tarda unos segundos.

Después de la conexión de prueba correcta, seleccione Siguiente: Bases de datos para validar o migrar.

Bases de datos para validar o migrar

En la pestaña Bases de datos para validar o migrar , puede elegir una lista de bases de datos de usuario para migrar desde el servidor postgreSQL de origen.

Después de seleccionar las bases de datos, seleccione Siguiente: Resumen.

Resumen

La pestaña Resumen resume todos los detalles de origen y destino para crear la validación o migración. Revise los detalles y seleccione Iniciar validación y migración.

Cancelación de la validación o migración

Puede cancelar las validaciones o migraciones en curso. El flujo de trabajo debe estar en el estado En curso para cancelarse. No se puede cancelar una validación o migración en el estado Correcto o Erróneo .

La cancelación de una validación detiene cualquier actividad de validación adicional y la validación se mueve a un estado Cancelado .

La cancelación de una migración detiene aún más la actividad de migración en el servidor de destino y se mueve al estado Cancelado . No elimina ni deshace ningún cambio en el servidor de destino. Asegúrese de quitar las bases de datos implicadas en una migración cancelada de su servidor de destino.

CLI

En este artículo se explora el uso de la CLI de Azure para migrar la base de datos de PostgreSQL desde una máquina virtual de Azure o una instancia de PostgreSQL local a una instancia de Azure Database for PostgreSQL. La CLI de Azure proporciona una interfaz de línea de comandos eficaz y flexible que le permite realizar diversas tareas, incluida la migración de bases de datos. Siguiendo los pasos descritos en este artículo, puede transferir sin problemas la base de datos a Azure y aprovechar sus eficaces características y escalabilidad.

Para más información sobre la CLI de Azure con el servicio de migración, consulte Configuración de la CLI de Azure para el servicio de migración.

Una vez instalada la CLI, abra el terminal e inicie sesión en su cuenta de Azure usando el siguiente comando.

az login

Configuración de la tarea de migración

Para comenzar la migración, cree un archivo JSON con los detalles de la migración. El archivo JSON contiene la siguiente información:

• Edite los siguientes marcadores de posición << >> en las líneas JSON y almacénelos en el equipo local como <<filename>>.json donde se invoque la CLI. En este tutorial, hemos guardado el archivo en c:/migration-CLI/migration_body.json

{
"properties": {
"SourceDBServerResourceId": "<<source-server-hostname-or-IP-address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<source-server-administrator-password>>",
                "TargetServerPassword": "<<target-server-administrator-password>>"
            },
            "targetServerUserName": "<<target-server-administrator-login>>"
        },
        "DBsToMigrate": "<<comma-separated-list-of-databases-in-array-like-["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "OnPremises",
        "sslMode": "Prefer"
    }
}

Nota:

Al configurar las propiedades JSON para la migración al servidor flexible de Azure Database for PostgreSQL, si el entorno de origen es una máquina virtual de Azure, puede especificar el tipo de origen mediante la "sourceType":"AzureVM" propiedad . Esto ayuda al servicio de migración a comprender el entorno desde el que se migran los datos.

• Ejecute el comando siguiente para comprobar si hay migraciones en ejecución. El nombre de la migración es único en las migraciones en el destino de servidor flexible de Azure Database for PostgreSQL.

  az postgres flexible-server migration list --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --filter all
  

• En los pasos anteriores, no hay ninguna migración realizada, por lo que empezamos con la nueva migración ejecutando el comando siguiente.

  az postgres flexible-server migration create --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration> --migration-mode offline --migration-option ValidateAndMigrate --properties "c:/migration-cli/migration_body.json"
  

• Ejecute el siguiente comando para ver el estado de la migración iniciada en el paso anterior. Para comprobar el estado de la migración, proporcione el nombre de la migración.

  az postgres flexible-server migration show --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

• El progreso y el estado de la migración se muestran en la CLI de Azure.

• También puede ver el progreso y el estado en Azure Portal.

• Puede cancelar cualquier intento de migración en curso mediante el comando cancel. Este comando detiene el intento de migración concreto y revierte todos los cambios que podría haber realizado en el servidor de destino. A continuación se muestra el comando de la CLI para cancelar la migración que tiene un estado "En curso".

  az postgres flexible-server migration update cancel --subscription <subscription_id> --resource-group <resource_group> --name <target_server> --migration-name <migration>
  

Supervisión de la migración

Después de seleccionar el botón Iniciar validación y migración , aparece una notificación, en unos segundos, para decir que la validación o la creación de la migración se han realizado correctamente. Se le redirigirá automáticamente a la página Migración del servidor flexible. La entrada muestra Estado como En curso. El flujo de trabajo tarda entre 2 y 3 minutos en configurar la infraestructura de migración y comprobar las conexiones de red.

La cuadrícula que muestra las migraciones tiene las columnas siguientes: Nombre, Estado, Modo de migración, Tipo de migración, Servidor de origen, Tipo de servidor de origen, Bases de datos, Duración y Hora de inicio. Las entradas se muestran ordenadas por Hora de inicio en orden descendente, con la entrada más reciente en la parte superior. Puede usar el botón Actualizar de la barra de herramientas para actualizar el estado de la validación o ejecución de migración.

Detalles de la migración

Seleccione el nombre de la migración en la cuadrícula para ver los detalles asociados.

Recuerde que, en los pasos anteriores, al crear esta migración, configuró la opción de migración como Validar y migrar. En este escenario, las validaciones se realizan primero antes de que se inicie la migración. Una vez completado el subestado Realización de pasos previos, el flujo de trabajo pasa al subestado Validación en progreso.

• Si la validación tiene errores, la migración pasa a un estado Error.

• Si la validación se completa sin errores, se inicia la migración y el flujo de trabajo se mueve al subestado de Migración de datos.

Los detalles de validación están disponibles en el nivel de instancia y base de datos.

• Detalles de validación de la instancia
  • Contiene la validación relacionada con la comprobación de conectividad, la versión de origen, es decir, la versión >de PostgreSQL = 9.5 y la comprobación de parámetros de servidor, si las extensiones están habilitadas en los parámetros de servidor del servidor flexible de Azure Database for PostgreSQL.
• Detalles de validación y migración para bases de datos
  • Contiene la validación de las bases de datos individuales relacionadas con la compatibilidad de extensiones e intercalaciones en un servidor flexible de Azure Database for PostgreSQL.

Puede ver el estado de validación y el estado de migración en la página de detalles de la migración.

Algunos estados de migración posibles:

Estado de migración

Estado	Description
En curso	La infraestructura de migración se está configurando o la migración de datos en sí está en curso.
Cancelado	La migración está cancelada o eliminada.
Fallido	La migración ha fallado.
Error de validación	Se ha producido un error de validación.
Éxito	La migración se ha realizado correctamente y se ha completado.
Esperando la acción del usuario	Espera a que la acción del usuario realice la transición.

Detalles de la migración

Subestado	Description
Realizar pasos previos necesarios	La configuración de la infraestructura está en curso para la migración de datos.
Validación en curso	La validación está en curso.
Eliminación de la base de datos en el destino	Eliminar la base de datos ya existente en el servidor de destino.
Migración de datos	La migración de datos está en curso.
Finalización de la migración	La migración está en las últimas fases de finalización.
completado	La migración se ha completado.
Fallido	Se produjeron errores en la migración.

Subestados de validación

Subestado	Description
Fallido	Error de validación.
Éxito	La validación se ha realizado correctamente.
Advertencia	La validación está en advertencia.

Inicio de la transición

Puede iniciar la migración mediante Azure Portal o la CLI de Azure.

Portal

Para la opción Validar y migrar , la finalización de la migración en línea requiere que el usuario complete un paso adicional, que es desencadenar la acción de transición. Una vez completada la copia o clonación de los datos base, la migración se mueve al Waiting for user action estado y al Waiting for cutover trigger subestado. En este estado, el usuario puede desencadenar la transición desde el portal seleccionando la migración.

Antes de iniciar la transición, es importante comprobar lo siguiente:

• Las escrituras en el origen se detienen: el valor de latency es 0 o cerca de 0. La latency información se puede obtener de la pantalla de detalles de la migración, como se muestra a continuación:
• latency el valor disminuye a 0 o cerca de 0
• El valor latency indica cuándo el destino se sincronizó por última vez con el origen. La escritura en el origen se puede detener en este momento y se puede iniciar una transición. En caso de que haya tráfico pesado en el origen, se recomienda detener primero las escrituras para que latency pueda acercarse a 0 y, a continuación, se inicia una transición.

La operación de transición aplica todos los cambios pendientes del servidor de origen al servidor de destino y completa la migración. Si desencadena una transición, incluso con una latency distinta de cero, la replicación se detiene hasta ese momento dado. Todos los datos del origen hasta el punto de transición se aplican al destino. Si experimenta una latencia de 15 minutos en el punto de transición, todos los cambios realizados en los datos de los últimos 15 minutos se aplican al destino.

El tiempo está condicionado por la acumulación de cambios que se producen en los últimos 15 minutos. Por lo tanto, se recomienda que la latencia vaya a cero o cerca de cero antes de desencadenar la transición.

• La migración pasa al estado Succeeded cuando el subestado Migrating data o la transición (en la migración en línea) finaliza correctamente. Si hay un problema en el subestado Migrating data, la migración pasa a un estado Failed.

CLI

Para la opción Validar y migrar , la finalización de la migración en línea requiere que el usuario complete un paso adicional, que es desencadenar la acción de transición. Una vez completada la copia o clonación de los datos base, la migración se mueve al Waiting for user action estado y al Waiting for cutover trigger subestado. En este estado, el usuario puede desencadenar la transición a través de la CLI mediante el comando siguiente. También se puede desencadenar la transición desde el portal seleccionando el nombre de la migración en la cuadrícula de migración.

Antes de iniciar la transición, es importante comprobar lo siguiente:

• Las escrituras en el origen se detienen: el valor de latency es 0 o cerca de 0. La latency información se puede obtener de la pantalla de detalles de la migración, como se muestra a continuación:
• latency el valor disminuye a 0 o cerca de 0
• El valor latency indica cuándo el destino se sincronizó por última vez con el origen. La escritura en el origen se puede detener en este momento y se puede iniciar una transición. En caso de que haya tráfico pesado en el origen, se recomienda detener primero las escrituras para que latency pueda acercarse a 0 y, a continuación, se inicia una transición.

La operación de transición aplica todos los cambios pendientes del servidor de origen al servidor de destino y completa la migración. Si desencadena una transición, incluso con una latency distinta de cero, la replicación se detiene hasta ese momento dado. Todos los datos del origen hasta el punto de transición se aplican al destino. Si experimenta una latencia de 15 minutos en el punto de transición, todos los cambios realizados en los datos de los últimos 15 minutos se aplican al destino.

El tiempo está condicionado por la acumulación de cambios que se producen en los últimos 15 minutos. Por lo tanto, se recomienda que la latencia vaya a cero o cerca de cero antes de desencadenar la transición.

• La migración pasa al estado Succeeded cuando el subestado Migrating data o la transición (en la migración en línea) finaliza correctamente. Si hay un problema en el subestado Migrating data, la migración pasa a un estado Failed.

Para desencadenar la transición, use el siguiente comando:

az postgres flexible-server migration update --subscription <subscription_id> --resource-group <resource_group> --name <server> --migration-name <migration> --cutover

Comprobación de la migración cuando se complete

Después de completar las bases de datos, debe validar manualmente los datos entre el origen y el destino y comprobar que todos los objetos de la base de datos de destino se crean correctamente.

Después de la migración, puede realizar las siguientes tareas:

• Compruebe los datos en el servidor flexible y asegúrese de que es una copia exacta de la instancia de origen.

• Después de la comprobación, habilite la opción de alta disponibilidad en el servidor flexible según sea necesario.

• Cambie la SKU del servidor flexible para que coincida con las necesidades de la aplicación. Este cambio necesita un reinicio del servidor de bases de datos.

• Si modifica los parámetros del servidor desde sus valores predeterminados en la instancia de origen, copie esos valores de los parámetros del servidor en el servidor flexible.

• Copie otras opciones de configuración del servidor, como etiquetas, alertas y reglas de firewall (si procede), desde la instancia de origen al servidor flexible.

• Realice cambios en la aplicación para que las cadenas de conexión apunten a un servidor flexible.

• Supervise atentamente el rendimiento de la base de datos para ver si requiere el ajuste del rendimiento.

Contenido relacionado

• Servicio de migración
• procedimientos recomendados
• Problemas y limitaciones conocidos
• Configuración de red
• Validaciones previas a la migración