Entre iguales - replicación transaccional

Se aplica a:SQL Server

La replicación punto a punto proporciona una solución escalada y de alta disponibilidad manteniendo copias de datos en varias instancias de servidor, también denominadas nodos. Basada en la replicación transaccional, la replicación de igual a igual propaga cambios transaccionalmente coherentes casi en tiempo 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 punto a punto 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 punto a punto 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 punto a punto permite escalar las operaciones de lectura, el rendimiento de escritura de la topología es similar al de un único nodo. 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 producirse un conflicto o incluso la pérdida de 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 punto a punto incluye la opción de habilitar la detección de conflictos en una topología punto a punto. Esta opción ayuda a evitar problemas que se producen por conflictos no detectados, como comportamientos incoherentes de las aplicaciones y 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 más información, consulte Conflict Detection in Peer-to-Peer Replication.

Topologías punto a punto

En los siguientes escenarios se ilustran los usos típicos de la replicación punto a punto.

Topología en la que participan dos bases de datos

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 allí, las actualizaciones se replican en el nodo A. Si B está sin conexión (por ejemplo, para mantenimiento), el servidor de aplicaciones puede dirigir toda la actividad a A. Cuando B vuelve a estar en línea, las actualizaciones pueden fluir a ella y el servidor de aplicaciones puede volver a mover todas las actualizaciones a B o seguir dirigiéndolas a A.

La replicación punto a punto 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

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 solo 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.

  

  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 punto a punto

La configuración de una topología de replicación punto a punto es similar a la configuración de una serie de suscripciones y publicaciones transaccionales estándar. En los pasos descritos en los artículos 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 punto a punto.

Configuración del cifrado TLS 1.3

SQL Server 2025 (17.x) presenta compatibilidad con TDS 8.0 para la replicación punto a punto, que incluye:

• Configuración de agentes de replicación para usar el cifrado TLS 1.3 entre instancias de SQL Server 2025 (17.x) y también entre SQL Server 2025 (17.x) e Instancia administrada de Azure SQL.
• Cifrado predeterminado para la comunicación de servidores vinculados entre instancias de SQL Server 2025 (17.x) en una topología de replicación. Los servidores vinculados de SQL Server 2025 (17.x) usan el controlador OLE DB v19, que tiene Encrypt=Mandatory como valor predeterminado el cifrado.

Consideraciones para utilizar la replicación punto a punto

Esta sección proporciona información e instrucciones para tener en cuenta al usar la replicación punto a punto.

Consideraciones generales

• La replicación punto a punto solo está disponible en Enterprise Edition de SQL Server.

• Todas las bases de datos que participan en la replicación punto a punto 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. (Este es un valor de 1 para la propiedad publication replicate_ddl, que es la configuración predeterminada). Para obtener más información, vea Realizar cambios de esquema en bases de datos de publicación.

  • No se admite el filtrado de filas y columnas.

• Cada nodo debe usar 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 de igual a igual en una sola base de datos de publicación.

• Debe habilitarse una publicación para la replicación punto a punto antes de crear las suscripciones.

• Las suscripciones se deben inicializar con una copia de seguridad o con la opción replication support only. Para obtener más información, consulte Inicializar una suscripción transaccional sin una instantánea.

• No utilice columnas de identidad. Cuando se utilizan identidades, se deben administrar manualmente los intervalos asignados a las tablas en cada base de datos participante. Para más información, vea Asignar intervalos para la administración manual del intervalo de identidad.

Restricciones de características

La replicación punto a punto 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 fecha y hora.

• Publicadores y suscriptores distintos 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 estaban en desuso en SQL Server 2005 (9.x).)

• Agentes de distribución compartidos.

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

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

• La replicación transaccional punto a punto no admite la creación de una suscripción transaccional unidireccional para una publicación punto a punto

• La replicación transaccional punto a punto no admite la publicación de tablas con columnas calculadas como parte de su clave principal.

Las siguientes propiedades requieren consideraciones especiales:

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

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

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

• La propiedad de suscripción @sync_type requiere un valor de none o automatic.

• SQL Server 2019 (15.x) CU 13 introduce la propiedad de publicación, @p2p_confictdetection_policy. El valor del parámetro predeterminado es originatorid y resuelve el conflicto en función del identificador del originador. El valor del parámetro lastwriter resuelve el conflicto en función del último escritor.

Consideraciones de mantenimiento

Las acciones siguientes requieren que el sistema esté inactivo. 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.

Los cambios en el esquema de la topología (añadir o eliminar un elemento) requieren poner el sistema en estado quiescente. Para obtener más información, consulte Administrar una topología punto a punto (programación de la replicación con Transact-SQL).

Eliminar un nodo de la topología nunca requiere ponerlo en estado quiescente.

Cambiar las propiedades del artículo mediante sp_changearticle no requiere nunca ponerlo en estado de inactividad. Los cambios permitidos (para P2P) son las propiedades description, ins_cmd, upd_cmdy del_cmd .

Los cambios en el esquema del artículo (agregar o eliminar columnas) nunca requieren ponerlo en estado quiescente.

• Agregar artículo: para agregar un artículo a una configuración existente: necesitamos desactivar el sistema, ejecutar CREATE TABLE instrucción y cargar datos iniciales en cada nodo de la topología y agregar el nuevo artículo en cada nodo de la topología.

• Eliminar artículo: Si queremos un estado coherente en todos los nodos, necesitamos detener temporalmente la topología.

Para obtener más información, consulte Detener una topología de replicación (programación de la replicación con Transact-SQL) y Administrar una topología punto a punto (programación de la replicación con Transact-SQL).

• Si agrega un nuevo nodo a una topología punto a punto, solo debe restaurar a partir de las copias de seguridad que se crearon una vez agregado el nuevo nodo.

• No se pueden reinicializar las suscripciones en una topología punto a punto. Si tiene que asegurarse de que un nodo tiene una copia nueva de los datos, restaure una copia de seguridad en el nodo.

Contenido relacionado

• Administrar una topología punto a punto (programación de la replicación con Transact-SQL)
• Estrategias para realizar copias de seguridad y restaurar la replicación de instantáneas y la replicación transaccional
• Replicación transaccional