Compartir a través de

  • Artículo

Replicación transaccional del mismo nivel

La replicación del mismo nivel proporciona una solución escalada y de alta disponibilidad manteniendo copias de datos en varias instancias de servidor, también denominadas nodos. Generada en la base de replicación transaccional, la replicación del mismo nivel propaga transaccionalmente los cambios coherentes en tiempo casi real. Esto permite a las aplicaciones que requieran una escalada de las operaciones de lectura distribuir las lecturas de los clientes en varios nodos. Dado que los datos se mantienen en los nodos en tiempo casi real, la replicación del mismo nivel proporciona redundancia de datos, lo que aumenta la disponibilidad de los mismos.

Imagine una aplicación web. Ésta se puede beneficiar de la replicación del mismo nivel de las maneras siguientes:

  • Las consultas del catálogo y otras lecturas se expanden por varios nodos. Esto permite que el rendimiento permanezca coherente conforme aumentan las lecturas.

  • Si se produce un error en uno de los nodos del sistema, un nivel de aplicación puede redirigir las escrituras para dicho nodo a otro. Así se mantiene la disponibilidad.

  • Si un nodo requiere el mantenimiento o el sistema completo requiere una actualización, cada nodo se puede tomar sin conexión y agregar de nuevo al sistema sin que se vea afectada la disponibilidad de la aplicación.

Aunque la replicación del mismo nivel habilita la escalada de las operaciones de lectura, el rendimiento de escritura para la topología es similar para un nodo único. Esto se debe a que en última instancia todas las inserciones, actualizaciones y eliminaciones se propagan a todos los nodos. La replicación reconoce cuándo se ha aplicado un cambio a un nodo determinado y evita cambios cíclicos en los nodos más de una vez. Se recomienda encarecidamente que las operaciones de escritura para cada fila se realicen en un solo nodo, por las razones siguientes:

  • Si una fila se modifica en más de un nodo, puede producir un conflicto o incluso que se pierda una actualización cuando la fila se propaga a otros nodos.

  • Siempre hay alguna latencia implicada cuando se replican los cambios. Para las aplicaciones que requieren que se vea el cambio más reciente inmediatamente, el equilibrio de carga dinámico de la aplicación en varios nodos puede ser problemático.

La replicación del mismo nivel en SQL Server 2008 presenta la opción de habilitar la detección de conflictos en una topología del mismo nivel. Esta opción ayuda a evitar los problemas que se producen de los conflictos no detectados, incluyendo el comportamiento incoherente de las aplicaciones y las actualizaciones perdidas. Habilitando esta opción, de forma predeterminada, un cambio conflictivo se trata como un error crítico que produce el error del Agente de distribución. En caso de un conflicto, la topología permanece en un estado incoherente hasta que se resuelve el conflicto manualmente y los datos se hacen coherentes en toda la topología. Para obtener más información, vea Detección de conflictos en la replicación punto a punto.

[!NOTA]

Para evitar la posible incoherencia de datos, asegúrese de evitar los conflictos en una topología del mismo nivel, incluso con la detección de conflictos habilitada. Para asegurarse de que las operaciones de escritura para una fila determinada se realizan en un solo nodo, las aplicaciones que tienen acceso y cambian datos deben particionar las operaciones de inserción, actualización y eliminación. Este particionamiento asegura que las modificaciones a una fila determinada que se originan en un nodo están sincronizadas con todos los demás nodos en la topología antes de que se modifique la fila por un nodo diferente. Si una aplicación requiere funcionalidades de resolución y detección de conflictos sofisticadas, use la replicación de mezcla. Para obtener más información, vea Información general sobre la replicación de mezcla y Detectar y resolver conflictos de replicación de mezcla.

Topologías del mismo nivel

En los siguientes escenarios se ilustran los usos típicos de la replicación del mismo nivel.

Topología en la que participan dos bases de datos

Replicación del mismo nivel, dos nodos

