Compartir a través de

Actualización o revisión de bases de datos replicadas

  • Artículo

Se aplica a:SQL Server: solo Windows

SQL Server admite la actualización de bases de datos replicadas de versiones anteriores de SQL Server; no es necesario detener la actividad en otros nodos mientras se actualiza un nodo.

Requisitos previos

Asegúrese de cumplir las reglas relativas a la versión admitida en una topología:

  • Un distribuidor puede ser cualquier versión siempre que sea mayor o igual que la versión del publicador (en muchos casos, el distribuidor es la misma instancia que el publicador).

  • Un publicador puede ser de cualquier versión siempre que ésta sea menor o igual que la versión del distribuidor.

  • La versión del suscriptor depende del tipo de publicación:

    • Un suscriptor de una publicación transaccional puede ser de cualquiera de las dos versiones del publicador. Por ejemplo: un publicador de SQL Server 2012 (11.x) puede tener suscriptores de SQL Server 2014 (12.x) y SQL Server 2016 (13.x); y un publicador de SQL Server 2016 (13.x) puede tener suscriptores de SQL Server 2014 (12.x) y SQL Server 2012 (11.x).

    • En un suscriptor a una publicación de combinación todas las versiones pueden ser iguales o inferiores a la versión del publicador que se admite según el ciclo de soporte del ciclo de vida de las versiones.

Rutas de actualización

La ruta de actualización a SQL Server es diferente según el modelo de implementación. SQL Server ofrece dos rutas de actualización en general:

  • En paralelo: se implementa un entorno en paralelo y se mueven al entorno nuevo las bases de datos junto con los objetos de nivel de instancia asociados, como los inicios de sesión, los trabajos, etc.

  • Actualización local: se permite que los medios de instalación de SQL Server actualicen la instalación de SQL Server existente mediante el reemplazo de los bits de SQL Server y la actualización de los objetos de base de datos. Para los entornos que ejecutan grupos de disponibilidad (AG) o instancias de clúster de conmutación por error (FCI), una actualización local se combina con una actualización gradual para minimizar el tiempo de inactividad.

Un enfoque común para las actualizaciones en paralelo de las topologías de replicación es mover los pares de publicador y suscriptor por partes al nuevo entorno en paralelo, en lugar de mover toda la topología. Este enfoque por fases ayuda a controlar el tiempo de inactividad y minimiza el impacto en cierta medida para la empresa que depende de la replicación.

La mayoría de este artículo se limita a actualizar la versión de SQL Server. Sin embargo, el proceso de actualización en contexto también debe utilizarse al aplicar revisiones en SQL Server con un Service Pack o actualización acumulativa también.

Observaciones

La actualización de una topología de replicación es un proceso de varios pasos. Se recomienda intentar la actualización de una réplica de la topología de replicación en un entorno de prueba antes de ejecutar la actualización en el entorno de producción real. Esto ayuda a resolver cualquier documentación operativa necesaria para controlar la actualización sin problemas sin incurrir en tiempos de inactividad costosos y largos durante el proceso de actualización real. Puede reducir significativamente el tiempo de inactividad con el uso de grupos de disponibilidad (AG) y/o instancias de clúster de conmutación por error (FCI) para sus entornos de producción, mientras actualiza su topología de replicación. Además, se recomienda realizar copias de seguridad de todas las bases de datos, incluidas msdb, master, bases de datos de distribución y las bases de datos de usuario que participan en la replicación antes de intentar la actualización.

Cuando tenga una base de datos de distribución en una instancia de clúster de conmutación por error, asegúrese de que todos los nodos participantes usan la misma compilación. No se recomienda una instalación en la que un nodo sea una versión de SQL Server anterior a SQL Server 2016 (13.x) SP2-CU3 o SQL Server 2017 (14.x) CU6 y el otro nodo es una versión de SQL Server posterior a SQL Server 2016 (13.x) SP2-CU3 o SQL Server 2017 (14.x) CU6. A partir de SQL Server 2016 (13.x) SP2-CU3 y SQL Server 2017 (14.x) CU6, se agrega compatibilidad para usar una base de datos de distribución en un AG y para nuevos objetos (tablas y procedimientos almacenados) en bases de datos de distribución. Si la base de datos de distribución está en una instancia de clúster de conmutación por error y está realizando una migración por fases (y no puede actualizar todos los nodos a la misma versión de SQL Server), para el período de tiempo de migración reducido, se recomienda realizar tareas de cuenta como agregar un nuevo suscriptor, una suscripción, un publicador o una publicación en el nodo que tenga la versión posterior de SQL Server.

Matriz de replicación

Matriz de compatibilidad de replicación transaccional y de instantáneas

