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

Question

A empresa que trabalho tem um conjunto de bancos de dados (maiores apenas abaixo de 1TB) em servidores diferentes - 2 nos EUA, 2 na Europa.

Executamos a replicação completa de peer-to-peer por banco de dados entre os 4 nós - para que todos possam fazer transações (Inserir / Atualizar / Excluir) e todos terem os dados que os outros nós se reuniram (dentro de uma latência variável - pior A conexão é em média cerca de 30-40 segundos).

O maior banco de dados carrega dados do início de 2008 para hoje. Todos esses dados são replicados para relatar os nós que mantêm todos os dados.

Eu preciso remover dados nos nós transacionais, até 2013, para remover o déficit de espaço de acionamento nos nós transacionais e, portanto, os dados históricos só estarão disponíveis nos nós de relatórios.

Qual é a melhor maneira de fazer isso? Os dados são relativamente gerenciáveis, pois são bem particionados (mensalmente - por partição e, em seguida, anualmente em arquivos / arquivos de arquivos separados). No entanto, há o problema de não poder deixar cair as partições enquanto eles estão envolvidos na replicação e lendo a comutação de partição - isso não é permitido com isso. ( Partições de comutação Pré-requisitos - ponto 18 )

Como ambiente de produção completo, estou tentando evitar qualquer coisa que afetará a replicação - incluindo ressincronização (muitos dados para Ressync, em grandes distâncias).

Alguém tem alguma boa sugestão para como realizar essa tarefa?

Answer 1

Então, sem respostas daqui, mas depois de uma certa quantidade de discussão e pensamento, eu inventei um plano há alguns meses.

Eu vou fazer esta resposta concisa para este fórum (você pode não concordar que eu tenho!), tentar ajudar qualquer um que precise realizar uma tarefa semelhante no futuro, sinta-se à vontade para fazer perguntas se eu perder alguma coisa Embora o método esteja direto.

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

Melhor maneira de fazer isso (lembre-se que você não pode largar partições e qualquer / a maioria das operações são replicadas e, portanto, criar 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 um sp. Portanto, deve 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 (isto é, replicar a chamada EXEC SP_DELETE não a exclusão em que id= 1, excluir onde mudanças de nível id= 2 -. Isso é definido com o botão direito do mouse em sua nova publicação (antes de configurar os outros nós na topologia)> Propriedades> Artigos> Clique no botão SP_Delete Você tem configuração> Botão de propriedades do artigo> Definir propriedades do artigo realçado do procedimento armazenado> Replicar linha= execução do procedimento armazenado. Complete sua topologia P2P.

Mas MHSQLDBA, você pode estar dizendo, isso só vai excluir separadamente as linhas em todos os nó através do SP. - É por isso que você define o SP para fazer apenas as exclusões:

se @@ servername= 'o servidor atual que você deseja afetar'

Siga com o seu procedimento de exclusão.

Assim, quando esta chamada EXEC é apanhada no (s) servidor (s) que você não deseja executar as exclusões, ela será ignorada como @@ serverName não será igual ao servidor que você selecionou.

Você pode pensar - por que não apenas criar um SP apenas no servidor em que você está interessado e execute isso? - Isso é porque se você fizer isso, a replicação vai quebrar as alterações em como eles afetam as linhas do artigo (tabela) e replicar as alterações reais - você tem que replicar o SP para que você possa especificar que o EXEC do SP seja replicado em vez das alterações resultantes.

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

.
1. Criar SP com o código de exclusão que especifica que ele só executará o código de exclusão se @@ serverName= seu servidor desejado
2. Configurar uma nova publicação que replica este 1 SP com a execução de replicada= de procedimento armazenado na Propriedades do artigo
3. Execute o SP no seu servidor desejado e seja feliz que você não tenha derrubado toda a propriedade com milhares de comandos de exclusão replicados

Pontos da nota:

.
1. Esta é uma tarefa laboriosa. Usando este método, você diminuiu seu efeito em todos os servidores além do que você está trabalhando. Você não diminuiu a carga de trabalho para você, na verdade, você conseguiu pior - você terá que executar este mesmo SP em cada nó (com a linha se alterada para o servidor que você estiver segmentando), aumentando efetivamente o trabalho que você tem para fazer, pelo número de servidores que você tem que afetar. É massivamente mais seguro, embora você tenha efeito mínimo em todos os outros nós (estou presumindo que você falhou tráfego longe do nó que você está trabalhando, é claro!)
2. Usando este método, você criou inconsistência entre seus nós - você realmente precisa ter certeza de que os dados que você está removendo não vai mudar antes de poder terminar de executar a mesma operação em todos os nós que exigem trabalho. Se uma linha que você tiver excluído em 1 nó é alterada dentro do resto da propriedade, você vai acabar com erros de consistência.
3. você provavelmente vai colocar sua replicação normal SLAs esperados pela quantidade de tempo que leva para executar as exclusões no nó em que você está trabalhando (eu recomendo que você leia em lote os exclusões) - Portanto, você precisa Para saber 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 tenha pego de volta após as fechaduras de exclusão da operação terem liberado. Se você estiver replicando em linhas de alta latência, eu sugiro seriamente que você verifique usando agentes de puxar em vez de empurrar - faz uma diferença humonosa.

provavelmente há uma maneira melhor de mover os dados para longe no SP do que usar a exclusão - talvez movê-lo para outra tabela que não esteja envolvida na replicação e, em seguida, soltando a tabela 'nova' - ou o reverso, se os dados deseja manter é menor que o valor para excluir, mova os dados que você deseja manter para uma nova tabela, soltar o antigo, então renomeie sua nova tabela - há muitos conselhos lá fora dessas perspectivas - eu trabalho em um ambiente onde foi mais fácil lutar pela exclusão do que promover um conceito que

algum pessoal não entenderá, então estou descrevendo a maneira dolorosa, mas básica.

Isenção de responsabilidade: todos os itens acima são perigosos.Se feitos apressadamente sem precisão apropriado, você pode seriamente bagunçar uma topologia de replicação, os dados da sua empresa e provavelmente seu emprego.Por favor, tome o método acima e desenvolva seu próprio Battleplan - crie um ambiente de teste para provar o conceito, teste de teste e reteste, não tome essa tarefa levemente.Com consideração suficiente, você alcançará sua tarefa - mas não vale a pena fazer na tarde de sexta-feira depois de algumas cervejas de almoço.Faça certo, faça uma vez (para teste real o máximo que puder), faça isso corretamente.

Espero que isso ajude outra pessoa.- Eu estou adicionando esse pouco como é o que eu teria procurado se eu quisesse esta resposta:

Exclua grande quantidade de dados de uma topologia de replicação peer-to-peer