Secundarias activas: réplicas secundarias legibles (grupos de disponibilidad AlwaysOn)

Artículo
06/25/2013

Las funciones de compatibilidad secundaria activa de Grupos de disponibilidad AlwaysOn incluyen compatibilidad con el acceso de solo lectura a una o varias réplicas secundarias (réplicas secundarias legibles). Una réplica secundaria legible permite el acceso de solo lectura a todas las bases de datos secundarias. Sin embargo, las bases de datos secundarias legibles no se establecen como de solo lectura. Son dinámicas. Una base de datos secundaria dada cambia a medida que se aplican los cambios en la base de datos principal correspondiente. Para una réplica secundaria típica, los datos de las bases de datos secundarias están casi en tiempo real. Además, los índices de texto completo se sincronizan con las bases de datos secundarias. En muchas circunstancias, la tencia de datos entre una base de datos principal y la base de datos secundaria correspondiente suele ser de solo unos pocos segundos.

La configuración de seguridad de las bases de datos principales se mantiene en las secundarias. Esto incluye usuarios, roles de base de datos y roles de aplicación, junto con sus permisos correspondientes, y también incluye cifrado de datos transparentes (TDE) si está habilitado en la base de datos principal.

[!NOTA]

Aunque no puede escribir datos en las bases de datos secundarias, puede escribir en bases de datos de lectura y escritura de la instancia de servidor que hospeda la réplica secundaria, incluidas las bases de datos de usuario y las bases de datos del sistema, como tempdb.

Grupos de disponibilidad AlwaysOn también admite el reenrutamiento de las solicitudes de conexión de intento de lectura a una réplica secundaria legible (enrutamiento de solo lectura). Para obtener información sobre el enrutamiento de solo lectura, vea Usar un agente de escucha para conectar a una réplica secundaria de solo lectura (enrutamiento de solo lectura).

En este tema:

Ventajas
Requisitos previos del grupo de disponibilidad
Limitaciones y restricciones
Consideraciones de rendimiento
Consideraciones de planeamiento de capacidad
Tareas relacionadas
Contenido relacionado

Ventajas

La dirección de conexiones de solo lectura a las réplicas secundarias legibles proporciona las siguientes ventajas:

Alivia las cargas de trabajo de solo lectura secundarias de la réplica primaria, que conserva los recursos para las cargas de trabajo esenciales de la misión. Si tiene una carga de trabajo de lectura de gran importancia o si la carga de trabajo no puede tolerar la latencia, debe ejecutarla en el servidor principal.
Mejora la rentabilidad de la inversión para los sistemas que hospedan las réplicas secundarias legibles.

Además, las réplicas secundarias legibles proporcionan compatibilidad robusta con las operaciones de solo lectura, de la forma siguiente:

Las estadísticas de tiempo en la base de datos secundaria legible optimizan las consultas de solo lectura. Para obtener más información, vea Estadísticas de las bases de datos de acceso de solo lectura, más adelante en este tema.
Las cargas de trabajo de solo lectura usan las versiones de fila para quitar la contención de bloqueo en las bases de datos secundarias. Todas las consultas que se ejecutan en las bases de datos secundarias se asignan automáticamente al nivel de transacción de aislamiento de instantánea, incluso cuando se establecen otros niveles de aislamiento de transacción de forma explícita. Asimismo, se pasan por alto todas las sugerencias de bloqueo. Esto elimina el conflicto de lectura y escritura.

Icono de flecha usado con el vínculo Volver al principio [Arriba]

Requisitos previos del grupo de disponibilidad

Réplicas secundarias legibles (requeridas)

El administrador de la base de datos debe configurar una o varias réplicas de modo que, cuando se ejecutan en el rol secundario, permiten todas las conexiones (solo para el acceso de solo lectura) o solo conexiones de intento de lectura.

[!NOTA]

Opcionalmente, el administrador de bases de datos puede configurar cualquiera de las réplicas de disponibilidad para excluir las conexiones de solo lectura al ejecutarse en el rol principal.

Para obtener más información, vea Acerca del acceso de conexión de cliente a réplicas de disponibilidad (SQL Server).
Agente de escucha de grupo de disponibilidad

Para admitir el enrutamiento de solo lectura, un grupo de disponibilidad debe poseer un agente de escucha de grupo de disponibilidad. El cliente de solo lectura debe dirigir sus solicitudes de conexión a dicho agente y la cadena de conexión de cliente debe especificar el intento de aplicación como “de solo lectura”. Es decir, deben ser solicitudes de conexión de intento de lectura.
Enrutamiento de solo lectura

