Post reply

Availability Group database went into 'Restoring' state

  • June 1, 2023 at 8:19 am

    #4202087

    Dear Friends,

    Please advise why would one of my Availability Group databases go into 'Restoring' state. Thanks in advance.

     

    • This topic was modified 10 months, 3 weeks ago by  Arsh.

  • June 1, 2023 at 9:05 am

    #4202117

    for reference , i have attached the comparative state of the Availability groups and also how the database in question 'CITRIX_XD_CL' shows a changed-state (of Restoring).

     

    Thanks and Regards.

    Attachments:
    You must be logged in to view attached files.

  • June 1, 2023 at 9:51 am

    #4202150

    Check the Always On Health extended event files from all replicas, it should hopefully shine some insight as to what went on.

     

    Going to hazard a guess someone set HADR OFF on that replica making it go to restoring state, but the XEL files should show more.

  • June 1, 2023 at 11:57 am

    #4202208

    @Ant-Green

    .There was an OS related system activity (patches)  by system team and they restarted the server itself , directly multiple times brutally . can I set the HADR , ON direclty? thanks

  • June 1, 2023 at 12:19 pm

    #4202210

    @Ant-Green

    Where do I find the 'Always On Health extended event files' ? pls guide as I am completely new to AoAG.btw, I attached the Health state  snapshot..Also since it doesnt appear in the aoag group list in the secondary , is it recoverable ? I can just remove it from the AOAG group and restore that DB , and then configure again for this DB.Imense thanks.

     

    Attachments:
    You must be logged in to view attached files.

  • June 1, 2023 at 12:31 pm

    #4202251

    @Ant-green

    When I clicked on the 'Warnings' link from the dashboard, it says the replicas are not connected.I attached the screen shot of the same.Thank you.

    Attachments:
    You must be logged in to view attached files.

  • June 1, 2023 at 12:43 pm

    #4202255

    Can't just set HADR back to ON if the replica is disconnected.

    If you have no experience in AOAG's I wouldn't have put that technology in place for something as critical as HADR.

     

    Does that DB in question belong to the AG VM02?

    It looks like either it wasn't fully created on the replicas properly as it is missing from one replica, or that replica has had some of the metadata removed.

    Backup the DB in question, trash the AG and set it up again from scratch.

  • June 1, 2023 at 3:13 pm

    This was removed by the editor as SPAM

  • June 8, 2023 at 10:27 am

    #4206941

    Hi @Ant-Green,

    Yes the database is there in the AG  MV02 in the secondary (now primary, as it failed over automatically as the Database in the primary(now secondary) had entered the 'restoring' state) .  I tried to remove the database and add it again on the replica that is active and has no issues but it doesn't allow to add , as the corresponding AG Group is no more there in the other replica ?

    SO now please advise if I must dismantle this AG Group and need to recreate it , (as the database can be only added once the corresponding AG Groups exist in entirely in both the replicas , understandably)?  Thank you for guiding me further from there .

  • June 8, 2023 at 11:47 am

    #4206986

    If the AG metadata is no longer present on a replica, then you need to destroy that AG and recreate it from the beginning.

  • June 19, 2023 at 12:59 pm

    #4214490

    @ant-green

    I removed the AOAG from the secondary too and reconfigured afresh. Now its in sync and healthy..thanks for your experienced advises.

     

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply