none
впорос по SCR... RRS feed

  • Вопрос

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

     

    СПС...

     

    З.Ы. Первая попытка включения SCR получилаьс неудачной, несколько часов прождал, но на цели так и не заполнился журнал транзакций... в общем ничего не произошло...

    • Перемещено Hengzhe Li 16 марта 2012 г. 8:29 forum merge (От:Exchange Server 2007)
    29 января 2009 г. 13:03

Все ответы

  • на цели создавать ничего не нужно. scr сам создаст структуру папок и базу.
    Skorp написал: Первая попытка включения SCR получилаьс неудачной, несколько часов прождал, но на цели так и не заполнился журнал транзакций... в общем ничего не произошло...



    опишите какие действия вы выполняли

    что выдаёт?: Get-StorageGroupCopyStatus -Identity "exchange2\omega group" -StandbyMachine exchange

    29 января 2009 г. 13:35
  •  вот что написано в мануале:

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

    Например, если на исходном компьютере файлы группы хранения и файлы журналов размещены в папке «D:\SG1\Logs», а база данных — в папке «E:\SG1\Database», на всех целевых компьютерах также должны быть папки «D:\SG1\Logs» и «E:\SG1\Database».

    это написано вмануале... разве это не подразумевает предварительное создание???

     

    поднял второй экс 2007 сп1... установлен в ту же папку что и на источнике... +  2 раздела, Д и Е для логов и БД соответсвенно... на источнике раположение такое-же... затем на цели создал папки, такие-же как и на источнике... создал группу хранения, с путями и названием как на источнике... вот вроде и все... да, единственное, забыл удалить старые файлы журнала транзакций, которые остались от БД, которая была поднята при установке... включил SCR... комманда вполнилась, но было предупреждение-уведомление, что SCR заработает только после того, как на цели будет все заполненно... долсловно не помню... ждал долго, несколько часов, ничего не произошло... после этого, на цели создал БД с таким же названием и расположением как на источнике... в евентах появились ошибки о невозможности репликации, к сожалению евенты не могу предоставить, стер... (знаю, косяк за мной...) Get-StorageGroupCopyStatus выдавал, что SCR отключен... т.к. выполнил отклбчение SCR, то Get-StorageGroupCopyStatus ничо не даст... вот такие вот дела... сейчас удалил все файлы из папок БД и логов, но сами папки не удалил... также на цели оставил пустую SG (зеркало с источника...)

    29 января 2009 г. 13:55
  • SG и базу создавать не нужно.

    Её можно создать в процессе востановления в случае краха сервера источника.

    http://technet.microsoft.com/ru-ru/library/bb738132.aspx - раздел "Активация целевой базы данных пассивной непрерывной репликации"

    Имена SG и базы после восстановления не принципиальны, так как всё равно идёт смена настроек почтовых ящиков на новую базу командлетом

    Get-Mailbox -Database OLD_MB_SRV\OLD_SG\OLD_MDB |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly -TargetDatabase NEW_MB_SRV\NEW_SG\NEW_MDB

    Другими словами на цели нужно, как правильно ты заметил создать структуру папок.

    PS.

    solaris24 наверное хотел сказать что папки автоматически создадутся, когда SCR включается при создании новой SG

    New-StorageGroup -Server <Server> -Name <StorageGroupName> -LogFolderPath <PathforLogFiles> -SystemFolderPath <PathforSystemFiles> -StandbyMachine <NameofSCRTargetMachine>

     

     

    29 января 2009 г. 14:03
  • В общем так, сейчас удалю SG на цели, и включю SCR... посмотрим как сейчас все пройдет...

    New-StorageGroup -Server <Server> -Name <StorageGroupName> -LogFolderPath <PathforLogFiles> -SystemFolderPath <PathforSystemFiles> -StandbyMachine <NameofSCRTargetMachine> - выполнять незачем, ибо источник давно в бою и надо резервировать боевую SG...

    29 января 2009 г. 14:20
  •  [PS] C:\>Enable-StorageGroupCopy -Identity "srv-mail01\First Storage Group" -StandbyMachine  srv-mail02 -ReplayLagTime 0.1:0:0 -DomainController dc00.sub.domain.ru
    ПРЕДУПРЕЖДЕНИЕ: Копирование First Storage Group включено, но для копии требуется заполнение. Копирование группы хранения временно приостановлено. Возобновите копирование после заполнения базы данных.
    [PS] C:\>

    вот что выдал экс, после повторного включения... это же было и в первый раз...

    29 января 2009 г. 14:33
  • всё правильно. теперь нужно выполнить заполнение целевой базы:

    Update-StorageGroupCopy

    а после этого:

    resume-StorageGroupCopy

    29 января 2009 г. 14:36
  • да, именно это и делаю в данный момент... база большая... придется долго подождать... надеюсь к концу рабочего дня запонится и включу непосредственно SCR...
    29 января 2009 г. 14:48
  • полсе заполнения выполнил комманду возобновления resume-StorageGroupCopy, но, почему-то воз и ныне там... файлы журнала транзакций успешно копируются, но ни воспроизведения ни усечения не происходит... вот что выдается

     

    [PS] C:\>Get-StorageGroupCopyStatus -identity "srv-mail01\first storage group"|fl


    Identity                         : SRV-MAIL01\First Storage Group
    StorageGroupName                 : First Storage Group
    SummaryCopyStatus                : Disabled
    NotSupported                     : False
    NotConfigured                    : False
    Disabled                         : True
    ServiceDown                      : False
    Failed                           : False
    Initializing                     : False
    Resynchronizing                  : False
    Seeding                          : False
    Suspend                          : False
    CCRTargetNode                    :
    FailedMessage                    :
    SuspendComment                   :
    CopyQueueLength                  : 0
    ReplayQueueLength                : 0
    LatestAvailableLogTime           :
    LastCopyNotificationedLogTime    :
    LastCopiedLogTime                :
    LastInspectedLogTime             :
    LastReplayedLogTime              :
    LastLogGenerated                 : 0
    LastLogCopyNotified              : 0
    LastLogCopied                    : 0
    LastLogInspected                 : 0
    LastLogReplayed                  : 0
    LatestFullBackupTime             :
    LatestIncrementalBackupTime      :
    LatestDifferentialBackupTime     :
    LatestCopyBackupTime             :
    SnapshotBackup                   :
    SnapshotLatestFullBackup         :
    SnapshotLatestIncrementalBackup  :
    SnapshotLatestDifferentialBackup :
    SnapshotLatestCopyBackup         :
    OutstandingDumpsterRequests      :
    DumpsterServersNotAvailable      :
    DumpsterStatistics               :
    IsValid                          : True
    ObjectState                      : Unchanged

     

    в евентах ошибок нет... в чем теперь проблема???

    30 января 2009 г. 4:32
  • комадна проверки состояния, должа всегда быть в таком формате:

    Get-StorageGroupCopyStatus -Identity "exchange2\omega group" -StandbyMachine exchange

    т.е. укажи -StandbyMachine

    30 января 2009 г. 5:25
  • блин, точно, речь же о SCR, поэтому -StandbyMachine нужна... щас проверю...

    да, и как я понял, если не указывать параметр усечения файлов журнала, то по умолчанию они сразу удаляются после воспроизведения, так ведь???

    в оснастке говорит, copy status - disabled, или это для LCR???

    вообще, на целевом компе появится ли в оснастке резервируемая группа???

    Identity                         : SRV-MAIL01\First Storage Group
    StorageGroupName                 : First Storage Group
    SummaryCopyStatus                : Healthy
    NotSupported                     : False
    NotConfigured                    : False
    Disabled                         : False
    ServiceDown                      : False
    Failed                           : False
    Initializing                     : False
    Resynchronizing                  : False
    Seeding                          : False
    Suspend                          : False
    CCRTargetNode                    :
    FailedMessage                    :
    SuspendComment                   :
    CopyQueueLength                  : 0
    ReplayQueueLength                : 93
    LatestAvailableLogTime           : 30.01.2009 9:48:58
    LastCopyNotificationedLogTime    : 30.01.2009 9:48:58
    LastCopiedLogTime                : 30.01.2009 9:48:58
    LastInspectedLogTime             : 30.01.2009 9:48:58
    LastReplayedLogTime              : 30.01.2009 8:48:26
    LastLogGenerated                 : 576910
    LastLogCopyNotified              : 576910
    LastLogCopied                    : 576910
    LastLogInspected                 : 576910
    LastLogReplayed                  : 576817
    LatestFullBackupTime             : 24.01.2009 1:01:15
    LatestIncrementalBackupTime      :
    LatestDifferentialBackupTime     : 30.01.2009 1:00:22
    LatestCopyBackupTime             :
    SnapshotBackup                   : False
    SnapshotLatestFullBackup         : False
    SnapshotLatestIncrementalBackup  :
    SnapshotLatestDifferentialBackup : False
    SnapshotLatestCopyBackup         :
    OutstandingDumpsterRequests      : {}
    DumpsterServersNotAvailable      : {}
    DumpsterStatistics               : {SRV-MAIL01(0;0KB), SRV-MAIL02(0;0KB)}
    IsValid                          : True
    ObjectState                      : Unchanged

    30 января 2009 г. 6:42
  • такс народ, чот я запаниковал не в тему... все вроде как работает... LastLogReplayed изменяется, я не обратил на него внимания...

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

     

    так что все работает вроде как... всем спсб...

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

    30 января 2009 г. 7:49
  • Группа хранения не должна создаваться, её ты должен бужешь сосздать сам, с именем, какое тебе нравится...

    http://technet.microsoft.com/ru-ru/library/bb738132.aspx - раздел "Активация целевой базы данных пассивной непрерывной репликации"

    30 января 2009 г. 7:52
  • такс, ну вроде бы все работает, единственный вопрос, на целевой базе когда будут усечены файлы журнала??? после полного бэкапа базы источника что ли???

     

    вот комманда, которой повторно запустил SCR...

    Enable-StorageGroupCopy -Identity "srv-mail01\First Storage Group" -StandbyMachine srv-mail02 -ReplayLagTime 0.1:0:0 -TruncationLagTime 0.0:0:0 -DomainController DCs FQDN

    30 января 2009 г. 14:22
  •  Должны усекаться исходя из TruncationLagTime 0.0:0:0 сразу после Replay.
    MCSE, MCTS, MCITP, STS
    30 января 2009 г. 14:25
  • я также думаю, но, они не усекаются... количество файлов растет, самый старый файл имеет дату создания 30 января 2009 г., 16:49:13... час после включения репликации еще не прошел, наверное по прошествии часа начнут усекаться???

    30 января 2009 г. 14:39
  •  ну правильно REplay у тебя должен быть грубо говоря через час после создания лога, и 0 часов до усекания, то есть сразу после проигрывания лога в базу
    MCSE, MCTS, MCITP, STS
    30 января 2009 г. 14:42
  • вот еще чем пугает мелкософт, что

    Исправность копии резервной непрерывной репликации можно быстро оценить по значениям свойств SummaryCopyStatus, CopyQueueLength, ReplayQueueLength и LastInspectedLogTime. Эти свойства показывают, правильно ли функционирует копия резервной непрерывной репликации, и является ли копия резервной непрерывной репликации достаточно новой в плане копирования и преобразования журналов. При возникновении следующих условий необходимо определить причину их возникновения и устранить неполадку.

    • Копия находится значительное время в неисправном состоянии.
    • Длина очереди копирования более 5 элементов.
    • Длина очереди преобразования более 20 элементов.
    • Время последнего проверенного журнала не показывает текущее время. Существует две вероятные причины этого: изменения группы хранения незначительны или служба репликации остановлена.

    3-й пункт у меня явно больше 20... это действительно так страшно??? например прямо сейчас - 352... но он меняется то вверх то вниз...

    30 января 2009 г. 14:42
  • т.е. усечение должно начаться в 17:49:13???
    30 января 2009 г. 14:43
  •  Если не секрет - скажи где нашёл, что ReplayQueueLength должно быть меньше 20.(это справедливо для CCR & LCR) 

    Я вот думаю что оно у тебя не будет меньше 50.

    Это именно для SCR.


    MCSE, MCTS, MCITP, STS
    30 января 2009 г. 15:23
  •  http://www.oszone.net/print/6135/ - вот ссылка на счет "Длина очереди преобразования более 20 элементов."

    а файлы так и не усекаются... уже больше 5000... что скажите??? где косяк???

    30 января 2009 г. 18:48
  •  Должны усекаться...

    Вот что написано в Управление резервной непрерывной репликацией о TruncationLag

    "Период времени начинается после того, как журнал был успешно воспроизведен в копию базы данных" , то есть так как он у тебя 0, то должен начаться после успешного Replay. Не усекается может потому что Replay ещё идёт? 

    Ознакомься -http://technet.microsoft.com/en-us/library/cc535020.aspx#LogTrunc

    Там как раз написано о известном баге, когда файлы не удаляются, но это случается если TruncationLag > ReplayLagTime

    Вот подробнее об этом - http://support.microsoft.com/default.aspx/kb/952682/

    В любом случае 4 RollUp на сервер поставь, если ещё не стоит.

    Покажи ещё раз результат 

    Get-StorageGroupCopyStatus -Identity "exchange2\omega group" -StandbyMachine exchange

    и установленные задержки :

    $sg = Get-StorageGroup "MyServer\MyStorageGroupName"
    $sg.StandbyMachines


    MCSE, MCTS, MCITP, STS
    30 января 2009 г. 19:41
  • Вот статистика которую только что получил:

    Identity                         : SRV-MAIL01\First Storage Group
    StorageGroupName                 : First Storage Group
    SummaryCopyStatus                : Healthy
    NotSupported                     : False
    NotConfigured                    : False
    Disabled                         : False
    ServiceDown                      : False
    Failed                           : False
    Initializing                     : False
    Resynchronizing                  : False
    Seeding                          : False
    Suspend                          : False
    CCRTargetNode                    :
    FailedMessage                    :
    SuspendComment                   :
    CopyQueueLength                  : 0
    ReplayQueueLength                : 150
    LatestAvailableLogTime           : 31.01.2009 11:01:14
    LastCopyNotificationedLogTime    : 31.01.2009 11:01:14
    LastCopiedLogTime                : 31.01.2009 11:01:14
    LastInspectedLogTime             : 31.01.2009 11:01:14
    LastReplayedLogTime              : 31.01.2009 10:00:48
    LastLogGenerated                 : 583651
    LastLogCopyNotified              : 583651
    LastLogCopied                    : 583651
    LastLogInspected                 : 583651
    LastLogReplayed                  : 583501
    LatestFullBackupTime             : 24.01.2009 1:01:15
    LatestIncrementalBackupTime      :
    LatestDifferentialBackupTime     : 30.01.2009 1:00:22
    LatestCopyBackupTime             :
    SnapshotBackup                   : False
    SnapshotLatestFullBackup         : False
    SnapshotLatestIncrementalBackup  :
    SnapshotLatestDifferentialBackup : False
    SnapshotLatestCopyBackup         :
    OutstandingDumpsterRequests      : {}
    DumpsterServersNotAvailable      : {}
    DumpsterStatistics               : {SRV-MAIL01(0;0KB), SRV-MAIL02(0;0KB)}
    IsValid                          : True
    ObjectState                      : Unchanged

    на цели стоит RU5, на источнике стоит RU3, RU4, RU5...

    $sg = Get-StorageGroup "srv-mail01\First Storage Group"
    $sg.StandbyMachines

    NodeName                 Version ReplayLagTime            TruncationLagTime
    --------                           ------- -------------                     -----------------
    srv-mail02                            1 01:00:00                          00:00:00

    сейчас почитаю вторую ссылку, может что подскажет...

    31 января 2009 г. 8:09
  •  Судя по приведённому тобой у тебя должно остаться 150 файлов логов.
    все логи с номерами меньше и равно 583501 можно удалить то есть меньше Enn8E74D.log
    MCSE, MCTS, MCITP, STS
    31 января 2009 г. 20:57
  • ну так что, куда теперь рыть??? автоматом ведь должны усекаться...

    2 февраля 2009 г. 9:08
  •  Должны...
    Пока не понятно... мысли кончились...
    На источнике стоит Circular logging?

    Есть один критерий, который может проверить?
    Это отсюда - http://technet.microsoft.com/en-us/library/cc535020.aspx#LogTrunc

    In an SCR environment, if the following criteria are met, a log file will be truncated on an SCR target.

    • The log file generation sequence is below the log file checkpoint for the storage group.
    • The log file is older than ReplayLagTime + TruncationLagTime.
    • The log file must have been deleted on the source.

    MCSE, MCTS, MCITP, STS
    2 февраля 2009 г. 9:21
  •  нет, Circular logging не включено...

    на счет "The log file must have been deleted on the source." - прошел полный бэкап, а файлы и ныне там...
    почитаю ссылку... я еще и белые страницы не успел просмотреть... благо пока место есть под журнал...
    2 февраля 2009 г. 10:18
  •  А чем Бэкап делаешь на источнике? NTBACKUP?
    На источнике файлы логов транзакций удаляются после бэкапа?
    MCSE, MCTS, MCITP, STS
    2 февраля 2009 г. 11:59
  •  Да...
    Да...

    бэкап прошел нормально... файлы журнала удалились...
    2 февраля 2009 г. 12:12
  • "бэкап прошел нормально... файлы журнала удалились..."
    То есть на источнике они удалились а на цели остались?


    MCSE, MCTS, MCITP, STS
    2 февраля 2009 г. 12:39
  •  Да, именно так... и в евентах, как обычно все замечательно, никактх проблем...

    2 февраля 2009 г. 13:57
  •  В англицкой части И-нета попалась похожая проблема, человек написал что справился с ней, остановкой репликации и ресинхронизацией.
    то есть
    1. останавливаем Suspend-StorageGroupCopy -Identity "srv-mail01\First Storage Group" -StandByMachine srv-mail02
    2. на цели удаляем все файлы 
      "The Update-StorageGroupCopy cmdlet requires that no Exchange files exist in the target location when it is run, and that the storage group copy has replication activity suspended."
    3. Update-StorageGroupCopy -Identity "srv-mail01\First Storage Group" -StandByMachine srv-mail02
    После успешного заполнения базы репликация сама включится автоматически resume-StorageGroupCopy не надо.
    MCSE, MCTS, MCITP, STS
    2 февраля 2009 г. 14:10
  • получается как-бы переседируем базу...
    попробую...

    а можно ссылку на статью???

    2 февраля 2009 г. 14:57
  •  ну да, только вот поможет ли?
    в том форуме (просто не помню уже где) человек клялся что у него после этого файлы удаляться стали, но странно что  в след. постах писали о помощи по похожей проблеме.
    MCSE, MCTS, MCITP, STS
    2 февраля 2009 г. 15:04
  • не получилось и с этим вариантом, файлы не усекаются...

    3 февраля 2009 г. 15:54