Share via

Mejorar la disponibilidad y la escalabilidad

  • Artículo

En muchas aplicaciones, es fundamental proporcionar mayor disponibilidad y escalabilidad de lectura. La réplica 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 réplica. 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 réplica para aumentar la disponibilidad y la escalabilidad. En los dos casos, las tres bases de datos de los diagramas son pares entre sí: contienen datos y esquemas idénticos. La actividad de escritura para las bases de datos debe particionarse: si la base de datos contiene un catálogo de productos, por ejemplo, puede dirigir las actualizaciones a la primera base de datos para los nombres de productos que empiezan por la letra A hasta la I, la segunda base de datos para los que empiezan por la letra J hasta la R, y la tercera base de datos para los que empiezan por la letra S hasta la Z. Las actualizaciones se replican posteriormente en las otras 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 réplica 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.

Réplica de punto a punto 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 Ejemplos y bases de datos de ejemplo.

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 activo, los cambios recibidos mientras estaba cerrado se propagarán al servidor del Londres para actualizarlo.

Requisitos comunes para este escenario

Las aplicaciones que utilizan la réplica para obtener escalabilidad y disponibilidad normalmente tienen los siguientes requisitos que una solución de réplica 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 una latencia reducida: las actualizaciones en un servidor deben llegar a los demás servidores con rapidez.
  • El sistema debe tener un alto rendimiento: debe controlar la réplica de un gran número de transacciones.
  • El proceso de réplica debe producir una sobrecarga mínima.

Tipo de réplica que se debe utilizar en este escenario

Microsoft SQL Server utiliza una metáfora del sector editorial para describir los componentes del sistema de réplica. 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 réplica.

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

[!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 réplica de mezcla, que se adapta perfectamente para controlar conflictos. Para obtener más información sobre la réplica de mezcla, vea Información general sobre la réplica de mezcla.

Por diseño, la réplica 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 de punto a punto de la réplica transaccional permite a los servidores publicar y suscribirse a los mismos datos. Todos los nodos de una topología de punto a punto 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:

Vea también

Otros recursos

Replicar datos en un entorno de servidor a servidor

Ayuda e información

Obtener ayuda sobre SQL Server 2005