Prácticas recomendadas para el enlace de Instancia administrada: Azure SQL Managed Instance

Applies to:Azure SQL Managed Instance

En este artículo se describen los procedimientos recomendados para usar el vínculo Instancia administrada para replicar datos entre Azure SQL Managed Instance y las instancias de SQL Server hospedadas en cualquier lugar. El vínculo proporciona replicación de datos casi en tiempo real entre las réplicas vinculadas.

Realizar copias de seguridad de registros con regularidad

Si SQL Server es su principal inicial, realice la primera copia de seguridad del registro en SQL Server después de que termine la propagación inicial, cuando la base de datos ya no esté en el estado de Restaurando... en Azure SQL Managed Instance. A continuación, realice copias de seguridad del registro de transacciones de SQL Server de forma periódica para mantener el tamaño del archivo del registro de transacciones en buen estado mientras SQL Server se encuentra en el rol principal.

La característica de vínculo replica los datos mediante la tecnología de grupos de disponibilidad distribuidos basada en grupos de disponibilidad AlwaysOn. La replicación de datos del grupo de disponibilidad distribuido se basa en la replicación de registros de transacciones. La instancia principal de SQL Server no puede truncar ningún registro del log de transacciones de la base de datos hasta que estos se repliquen en la base de datos en la réplica secundaria. Si los problemas de conexión de red hacen que la replicación de registros de transacciones sea lenta o bloqueada, el archivo de registro sigue creciendo en la instancia principal. La intensidad de la carga de trabajo y la velocidad de red determinan la velocidad de crecimiento. Si se prolonga una interrupción de la conexión de red y la carga de trabajo en la instancia principal es pesada, el archivo de registro puede ocupar todo el espacio de almacenamiento disponible.

La realización de copias de seguridad normales del registro de transacciones trunca el registro de transacciones y minimiza el riesgo de quedarse sin espacio en la instancia de SQL Server principal debido al crecimiento del archivo de registro. No es necesario realizar ninguna acción adicional cuando SQL Managed Instance es la principal, ya que las copias de seguridad de log ya se realizan automáticamente. Al realizar copias de seguridad de registros periódicamente en la SQL Server principal, la base de datos es más resistente a los eventos de crecimiento de registros no planeados. Considere la posibilidad de programar tareas de copia de seguridad diarias de registros mediante un trabajo de Agente SQL Server.

Puede usar un script de Transact-SQL (T-SQL) para realizar una copia de seguridad del archivo de registro, como el ejemplo proporcionado en esta sección. Reemplace los marcadores de posición del script de muestra por el nombre de la base de datos, el nombre y la ruta de acceso del archivo de copia de seguridad y la descripción.

Para realizar una copia de seguridad del registro de transacciones, use el siguiente script de ejemplo Transact-SQL (T-SQL) en SQL Server:

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

Use el siguiente comando Transact-SQL (T-SQL) para comprobar el registro espaciado usado por la base de datos en SQL Server:

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE); 

La salida de la consulta es similar a la del ejemplo siguiente para la base de datos de muestra tpcc:

En este ejemplo, la base de datos ha usado el 76 % del registro disponible, con un tamaño absoluto de archivo de registro de aproximadamente 27 GB (27 971 MB). Los umbrales de acción pueden variar en función de la carga de trabajo. En el ejemplo anterior, el tamaño del registro de transacciones y el porcentaje de uso del registro normalmente indican que debe realizar una copia de seguridad del registro de transacciones para truncar el archivo de registro y liberar espacio, o bien, debe realizar copias de seguridad de registros más frecuentes. También podría ser una indicación de que el truncamiento del log de transacciones esté siendo bloqueado por transacciones abiertas. Para obtener más información sobre cómo solucionar problemas de un registro de transacciones en SQL Server, consulte Troubleshoot a Full Transaction Log (SQL Server Error 9002). Para obtener más información sobre cómo solucionar problemas de un registro de transacciones en Azure SQL Managed Instance, consulte Solucionar errores del registro de transacciones con Azure SQL Managed Instance.

Adecuar la capacidad de rendimiento entre réplicas

Al utilizar la función de enlace, iguale la capacidad de rendimiento entre SQL Server y SQL Managed Instance. Esta coincidencia le ayuda a evitar problemas de rendimiento si la réplica secundaria no puede mantenerse al día con la replicación desde la réplica principal o después de la conmutación por error. La capacidad de rendimiento incluye núcleos de CPU (o núcleos virtuales en Azure), memoria y rendimiento de E/S.

Puede supervisar el rendimiento de la replicación verificando el tamaño de la cola de reproducción en la réplica secundaria. El tamaño de la cola de rehacer muestra el número de registros que están esperando a ser rehechos en la réplica secundaria. Un tamaño de cola de rehacer constantemente alto muestra que la réplica secundaria no puede mantenerse al día con la réplica principal. Puede comprobar el tamaño de la cola de puesta al día de las maneras siguientes:

• El valor redo_queue_size en la vista de administración dinámica sys.dm_hadr_database_replica_states en la réplica principal.
• Valor InstanceRedoLagReplicationSeconds de Get-AzSqlInstanceLink en la réplica principal.

Si el tamaño de la cola de rehacer es constantemente alto, considere aumentar los recursos en la réplica secundaria.

Supervisión del retraso de replicación

