none
Banco corrompido após Failover Availability Groups RRS feed

  • Pergunta

  • Olá Pessoal,

    Temos um ambiente SQL Server 2014 Enterprise rodando em 2 servidores - serv1(primario) e serv2(secundario)-, no mesmo cluster, mas geograficamente separados. Temos um AG com 10 DBs configurado entre eles. São duas failover cluster instances, embora ainda não tenhamos um par de failover para cada um dos servidores (temos apenas os dois). Temos este ambiente rodando desde Out2015 e sempre fizemos diversos Availability Group failover entre as duas maquinas, mudando entre Primaria e Secundaria quando necessaria alguma manutenção.

    Pois no final de semana tínhamos uma manutenção simples, era fazer o failover (usando AG) do serv1 para o serv2, stop start do serv1 (agora sendo secundário) e fazer o failover de volta.

    Terminamos essa tarefa e apenas um banco (o maior) dos replicados foi corrompido. 

    Analisando o errorlog, eu acredito que ele tenha sido corrompido após o failover e antes do stop. Obs. Nenhuma mensagem me impediu de fazer o failover e ele foi concluido com sucesso, segundo o AG Dashboard. Esse log apareceu logo após o failover e antes do restart.

    06/12/2015 10:09:19 spid119s Database 6 cannot be autostarted during server shutdown or startup.
    06/12/2015 10:09:19 spid119s Error: 904, Severity: 16, State: 2.

    Após o restart, tivemos esse log:

    2015-12-06 10:10:07.620 spid27s Skipping the default startup of database 'banco_id_6' because the database belongs to an availability group (Group ID:  65536). The database will be started by the availability group. This is an informational message only. No user action is required.
    2015-12-06 10:10:07.620 spid27s Error: 35262, Severity: 17, State: 1.

    2015-12-06 10:10:20.650 spid47s The operating system returned error 170(The requested resource is in use.) to SQL Server during a read at offset 0x00000000012000 in file 'D:\sqlserver_data\banco_id_6.mdf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
    2015-12-06 10:10:20.650 spid47s Error: 823, Severity: 24, State: 1.

    Li que restart do SQL havia resolvido muitos casos deste erro 823. Então o fiz. Encontrei depois o erro abaixo, mas o banco estava acessível:

    06/12/2015 10:24:44 spid32s The recovery LSN (238785:141838:1) was identified for the database with ID 6. This is an informational message only. No user action is required.
    06/12/2015 10:24:44 spid32s Error: 35285, Severity: 16, State: 1.
    06/12/2015 10:24:44 spid32s AlwaysOn Availability Groups connection with primary database established for secondary database 'banco_id_6' on the availability replica 'serv2' with Replica ID: {xxxxxx}. This is an informational message only. No user action is required.
    06/12/2015 10:24:44 spid32s 1 transactions rolled forward in database 'banco_id_6' (6:0). This is an informational message only. No user action is required.
    06/12/2015 10:24:44 spid32s Recovery completed for database banco_id_6 (database ID 6) in 8 second(s) (analysis 0 ms, redo 7 ms, undo 0 ms.) This is an informational message only. No user action is required.
    06/12/2015 10:24:44 spid57s AlwaysOn Availability Groups connection with primary database established for secondary database 'banco_id_6' on the availability replica 'serv2' with Replica ID: {xxxxxx}. This is an informational message only. No user action is required.
    06/12/2015 10:24:44 spid57s The recovery LSN (238785:141838:1) was identified for the database with ID 6. This is an informational message only. No user action is required.
    06/12/2015 10:24:44 spid57s Error: 35285, Severity: 16, State: 1.
    06/12/2015 10:24:44 spid32s CHECKDB for database 'banco_id_6' finished without errors on 2015-03-13 09:45:39.547 (local time). This is an informational message only; no user action is required.

    Fiz o failover transformando esse servidor serv1 em primario, pois não havia identificado nenhum erro. Logo após fazer isso, encontrei essa mensagem:

    2015-12-06 10:36:21.570 spid106 Attempt to fetch logical page (1:86072696) in database 6 failed. It belongs to allocation unit 72057594181255168 not to 72057594161987584.

    Este banco no servidor serv2 entrou em SUSPECT e daí pra frente foi só tortura para recuperar tudo.

    Minha questão é: Alguém tem alguma dica do que pode ter causado este crash? Algum SP ou Cumulative Upadate que pode resolver este problem? É um problema conhecido? 

    Ps. Nas últimas semanas estava fazendo um purge de dados, eliminamos mais de 1 bilhão de linhas.


    Rafael Dontal Goncalez

    segunda-feira, 7 de dezembro de 2015 15:43

Respostas

  • Pessoal,

    Descobrimos o porque corrompemos o banco:

    "A failover command returns as soon as the target secondary replica has accepted the command. However, database recovery occurs asynchronously after the availability group has finished failing over."

    https://msdn.microsoft.com/en-us/library/hh231018%28v=sql.120%29.aspx?f=255&MSPPError=-2147217396

    A gente foi enganado pelo failover wizard dizendo que ele havia completado com sucesso, mas na verdade, no serv1 (agora secundario) ele ainda estava se recuperando quando fizemos o stop desse servidor.

    Portanto, não confiem apenas no failover wizard para fazer o stop da instancia. Acompanhe os logs e teste a conexão com o bd secundario tambem.


    Rafael Dontal Goncalez



    • Marcado como Resposta Rafael Dontal terça-feira, 8 de dezembro de 2015 08:56
    • Editado Rafael Dontal terça-feira, 8 de dezembro de 2015 08:58
    terça-feira, 8 de dezembro de 2015 08:56

Todas as Respostas

  • Pessoal,

    Descobrimos o porque corrompemos o banco:

    "A failover command returns as soon as the target secondary replica has accepted the command. However, database recovery occurs asynchronously after the availability group has finished failing over."

    https://msdn.microsoft.com/en-us/library/hh231018%28v=sql.120%29.aspx?f=255&MSPPError=-2147217396

    A gente foi enganado pelo failover wizard dizendo que ele havia completado com sucesso, mas na verdade, no serv1 (agora secundario) ele ainda estava se recuperando quando fizemos o stop desse servidor.

    Portanto, não confiem apenas no failover wizard para fazer o stop da instancia. Acompanhe os logs e teste a conexão com o bd secundario tambem.


    Rafael Dontal Goncalez



    • Marcado como Resposta Rafael Dontal terça-feira, 8 de dezembro de 2015 08:56
    • Editado Rafael Dontal terça-feira, 8 de dezembro de 2015 08:58
    terça-feira, 8 de dezembro de 2015 08:56
  • Bom dia Rafael.

    Grande Dica, ainda não administro nenhum cenário com AG, mas poderá servir futuramente.

    Vlw

    Att

    Reginaldo

    terça-feira, 8 de dezembro de 2015 11:04