Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Esta sección contiene escenarios de replicación específicos de SQL Server. Para determinar qué cambios se van a replicar desde el servidor SQL, AWS DMS lee los registros de transacciones y realiza escaneos periódicos en la base de datos de origen. La latencia de replicación suele deberse a que SQL Server limita estos escaneos debido a las limitaciones de recursos. También puede deberse a un aumento significativo del número de eventos que se escriben en el registro de transacciones en poco tiempo.
Temas
Reconstrucciones de índices
Cuando SQL Server reconstruye un índice grande, utiliza una sola transacción. Esto genera muchos eventos y puede ocupar una gran cantidad de espacio de registro si SQL Server reconstruye varios índices a la vez. Cuando esto sucede, puede esperar picos de replicación breves. Si el origen de SQL Server tiene picos de registro sostenidos, compruebe lo siguiente:
En primer lugar, compruebe el período de tiempo de los picos de latencia mediante
CDCLatencySourceCloudWatch las métricasCDCLatencySourcey o consultando los mensajes de supervisión del rendimiento de los registros de tareas. Para obtener información sobre CloudWatch las métricas de AWS DMS, consulte. Métricas de tareas de replicaciónCompruebe si el tamaño de los registros de transacciones activos o de las copias de seguridad de los registros aumentó durante el pico de latencia. Compruebe también si se realizó un trabajo de mantenimiento o una reconstrucción durante ese tiempo. Para obtener información sobre cómo comprobar el tamaño del registro de transacciones, consulte Monitorear el uso del espacio de registro
en la documentación técnica de SQL Server . Compruebe que el plan de mantenimiento sigue las prácticas recomendadas de SQL Server. Para obtener información sobre las prácticas recomendadas de mantenimiento de SQL Server, consulte la estrategia de mantenimiento de índices
en la documentación técnica de SQL Server .
Para corregir problemas de latencia durante la reconstrucción de índices, pruebe lo siguiente:
Utilice el modelo de recuperación
BULK_LOGGEDpara las reconstrucciones sin conexión a fin de reducir los eventos que debe procesar una tarea.Si es posible, detenga la tarea durante la reconstrucción de índices. O bien, intente programar la reconstrucción de índices durante las horas de menor actividad para mitigar el impacto de un pico de latencia.
Intente identificar los cuellos de botella de los recursos que ralentizan las lecturas del DMS, como la latencia del disco o el rendimiento de E/S y solucione estos problemas.
Transacciones grandes
Las transacciones con muchos eventos o las transacciones de larga duración, hacen que el registro de transacciones aumente. Esto hace que las lecturas del DMS tarden más, lo que se traduce en latencia. Esto es similar al efecto que tiene la reconstrucción de índices en el rendimiento de la replicación.
Es posible que tenga dificultades para identificar este problema si no está familiarizado con la carga de trabajo típica de la base de datos de origen. Para solucionar este error, haga lo siguiente:
En primer lugar, identifique el momento en que la latencia alcanzó su punto máximo mediante
WriteThroughputCloudWatch las métricasReadThroughputy o consultando los mensajes de supervisión del rendimiento en los registros de tareas.Compruebe si hay consultas de larga duración en la base de datos de origen durante el pico de latencia. Para obtener información sobre las consultas de ejecución prolongada, consulte Solución de problemas de consultas de ejecución lenta en SQL Server
en la documentación técnica de SQL Server . Compruebe si el tamaño de los registros de transacciones activos o de las copias de seguridad de los registros ha aumentado. Para obtener información, consulte Monitorear el uso del espacio de registro
en la documentación técnica de SQL Server .
Para solucionar este problema, realice una de las siguientes opciones:
La mejor solución es reestructurar las transacciones desde el punto de vista de la aplicación para que se completen rápidamente.
Si no puede reestructurar las transacciones, una solución a corto plazo consiste en comprobar si hay cuellos de botella en los recursos, como las esperas en el disco o la contención de la CPU. Si encuentra cuellos de botella en la base de datos de origen, puede reducir la latencia aumentando los recursos de disco, CPU y memoria de la base de datos de origen. Esto reduce la contención de los recursos del sistema, lo que permite que las consultas del DMS se completen más rápido.
Intervalo de sondeo de MS-CDC mal configurado para Amazon RDS SQL Server
Un intervalo de sondeo mal configurado en las instancias de Amazon RDS puede provocar que el registro de transacciones aumente. Esto se debe a que la replicación evita el truncamiento de registros. Aunque las tareas que están en ejecución pueden seguir replicándose con una latencia mínima, detener y reanudar tareas o iniciar tareas exclusivas de CDC puede provocar errores en las tareas. Esto se debe a que se agota el tiempo de espera al escanear el gran registro de transacciones.
Para solucionar un problema de intervalo de sondeo mal configurado, haga lo siguiente:
Compruebe si el tamaño del registro de transacciones activo está aumentando y si el uso del registro se acerca al 100 por cien. Para obtener información, consulte Monitorear el uso del espacio de registro
en la documentación técnica de SQL Server . Compruebe si el truncamiento del registro se retrasa con un
log_reuse_wait_desc valuedeREPLICATION. Para obtener más información, consulte El registro de transacciones (SQL Server)en la documentación técnica de SQL Server .
Si encuentra problemas con alguno de los elementos de la lista anterior, ajuste el intervalo de sondeo de MS-CDC. Para obtener información sobre cómo ajustar el intervalo de sondeo, consulte Configuración recomendada cuando se utiliza RDS para SQL Server como fuente de AWS DMS.
Replicación de varias tareas de CDC desde la misma base de datos de origen
Durante la fase de carga completa, recomendamos dividir las tablas entre tareas para mejorar el rendimiento, separar las tablas dependientes de forma lógica y mitigar el impacto de un error de tarea. Sin embargo, durante la fase de CDC, recomendamos consolidar las tareas para minimizar los análisis de DMS. Durante la fase de CDC, cada tarea de DMS analiza los registros de transacciones en busca de nuevos eventos varias veces por minuto. Como cada tarea se ejecuta de forma independiente, cada tarea analiza cada registro de transacciones de forma individual. Esto aumenta el uso del disco y la CPU en la base de datos de origen de SQL Server. Como resultado, una gran cantidad de tareas que se ejecutan en paralelo pueden provocar que SQL Server limite las lecturas de DMS, lo que aumenta la latencia.
Es posible que tenga dificultades para identificar este problema si varias tareas se inician gradualmente. El síntoma más común de este problema es que la mayoría de los análisis de tareas comienzan a tardar más. Esto conduce a una mayor latencia para estos análisis. SQL Server prioriza algunos de los análisis de tareas, por lo que algunas de ellas muestran una latencia normal. Para solucionar este problema, compruebe la métrica CDCLatencySource de todas las tareas. Si algunas de las tareas tienen un CDCLatencySource aumentado, mientras que otras tienen un nivel CDCLatencySource bajo, es probable que SQL Server esté limitando las lecturas de DMS para algunas de las tareas.
Si SQL Server limita las lecturas de las tareas durante CDC, consolide las tareas para minimizar la cantidad de análisis de DMS. El número máximo de tareas que se pueden conectar a la base de datos de origen sin crear conflictos depende de factores como la capacidad de la base de datos de origen, la tasa de crecimiento del registro de transacciones o el número de tablas. Para determinar el número ideal de tareas para el escenario de replicación, pruebe la replicación en un entorno de prueba similar al entorno de producción.
Procesamiento de copias de seguridad del registro de transacciones en RDS para SQL Server
AWS DMS La versión 3.5.3 y las versiones posteriores admiten la replicación desde RDS para las copias de seguridad de registros de SQL Server. La replicación de eventos desde los registros de copia de seguridad en las instancias de RDS es más lenta que desde el registro de transacciones activo. Esto se debe a que DMS solicita acceso a las copias de seguridad en serie para asegurarse de mantener la secuencia de las transacciones y minimizar el riesgo de que se llene el almacenamiento de instancias de Amazon RDS. Además, en el lado de Amazon RDS, el tiempo necesario para que las copias de seguridad estén disponibles para DMS varía en función del tamaño de la copia de seguridad del registro y de la carga de la instancia de RDS para SQL Server.
Debido a estas restricciones, se recomienda establecer el atributo de conexión adicional ActivateSafeguard en true. Esto garantiza que no se haga una copia de seguridad de las transacciones mientras la tarea de DMS lee desde el registro de transacciones activo. Esta configuración también impide que Amazon RDS archive las transacciones en el registro activo cuando DMS lee las transacciones de la copia de seguridad, lo que elimina la posibilidad de que DMS no pueda ponerse al día con el registro activo. Tenga en cuenta que esto puede provocar que el tamaño del registro activo aumente mientras la tarea se actualiza. Asegúrese de que la instancia tenga suficiente espacio de almacenamiento para evitar que se quede sin espacio.
En el caso de una tarea exclusiva de CDC que se replique desde los orígenes de RDS para SQL Server, utilice la posición de inicio de CDC nativa en lugar de la hora de inicio de CDC nativa, si es posible. Esto se debe a que DMS se basa en las tablas del sistema para identificar el punto de partida de la posición de inicio nativa, en lugar de escanear copias de seguridad de registros individuales cuando se especifica una hora de inicio nativa.
