Мы только что развернули новую систему репликации DFS между двумя серверами Windows 2012 R2. Мы клонировали базу данных DFSr, используя рекомендации MS (http://blogs.technet.com/b/filecab/archive/2013/08/21/dfs-replication-initial-sync-in-windows-server-2012-r2-attack-of-the-clones.aspx), а репликация / синхронизация работала на 99% идеально (несколько файлов застряли в очереди, но в остальном все отлично).
После перезагрузки неосновного рядового сервера он пожаловался в журнале событий на нечистое завершение работы / обертывание журнала (отключение было запланировано) и сказал, что ему придется восстановить базу данных, если она не сможет надежно восстановить (событие 2212). . Затем он бросил журнал 2218, заявив, что он был на втором этапе проверки целостности базы данных репликации.
Практически сразу после этого оба сервера начали генерировать огромное количество журналов 4412 (файл изменен на нескольких серверах, «проигравший» файл перемещен в DFSrPrivate \ ConflictsandDeleted) как на первичном, так и на вторичном серверах. Однако, когда я запускаю PS Get-DFSrFileHash как для «выигравшего» файла, так и для файла, перемещенного в ConflictsandDeleted, они идеально совпадают.
Установка DFSr имеет 19 миллионов файлов, и замена каждого файла, даже если они равны, займет недели; поскольку кажется, что репликация остановлена до завершения этого процесса, я бы хотел, чтобы DFS «осознала», что файлы на самом деле одинаковы. Кто-нибудь видел что-то подобное раньше?
Когда у меня была аналогичная проблема в прошлом, я удалил всех потомков пула (так что у вас есть только основной). Ждал около 15 минут, затем добавлял по одному потомку, ожидая около 15 минут за раз. Ошибка была на одном сервере. На этом сервере я синхронизировал права доступа к файлам с рабочим сервером (обычно основным), промываю и повторяю, пока не будут добавлены все ваши потомки.