Compartir a través de

La replicación de mezcla no admite topologías de suscriptor centralizadas

Este artículo le ayuda a solucionar el problema en el que la replicación de mezcla no admite topologías de suscriptor centralizadas.

Versión original del producto: SQL Server 2012, SQL Server 2008, SQL Server 2005
Número de KB original: 2750005

Resumen

La replicación de mezcla no admite topologías de suscriptor centralizadas. Una base de datos de suscriptor de mezcla única solo puede suscribirse a una sola publicación de mezcla. Por lo tanto, no se admite ningún tipo de topología de suscriptor centralizada en la replicación de mezcla.

Nota:

Esta limitación se aplica a todas las versiones admitidas actualmente de SQL Server, pero no se aplica a los suscriptores de Microsoft SQL Server Compact.

Solución

Para solucionar este problema, tenga en cuenta las siguientes alternativas al uso de una topología de suscriptor central y replicación de mezcla:

  • Implemente una sola publicación de combinación central que tenga filtros de fila parametrizados en los que las particiones de datos proporcionan los datos para las bases de datos de suscriptor individuales.
  • Uso de la replicación transaccional en lugar de la replicación de mezcla para implementar la topología del suscriptor central

Nota:

Para obtener más información sobre cómo implementar topologías de suscriptor central e integrar datos de varios sitios, consulte la sección Referencias .

Información adicional

En un modelo de suscriptor central, la base de datos del suscriptor se sincroniza con dos o más orígenes de publicación. En este escenario, los orígenes de publicación constan de una de las siguientes combinaciones:

  • Dos o más publicaciones dentro de la misma base de datos del publicador en la misma instancia del servidor de publicación.
  • Dos o más publicaciones en dos o más bases de datos de publicador en la misma instancia del servidor de publicación.
  • Dos o más publicaciones en dos o más bases de datos de publicador en distintas instancias del servidor de publicación.

La replicación de mezcla no admite el modelo de suscriptor central. Los agentes de combinación no se diseñaron ni probaron para funcionar en este escenario. La única topología admitida es la topología en la que cada base de datos de suscriptor se sincroniza con una sola publicación de combinación. Tenga en cuenta lo siguiente.

Nota:

Esto se aplica a todas las versiones de Microsoft SQL Server.

  • Los metadatos de replicación de mezcla de una base de datos de suscriptor se almacenan en un único conjunto de tablas de metadatos. Si se crean varias suscripciones en la misma base de datos, los metadatos de todas las suscripciones se almacenarán en el mismo conjunto de tablas del sistema.
  • Los metadatos de replicación son compartidos por varios agentes de mezcla.
  • Los agentes de mezcla sincronizan la información de publicación y suscripción entre sus asociados de sincronización configurados. Por lo tanto, cada sincronización también carga metadatos no relacionados desde la base de datos de suscriptor a la base de datos del publicador. Después, las sincronizaciones adicionales distribuyen estos metadatos a otros nodos no relacionados de la topología.
  • Cuando los agentes de mezcla sincronizan sus suscripciones al mismo tiempo en paralelo. La interacción entre los agentes de mezcla puede afectar a cómo se controlan los cambios. Por ejemplo, la agrupación de generaciones en lotes durante la fase de carga individual de cada sincronización puede verse afectada.

Es posible que tenga problemas si implementa un modelo de suscriptor de mezcla central. Entre los ejemplos de problemas que puede experimentar al implementar un modelo de suscriptor de mezcla central se incluyen los siguientes:

  • La coherencia de los metadatos de replicación de mezcla se pone en peligro después de quitar una publicación y, a continuación, se vuelve a crear en el mismo servidor de publicador y la misma base de datos que tiene el mismo nombre. En este escenario, es posible que los agentes de mezcla no se sincronicen más adelante. Por ejemplo, puede recibir uno o varios de los siguientes mensajes de error:

    • No se puede insertar una fila de clave duplicada en el objeto dbo.sysmergepartitioninfo con un índice uc1sysmergepartitioninfoúnico.

    • La publicación difiere de la publicación en la que se creó inicialmente la suscripción. Puede que la publicación original se haya eliminado y reemplazado por una nueva publicación con el mismo nombre. En el suscriptor, elimine la suscripción y vuelva a crearla para la nueva publicación.

    • El proceso de mezcla ha detectado una incoherencia mientras evaluaba la expresión de validación de partición del suscriptor. El problema puede resolverse reinicializando la suscripción.

    • No se puede recuperar la información de suscripción del "Suscriptor" del "Publicador". La suscripción a la publicación "publication" no es válida o no se ha configurado correctamente.

  • La coherencia de los metadatos de replicación de mezcla puede estar en peligro después de quitar una suscripción y, a continuación, volver a crearse en la base de datos del suscriptor central.

  • La coherencia de los metadatos de replicación de mezcla puede verse comprometida si las suscripciones a la base de datos del suscriptor central están configuradas para usar valores diferentes para sus filtros de fila con parámetros. Esto incluye el uso de valores diferentes para el parámetro host_name en distintas suscripciones. Además, sospechamos que mezclar filtros basados en host_name y suser_sname contribuye a este problema.

  • Los conflictos inesperados durante la resolución de conflictos pueden dar lugar a una posible pérdida de datos. Este problema puede producirse cuando los agentes de mezcla se ejecutan en paralelo en el suscriptor central.

  • Se produce un bloqueo extenso si los agentes de mezcla se ejecutan en paralelo. Este problema puede producirse durante el inicio de la carga o la fase de descarga de la sincronización. Este problema también puede producirse cuando se leen o escriben datos modificados. Este problema de rendimiento puede entrar en cascada en la topología, en función de los objetos implicados en el bloqueo.

Nota:

Es posible que estos problemas no se produzcan inmediatamente después de configurar o cambiar la topología. Estos problemas pueden producirse de forma inesperada e intermitente más adelante. La extensión de los problemas puede depender del tiempo de los eventos. Por ejemplo, cuando los agentes de combinación individuales se sincronizan entre sí, la gravedad del problema puede verse afectada por el evento que causa el problema y por la cantidad de datos que se cargan o descargan.

Referencias