Dejando caer particiones históricas que ya no son necesarias en la replicación P2P

Question

La compañía en la que trabajo tiene un conjunto de bases de datos (más grande justo debajo de 1TB) en diferentes servidores - 2 en los EE. UU., 2 en Europa.

Ejecutamos la replicación completa de igual a igual por base de datos entre los 4 nodos, para que todos puedan tomar transacciones (insertar / actualizar / eliminar) y todos tienen los datos que los otros nodos se han recopilado (dentro de una latencia variable, lo peor La conexión es en promedio unos 30-40 segundos).

La base de datos más grande lleva datos desde principios de 2008 hasta hoy. Todos estos datos se replican aún más para informar los nodos que mantienen todos los datos.

Necesito eliminar los datos en los nodos transaccionales, hasta 2013, para eliminar el déficit de espacio de la unidad en los nodos transaccionales, y por lo tanto, los datos históricos solo estarán disponibles en los nodos de informes.

¿Cuál es la mejor manera de hacer esto? Los datos son relativamente manejables, ya que está bien particionado (mensualmente por partición, y luego anualmente en archivos separados / grupos de archivos). Sin embargo, existe el problema de no poder eliminar las particiones mientras están involucradas en la replicación y la lectura de la conmutación de partición, esto tampoco está permitido. ( Particiones de conmutación Prerrequisitos - Punto 18 )

Como entorno de producción completo, estoy tratando de evitar cualquier cosa que afectará la replicación, incluida la resincronización (lotes de datos a RESIVC, en grandes distancias).

¿Alguien tiene alguna buena sugerencia de cómo realizar esta tarea?

Answer 1

Entonces, no hay respuestas de aquí, pero después de una cierta cantidad de discusión y pensamiento, se me ocurrió un plan hace unos meses.

Haré esta respuesta concisa para este foro (¡es posible que no esté de acuerdo en que lo tengo!), Para tratar de ayudar a cualquier persona que necesita para realizar una tarea similar en el futuro, no dude en hacerle preguntas si extraño algo, aunque el método es directo.

Por lo tanto, la principal preocupación es eliminar los datos sin un impacto significativo en el tráfico de producción en los nodos con los que nos repliquemos a / desde. La forma más fácil de hacer esto es segregar un nodo en el que desea trabajar, eliminando los datos de ese nodo mientras que dejan a todos los demás no afectados (incluidos los nodos de informes).

La mejor manera de hacer esto (recuerde que no puede dejar caer particiones y cualquier otra operación se replica y, por lo tanto, crear una gran cantidad de tráfico y una gran cantidad de cambios de fila), es crear una nueva SP y configurar una publicación alrededor de este sp. Por lo tanto, debe estar disponible en todos los nodos. El bit importante es establecer la replicación para replicar la ejecución del SP, no el resultado (es decir, replicar la llamada EXEC SP_DELETE, no el delete donde ID= 1, elimine donde cambie el nivel ID= 2 - FILA). Esto se establece en el botón derecho en su nueva publicación (antes de configurar los otros nodos en la topología)> Propiedades> Artículos> Haga clic en el SP_Delete que tiene configuración> Botón de propiedades del artículo> Establecer propiedades del artículo de procedimiento almacenado resaltado> Replicación de la ejecución de la procedimiento almacenado. Completa tu topología P2P.

Pero MHSQLDBA, podría estar diciendo, eso solo va a eliminar por separado las filas en cada nodo a través de la SP. - Es por eso que establece el SP solo para hacer las eliminaciones:

if @@ servername= 'El servidor actual que desea afectar'

Síguelo con su procedimiento de eliminación.

Por lo tanto, cuando se recoge esta llamada EXEC en el (los) servidor (s) que no desea realizar las eliminaciones, se ignorará como @@ ServerName no será igual al servidor que ha seleccionado.