El enrutamiento de solo lectura hace referencia a la capacidad de SQL Server para enrutar las solicitudes de conexión de intento de lectura entrantes, que se dirigen a un agente de escucha de grupo de disponibilidad, a una réplica secundaria legible disponible. Los requisitos previos para el enrutamiento de solo lectura son los siguientes:
- Para admitir el enrutamiento de solo lectura, una réplica secundaria legible requiere una dirección URL de enrutamiento de solo lectura. Esta dirección URL tiene efecto cuando la réplica local se ejecuta en el rol secundario. La dirección URL de enrutamiento de solo lectura debe especificarse réplica a réplica, según sea necesario. Cada dirección URL de solo lectura se usa para enrutar las solicitudes de conexión de intento de lectura a una réplica secundaria legible específica. Normalmente, cada réplica secundaria legible se asigna a una dirección URL de enrutamiento de solo lectura.
- Cada réplica de disponibilidad que vaya a admitir el enrutamiento de solo lectura cuando la réplica principal requiera una lista de enrutamiento de solo lectura. Una lista de enrutamiento de solo lectura dada solo tiene efecto cuando la réplica local se ejecuta con el rol principal. Esta lista se debe especificar réplica a réplica, según sea necesario. Normalmente, cada lista de enrutamiento de solo lectura contendría cada dirección URL de enrutamiento de solo lectura con la dirección URL de la réplica local al final de la lista.
  
  [!NOTA]
  
  Las solicitudes de conexión de intento de lectura se enrutan al primer elemento secundario legible disponible en la lista de enrutamiento de solo lectura de la réplica principal actual. No hay equilibrio de carga.
Para obtener más información, vea Configurar el enrutamiento de solo lectura para un grupo de disponibilidad (SQL Server).

[!NOTA]

Para obtener información acerca de los agentes de escucha del grupo de disponibilidad y el enrutamiento de solo lectura, vea Agentes de escucha del grupo de disponibilidad, conectividad de cliente y conmutación por error de una aplicación (SQL Server).

Icono de flecha usado con el vínculo Volver al principio [Arriba]

Limitaciones y restricciones

Algunas operaciones no se admiten por completo, como se indica a continuación:

En cuanto una réplica secundaria legible se une al grupo de disponibilidad, la réplica secundaria puede empezar a aceptar conexiones a las bases de datos secundarias. Sin embargo, si hay transacciones activas en una base de datos principal, las versiones de fila no estarán del todo disponibles inmediatamente en la base de datos secundaria correspondiente. Las transacciones activas que existieran en la réplica principal cuando se configuró la réplica secundaria deben confirmarse o deshacerse. Hasta que el proceso finalice, la asignación del nivel de aislamiento de transacción en la base de datos secundaria estará incompleta y las consultas se bloquearán temporalmente.

[!NOTA]

La ejecución de transacciones largas afectará al número de filas de versiones que se mantienen.
El seguimiento de cambios y la captura de datos de cambios no se admiten en las bases de datos secundarias que pertenecen a una réplica secundaria legible:
- El seguimiento de cambios está deshabilitado de forma explícita en las bases de datos secundarias.
- La captura de datos de cambios se puede habilitar en una base de datos secundaria, pero no es compatible.
Dado que las operaciones de lectura se asignan al nivel de transacción de aislamiento de instantánea, la limpieza de registros fantasma en la réplica principal puede bloquearse por las transacciones en una o varias réplicas secundarias. La tarea de limpieza de registros fantasma limpiará automáticamente los registros fantasma en la réplica principal cuando las réplicas secundarias ya no los necesiten. Esto es similar a lo que se realiza cuando se ejecutan transacciones en la réplica principal. En el caso extremo de la base de datos secundaria, deberá eliminar una consulta de lectura de ejecución prolongada que esté bloqueando la limpieza de registros fantasma. Tenga en cuenta que la limpieza de registros fantasma se puede bloquear si la réplica secundaria se desconecta o cuando se suspende el movimiento de datos en la base de datos secundaria. Este estado también evita el truncamiento del registro, por lo que si el estado persiste, se recomienda quitar esta base de datos secundaria del grupo de disponibilidad.
Se puede producir un error en la operación DBCC SHRINKFILE en la réplica principal si el archivo contiene registros fantasma que siguen siendo necesarios en una réplica secundaria.

[!NOTA]

