Início / dba / Perguntas / 201859
Accepted
Andrew Bickerton
Asked: 2018-03-22 01:16:08 +0800 CST

Relatórios de replicação transacional ok, mas o token do rastreador não está chegando

  • 772

Estou com um problema estranho aqui. Eu estava testando o uso de 'initialize from lsn' em nossa configuração de replicação de teste e agora quebrei todas as publicações de um de nossos bancos de dados, a reconstrução do zero (aplicando um novo instantâneo) não corrigiu o problema.

No monitor de replicação, o agente distribuidor é executado continuamente e relata:

Nenhuma transação replicada está disponível

O token Tracer está relatando que:

  • Editor para Distribuidor: 00:00:02
  • Distribuidor para Assinante: Pendente...
  • Latência total: pendente...

Quando investiguei os logs de distribuição usando:

SELECT time,
       CAST(comments AS XML) AS comments,
       runstatus,
       duration,
       xact_seqno,
       delivered_transactions,
       delivered_commands,
       average_commands,
       delivery_time,
       delivery_rate,
       delivery_latency / (1000 * 60) AS delivery_latency_Min,
       agent_id
FROM dbo.MSlogreader_history WITH (NOLOCK)
WHERE agent_id = 5
ORDER BY time DESC;

SELECT *
FROM dbo.MSdistribution_history
WHERE agent_id = 125
ORDER BY time DESC;

Eu posso ver que o último xact_seqno de:

  • O agente LogReader é: 0x00000378000384880003
  • O agente de distribuição é: 0x000CA68B000010A8000A000000070000

Como comparação em um dos outros bancos de dados (indo para o mesmo assinante), recebo:

  • O agente LogReader é: 0x00000D140001F52A0003
  • O agente de distribuição é: 0x00000D140001F52A0003000000000000

Para mim, parece que o agente de distribuição está lembrando do antigo xact_seqno quebrado (de quando cometi um erro ao testar 'initialize from lsn'), mas agora parece ter quebrado permanentemente toda a replicação desse banco de dados.

Servidores:

  • PubA - Um editor hospeda vários bancos de dados que são replicados
  • Dist - Um distribuidor separado
  • SubA - Primeiro assinante
  • SubB - Segundo assinante

Bancos de dados:

  • PubA.DB1 = Publisher DB que está funcionando bem
  • PubA.DB2 = DB Publisher que está quebrado
  • SubA.PullWorking1 = 1º assinante tem uma assinatura pull em funcionamento do DB1
  • SubA.PullBroken2 = 1º assinante também tem uma assinatura pull quebrada do DB2
  • SubA.PushWorking1 = 2º assinante tem uma assinatura push funcional do DB1
  • SubA.PushBroken2 = 2º assinante também tem uma assinatura push quebrada do DB2

Publicações:

  • PubA.DB1.PushPub_works
  • PubA.DB1.PullPub1_works
  • PubA.DB1.PullPub2_works
  • PubA.DB2.PushPub_broken
  • PubA.DB2.PullPub_broken
sql-server-2016 transactional-replication

1 respostas

  1. Best Answer

    Ok, caso alguém tenha esse problema, encontrei a correção (embora não a causa raiz).

    Fixar

    1. Interrompa os agentes de distribuição para todos os assinantes de publicações deste banco de dados
    2. Obtenha o LSN que está causando o problema de um dos assinantes :

    SELECT publication, '0x' + CONVERT(VARCHAR(32),MAX(transaction_timestamp),2) as LastPubLSN FROM dbo.MSreplication_subscriptions GROUP BY publication

    1. Encontre um LSN válido para começar:

    DECLARE @Publisher sysname = N'PubA', @PubDB sysname = N'DB2', @Publication sysname = N'PushPub_Broken'; SELECT TOP 1000 trans.entry_time, trans.publisher_database_id, trans.xact_seqno FROM dbo.MSpublications AS p JOIN master..sysservers AS srv ON srv.srvid = p.publisher_id JOIN dbo.MSpublisher_databases AS d ON d.publisher_id = p.publisher_id AND d.publisher_db = p.publisher_db JOIN dbo.MSrepl_transactions AS trans ON trans.publisher_database_id = d.id WHERE p.publication = @Publication AND p.publisher_db = @PubDB AND srv.srvname = @Publisher AND trans.xact_seqno >= p.min_autonosync_lsn ORDER BY trans.entry_time DESC

    1. Verifique quais comandos inválidos estão na fila de reposição:

    DECLARE @PubDB INT = 5 /* use the publisher_database_id retrieved above */ select * from MSrepl_commands with (READPAST) where publisher_database_id = @PubDB and command_id = 1 and type <> 30 and /* 30 = normal repl commands */ type <> -2147483611 /* -2147483611 = is ignored by sp_MSget_repl_commands (it's snapshot related?) */

    1. Faça backup e exclua os comandos que estão causando o bloqueio, este deve ser o mesmo LSN que está causando o problema (consulte a etapa 2)
    2. Redefina o LSN em cada um dos bancos de dados do assinante

    EXEC sp_setsubscriptionxactseqno @publisher = 'PubA', @publisher_db = 'DB2', @publication = 'PushPub_Broken', @xact_seqno = 0x0000... /* New valid LSN to start from (step 3) */

    1. Inicie seu agente de distribuição e verifique se tudo está funcionando.

    Como eu encontrei

    Então, depois de encontrar e testar sp_setsubscriptionxactseqno em conjunto com saber como obter o LastLSN aplicado ao assinante, executei um rastreamento no distribuidor, pude ver que a sequência era:

    exec sp_MSget_repl_commands 126,/* good LSN that I was telling it to use */,0,10000000
go
exec sp_MShelp_distribution_agentid 6,N'PushPub_broken',N'DB2',8,N'PushBroken2',0
go
exec sp_MSget_repl_commands 126,/* bad LSN that it was resetting too */,0,10000000
go

    Executando o primeiro comando sozinho, pude ver 2 conjuntos de resultados retornados, o segundo dos quais incluía o LSN ruim. Obviamente, algo dentro deste proc estava fazendo com que ele substituísse o LSN que eu queria que ele aplicasse.

    Encontrando o código para sp_MSget_repl_commands, consegui identificar que era:

    select @max_xact_seqno = max(xact_seqno) from MSrepl_commands with (READPAST)
  where 
     publisher_database_id = @publisher_database_id and
     command_id = 1 and
     type <> -2147483611

    A partir daí, encontrei os registros culpados e consegui reiniciar a replicação (depois de ressincronizar meus dados)

    • 2

relate perguntas