Puede pensar: ¿por qué no solo crear un SP en el servidor que le interesa y ejecute eso? - Esto se debe a que si lo hace, la replicación desalentará los cambios en la forma en que afectan las filas del artículo (tabla) y replicarán los cambios reales: debe replicar el SP para que pueda especificar que la ejecución de la SP se replique en lugar de los cambios resultantes.

Este es el orden sugerido de eventos en mi opinión / experiencia:

1. Cree SP con código de eliminación que especifica que solo ejecutará el código de eliminación @@@ servername= su servidor deseado
2. Configurar una nueva publicación que replica este 1 SP con la ejecución de la ejecución del procedimiento almacenado dentro de las propiedades del artículo
3. Ejecute el SP en su servidor deseado y sea feliz de que no haya derribado a toda la finca con miles de comandos de eliminación replicados

puntos de nota:

1. Esta sigue siendo una tarea laboriosa. Al utilizar este método, ha disminuido su efecto en todos los servidores, aparte de la que está trabajando. No ha disminuido la carga de trabajo para usted, de hecho, lo ha hecho peor: tendrá que ejecutar este mismo SP en cada nodo (con la línea de IF cambiada al servidor que está dirigido), aumentando efectivamente el trabajo que tiene Para hacer, por el número de servidores que tiene que afectar. Sin embargo, es masivamente más seguro, ya que tendrá un efecto mínimo en todos los otros nodos (supongo que ha fallado el tráfico del nodo al que está trabajando, por supuesto!)
2. Al utilizar este método, ha creado inconsistencia entre sus nodos: realmente necesita estar seguro de que los datos que está eliminando no va a cambiar antes de poder terminar de realizar la misma operación en todos los nodos que requieren trabajo. Si una fila, ha eliminado en 1 nodo, se cambia dentro del resto de la finca, terminará con errores de consistencia.
3. Es probable que usted pondrá detenidamente su replicación normal que está detenida por la cantidad de tiempo que se tarda en realizar las eliminaciones en el nodo en el que está trabajando (le recomiendo encarecidamente que lea la lectura de las eliminaciones), por lo tanto, necesita Para ser consciente de que una vez que se complete la operación, no tendrá el nodo nuevamente en acción hasta que la replicación normal haya retrocedido después de que se hayan liberado las cerraduras de su operación. Si se le replica sobre las altas líneas de latencia, le sugiero seriamente que se revise usando agentes de plomo en lugar de empujar, hace una diferencia de humonujos.

Probablemente haya una mejor manera de mover los datos de distancia en el SP que usar Eliminar, tal vez moverlo a otra tabla que no esté involucrado en la replicación y luego desplegar la tabla 'nueva', o la inversa, si los datos usted ¿Quieres mantenerse es menor que la cantidad de eliminar, mueva los datos que desea conservar en una nueva tabla, deje caer el antiguo, cambie el nombre de su nueva tabla: hay muchos consejos por ahí desde estas perspectivas, trabajo en un entorno donde Era más fácil luchar por la eliminación que promover un concepto de que

Algún personal no entenderá, por lo que estoy describiendo la forma dolorosa pero básica.

Descargo de responsabilidad: todo lo anterior es peligroso.Si se realiza apresuradamente sin previsión, puede arruinar seriamente una topología de replicación, los datos de su empresa y probablemente su empleo.Tome el método anterior y desarrolle su propio plan de batalla: cree un entorno de prueba para demostrar el concepto, la prueba de prueba y la reevaluación, no tome esta tarea a la ligera.Con suficiente consideración, logrará su tarea, pero no vale la pena hacer el viernes por la tarde después de un par de cervezas de la hora del almuerzo.Hágalo bien, hágalo una vez (para la prueba real tanto como pueda), hágalo correctamente.

Espero que esto ayude a otra persona.- Estoy agregando este bit, ya que es lo que habría buscado si quería esta respuesta:

Eliminar gran cantidad de datos de una topología de replicación de igual a igual