none
Как такое исправить RRS feed

Ответы

  • Да, пригляделся внимательнее: там магическое число 9223372036854775766, блокирующее автоматическую активацию копии БД. Чтобы убрать его, надо будет активировать эту копию вручную (см. ниже).

    Но для начала рекомендую убедиться, что на обоих серверах содержимое данных об активной копии реплицируется в кластере, и что время последней записи не отстает от времени сервера более  чем на 12 минут.

    Данные эти хранятся в кластерной БД в реестре (ключ HKEY_LOCAL_MACHINE\Cluster) под ключом HKEY_LOCAL_MACHINE\Cluster\ExchangeActiveManager\LastLog, там набор параметров: <GUID_БД> со значением последнего номера лога и <GUID_БД>_TIME со временем последней записи (формат UTC, то есть без поправки на часовой пояс). Посмотрите, чтобы время не отставало сильно и вообще сравните содержимое на обоих серверах (имейте в виду, что оно может слегка отличаться, т.к. постоянно обновляется и реплицируется).

    Если там всё ОК то можно попытаться вручную активировать копию на MBX1 с игнорированием проверок - командой в EMS 

    Move-ActiveMailboxDatabase DB01 –ActivateOnServer YOUR_SERVER_NAME -SkipLagChecks -SkipActiveCopyChecks –MountDialOverride:BESTEFFORT -SkipClientExperienceChecks

    (можно ещё -SkipHealthChecks добавить)

    PS Описание механизма защиты, если интересно - https://blogs.technet.microsoft.com/timmcmic/2012/05/30/exchange-2010-the-mystery-of-the-9223372036854775766-copy-queue/


    Слава России!

    8 апреля 2020 г. 20:40
  • Проблема с магическим числом очереди решилась. Была найдена не верна настройка реестра.

    Было:
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
    "RealTimeIsUniversal"=dword:00000001

    Стало:
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
    "RealTimeIsUniversal"=dword:00000001


    Пока полет нормальный

    • Помечено в качестве ответа LazyPepper 18 мая 2020 г. 5:50

