Mejorar la disponibilidad

Actualizado: 14 de abril de 2006

La réplica se puede utilizar para replicar datos en un servidor en espera, que proporciona mayor disponibilidad en caso de inactividad prevista o imprevista del sistema. La réplica debe utilizarse para proporcionar datos en espera semiactiva si los datos requeridos en el servidor en espera son un subconjunto de los datos necesarios en el servidor primario. Considere también los siguientes aspectos:

• Si la aplicación requiere datos en vatios sitios para aumentar la escalabilidad y disponibilidad, vea Mejorar la disponibilidad y la escalabilidad.
• Si la aplicación requiere que esté disponible una base de datos completa en un servidor en espera, utilice la creación de reflejo de la base de datos en vez de la réplica. La creación de reflejo de la base de datos es más eficaz si se necesita sincronizar toda la base de datos y no es necesario utilizar el servidor secundario para consultas. Para obtener más información, vea Creación de reflejo de la base de datos.

En el siguiente diagrama se muestra un servidor primario y un solo servidor en espera, con un subconjunto de los datos del servidor primario disponible en el servidor secundario.

[!NOTA] La réplica no proporciona un mecanismo para conmutar de un servidor a otro servidor en espera. Las aplicaciones que tienen acceso a un servidor determinado deben programarse para utilizar otro servidor si el primer servidor no está disponible.

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 varios servidores en todas sus fábricas que recopilan datos sobre defectos en las líneas de producción. Utilizan la réplica para proporcionar disponibilidad para estos servidores. Han escrito código para redirigir consultas a un servidor en espera semiactiva durante períodos de inactividad previstos y no previstos.

Requisitos comunes para este escenario

Las aplicaciones que utilizan la réplica para obtener disponibilidad normalmente tienen los siguientes requisitos que una solución de réplica adecuada debe resolver:

• 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.
• Los datos requeridos en un servidor secundario deben ser un subconjunto de los datos disponibles en el servidor primario (vea el primer diagrama anterior).

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 el diagrama anterior, el servidor primario es el publicador. Algunos o todos los datos del servidor primario 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). El servidor en espera es un suscriptor de la publicación 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, que se adapta perfectamente para controlar los requisitos indicados en la sección anterior. Para obtener más información sobre la réplica transaccional, vea Información general de la réplica transaccional y Cómo funciona la réplica transaccional.

Por diseño, la réplica transaccional satisface los requisitos principales de este escenario:

• Coherencia transaccional
• Latencia baja
• Rendimiento alto
• Sobrecarga mínima

La opción principal que hay que tener en cuenta en este escenario es el filtro. La réplica transaccional permite filtrar columnas y filas, por lo que las tablas en los suscriptores sólo contienen los datos requeridos por la aplicación. Para obtener más información, vea Filtrar datos publicados.

Pasos para implementar este escenario

Para implementar este escenario, primero debe crear una publicación y suscripciones y, a continuación, inicializar cada suscripción. Para obtener más información sobre cada paso, haga clic en los siguientes vínculos:

• Configurar la distribución
• Publicar datos y objetos de base de datos
• Suscribirse a publicaciones
• Inicializar una suscripción

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

• Supervisar la réplica
• Estrategias para hacer copias de seguridad y restaurar la réplica de instantáneas o transaccional
• Solucionar problemas de réplica
• Quitar la réplica

Vea también

Otros recursos

Replicar datos en un entorno de servidor a servidor

Ayuda e información

Obtener ayuda sobre SQL Server 2005

Historial de cambios