En las ilustraciones anteriores se muestran dos bases de datos participantes, con tráfico de usuario dirigido a las bases de datos a través de un servidor de aplicaciones. Esta configuración se puede usar en varias aplicaciones, desde sitios web hasta aplicaciones de grupos de trabajo, y proporciona las siguientes ventajas:

  • Rendimiento de lectura mejorado, porque las lecturas se reparten en dos servidores.

  • Alta disponibilidad si se requiere mantenimiento o en caso de error en un nodo.

En ambas ilustraciones, la actividad de lectura tiene equilibrio de carga entre las bases de datos participantes, pero las actualizaciones se controlan de forma diferente:

  • En la izquierda, las actualizaciones se particionan entre los dos servidores. Si la base de datos contiene un catálogo de productos, podría, por ejemplo, hacer que una aplicación personalizada dirija las actualizaciones al nodo A para los nombres de productos que empiecen con la letra A hasta la M y que dirija las actualizaciones al nodo B para los nombres de productos que empiecen con la letra N hasta la Z. Más tarde, las actualizaciones se replican en el otro nodo.

  • A la derecha, todas las actualizaciones se dirigen al nodo B. Desde ahí, las actualizaciones se replican en el nodo A. Si B se encuentra en modo sin conexión (por ejemplo, por motivos de mantenimiento), el servidor de aplicaciones puede dirigir toda la actividad a A. Cuando B vuelve a estar en línea, las actualizaciones pueden pasar a él, y el servidor de aplicaciones puede mover todas las actualizaciones de vuelta al nodo B o seguir dirigiéndolas al nodo A.

La replicación del mismo nivel puede admitir este método, pero el ejemplo de actualización centralizada de la derecha también se utiliza frecuentemente con la replicación transaccional estándar.

Topología en la que participan tres o más bases de datos

Replicación del mismo nivel a ubicaciones dispersas

En la ilustración anterior se muestran tres bases de datos participantes que proporcionan datos para una organización de soporte de software internacional, con oficinas en Los Ángeles, Londres y Taipei. Los ingenieros de soporte de cada oficina reciben llamadas de clientes e incluyen y actualizan la información de las llamadas de los clientes. Las zonas horarias de las tres oficinas tienen una diferencia de ocho horas, por lo que no se superponen en la jornada laboral. Cuando la oficina de Taipei cierra, se abre la oficina de Londres. Si hay una llamada en curso cuando se cierra una oficina, la llamada se transfiere a un representante de la siguiente oficina abierta.

Cada ubicación tiene una base de datos y un servidor de aplicaciones, que los ingenieros de soporte utilizan para incluir y actualizar la información de las llamadas de los clientes. La topología se particiona por tiempo. Por consiguiente, las actualizaciones sólo se producen en el nodo que está abierto; a continuación, las actualizaciones pasan al resto de bases de datos participantes. Esta topología proporciona las siguientes ventajas:

  • Independencia sin aislamiento: cada oficina puede insertar, actualizar o eliminar datos de forma independiente, pero también puede compartir los datos porque se replican en el resto de bases de datos participantes.

  • Alta disponibilidad en caso de error o para permitir el mantenimiento en una o más de las bases de datos participantes.

    Replicación del mismo nivel, tres y cuatro nodos

La ilustración anterior muestra la adición de un nodo a la topología de tres nodos. Se podría agregar un nodo en este escenario por las razones siguientes:

  • Porque se abre otra oficina.

  • Para proporcionar mayor disponibilidad para admitir el mantenimiento o aumentar la tolerancia a errores si se produce un error de disco u otro error principal.

Observe que en ambas topologías de tres y cuatro nodos, todas las bases de datos publican y se suscriben a todas las demás bases de datos. Esto proporciona la máxima disponibilidad en caso de necesidades de mantenimiento o error de uno o más nodos. Al agregar nodos, se deben equilibrar las necesidades de disponibilidad y escalabilidad respecto al rendimiento y la complejidad de implementación y administración.