Publicador Distribuidor Suscriptor
Azure SQL Managed InstanceAUTD Azure SQL Managed InstanceAUTD Azure SQL Database
Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
Azure SQL Managed Instance2022 Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2022		 Azure SQL Database
Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2022 (16.x) SQL Server 2022 (16.x) Azure SQL Database
Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2019 (15.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)		 Azure SQL Database
Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2017 (14.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)		 Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2016 (13.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)		 SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2014 (12.x) Azure SQL Managed InstanceAUTD
Azure SQL Managed Instance2022
SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)		 SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2012 (11.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)		 SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)		 SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)		 SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)

2022 Se aplica a Azure SQL Managed Instance configurada con la directiva de actualización de SQL Server 2022. AUTD Se aplica a Azure SQL Managed Instance configurada con la directiva de actualización siempre actualizada.

Matriz de compatibilidad de replicación de mezcla

Publicador Distribuidor Suscriptor
SQL Server 2022 (16.x) SQL Server 2022 (16.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2019 (15.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)		 SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2017 (14.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)		 SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2016 (13.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)		 SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2014 (12.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)		 SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2012 (11.x) SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)		 SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)		 SQL Server 2022 (16.x)
SQL Server 2019 (15.x)
SQL Server 2017 (14.x)
SQL Server 2016 (13.x)
SQL Server 2014 (12.x)
SQL Server 2012 (11.x)
SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)		 SQL Server 2008 R2 (10.50.x)
SQL Server 2008 (10.0.x)

Consideraciones de actualización

Ejecutar el Agente Log Reader para replicación transaccional antes de la actualización

Antes de actualizar SQL Server, debe asegurarse de que el Agente de registro del Log Reader procesó todas las transacciones confirmadas de las tablas publicadas. Para asegurarse de que todas las transacciones se procesan, realice los pasos siguientes para cada base de datos que contenga publicaciones transaccionales:

  1. Asegurarse de que el Agente de registro del LOG se está ejecutando para la base de datos. De forma predeterminada, el agente se ejecuta sin interrupción.

  2. Detenga la actividad de usuario en las tablas publicadas.

  3. Deje tiempo para que el Agente de registro del LOG copie las transacciones en la base de datos de distribución y, a continuación, detenga el agente.

  4. Ejecute sp_replcmds para comprobar que todas las transacciones se procesan. El conjunto de resultados de este procedimiento debe estar vacío.

  5. Ejecute sp_replflush para cerrar la conexión desde sp_replcmds

  6. Actualice el servidor a la versión más reciente de SQL Server.

  7. Reinicie el Agente SQL Server y el Agente de lectura de registros si no se inician automáticamente después de la actualización.

Ejecutar agentes para la replicación de mezcla después de la actualización

Después de la actualización, ejecute el Agente de instantáneas de cada publicación de combinación y el Agente de mezcla de cada suscripción para actualizar los metadatos de la replicación. No es necesario aplicar la nueva instantánea, ya que no es necesario reinicializar las suscripciones. Los metadatos de suscripción se actualizan la primera vez que el Agente de mezcla se ejecuta tras la actualización. Esto significa que la base de datos de suscripciones puede permanecer en línea y activa durante la actualización del publicador.

La replicación de mezcla almacena metadatos de publicación y suscripción en un determinado número de tablas del sistema en las bases de datos de publicaciones y suscripciones. La ejecución del Agente de instantáneas actualiza los metadatos de publicación y la ejecución del Agente de mezcla actualiza los metadatos de suscripción. Solo es necesaria para generar una instantánea de publicación. Si una publicación de combinación utiliza filtros con parámetros, cada partición también tendrá una instantánea. No es necesario actualizar estas instantáneas particionadas.

Ejecute los agentes desde SQL Server Management Studio, el Monitor de replicación o la línea de comandos. Para más información sobre la ejecución del Agente de instantáneas, vea estos artículos:

Para más información sobre la ejecución del Agente de mezcla, vea estos artículos:

Después de actualizar SQL Server en una topología que utiliza la replicación de mezcla, cambie el nivel de compatibilidad de publicación de todas las publicaciones si desea utilizar nuevas características.

Actualización a las ediciones Standard, Workgroup o Express

Antes de actualizar de una edición de SQL Server a otra, compruebe que la funcionalidad que está usando actualmente es compatible con la edición a la que va a actualizar. Para más información, vea la sección sobre replicación de Ediciones y características admitidas de SQL Server 2022.

Pasos para actualizar una topología de replicación

En estos pasos se describe el orden en que se deben actualizar los servidores de una topología de replicación. Se aplican los mismos pasos con independencia de que se ejecute la replicación transaccional o de mezcla. Sin embargo, estos pasos no abarcan la replicación entre pares, las suscripciones de actualización en cola ni las suscripciones de actualización inmediata.