La supervisión del retraso de replicación le ayuda a determinar la velocidad de la que la réplica secundaria se sincroniza con la réplica principal. Una discrepancia grande indica que la réplica secundaria tiene problemas para mantenerse al día con la réplica principal, lo que suele deberse a un rendimiento de red lento en el vínculo entre las dos instancias, la asignación de recursos no coincidentes entre las dos réplicas o por una carga de trabajo excesivamente alta en la réplica principal.

La supervisión del retraso de replicación es especialmente importante al realizar una conmutación por error planeada, lo que requiere que la réplica secundaria se sincronice completamente con la réplica principal antes de que se pueda ejecutar la conmutación por error. Si el retraso de replicación es alto, la conmutación por error puede tardar más tiempo en completarse y, en algunos casos, incluso podría fallar.

Use la siguiente consulta de T-SQL en SQL Server y SQL Managed Instance para supervisar el retraso de replicación entre las réplicas:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

Rotar certificado

Es posible que tenga que rotar manualmente el certificado usado para proteger el extremo de reflejo de base de datos en SQL Server. Dado que el servicio administra y rota automáticamente el certificado usado para asegurar el punto de conexión de espejo de la base de datos en SQL Managed Instance, no es necesario rotarlo manualmente.

SQL Server

El certificado que se usa para proteger el punto de conexión de espejado de bases de datos en SQL Server puede expirar. Si el certificado expira, puede provocar una degradación del vínculo. Para evitar este problema, gire el certificado antes de que expire.

Use el siguiente comando Transact-SQL (T-SQL) para comprobar la fecha de expiración del certificado actual:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK' 

Si el certificado está a punto de expirar o ya ha expirado, cree un nuevo certificado y, a continuación, modifique el punto de conexión existente para reemplazar el certificado actual.

Después de configurar el punto de conexión para usar el nuevo certificado, puede quitar el certificado expirado.

Instancia Administrada de SQL

El certificado de punto de conexión para reflejo de la base de datos en SQL Managed Instance se rota automáticamente de manera periódica. No es necesario supervisar la fecha de expiración del certificado de punto de conexión de creación de reflejo de la base de datos en SQL Managed Instance, siempre que pueda validar la cadena de certificados en SQL Server correctamente.

Validación de la cadena de certificados en SQL Server

Los problemas con la cadena de certificados pueden degradar el vínculo. Para evitar este problema, valide periódicamente la cadena de certificados en SQL Server.

Los escenarios siguientes pueden causar problemas con la cadena de certificados en SQL Server:

• Rotación de certificados programada en SQL Managed Instance.
• Cambios involuntarios o accidentales en los certificados de SQL Server, como quitar o modificar el certificado usado para proteger el extremo de reflejo de la base de datos.

En primer lugar, determine el certificate_id del certificado de punto de conexión mi importado reemplazando el valor de <ManagedInstanceFQDN> y, a continuación, ejecute la siguiente consulta en SQL Server:

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO 

A continuación, valide el certificado reemplazando el valor de <certificate_id> del resultado de la consulta anterior y, a continuación, ejecute la siguiente consulta en SQL Server:

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO 

Una respuesta de Commands completed successfully. Completion time: ... indica que el certificado del punto final MI se valida correctamente.

Si se produce un error, la mitigación más confiable consiste en restaurar la cadena de certificados eliminando primero todos los certificados creados en las secciones Obtener la clave pública del certificado de SQL Managed Instance e importarla a SQL Server y Importar las claves de la autoridad de certificación raíz de confianza de Azure a SQL Server, y luego volver a importarlos.

Adición de marcas de seguimiento de inicio

En SQL Server, hay dos marcas de seguimiento (-T1800 y -T9567) que, cuando se agregan como parámetros de inicio, pueden optimizar el rendimiento de la replicación de datos a través del vínculo. Consulte Habilitar las banderas de seguimiento de inicio para obtener más información.

Use la confirmación sincrónica con precaución

El modo de confirmación predeterminado para el vínculo es asincrónico. Aunque es posible cambiar el modo de confirmación a sincrónico, no se recomienda y no es necesario proteger contra la posible pérdida de datos.

Durante un failover vinculado planificado, la replicación cambia temporalmente al modo de confirmación sincrónica hasta que se completa el failover. Después de la conmutación por error, el modo de confirmación vuelve a ser asincrónico, incluso si se establece explícitamente en modo de confirmación sincrónica antes de la conmutación por error.

El uso del modo de confirmación sincrónica para el vínculo puede afectar al rendimiento de la réplica principal, especialmente si hay una latencia de red elevada entre las réplicas. En el modo de confirmación sincrónica, las transacciones de la réplica principal deben esperar a la confirmación de que los registros de registro de transacciones se protegen en la réplica secundaria antes de que la transacción se pueda confirmar en la principal. Este tiempo de espera aumenta con una mayor latencia de red, lo que puede provocar un aumento de los tiempos de respuesta de la transacción y un rendimiento reducido en la réplica principal.

Contenido relacionado

Para usar el vínculo:

• Preparar el entorno para el vínculo de Instancia administrada
• Configurar vínculo entre SQL Server e Instancia Administrada de SQL con SSMS
• Configurar el vínculo entre SQL Server e Instancia Administrada de SQL con scripts
• Conmutación por error de un vínculo
• Migración con el vínculo
• Solución de problemas con el vínculo

Para más información sobre el vínculo:

• Información general del vínculo Instancia administrada
• Recuperación ante desastres con vínculo de Instancia administrada
• Procedimientos recomendados para mantener el vínculo

Para otros escenarios de replicación y migración, considere lo siguiente:

• Replicación transaccional con SQL Managed Instance
• Servicio de reproducción de registros (LRS)