Все ответы

  • Для начала разберитесь, что там с репликацией - такое впечатление, что MBX1 не может общаться с MBX2, вплоть до того, что его состояние БД не видит.

    Команда Test-ReplicationHealth вам в помощь (например - в форме Test-ReplicationHealth -DatabaseAvailabilityGroup DAG-01 ). Ну и, как всегда - анализ событий с ошибками/предупреждениями из журналов Система и Приложение.

    Потом, когда наладите репликацию, можно будет и с индексом разобираться - например, стянуть его с исправной копии помощью Update-MailboxDatabaseCopy с ключом -CatalogOnly.


    Слава России!


    • Изменено M.V.V. _ 5 апреля 2020 г. 15:03
    5 апреля 2020 г. 14:47
  • Для начала разберитесь, что там с репликацией - такое впечатление, что MBX1 не может общаться с MBX2, вплоть до того, что его состояние БД не видит.

    Команда Test-ReplicationHealth вам в помощь (например - в форме Test-ReplicationHealth -DatabaseAvailabilityGroup DAG-01 ). Ну и, как всегда - анализ событий с ошибками/предупреждениями из журналов Система и Приложение.

    Потом, когда наладите репликацию, можно будет и с индексом разобираться - например, стянуть его с исправной копии помощью Update-MailboxDatabaseCopy с ключом -CatalogOnly.


    Слава России!


    Спасибо за ваш ответ.
    Действительно была проблема со связью. Топология АД восстановилась. Но вот очереди так и не удалось починить.
    Update-MailboxDatabaseCopy с ключом -CatalogOnly. Отрабатывает, но результат тот же.
    Где-то читал, что такое происходит, если разница во времени синхронизации журналов больше 12-ти минут. 
    Может какие службы перезапустить или сервер целиком ?
    7 апреля 2020 г. 20:21
  • Команда Test-ReplicationHealth ошибок не выявило. 
    7 апреля 2020 г. 20:27
  • Службу индексации Exchange можете попробовать на MBX2 перезапустить.

    А по поводу репликации между копиями БД - помониторьте для начала (командой Get-MailboxDatabaseCopyStatus имя_базы , к примеру) движется ли очередь репликации. Если нет, то можно попробовать сделать Suspend/Resume для пассивной копии. Ну, и смотрите в журнале событий Приложение, какие ошибки служба репликации пишет.


    Слава России!

    7 апреля 2020 г. 20:38
  • Службу индексации Exchange можете попробовать на MBX2 перезапустить.

    А по поводу репликации между копиями БД - помониторьте для начала (командой Get-MailboxDatabaseCopyStatus имя_базы , к примеру) движется ли очередь репликации. Если нет, то можно попробовать сделать Suspend/Resume для пассивной копии. Ну, и смотрите в журнале событий Приложение, какие ошибки служба репликации пишет.


    Слава России!

    Очередь не двигается и это вообще не очередь, а защитные меры. Вот такая ошибка.

    The timestamp indicating the age of the last log generated on the active database copy is '4/8/2020 8:19:15 AM', which is stale or missing. As a safeguard, the system set the copy queue length to a large value to prevent losses greater than the automatic database mount dial setting.

    Suspend/Resume  -  не работает. не нажимается.

    Как этот timestamp привести в нормальное состояние ?

    8 апреля 2020 г. 9:10
  • Да, пригляделся внимательнее: там магическое число 9223372036854775766, блокирующее автоматическую активацию копии БД. Чтобы убрать его, надо будет активировать эту копию вручную (см. ниже).

    Но для начала рекомендую убедиться, что на обоих серверах содержимое данных об активной копии реплицируется в кластере, и что время последней записи не отстает от времени сервера более  чем на 12 минут.

    Данные эти хранятся в кластерной БД в реестре (ключ HKEY_LOCAL_MACHINE\Cluster) под ключом HKEY_LOCAL_MACHINE\Cluster\ExchangeActiveManager\LastLog, там набор параметров: <GUID_БД> со значением последнего номера лога и <GUID_БД>_TIME со временем последней записи (формат UTC, то есть без поправки на часовой пояс). Посмотрите, чтобы время не отставало сильно и вообще сравните содержимое на обоих серверах (имейте в виду, что оно может слегка отличаться, т.к. постоянно обновляется и реплицируется).

    Если там всё ОК то можно попытаться вручную активировать копию на MBX1 с игнорированием проверок - командой в EMS 

    Move-ActiveMailboxDatabase DB01 –ActivateOnServer YOUR_SERVER_NAME -SkipLagChecks -SkipActiveCopyChecks –MountDialOverride:BESTEFFORT -SkipClientExperienceChecks

    (можно ещё -SkipHealthChecks добавить)

    PS Описание механизма защиты, если интересно - https://blogs.technet.microsoft.com/timmcmic/2012/05/30/exchange-2010-the-mystery-of-the-9223372036854775766-copy-queue/


    Слава России!

    8 апреля 2020 г. 20:40
  • Да, пригляделся внимательнее: там магическое число 9223372036854775766, блокирующее автоматическую активацию копии БД. Чтобы убрать его, надо будет активировать эту копию вручную (см. ниже).

    Но для начала рекомендую убедиться, что на обоих серверах содержимое данных об активной копии реплицируется в кластере, и что время последней записи не отстает от времени сервера более  чем на 12 минут.

    Данные эти хранятся в кластерной БД в реестре (ключ HKEY_LOCAL_MACHINE\Cluster) под ключом HKEY_LOCAL_MACHINE\Cluster\ExchangeActiveManager\LastLog, там набор параметров: <GUID_БД> со значением последнего номера лога и <GUID_БД>_TIME со временем последней записи (формат UTC, то есть без поправки на часовой пояс). Посмотрите, чтобы время не отставало сильно и вообще сравните содержимое на обоих серверах (имейте в виду, что оно может слегка отличаться, т.к. постоянно обновляется и реплицируется).

    Если там всё ОК то можно попытаться вручную активировать копию на MBX1 с игнорированием проверок - командой в EMS 

    Move-ActiveMailboxDatabase DB01 –ActivateOnServer YOUR_SERVER_NAME -SkipLagChecks -SkipActiveCopyChecks –MountDialOverride:BESTEFFORT -SkipClientExperienceChecks

    (можно ещё -SkipHealthChecks добавить)

    PS Описание механизма защиты, если интересно - https://blogs.technet.microsoft.com/timmcmic/2012/05/30/exchange-2010-the-mystery-of-the-9223372036854775766-copy-queue/


    Слава России!

    То есть, это лечится только(!) насильным переключением базы ?
    Просто я лечил это перезагрузкой сервиса Exchange Active Directory Topology, но ошибка постоянно появляется.


    • Изменено LazyPepper 14 мая 2020 г. 18:05
  • Проблема с магическим числом очереди решилась. Была найдена не верна настройка реестра.

    Было:
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
    "RealTimeIsUniversal"=dword:00000001

    Стало:
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
    "RealTimeIsUniversal"=dword:00000001


    Пока полет нормальный

    • Помечено в качестве ответа LazyPepper 18 мая 2020 г. 5:50