Configurar la replicación del mismo nivel

La configuración de una topología de replicación del mismo nivel es muy similar a la configuración de una serie de suscripciones y publicaciones transaccionales estándar. En los pasos descritos en los temas siguientes se muestra la configuración de un sistema de tres nodos, similar a la configuración mostrada a la izquierda en la ilustración anterior que muestra topología del mismo nivel.

Para configurar la replicación transaccional del mismo nivel

Consideraciones para utilizar la replicación del mismo nivel

Esta sección proporciona información e instrucciones para tener en cuenta al usar la replicación del mismo nivel.

Consideraciones generales

  • La replicación del mismo nivel sólo está disponible en SQL Server 2008 Enterprise.

  • Todas las bases de datos que participan en la replicación del mismo nivel deberían contener datos y esquema idénticos:

    • Los nombres de objeto, esquema de objeto y nombres de publicación deberían ser idénticos.

    • Las publicaciones deben permitir la replicación de los cambios de esquema. (Éste es un valor de 1 para la propiedad de publicación replicate_ddl, que es el valor predeterminado.) Para obtener más información, vea Realizar cambios de esquema en las bases de datos de publicación.

    • No se admite el filtrado de filas y columnas.

  • Se recomienda que cada nodo use su propia base de datos de distribución. Esto elimina la posibilidad de tener un punto de error único.

  • Las tablas y otros objetos no se pueden incluir en varias publicaciones del mismo nivel de una única base de datos de publicación.

  • Debe habilitarse una publicación para la replicación del mismo nivel antes de crear las suscripciones.

  • Las suscripciones se deben inicializar con una copia de seguridad o con la opción 'Sólo compatibilidad con replicación'. Para obtener más información, vea Inicializar una suscripción transaccional sin una instantánea.

  • No se recomienda el uso de columnas de identidad. Cuando se utilizan identidades, se deben administrar manualmente los intervalos asignados a las tablas en cada base de datos participante. Para obtener más información, vea la sección sobre cómo asignar intervalos para la administración manual de intervalos de identidad en Replicar columnas de identidad.

Restricciones de características

La replicación del mismo nivel admite las características principales de replicación transaccional pero no admite las opciones siguientes:

  • Inicialización y reinicialización con una instantánea.

  • Filtros de filas y columnas.

  • Columnas de marca de tiempo.

  • Suscriptores y publicadores que no son de SQL Server.

  • Suscripciones de actualización inmediata y de actualización en cola.

  • Suscripciones anónimas.

  • Suscripciones parciales.

  • Suscripciones adjuntables y suscripciones transformables (Ambas opciones han quedado obsoletas en SQL Server 2005).

  • Agentes de distribución compartidos.

  • El parámetro -SubscriptionStreams del Agente de distribución y el parámetro -MaxCmdsInTran del Agente de registro del LOG.

  • Las propiedades de artículo @destination_owner y @destination_table.

Las siguientes propiedades requieren consideraciones especiales:

  • La propiedad de publicación @allow_initialize_from_backup requiere el valor true.

  • La propiedad de artículo @replicate_ddl exige el valor true; @identityrangemanagementoption exige el valor manual; y @status exige que la opción 24 esté establecida.

  • El valor de las propiedades de artículo @ins_cmd, @del_cmd y @upd_cmd no puede establecerse en SQL.

  • La propiedad de suscripción @sync_type exige el valor none o automatic.

Consideraciones de mantenimiento

Las acciones siguientes exigen que se detenga el sistema. Esto significa que hay que detener la actividad de las tablas publicadas en todos los nodos y asegurarse de que cada nodo haya recibido todos los cambios de los demás nodos.

  • Agregar un nodo de SQL Server 2005 a una topología existente

  • Agregar un artículo a una publicación existente

  • Realizar cambios en el esquema

  • Restaurar un nodo desde una copia de seguridad