Compartir a través de


Mejorar la disponibilidad y la escalabilidad

En muchas aplicaciones, es fundamental proporcionar mayor disponibilidad y escalabilidad de lectura. La replicación se puede utilizar como una parte fundamental de una solución para proporcionar ambas. En algunas aplicaciones, el objetivo podría ser mejorar la disponibilidad o la escalabilidad mediante la replicación. Si sólo necesita cubrir una de estas áreas, considere uno de los siguientes escenarios:

En los siguientes diagramas se ilustran dos aplicaciones que aprovechan el uso de la replicación para aumentar la disponibilidad y la escalabilidad. En ambos casos, las tres bases de datos de los diagramas son pares entre sí: contienen esquema y datos idénticos. La actividad de escritura para estas bases de datos deben tener particiones: si la base de datos contenía un catálogo de productos, podría, por ejemplo, dirigir actualizaciones a la primera base de datos para los nombres de productos que comienzan por A-I, la segunda base de datos para J-R y la tercera, para S-Z. Las actualizaciones se replican, a continuación, a las demás bases de datos.

En el primer diagrama se ilustra una configuración donde cada servidor de aplicaciones y Web utiliza datos de un servidor de almacenamiento en caché determinado. Las lecturas y actualizaciones de un usuario determinado pasan a un servidor de aplicaciones específico y, a continuación, a un servidor de almacenamiento en caché específico. Puesto que el servidor de aplicaciones actualiza la caché directamente, no se necesita un servidor de origen central. Las actualizaciones en cada caché se propagan a las demás cachés.

Usar replicación para ajustar actividad de lectura

En el segundo diagrama se muestran tres servidores separados geográficamente con datos que se transfieren entre los tres, lo que permite que cada servidor admita solicitudes de lectura y mejore la disponibilidad.

Replicación del mismo nivel a ubicaciones dispersas

Ejemplo de Adventure Works Cycles

Adventure Works Cycles es una compañía ficticia que se utiliza para mostrar situaciones y conceptos de bases de datos. Para obtener más información, vea Bases de datos de ejemplo AdventureWorks.

Adventure Works Cycles tiene varias oficinas en todo el mundo, incluidas las ubicadas en Los Ángeles, Londres y Taipei. La información de pedidos de clientes se recopila en cada ubicación y, a continuación, se replica en las otras ubicaciones.

La información de pedidos puede leerse desde las otras ubicaciones; por tanto, si la oficina de Londres tiene una actividad de lectura grande, las aplicaciones internas pueden distribuir parte de esta actividad a las otras dos oficinas.

Por ejemplo, si el servidor de la oficina de Londres se cierra por mantenimiento, los pedidos pueden recuperarse en otra ubicación y el personal de la oficina de Londres puede seguir leyendo y escribiendo datos. Cuando el servidor de Londres vuelve a estar en línea, los cambios recibidos mientras estaba inactivo se propagarán al servidor del Londres para actualizarlo.

Requisitos comunes para este escenario

Las aplicaciones que utilizan la replicación para obtener escalabilidad y disponibilidad normalmente tienen los siguientes requisitos que una solución de replicación adecuada debe resolver:

  • El sistema debe permitir realizar cambios en cualquier servidor y hacer que los cambios se repliquen en los otros servidores.

  • El sistema debe mantener la coherencia transaccional.

  • El sistema debe tener latencia baja: las actualizaciones en un servidor deben llegar a los demás servidores rápidamente.

  • El sistema debe tener un rendimiento alto: debe controlar la replicación de un gran número de transacciones.

  • El proceso de replicación debe producir una sobrecarga mínima.

Tipo de replicación que se debe utilizar en este escenario

MicrosoftSQL Server utiliza una metáfora del sector editorial para describir los componentes del sistema de replicación. Los componentes incluyen el publicador, los suscriptores, las publicaciones y artículos, y las suscripciones.

En los diagramas anteriores, todos los servidores de almacenamiento en caché son publicadores y suscriptores. Todos los datos de la base de datos replicada en cada servidor se incluyen en la publicación, donde cada tabla de datos es un artículo (los artículos también pueden ser otros objetos de base de datos, por ejemplo procedimientos almacenados). Cada servidor se suscribe a publicaciones de otros servidores y recibe el esquema y los datos como una suscripción. Para obtener más información sobre los componentes del sistema, vea Información general del modelo de publicación de replicación.

SQL Server ofrece diferentes tipos de replicación para distintos requisitos de aplicación: replicación de instantáneas, replicación transaccional y replicación de mezcla. La mejor implementación para este escenario es la replicación transaccional del mismo nivel, que se adapta perfectamente para controlar los requisitos descritos en la sección anterior. Para obtener más información sobre la replicación transaccional del mismo nivel, vea Replicación transaccional del mismo nivel.

[!NOTA]

Si la aplicación requiere que se realicen modificaciones de una fila determinada en más de un nodo simultáneamente, pueden producirse conflictos de datos. En este caso, utilice la replicación de mezcla, que se adapta perfectamente para controlar conflictos. Para obtener más información sobre la replicación de mezcla, vea Información general sobre la replicación de mezcla.

Por diseño, la replicación transaccional satisface los requisitos principales de este escenario:

  • Los cambios se pueden realizar en cualquier servidor

  • Coherencia transaccional

  • Latencia baja

  • Rendimiento alto

  • Sobrecarga mínima

La opción del mismo nivel de la replicación transaccional permite a los servidores publicar y suscribirse a los mismos datos. Todos los nodos de una topología del mismo nivel son pares: cada nodo publica y suscribe al mismo esquema y los mismos datos. Los cambios (inserciones, actualizaciones y eliminaciones) pueden realizarse en todos los nodos y, a continuación, replicarse en el resto de los nodos.

Pasos para implementar este escenario

Para implementar este escenario, primero debe crear las publicaciones y las suscripciones e inicializar cada suscripción. Para obtener más información, vea:

Cuando la suscripción se haya inicializado y los datos fluyan entre los pares, es posible que necesite consultar los siguientes temas para obtener información sobre tareas habituales de administración y supervisión: