Estou tentando resolver um problema usando o ms-replication e não tenho certeza se é a melhor opção para o problema em questão.
Problema: É preciso replicar todas as inserções iniciais e todas as atualizações, ignorando exclusões para uma assinatura. Essencialmente, um banco de dados de destino que continua a crescer e os dados nunca são removidos, mesmo quando os registros são excluídos na origem. Ser capaz de restaurar na origem sem destruir o destino seria um grande bônus.
Posso fazer a maior parte disso funcionar via ms-replication configurando ignore deletes em todos os artigos de tabela e configurando o modo de preparação de tabela para do-nothing. Isso lidaria com a manutenção de dados durante restaurações e manteria registros excluídos no destino, no entanto, como lidar com inserções que resultariam em violações de PK após uma restauração na origem. Não consigo encontrar nenhuma maneira documentada de "Ignorar registros existentes durante a inserção" e, mesmo que haja um hack, isso reduziria muito o desempenho da replicação?
NOTA: Devo mencionar que dar suporte a um backup não significa voltar a um ponto no tempo há muito tempo, significa apenas que se ocorrer uma falha grave, o banco de dados de origem precisa ser restaurado usando a cadeia de log mais recente. Haveria no máximo duas horas de inserções para lidar. Isso provavelmente poderia ser resolvido excluindo manualmente os registros no destino que não estão na origem, no entanto, eu estava tentando evitar isso completamente.
Não estou muito familiarizado com a base do processo de snapshot, além de tentar carregar dados via BCP. Se o modo de preparação da tabela for do nothing, há uma opção para pular opcionalmente a fase de "carregamento em massa" do snapshot e então continuar com o leitor de log normalmente após o snapshot ter sido aplicado?
"como lidar com inserções que resultariam em violações de PK após uma restauração na fonte"
Você pode definir IGNORE_DUP_KEY no PK no assinante. Ou usar gatilhos INSTED OF INSERT, ou modificar o procedimento armazenado de inserção de replicação para sobrescrever a linha, se ela existir.
Mas você sempre precisa ter um processo documentado e testado para reinicializar um assinante. Então, como um processo de backup, você pode precisar estar preparado para renomear o DB do assinante, reinicializar a assinatura e, então, adicionar novamente as linhas que não existem mais no publicador.