Si consulta la vista de administración dinámica sys.dm_db_index_physical_stats en una instancia de servidor que está hospedando una réplica secundaria legible, puede producirse un problema de bloqueo de REDO. Esto se debe a que esta vista de administración dinámica adquiere un bloqueo IS en la tabla de usuario o la vista especificada que puede bloquear las solicitudes con un subproceso REDO para un bloqueo X en esa tabla o vista de usuario.

Icono de flecha usado con el vínculo Volver al principio [Arriba]

Consideraciones de rendimiento

En esta sección se describen las consideraciones de rendimiento para las bases de datos secundarias legibles

En esta sección:

Latencia de datos
Repercusión de la carga de trabajo de solo lectura
Indización
Estadísticas de las bases de datos de acceso de solo lectura

Latencia de datos

La implementación del acceso de solo lectura en las réplicas secundarias resulta útil si las cargas de trabajo de solo lectura pueden tolerar cierta latencia de datos. En las situaciones en las que la latencia de datos no es aceptable, considere la posibilidad de ejecutar cargas de trabajo de solo lectura en la réplica principal.

La réplica principal envía las entradas de registro de los cambios en la base de datos principal a las réplicas secundarias. En cada base de datos secundaria, un subproceso de rehacer dedicado aplica las entradas de registro. En una base de datos secundaria de acceso de lectura, un cambio determinado de datos no aparece en los resultados de la consulta hasta que la entrada del registro que contiene el cambio se haya aplicado a la base de datos secundaria y la transacción se haya confirmado en la base de datos principal.

Esto significa que hay latencia, normalmente solo se trata de unos segundos, entre las réplicas principales y secundarias. No obstante, en casos excepcionales, por ejemplo, si los problemas de red reducen el rendimiento, la latencia puede ser importante. La latencia aumenta cuando se producen cuellos de botella de E/S y cuando se suspende el movimiento de los datos. Para supervisar el movimiento de datos suspendido, puede usar el panel de AlwaysOn o la vista de administración dinámica sys.dm_hadr_database_replica_states.

Repercusión de la carga de trabajo de solo lectura

Al configurar la replicación secundaria para el acceso de solo lectura, las cargas de trabajo de solo lectura en las bases de datos secundarias utilizan los recursos del sistema, como la CPU y la E/S de los subprocesos de rehacer, especialmente si las cargas de trabajo de solo lectura realizan un uso intensivo de E/S.

Además, las cargas de trabajo de solo lectura en las réplicas secundarias pueden bloquear los cambios de lenguaje de definición de datos (DDL) que se aplican a través de las entradas de registro. Aunque las operaciones de lectura no tienen bloqueos compartidos debido a las versiones de fila, estas operaciones tienen bloqueos de estabilidad de esquema (Sch-S), que pueden bloquear las operaciones de puesta al día que aplican cambios DDL.

Debe tener en cuenta los procedimientos recomendados acerca de la creación de consultas y aplíquelos en las bases de datos secundarias. Por ejemplo, programe las consultas de ejecución prolongada tales como agregaciones de datos durante las horas de menos actividad.

[!NOTA]

Si las consultas en la réplica secundaria bloquean un subproceso de rehacer, se genera el evento XEvent sqlserver.lock_redo_blocked.

Indización

Para optimizar las cargas de trabajo de solo lectura en réplicas secundarias legibles, tal vez desee crear índices en las tablas de las bases de datos secundarias. Debido a que no se pueden realizar cambios de esquema o de datos en las bases de datos secundarias, cree los índices en las bases de datos principales y permita que los cambios se transfieran a la base de datos secundaria mediante el proceso de puesta al día.

Para supervisar la actividad de uso de índices en una réplica secundaria, consulte las columnas user_seeks, user_scans y user_lookups de la vista de administración dinámica sys.dm_db_index_usage_stats.

Estadísticas de las bases de datos de acceso de solo lectura

Las estadísticas de las columnas de tablas y vistas indizadas se usan para optimizar los planes de consulta. Para los grupos de disponibilidad, las estadísticas que se crean y se mantienen en las bases de datos principales se conservan automáticamente en las bases de datos secundarias como parte de la aplicación de los registros de transacciones. No obstante, la carga de trabajo de solo lectura en las bases de datos secundarias puede necesitar estadísticas distintas de las que se crean en las bases de datos principales. Sin embargo, debido a que las bases de datos secundarias están restringidas al acceso de solo lectura, las estadísticas no se pueden crear en las bases de datos secundarias.

