none
Развалился DAG, спасите кто может. Exchange 2013 RRS feed

 > 

  • Вопрос

  • Question
    Нужно войти
    0
    Нужно войти

    Доброго дня всем!

    Есть такая схема
    два сервера Exchange, MBX1 и MBX2 они объединены в DAG-01

    Так вот, вчера вечером МBX1 упал, не сам, а весь хост на котором он сидел со всем остальными виртуалками.

    Пока чинили остальные службы, свято верили что Exchange работает и что ему будет ведь у него есть MBX2. Но почта не ходила, аутлуки перестали подключатся. Полез смотреть, а там база валяется.

    При попытке ее подключить, он ругается что служба репликации на MBX1 недоступна и поэтому он не может приатачить базу. Я в шоке, вот так кластер.
    На формах советовали остановить службы и удалить логи и временные файлы, оставив только базу, но это не помогает. Всегда одно и тоже.

    Как же такое лечить ?

    12 февраля 2018 г. 8:33
    |

Ответы

  • Question
    Нужно войти
    2
    Нужно войти

    Ваш кластер не смог собрать кворум.

    Надеюсь вы не успели удалить логи у баз? Не знаю даже кто вам такое посоветовал. Это может потребоваться только после процедуры hard recover, но вы ведь этого не делали? или делали?


    • Изменено Egor Vasilev 12 февраля 2018 г. 9:04
    • Предложено в качестве ответа Ivan.Basov 12 февраля 2018 г. 18:44
    • Помечено в качестве ответа LazyPepper 13 февраля 2018 г. 7:27
    12 февраля 2018 г. 9:03
    |
  • Question
    Нужно войти
    1
    Нужно войти
    а где свидетель у этого кластера?
    • Помечено в качестве ответа LazyPepper 13 февраля 2018 г. 9:35
    12 февраля 2018 г. 8:49
    |

Все ответы

  • Question
    Нужно войти
    1
    Нужно войти
    а где свидетель у этого кластера?
    • Помечено в качестве ответа LazyPepper 13 февраля 2018 г. 9:35
    12 февраля 2018 г. 8:49
    |
  • Question
    Нужно войти
    0
    Нужно войти

    А если pam перекинуть? 


    Узнать где pam

    сначала получаем название группы DAG командой:
    Get-DatabaseAvailabilityGroup

    затем выводим свойства этой группы:

    Get-DatabaseAvailabilityGroup -Identity ″dag″ -Status | fl name, servers, primaryactivemanager


    Для переноса pam 

    Import-Module FailoverClusters
    Get-ClusterGroup

    Переносим Primary Active Manager на сервер MBX2: Move-ClusterGroup -Name ″Cluster Group″ -Node mbx2

    ======

    дайте вывод

    Test-ReplicationHealth -Identity mbx1

    Test-ReplicationHealth -Identity mbx2

    • Изменено Adlukashin 12 февраля 2018 г. 9:00
    12 февраля 2018 г. 8:52
    |
  • Question
    Нужно войти
    0
    Нужно войти
    а где свидетель у этого кластера?

    минуточку .... блин, он был там же
    Отпишусь позже, thx!

    12 февраля 2018 г. 8:54
    |
  • Question
    Нужно войти
    2
    Нужно войти

    Ваш кластер не смог собрать кворум.

    Надеюсь вы не успели удалить логи у баз? Не знаю даже кто вам такое посоветовал. Это может потребоваться только после процедуры hard recover, но вы ведь этого не делали? или делали?


    • Изменено Egor Vasilev 12 февраля 2018 г. 9:04
    • Предложено в качестве ответа Ivan.Basov 12 февраля 2018 г. 18:44
    • Помечено в качестве ответа LazyPepper 13 февраля 2018 г. 7:27
    12 февраля 2018 г. 9:03
    |
  • Question
    Нужно войти
    0
    Нужно войти

    Ваш кластер не смог собрать кворум.

    Надеюсь вы не успели удалить логи у баз? Не знаю даже кто вам такое посоветовал. Это может потребоваться только после процедуры hard recover, но вы ведь этого не делали? или делали?



    Я их переместил, они есть, но не знаю, сгодятся ли они теперь ...
    12 февраля 2018 г. 15:35
    |
  • Question
    Нужно войти
    0
    Нужно войти
    Если hard recover не делали, то без логов у вас база тем более не подключится
    12 февраля 2018 г. 16:27
    |
  • Question
    Нужно войти
    0
    Нужно войти
    Если hard recover не делали, то без логов у вас база тем более не подключится

    Интересная ситуация, я вернул логи на место и о чудо mbx1 посчитал себя активным, и без ошибок и сам примаунтил базу. Однако на mbx2 все так же было плохо. Коли есть одна рабочая база я решил удалить е с mbx2 и скопировать ее туда заново. Не тут то было:
    The Microsoft Exchange Replication service encountered an error while inspecting the logs and database for SRV\MBX2 on startup. Error: File check failed : Database file 'D:\base\srv\base.edb' was not found.

    Как же так, она же должна была ее туда скопировать, нет ?
    12 февраля 2018 г. 16:32
    |
  • Question
    Нужно войти
    0
    Нужно войти

    Если hard recover не делали, то без логов у вас база тем более не подключится


    Интересная ситуация, я вернул логи на место и о чудо mbx1 посчитал себя активным, и без ошибок и сам примаунтил базу. Однако на mbx2 все так же было плохо. Коли есть одна рабочая база я решил удалить е с mbx2 и скопировать ее туда заново. Не тут то было:
    The Microsoft Exchange Replication service encountered an error while inspecting the logs and database for SRV\MBX2 on startup. Error: File check failed : Database file 'D:\base\srv\base.edb' was not found.

    Как же так, она же должна была ее туда скопировать, нет ?

    Все, разобрался, надо было выбрать от куда копировать.

    Всем огромное спасибо, вы очень помогли своими подсказками и наводящими вопросами !
    Чтоб я еще хоть когда нибудь, хоть одним пальцем ... тронул логи =)

    12 февраля 2018 г. 18:04
    |
  • Question
    Нужно войти
    0
    Нужно войти

    Ваш кластер не смог собрать кворум.

    Надеюсь вы не успели удалить логи у баз? Не знаю даже кто вам такое посоветовал. Это может потребоваться только после процедуры hard recover, но вы ведь этого не делали? или делали?


    Вот один из советчиков
    https://social.technet.microsoft.com/Forums/ru-RU/849bde1a-62a1-4e9b-bba2-2ec3dffe7b12/-exchenge-2013-?forum=exchange2013ru
    13 февраля 2018 г. 9:35
    |
  • Question
    Нужно войти
    0
    Нужно войти
    Там товарищ предлагает файл бд и логи переместить во временную директорию (чтобы была возможность также вернуть их назад), а не тройной шифт-делит.
    13 февраля 2018 г. 10:53
    |