Patrón para actualizar bases de datos esclavas de SQL Server 2008 desde un maestro mientras se minimiza la interrupción

Question

Tenemos una aplicación web ASP.NET alojada por una granja de servidores web de muchas instancias que usa SQL Server 2008 en la que realizamos la agregación y el procesamiento previo de datos de múltiples fuentes en un formato optimizado para el rendimiento rápido de consultas del usuario final (produciendo 5 -10 millones de filas en algunas tablas). La agregación y la optimización se realizan mediante un servicio en un servidor back-end que luego queremos distribuir a múltiples copias front-end de solo lectura utilizadas por las instancias de la aplicación web para facilitar la máxima escalabilidad.

Mi pregunta es acerca de la mejor manera de obtener estos datos de una base de datos de back-end para las copias de front-end de solo lectura de tal manera que no elimine su rendimiento durante el proceso. Las instancias de la aplicación web front-end estarán bajo una carga alta constante y deben tener una buena capacidad de respuesta en todo momento.

La base de datos de back-end se actualiza constantemente, por lo que sospecho que la replicación transaccional no será el mejor enfoque, ya que el flujo constante de actualizaciones a las copias perjudicará su rendimiento.

La obsolescencia de los datos no es un gran problema, por lo que la replicación de instantáneas puede ser el camino a seguir, pero esto dará como resultado un bajo rendimiento durante los períodos de replicación.

Hacer una inserción de inserción y masiva dará como resultado períodos sin datos para las consultas de los usuarios.

Realmente no quiero escribir un enfoque complejo de clúster en el que dejamos caer copias del clúster durante la actualización: ¿hay algo en este sentido que podamos hacer sin demasiado esfuerzo, o hay una mejor alternativa?

Answer 1

En realidad, hay una tecnología integrada en SQL Server 2005 (y 2008) que está diseñada para abordar este tipo de problemas. Service Broker (me referiré más adelante como SSB). El problema es que tiene una curva de aprendizaje muy empinada.

Sé que MySpace hizo público cómo utiliza SSB para administrar su parque de servidores SQL: MySpace utiliza SQL Server Service Broker para proteger la integridad de 1 petabyte de datos . Sé de varios sitios (principales) más que usan patrones similares, pero desafortunadamente no se han hecho públicos, por lo que no puedo referir nombres. Participé personalmente en algunos proyectos en torno a esta tecnología (soy un ex miembro del equipo de SQL Server).

Ahora tenga en cuenta que SSB no es una tecnología dedicada de transferencia de datos como Replication. Como tal, no encontrará nada similar a los asistentes de publicación y las opciones de implementación simples de Replicación (verifique una tabla y se transfiere). SSB es una tecnología de mensajería confiable y, como tal, sus primitivas se detienen en el nivel de intercambio de mensajes, tendría que escribir el código que aprovecha el captura de cambio de datos , lo empaqueta como mensajes y también desempaqueta el mensaje en tablas relacionales en el destino.

¿Por qué algunas empresas prefieren SSB sobre la replicación en una tarea como la que usted describe? Porque SSB tiene una historia mucho mejor cuando se trata de confiabilidad y escalabilidad. Sé de proyectos que intercambian datos entre más de 1500 sitios, mucho más allá de las capacidades de replicación. SSB también se abstrae de la topología física: puede mover bases de datos, renombrar máquinas, reconstruir servidores, todo sin cambiar la aplicación. Debido a que el flujo de datos se produce en rutas lógicas la aplicación puede adaptarse sobre la marcha a nuevas topologías. SSB también es resistente a largos períodos de desconexión y tiempo de inactividad, siendo capaz de reanudar el flujo de datos después de horas, días e incluso meses de desconexión. El alto rendimiento alcanzado por la integración del motor (SSB es parte del motor SQL en sí mismo, no es una colección de aplicaciones y procesos satelitales como Replicación) significa que la acumulación de cambios puede ser procesos en tiempos razonables (sé de sitios que están pasando por la mitad a millones transacciones por minuto). Las aplicaciones SSB generalmente se basan en Activación interna para procesar los datos entrantes. SSB también tiene algunas características únicas como equilibrio de carga (a través de rutas) con semántica de sesión fija, soporte para procesamiento correlacionado específico de la aplicación gratuita de punto muerto , entrega de datos de prioridad , soporte específico para duplicación de bases de datos, autenticación basada en certificados para operaciones entre dominios, integrado temporizadores persistentes y muchos más.

Esta no es una respuesta específica 'cómo mover datos de la tabla T en el servidor A al servidor B'. Es más una tecnología genérica sobre cómo 'intercambiar datos entre el servidor A y el servidor B'.

Answer 2

Nunca he tenido que lidiar con este escenario antes, pero se me ocurrió una posible solución para esto. Básicamente, requeriría un cambio en la estructura de su base de datos principal. En lugar de almacenar los datos, debería mantener registros de las modificaciones de estos datos. Por lo tanto, si se agrega un registro, usted almacena " Tabla X, inserta un nuevo registro con estos valores: ... " Con modificaciones, simplemente almacene la tabla, el campo y el valor modificado. Con eliminaciones, solo almacene qué registro se elimina. Cada modificación se almacenará con una marca de tiempo.

Sus sistemas cliente mantendrían sus copias locales de la base de datos y solicitarán periódicamente todas las modificaciones de la base de datos después de una determinada fecha / hora. Luego ejecuta esas modificaciones en la base de datos local y estará actualizado nuevamente.

¿Y el back-end? Bueno, solo mantendría una lista de modificaciones y quizás una tabla con los datos base. Mantener solo las modificaciones también significa que está haciendo un seguimiento del historial, lo que le permite preguntarle al sistema cómo era hace un año.

Qué tan bien funcionaría esto depende del número de modificaciones en la base de datos de fondo. Pero si solicita los cambios cada 15 minutos, no debería haber tanta información cada vez.

Pero, de nuevo, nunca tuve la oportunidad de resolver esto en una aplicación real, por lo que sigue siendo un principio teórico para mí. Parece rápido, pero se requerirá mucho trabajo.

Answer 3

Opción 1 : escriba una aplicación para transferir los datos mediante transacciones a nivel de fila. Puede llevar más tiempo, pero no se interrumpirá el uso de los datos del sitio porque las filas están allí antes y después de que se produzca la lectura, solo con datos nuevos. Este procesamiento ocurriría en un servidor separado para minimizar la carga.

En el servidor sql 2008, puede configurar READ_COMMITTED_SNAPSHOT en ON para asegurarse de que la fila que se actualiza no esté causando el bloqueo.

Pero, básicamente, todo lo que hace esta aplicación es leer los nuevos datos, ya que están disponibles en una base de datos y en la otra.

Opción 2 : mueva los datos (tablas o toda la base de datos) del servidor de agregación al servidor front-end. Automatiza esto si es posible. Luego cambie su aplicación web para que apunte a la nueva base de datos o tablas para futuras solicitudes. Esto funciona pero requiere control sobre la aplicación web, que es posible que no tenga.

Opción 3 : si estaba hablando de una sola tabla (o esto podría funcionar con muchas), lo que puede hacer es cambiar la vista. Entonces escribe su código contra una vista sql que apunta a la tabla A. Trabaja en la Tabla B y cuando está listo, actualiza la vista para que apunte a la Tabla B. Incluso puede escribir una función que determine la tabla activa y automatice todo el intercambio.

Opción 4 : es posible que pueda usar algo como la replicación a nivel de bytes del servidor. Eso suena aterrador sin embargo. Que básicamente está copiando el servidor desde el punto A al punto B exactamente hasta los mismos bytes. Se usa principalmente en situaciones de recuperación de desastres, lo que parece que podría ser una situación de recuperación de DR, pero en realidad no.

Opción 5 : Renunciar y aprender a vender seguros. :)