Actualización local

  1. Actualice el distribuidor.
  2. Actualice el publicador y el suscriptor. Se pueden actualizar en cualquier orden.

Nota

Para SQL Server 2008 (10.0.x) y SQL Server 2008 R2 (10.50.x), la actualización del publicador y el suscriptor deben realizarse al mismo tiempo para alinearse con la matriz de topología de replicación. SQL Server 2008 (10.0.x) y SQL Server 2008 R2 (10.50.x) no pueden tener como publicador ni como suscriptor a SQL Server 2016 (13.x) (o superior). Si no es posible actualizar al mismo tiempo, use una actualización intermedia para actualizar las instancias de SQL Server a SQL Server 2014 (12.x) y, a continuación, vuelva a actualizarlas a SQL Server 2016 (13.x) (o posterior).

Actualización en paralelo

  1. Actualice el distribuidor.
  2. Vuelva a configurar Configure Distribution en la nueva instancia de SQL Server.
  3. Actualice el publicador.
  4. Actualice el suscriptor.
  5. Vuelva a configurar todos los pares de publicador y suscriptor, incluyendo la reinicialización del suscriptor.

Pasos para la migración en paralelo del distribuidor a Windows Server

Una actualización en paralelo es la única ruta de actualización disponible para las instancias de SQL Server que participan en un clúster de conmutación por error. Los pasos siguientes se pueden realizar en una instancia de SQL Server independiente, o bien en una instancia de clúster de conmutación por error (FCI).

  1. Configure una instancia nueva de SQL Server (independiente o FCI), con la misma edición y versión que el distribuidor en Windows Server con otro clúster de Windows y el nombre FCI de SQL Server o el nombre de host independiente. Debe mantener la estructura de directorios igual que el distribuidor antiguo para asegurarse de que los archivos ejecutables de los agentes de replicación, las carpetas de replicación y las rutas de acceso del archivo de base de datos se encuentran en la misma ruta de acceso en el nuevo entorno. Esto reduce los pasos posteriores a la migración o actualización necesarios.

  2. Asegúrese de que la replicación está sincronizada y, después, cierre todos los agentes de replicación.

  3. Apague la instancia actual del distribuidor de SQL Server. Si se trata de una instancia independiente, apague el servidor. Si se trata de una FCI de SQL Server, desconecte todo el rol de SQL Server en el administrador de clústeres, incluido el nombre de red.

  4. Elimine las entradas del objeto de equipo DNS y Active Directory para el entorno antiguo (instancia actual del distribuidor).

  5. Cambie el nombre de host del servidor nuevo para que coincida con el del servidor antiguo.

    1. Si se trata de una FCI de SQL Server, cambie el nombre de la nueva FCI de SQL Server con el mismo nombre de servidor virtual que la instancia anterior.

  6. Copie los archivos de base de datos de la instancia anterior mediante la redirección de SAN, copia de almacenamiento o copia de archivos.

  7. Conecte la nueva instancia de SQL Server.

  8. Reinicie todos los agentes de replicación y compruebe si los agentes se ejecutan correctamente.

  9. Compruebe que la replicación funciona de la manera esperada.

  10. Use los medios de instalación de SQL Server para ejecutar una actualización local de la instancia de SQL Server a la versión nueva de SQL Server.

Nota

Para reducir el tiempo de inactividad, se recomienda realizar la migración en paralelo de del distribuidor como una actividad y la actualización local a SQL Server como otra actividad. Esto le permite adoptar un enfoque por fases, reducir el riesgo y minimizar el tiempo de inactividad.

Sincronización web para la replicación de mezcla

La opción de sincronización web para la replicación de mezcla requiere que copie el agente de escucha de replicación de SQL Server (replisapi.dll) en el directorio virtual del servidor de Internet Information Services (IIS) que se usa para la sincronización. Al configurar la sincronización web, el Asistente para configurar sincronización web copia el archivo en el directorio virtual. Si se actualizan los componentes de SQL Server instalados en el servidor IIS, debe copiarse manualmente el archivo replisapi.dll del directorio COM en el directorio virtual del servidor IIS. Para obtener más información sobre cómo configurar la sincronización web, vea Configurar la sincronización web.

Restauración de una base de datos replicada a partir de una versión anterior

Para asegurarse de que la configuración de replicación se conserva al restaurar una copia de seguridad de una base de datos replicada a partir de una versión anterior, restaure en un servidor y una base de datos con los mismos nombres que el servidor y la base de datos donde se realizó la copia de seguridad.

Contenido relacionado