Para resolver este problema, la réplica secundaria crea y mantiene las estadísticas temporales para las bases de datos secundarias en tempdb. El sufijo _readonly_database_statistic se anexa al nombre de las estadísticas temporales para diferenciarlas de las estadísticas permanentes que se mantienen de la base de datos principal.

Solo SQL Server puede crear y actualizar las estadísticas temporales. No obstante, puede eliminar las estadísticas temporales y supervisar sus propiedades mediante las mismas herramientas que se usan para las estadísticas permanentes:

Elimine las estadísticas temporales mediante la instrucción Transact-SQL DROP STATISTICS.
Supervise las estadísticas con las vistas de catálogo sys.stats y sys.stats_columns. sys_stats incluye una columna, is_temporary, para indicar las estadísticas que son permanentes y las que son temporales.

Para obtener más información acerca de las estadísticas de SQL Server, vea Estadísticas.

En esta sección:

Estadísticas permanentes obsoletas en bases de datos secundarias
Limitaciones y restricciones

Estadísticas permanentes obsoletas en bases de datos secundarias

SQL Server detecta cuándo son obsoletas las estadísticas permanentes en una base de datos secundaria. Pero no se pueden realizar cambios en las estadísticas permanentes, excepto a través de los cambios en la base de datos principal. Para la optimización de consultas, SQL Server crea estadísticas temporales en la base de datos secundaria y usa estas estadísticas en lugar de las estadísticas obsoletas permanentes.

Cuando las estadísticas permanentes se actualizan en la base de datos principal, se guardan automáticamente en la base de datos secundaria. A continuación SQL Server usa las estadísticas actualizadas permanentes, más actuales que las estadísticas temporales.

Si el grupo de disponibilidad conmuta por error, las estadísticas temporales se eliminan en todas las réplicas secundarias.

Limitaciones y restricciones

Debido a que las estadísticas temporales se almacenan en tempdb, el reinicio del servicio SQL Server provoca que desaparezcan todas las estadísticas temporales.
El sufijo _readonly_database_statistic está reservado para las estadísticas que genera SQL Server. Este sufijo no se puede usar al crear estadísticas en una base de datos principal. Para obtener más información, vea Estadísticas.

Icono de flecha usado con el vínculo Volver al principio [Arriba]

Consideraciones de planeamiento de capacidad

Las réplicas secundarias legibles pueden necesitar espacio en tempdb por dos motivos:
- El nivel de aislamiento de instantánea copia las versiones de fila en tempdb.
- Se crean estadísticas temporales para las bases de datos secundarias y se mantienen en tempdb. Las estadísticas temporales pueden causar un ligero aumento del tamaño de tempdb. Para obtener más información, vea Estadísticas de las bases de datos de acceso de solo lectura, más adelante en esta sección.

Al configurar el acceso de lectura en una o varias réplicas secundarias, las bases de datos principales agregan 14 bytes de sobrecarga en las filas de datos eliminadas, modificadas o insertadas para almacenar punteros a las versiones de fila en las bases de datos secundarias. Esta sobrecarga de 14 bytes se aplica a las bases de datos secundarias. A medida que se agrega la sobrecarga de 14 bytes a las filas de datos, se pueden producir divisiones de página.

Las bases de datos principales no generan los datos de las versiones de fila. En su lugar, las bases de datos secundarias generan las versiones de fila. Sin embargo, las versiones de fila aumentan el almacenamiento de datos en las bases de datos principal y secundaria.

La adición de los datos de las versiones de fila depende del valor de nivel de aislamiento de instantánea o de aislamiento de instantánea de lectura confirmada (RCSI) en la base de datos principal. En la tabla siguiente se describe el comportamiento de las versiones en una base de datos secundaria legible en configuraciones diferentes.

¿Réplica secundaria legible?	¿Nivel de aislamiento de instantánea o de RCSI habilitado?	Base de datos principal	Base de datos secundaria
No	No	Sin versiones de fila ni sobrecarga de 14 bytes	Sin versiones de fila ni sobrecarga de 14 bytes
No	Sí	Con versiones de fila y sobrecarga de 14 bytes	Sin versiones de fila pero con sobrecarga de 14 bytes
Sí	No	Sin versiones de fila pero con sobrecarga de 14 bytes	Con versiones de fila y sobrecarga de 14 bytes
Sí	Sí	Con versiones de fila y sobrecarga de 14 bytes	Con versiones de fila y sobrecarga de 14 bytes