Descartando partições históricas que não são mais necessárias durante a replicação P2P

Portanto, não há respostas daqui, mas depois de uma certa discussão e reflexão, elaborei um plano alguns meses atrás.

Vou tornar esta resposta concisa para este fórum (você pode não concordar que eu tenha!), Para tentar ajudar alguém que precise realizar uma tarefa semelhante no futuro, sinta-se à vontade para fazer perguntas se eu perder alguma coisa - embora o método é direto.

Portanto, a principal preocupação é remover os dados sem impacto significativo no tráfego de produção nos nós de/para os quais estamos replicando. A maneira mais fácil de fazer isso é segregar um nó no qual você deseja trabalhar, removendo os dados desse nó e deixando todos os outros inalterados (incluindo os nós de relatórios).

A melhor maneira de fazer isso (lembre-se de que você não pode descartar partições e qualquer/a maioria das operações é replicada e, portanto, cria uma grande quantidade de tráfego e uma grande quantidade de alterações de linha), é criar um novo SP e configurar uma publicação em torno deste SP. Deve, portanto, estar disponível em todos os nós. O bit importante é definir a replicação para replicar a execução do SP - NÃO o resultado (ou seja, replicar a chamada EXEC Sp_delete NÃO excluir WHERE ID = 1, excluir WHERE ID = 2 - alterações no nível da linha). Isso é definido em Clique com o botão direito em sua nova publicação (antes de configurar os outros nós na topologia) > Propriedades > Artigos > Clique no SP_Delete que você configurou > botão Propriedades do artigo > Definir propriedades do artigo de procedimento armazenado destacado > Replicar linha = EXECUÇÃO do procedimento armazenado. Complete sua topologia P2P.

MAS MHSQLDBA, você pode estar dizendo, isso apenas excluirá separadamente as linhas em cada nó por meio do SP. - É por isso que você configura o SP para fazer apenas as exclusões:

IF @@SERVERNAME='O servidor atual que você deseja afetar'

Siga-o com o procedimento de exclusão.

Assim, quando esta chamada EXEC for captada no(s) servidor(es) que você não deseja realizar os Deletes, ela será ignorada pois @@Servername não será igual ao Servidor que você selecionou.

Você pode pensar - por que não criar um SP apenas no servidor em que está interessado e executá-lo? - isso ocorre porque, se você fizer isso, a replicação dividirá as alterações em como elas afetam as linhas do artigo (tabela) e replicarão as alterações reais - você deve replicar o SP para poder especificar que o EXEC do SP seja replicado ao invés das mudanças resultantes.

Esta é a ordem de eventos sugerida em minha opinião/experiência:

1. Crie SP com código de exclusão que especifica que ele só executará o código de exclusão se @@SERVERNAME = seu servidor desejado
2. Configure uma nova publicação que Replica este 1 SP com Replicate = Execution of Stored Procedure dentro das Propriedades do Artigo
3. Execute o SP no servidor desejado e fique feliz por não ter derrubado toda a propriedade com milhares de comandos DELETE replicados

Pontos de Observação:

1. Esta ainda é uma tarefa trabalhosa. Ao usar este método, você diminuiu seu efeito em todos os servidores, exceto naquele em que está trabalhando. Você não diminuiu a carga de trabalho para você, na verdade você piorou - você terá que executar este mesmo SP em cada nó (com a linha IF alterada para o servidor que você está direcionando), aumentando efetivamente o trabalho que você tem fazer, pelo número de servidores que você tem que afetar. É extremamente mais seguro, pois você terá um efeito mínimo em todos os outros nós (presumo que você tenha falhado no tráfego longe do nó em que está trabalhando, é claro!)
2. Ao usar esse método, você criou inconsistência entre seus nós - você realmente precisa ter certeza de que os dados que está removendo NÃO serão alterados antes de concluir a execução da mesma operação em todos os nós que exigem trabalho. Se uma linha que você excluiu em 1 nó for alterada no restante da propriedade, você acabará com erros de consistência.
3. É provável que você atrase os SLAs esperados de replicação normal pelo tempo necessário para executar as exclusões no nó em que está trabalhando (recomendo que você leia sobre como agrupar as exclusões em lote) - portanto, você precisa estar ciente que assim que a operação for concluída, você não terá o nó de volta em ação até que a replicação normal seja recuperada depois que os bloqueios da operação de exclusão forem liberados. Se você estiver replicando em linhas de alta latência, sugiro seriamente que verifique o uso de agentes PULL em vez de PUSH - isso faz uma diferença enorme.

Provavelmente existe uma maneira melhor de mover os dados no SP do que usar delete - talvez movê-los para outra tabela que não esteja envolvida na replicação e, em seguida, descartar a 'nova' tabela - ou o inverso, se os dados que você deseja manter é menor que o valor a ser excluído, mova os dados que deseja manter para uma nova tabela, descarte o antigo e renomeie sua nova tabela - há muitos conselhos por aí a partir dessas perspectivas - eu trabalho em um ambiente onde era mais fácil lutar pela exclusão do que promover um conceito que algumas pessoas não entenderão, então estou descrevendo a maneira dolorosa, mas básica.

ISENÇÃO DE RESPONSABILIDADE: Todos os itens acima são perigosos. Se feito às pressas sem premeditação apropriada, você pode atrapalhar seriamente uma topologia de replicação, os dados de sua empresa e provavelmente seu emprego. Por favor, use o método acima e desenvolva seu próprio plano de batalha - crie um ambiente de teste para provar o conceito, teste, teste e teste novamente, não leve esta tarefa levianamente. Com consideração suficiente, você cumprirá sua tarefa - mas não vale a pena fazê-lo na sexta-feira à tarde, depois de algumas cervejas na hora do almoço. Faça certo, faça uma vez (para testar o máximo que puder), faça corretamente.

Espero que isto ajude alguém. - Estou adicionando este trecho, pois é o que eu teria procurado se quisesse esta resposta:

Excluir grande quantidade de dados de uma topologia de replicação ponto a ponto