При репликации возникла ошибка 8451

Уважаемые коллеги, данная тему уже поднималась на форуме но ответ полученный там мне не помог, прошу помощи.

Ситуация следующая, есть коневой DC01 с WS2003sp2x32 (железка), есть вторичный DC02 с WS2008R2x64 (виртуальная машина), был вторичный DC03 с WS2003sp2x32 (железка).

Действия:

После удачного добавления DC02 к существующей инфраструктуре, понизил до рядового DC03, все прошло удачно информация из БД AD была удалена, поле еще прошелся утилитами и проверил ntdsutil.

Уровень леса пока ws2003, все FSMO роли живут на DC01.

DC03 это hp dl 320 g3

Далее на DC03 развернул WS2008r2x64, пост вил все обновления, запустил утилиту dcpromo, прошелся по шагам, началось действо, и уже под самый конец мне этот «товарищ» заявил, вот что в логах:

1. Дефрагментация БД AD

2. С помощью repadmin зачищал базу

3. по GUID объекта указанного в ошибке нашел этот объект в БД AD с помощью ADSEdit, он лежит по следующему пути CN=8f86b825-c322-4101-adc4-579f12d445db,CN=Operations,CN=ForestUpdates,CN=Configuration,DC=server,DC=local сделать с ним ничего нельзя. Как я
понял он не привязан к объектам непосредственно в AD, так что его не куда передвигать.

4. Прверял конфигурацию DNS там все чисто

5. Пробовал в dpcromo снимать галку GC не помогло

Воспрос:

Что по Вашему еще можно сделать, проверить, посмотреть, что бы устранить ошибку и завести дополнительный DC03?

Возможно данная информация кому нибудь поможет.

Описание проблемы:

Корневой доменный контроллер инфраструктуры развёрнут на Windows Server 2003 R2 SP2 x86, на нём размещаются все роли FSMO; При введении в домен доменного контроллера на базе Windows Server 2008 R2 оканчивается ошибкой репликации раздела CN=Configuration;

В журналах присутствуют следующие ошибки:

Имя журнала: Directory Service

Источник: Microsoft-Windows-ActiveDirectory_DomainService

Дата: 10.11.2011 13:06:15

Код события: 1084

Категория задачи:Репликация

Уровень: Ошибка

Ключевые слова:Классический

Пользователь: АНОНИМНЫЙ ВХОД

Компьютер: dc04.msft.local

Описание:

Internal event: Active Directory Domain Services could not update the following object with changes received from the following source directory service. This is because an error occurred during the application of the changes to Active Directory Domain Services on the directory service.

Object:

CN=Configuration,DC=msft,DC=local

Object GUID:

8686a414-5d23-407e-8061-a7d443382eef

Source directory service:

dc01.msft.local

Synchronization of the directory service with the source directory service is blocked until this update problem is corrected.

This operation will be tried again at the next scheduled replication.

User Action

Restart the local computer if this condition appears to be related to low system resources (for example, low physical or virtual memory).

Additional Data

Error value:

8451 Произошла ошибка базы данных при выполнении репликации.

Xml события:

<Event xmlns=»http://schemas.microsoft.com/win/2004/08/events/event»>

<System>

<Provider Name=»Microsoft-Windows-ActiveDirectory_DomainService» Guid=»{0e8478c5-3605-4e8c-8497-1e730c959516}» EventSourceName=»NTDS General» />

<EventID Qualifiers=»49152″>1084</EventID>

<Version>0</Version>

<Level>2</Level>

<Task>5</Task>

<Opcode>0</Opcode>

<Keywords>0x8080000000000000</Keywords>

<TimeCreated SystemTime=»2011-11-10T09:06:15.429679800Z» />

<EventRecordID>2009</EventRecordID>

<Correlation />

<Execution ProcessID=»452″ ThreadID=»768″ />

<Channel>Directory Service</Channel>

<Computer>dc04.msft.local</Computer>

<Security UserID=»S-1-5-7″ />

</System>

<EventData>

<Data>CN=Configuration,DC=msft,DC=local</Data>

<Data>8686a414-5d23-407e-8061-a7d443382eef</Data>

<Data>dc01.msft.local</Data>

<Data>Произошла ошибка базы данных при выполнении репликации.</Data>

<Data>8451</Data>

</EventData>

< /Event>

Имя журнала: Directory Service

Источник: Microsoft-Windows-ActiveDirectory_DomainService

Дата: 10.11.2011 13:06:15

Код события: 2108

Категория задачи:Репликация

Уровень: Ошибка

Ключевые слова:Классический

Пользователь: АНОНИМНЫЙ ВХОД

Компьютер: dc04.msft.local

Описание:

В этом событии содержится описание ПРОЦЕДУР ВОССТАНОВЛЕНИЯ для события 1084, которое было записано в журнал событий ранее. Это сообщение указывает на конкретную проблему согласованности базы данных доменных служб Active Directory на этом направлении репликации. Ошибка обработки базы данных произошла при применении реплицированных изменений для следующего объекта. База данных находится в непредвиденном состоянии, не позволяющем внести эти изменения.

Объект:

CN=Configuration,DC=msft,DC=local

GUID объекта:

8686a414-5d23-407e-8061-a7d443382eef

Исходный контроллер домена:

dc01.msft.local

Действия пользователя

1. Убедитесь, что на дисках, несущих базу данных доменных служб Active Directory, достаточно свободного места, затем повторите операцию. Убедитесь, что на дисках, несущих NTDS.DIT и файлы журналов, не включено сжатие NTFS. Проверьте, не используется ли для этих дисков антивирусное программное обеспечение.

2. Может быть полезным выполнить принудительное построение родительской цепочки контейнеров этого объекта в базе данных с помощью Security Descriptor Propagator. Это можно сделать, следуя инструкциям из статьи базы знаний 251343, http://support.microsoft.com/?id=251343.

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

4. Если этот компьютер является глобальным каталогом и ошибка возникает в одном из разделов, предназначенных только для чтения, то следует лишить этот компьютер роли глобального каталога, сняв флажок глобального каталога в пользовательском интерфейсе «Сайты и службы«. Если ошибка происходит в разделе каталога приложений, можно остановить несение раздела каталога приложений на этой реплике. Это можно сделать с помощью команды NTDSUTIL.EXE.

5. Получите самую последнюю версию NTDSUTIL.EXE, установив последний пакет обновления для данной операционной системы. Прежде чем выполнять загрузку в режиме восстановления службы каталогов (DSRM), убедитесь, что вам известен пароль режима DSRM. В противном случае следует сбросить пароль перед перезагрузкой системы.

6. В режиме DSRM запустите командную строку, затем выполните команду «ntdsutil files integrity». Если будет найдено повреждение и существуют другие реплики, лишите эту реплику ее роли и проверьте надежность работы оборудования. Если другие реплики отсутствуют, восстановите состояние системы с помощью архивной копии и повторите эту проверку.

7. Находясь в автономном режиме, выполните дефрагментацию с помощью функции «ntdsutil files compact».

8. Следует также выполнить команду «ntdsutil semantic database analysis». Если будут найдены ошибки, их можно исправить с помощью функции «go fixup». Не путайте эту команду с функцией «ESE repair», которую нельзя использовать в данном случае, поскольку она может привести к потере данных в базе данных Active Directory.

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

Дополнительные данные

Основная ошибка:

8451 Произошла ошибка базы данных при выполнении репликации.

Вторичная ошибка:

-1507 JET_errColumnNotFound, No such column

Xml события:

<Event xmlns=»http://schemas.microsoft.com/win/2004/08/events/event»>

<System>

<Provider Name=»Microsoft-Windows-ActiveDirectory_DomainService» Guid=»{0e8478c5-3605-4e8c-8497-1e730c959516}» EventSourceName=»NTDS General» />

<EventID Qualifiers=»49152″>2108</EventID>

<Version>0</Version>

<Level>2</Level>

<Task>5</Task>

<Opcode>0</Opcode>

<Keywords>0x8080000000000000</Keywords>

<TimeCreated SystemTime=»2011-11-10T09:06:15.429679800Z» />

<EventRecordID>2010</EventRecordID>

<Correlation />

<Execution ProcessID=»452″ ThreadID=»768″ />

<Channel>Directory Service</Channel>

<Computer>dc04.msft.local</Computer>

<Security UserID=»S-1-5-7″ />

</System>

<EventData>

<Data>CN=Configuration,DC=msft,DC=local</Data>

<Data>8686a414-5d23-407e-8061-a7d443382eef</Data>

<Data>dc01.msft.local</Data>

<Data>Произошла ошибка базы данных при выполнении репликации.</Data>

<Data>8451</Data>

<Data>JET_errColumnNotFound, No such column</Data>

<Data>-1507</Data>

</EventData>

< /Event>

Имя журнала: Directory Service

Источник: Microsoft-Windows-ActiveDirectory_DomainService

Дата: 10.11.2011 13:06:15

Код события: 1173

Категория задачи: Внутренняя обработка

Уровень: Предупреждение

Ключевые слова: Классический

Пользователь: АНОНИМНЫЙ ВХОД

Компьютер: dc04.msft.local

Описание:

Internal event: Active Directory Domain Services has encountered the following exception and associated parameters.

Exception:

e0010002

Parameter:

0

Additional Data

Error value:

8451

Internal ID:

106027e

Xml события:

<Event xmlns=»http://schemas.microsoft.com/win/2004/08/events/event»>

<System>

<Provider Name=»Microsoft-Windows-ActiveDirectory_DomainService» Guid=»{0e8478c5-3605-4e8c-8497-1e730c959516}» EventSourceName=»NTDS General» />

<EventID Qualifiers=»32768″>1173</EventID>

<Version>0</Version>

<Level>3</Level>

<Task>9</Task>

<Opcode>0</Opcode>

<Keywords>0x8080000000000000</Keywords>

<TimeCreated SystemTime=»2011-11-10T09:06:15.429679800Z» />

<EventRecordID>2011</EventRecordID>

<Correlation />

<Execution ProcessID=»452″ ThreadID=»768″ />

<Channel>Directory Service</Channel>

<Computer>dc04.msft.local</Computer>

<Security UserID=»S-1-5-7″ />

</System>

<EventData>

<Data>e0010002</Data>

<Data>8451</Data>

<Data>0</Data>

<Data>106027e</Data>

</EventData>

< /Event>

Анамнез:

Уровень леса и домена Windows Server 2003;

Подготовка к введению в инфраструктуру доменного контроллера на базе Windows Server 2008 R2 SP1 прошла успешно:

Подготовка леса и домена с помощью adprep /forest prep и adprep /domainprep /gpprep выполнена без ошибок;

Значение ObjectVertion после выполнения adprep для контейнера Schema:

Значение Revision после выполнения adprep для контейнера ActiveDirecrotyUpdate:

DCdiag ошибок в функционировании доменного контроллера не выявляет;

Вероятная причина:

Доподлинно установить не удалось, но есть подозрение, что вызвано некорректной работой adprep x86;

Решение:

В ручную через ADSI были изменены значения:

CN=Schema, CN=Configuration, DC=MSFT, DC=LOCAL равно 44

CN=ActiveDirectoryUpdate, CN=ForestUpdates, CN=Configuration, DC=MSFT, DC=LOCAL равно 2

После этого было проведено повторное расширение схемы и подготовка домена для Windows Server 2008 R2.

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

Благодарности:

Спасибо Smirnov_Nik за возможность совместно найти решение данного вопроса.

Коллеги, если у кого была похожая проблема поделитесь опытом!

Pavel17
Новичок

Зарегистрирован: 24.06.2021
Пользователь #: 176,471
Сообщения: 4

Источник

Ошибка репликации Active Directory 8451: «Операция репликации обнаружила ошибку базы данных»

Эта статья содержит разрешение ошибки репликации Active Directory 8451: «Операция репликации обнаружила ошибку базы данных».

Применимо к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер базы знаний: 2645996

Домашние пользователи: эта статья предназначена только для агентов технической поддержки и ИТ-специалистов. Если вам нужна помощь по устранению проблемы, обратитесь к сообществу Майкрософт.

Симптомы

В этой статье описываются симптомы и причины сбоя операций доменные службы Active Directory (AD DS) и возникновение ошибки 8451: «Операция репликации обнаружила ошибку базы данных». В этой статье также описано решение этой проблемы.
У вас может возникнуть один из следующих симптомов:

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

Dcpromo.exe ошибка 8451.
В пользовательском интерфейсе отображается следующее сообщение:

Не удалось выполнить операцию, так как:

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

При выполнении операции репликации произошла ошибка базы данных.

Файл Dcpromo.log содержит следующие сведения:

[INFO] NstdInstall for contoso.com returned 8451
[INFO] DsRolepInstallDs returned 8451
[ERROR] Failed to install to Directory Service (8451)
[INFO] Starting service NETLOGON

Repadmin.exe сообщает о сбое попытки репликации с состоянием 8451. Repadmin.exe команды, которые обычно ссылаются на состояние 8451, включают, но не ограничиваются:

Подробные сведения об использовании Repadmin для устранения неполадок репликации см. в разделе «Мониторинг и устранение неполадок репликации Active Directory с помощью Repadmin».

repadmin /showreps В следующем примере показаны выходные данные команды, указывающие, что входящая репликация из CONTOSO-DC2 в CONTOSO-DC1 завершилась сбоем и сообщение об отказе в доступе к репликации.

Default-First-Site-NameCONTOSO-DC1
Параметры DSA: IS_GC
Параметры сайта: (нет)
GUID объекта DSA: b6dc8589-7e00-4a5d-b688-045aef63ec01
DSA invocationID: b6dc8589-7e00-4a5d-b688-045aef63ec01
==== INBOUND NEIGHBORS ===========================================
DC=contoso,DC=com
Default-First-Site-NameCONTOSO-DC2 через RPC
GUID объекта DSA: 74fbe06c-932c-46b5-831b-af9e31f496b2
Сбой последней попытки @ <> и время, результат 8451 (0x2103):
При выполнении операции репликации произошла ошибка базы данных.
последовательные сбои.
Last success @ .

Просмотр событий содержит одно или несколько событий, ссылающееся на ошибку 8451. В следующей таблице перечислены источники событий и идентификаторы распространенных событий, которые ссылаются на ошибку 8451 (в порядке источника и идентификатора события).

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

При запуске служебной Dcdiag.exe она создает выходные данные, которые выглядят следующим образом:

* Проверка репликации
[Проверка репликацией, домена] Не удалось выполнить последнюю попытку репликации:
Из исходного в конечный
Контекст именования:
При репликации произошла ошибка (8451):
При выполнении операции репликации произошла ошибка базы данных.

Если щелкнуть правой кнопкой мыши объект подключения исходного контроллера домена и выбрать «Реплицировать сейчас», команда завершится ошибкой и создаст сообщение, похожее на следующее:

При попытке синхронизировать >
«Операция репликации обнаружила ошибку базы данных».
Операция не будет продолжена.

Декодирование кодов ошибок

С помощью Microsoft Exchange Server кода ошибки можно декодировать коды ошибок, описанные в этой статье. Декодирование кодов ошибок, связанных с ошибкой 8451 и сопутствующими ошибками, дает следующие сведения:

C:>err 8451
для десятичных знаков 8451 / шестнадцатеричных 0x2103:
ERROR_DS_DRA_DB_ERROR winerror.h
При выполнении операции репликации произошла ошибка базы данных.
Найдено 2 совпадения для «8451»

C:>err -1414
для десятичных знаков -1414 /шестнадцатеричные 0xfffffa7a:
JET_errSecondaryIndexCorrupted esent98.h
/Вторичный индекс поврежден. Необходимо дефрагментация базы данных/
Найдено 1 совпадения для «-1414»

C:>err -1526
для десятичных знаков -1526 /шестнадцатеричные 0xfffffa0a:
JET_errLVCorrupted esent98.h
/Повреждение в дереве длинных значений/
Найдено 1 совпадения для «-1526»

C:>err -1603
для десятичных знаков -1603 /шестнадцатеричные 0xfffff9bd:
JET_errNoCurrentRecord esent98.h
/Валюта не в записи/
Найдено 1 совпадения для «-1603»

C:>err -1075
для десятичных знаков –1075 /шестнадцатеричные 0xfffffbcd:
JET_errOutOfLongValueIDs esent98.h
/Счетчик идентификаторов длинных значений достиг максимального значения. (выполните автономную дефрагментацию для освобождения свободного или неиспользуемого
LongValueIDs)/
Найдено 1 совпадения для «-1075»

C:>err -1601
для десятичных знаков -1601 /шестнадцатеричные 0xfffff9bf:
JET_errRecordNotFound esent98.h
/Ключ не найден/
Найдено 1 совпадения для «-1601»

C:>err -1047
для десятичных знаков -1047 /шестнадцатеричные 0xfffffbe9:
JET_errInvalidBufferSize esent98.h
/Буфер данных не соответствует размеру столбца/
Найдено 1 совпадения для «-1047»

C:>err -1018
для десятичных знаков -1018/ шестнадцатеричных 0xfffffc06:
JET_errReadVerifyFailure ese.h
/Ошибка контрольной суммы на странице базы данных/
JET_errReadVerifyFailure esent98.h
/* Ошибка контрольной суммы на странице базы данных */
Найдено 2 совпадения для «-1018»

C:>err -1206
для десятичных знаков -1206 /шестнадцатеричные 0xfffffb4a:
JET_errDatabaseCorrupted esent98.h
/Не файл базы данных или поврежденная база данных/
Найдено 1 совпадения для «-1206»

Причина

Состояние 8451: «Операция репликации обнаружила ошибку базы данных» имеет несколько основных причин, включая следующие:

• Возможно, база данных Active Directory или индекс базы данных Active Directory повреждены. Это может быть вызвано следующими причинами:
  • Оборудование, завершившегося сбоем:
    • Диск
    • Контроллер
    • Кэш контроллера
  • Устаревшие драйверы:
    • Контроллер
  • Устаревшее встроенное ПО:
    • BIOS компьютера
    • Контроллер
    • Диск
  • Внезапное отключение питания.
  • Устаревшие объекты.
  • Счетчик идентификаторов длинных значений достиг максимального значения:
    • Типы столбцов ESE называются JET_coltypLongText JET_coltypLongBinary типами столбцов длинных значений. Эти столбцы являются большими строками и большими двоичными объектами, которые могут храниться в отдельных деревьях B+ вне основного индекса. Если длинные значения хранятся отдельно от основной записи, они имеют внутренний ключ с идентификатором длинного значения (СЛВ).
  • Недопустимый дескриптор безопасности в атрибуте msExchSecurityDescriptor .

Решение

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

Устранение одного вхождения проблемы

Если ошибка возникает только на одном контроллере домена и представляет собой изолированную проблему, лучше всего и быстрее всего выполнить автономную дефрагментацию базы данных на затронутом сервере. Сведения о том, как это сделать, см. в разделе «Выполнение автономной дефрагментации базы данных Active Directory».

Если автономная дефрагментация не исправит проблему, понизьте ее, а затем повторно создайте затронутый контроллер домена. Сведения о том, как это сделать, см. в разделе «Понижение уровня контроллеров домена и доменов».

Устранение повторяющейся проблемы

Если проблема повторится, соберите некоторые диагностические данные.

Включите ведение журнала диагностики NTDS для событий репликации и внутренней обработки на уровне 5.

Чтобы увеличить ведение журнала диагностики NTDS, измените следующие REG_DWORD в реестре целевого контроллера домена в следующем подразделе реестра:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSDiagnostics

Задайте для следующих записей значение 5:

• События репликации
• Внутренняя обработка

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

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

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

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

Если все эти методы завершались сбоем, восстановите контроллер домена из резервной копии или понизите его, а затем повторно отключите.

Дополнительные сведения

Проверьте стек вертикальной базы данных jet снизу вверх (переход к следующему стеку только после того, как базовый слой будет оценок как «хороший»), так же, как и для TCP.

Источник

Adblock
detector

Hello everyone, I am having some replication issues on my domain that I would like to verify before I take the appropriate steps listed in the Microsoft Tech articles. I am running in a 2 DC network both running 2008 R2 both are Global Catalog Servers.  I
am having a tough time deciding on which DC I should take down and make the appropriate fixes / changes to. For the purpose of this question I will name my DC’s DC-01 and DC-02.  On DC-01 Checking the error logs I am receiving 3 separate Event ID error
467 — Database Corruption.  On DC-02 I am receiving the Event ID 1084 Error Value: 8451 indication database error, it does keep showing one specific object that for some reason I cannot seem to remove manually. I have attempted to perform a remove lingering
objects which receives an error.  Below is the logs from my attempt to remove the lingering object and my repadmin /showrepl logs. Replication from DC-01 to DC-02 is not working, but replication from DC-02 to DC-01 is. My questions is should I take down
DC-01 and perform the database integrity  / fixes or DC-02? Also any other steps anyone can suggest where I may not need to take down the service on my DC’s would be appreciated, the staff around here is VERY weary when it comes to any of our machines
having any downtime. Thank you!

When I attempt to run a repadmin /removelingeringobjects I receive a : (this don’t work if i change these around either)

repadmin /removelingeringobjects af01e71d-2516-42ca-8560-6c4f643c5b51 64af9410-df22-4b7e-8da3-942cdfce5a92 CN=Deleted Objects,DC=contoso,DC=com

DsBindWithCred to af01e71d-2516-42ca-8560-6c4f643c5b51 failed with status 1722 (0x6ba):
    The RPC server is unavailable.

Here are the repadmin /showrepl errors I am receiving. 

PS C:Windowssystem32> repadmin /showrepl contoso-dc02

Default-First-SiteCONTOSO-DC02

DSA Options: IS_GC

Site Options: (none)

DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

DSA invocationID: 37ea7e96-ac79-4c52-8578-22c0a9fe5d48

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 13:24:12 failed, result 8451 (0x2103):

            The replication operation encountered a database error.

        49006 consecutive failure(s).

        Last success @ 2014-09-05 13:27:52.

CN=Configuration,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 13:20:52 was successful.

CN=Schema,CN=Configuration,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 12:49:02 was successful.

DC=DomainDnsZones,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 13:10:32 failed, result 8614 (0x21a6):

            The directory service cannot replicate with this server because the time since the last replication with thi

s server has exceeded the tombstone lifetime.

        22848 consecutive failure(s).

        Last success @ 2014-03-10 06:08:45.

DC=ForestDnsZones,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 12:49:02 was successful.

Source: Default-First-SiteCONTOSO-DC01

******* 48974 CONSECUTIVE FAILURES since 2014-09-05 13:27:52

Last error: 8451 (0x2103):

            The replication operation encountered a database error.

_____________________________________________________________________________________________________

PS C:Windowssystem32> repadmin /showrepl contoso-dc01

Default-First-SiteCONTOSO-DC01

DSA Options: IS_GC

Site Options: (none)

DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

DSA invocationID: 4700c518-bbe6-46d3-8245-aa7c23798241

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 13:24:46 was successful.

CN=Configuration,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 13:19:14 was successful.

CN=Schema,CN=Configuration,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 12:45:26 was successful.

DC=DomainDnsZones,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 12:45:26 failed, result 8614 (0x21a6):

            The directory service cannot replicate with this server because the time since the last replication with thi

s server has exceeded the tombstone lifetime.

        1887 consecutive failure(s).

        Last success @ 2014-07-11 07:58:30.

DC=ForestDnsZones,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 12:45:26 was successful.

Source: Default-First-SiteCONTOSO-DC02

******* 1887 CONSECUTIVE FAILURES since 2014-07-11 07:58:30

Last error: 8614 (0x21a6):

            The directory service cannot replicate with this server because the time since the last replication with thi

s server has exceeded the tombstone lifetime.

Hello everyone, I am having some replication issues on my domain that I would like to verify before I take the appropriate steps listed in the Microsoft Tech articles. I am running in a 2 DC network both running 2008 R2 both are Global Catalog Servers.  I
am having a tough time deciding on which DC I should take down and make the appropriate fixes / changes to. For the purpose of this question I will name my DC’s DC-01 and DC-02.  On DC-01 Checking the error logs I am receiving 3 separate Event ID error
467 — Database Corruption.  On DC-02 I am receiving the Event ID 1084 Error Value: 8451 indication database error, it does keep showing one specific object that for some reason I cannot seem to remove manually. I have attempted to perform a remove lingering
objects which receives an error.  Below is the logs from my attempt to remove the lingering object and my repadmin /showrepl logs. Replication from DC-01 to DC-02 is not working, but replication from DC-02 to DC-01 is. My questions is should I take down
DC-01 and perform the database integrity  / fixes or DC-02? Also any other steps anyone can suggest where I may not need to take down the service on my DC’s would be appreciated, the staff around here is VERY weary when it comes to any of our machines
having any downtime. Thank you!

When I attempt to run a repadmin /removelingeringobjects I receive a : (this don’t work if i change these around either)

repadmin /removelingeringobjects af01e71d-2516-42ca-8560-6c4f643c5b51 64af9410-df22-4b7e-8da3-942cdfce5a92 CN=Deleted Objects,DC=contoso,DC=com

DsBindWithCred to af01e71d-2516-42ca-8560-6c4f643c5b51 failed with status 1722 (0x6ba):
    The RPC server is unavailable.

Here are the repadmin /showrepl errors I am receiving. 

PS C:Windowssystem32> repadmin /showrepl contoso-dc02

Default-First-SiteCONTOSO-DC02

DSA Options: IS_GC

Site Options: (none)

DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

DSA invocationID: 37ea7e96-ac79-4c52-8578-22c0a9fe5d48

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 13:24:12 failed, result 8451 (0x2103):

            The replication operation encountered a database error.

        49006 consecutive failure(s).

        Last success @ 2014-09-05 13:27:52.

CN=Configuration,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 13:20:52 was successful.

CN=Schema,CN=Configuration,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 12:49:02 was successful.

DC=DomainDnsZones,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 13:10:32 failed, result 8614 (0x21a6):

            The directory service cannot replicate with this server because the time since the last replication with thi

s server has exceeded the tombstone lifetime.

        22848 consecutive failure(s).

        Last success @ 2014-03-10 06:08:45.

DC=ForestDnsZones,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC01 via RPC

        DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

        Last attempt @ 2014-09-16 12:49:02 was successful.

Source: Default-First-SiteCONTOSO-DC01

******* 48974 CONSECUTIVE FAILURES since 2014-09-05 13:27:52

Last error: 8451 (0x2103):

            The replication operation encountered a database error.

_____________________________________________________________________________________________________

PS C:Windowssystem32> repadmin /showrepl contoso-dc01

Default-First-SiteCONTOSO-DC01

DSA Options: IS_GC

Site Options: (none)

DSA object GUID: 64af9410-df22-4b7e-8da3-942cdfce5a92

DSA invocationID: 4700c518-bbe6-46d3-8245-aa7c23798241

==== INBOUND NEIGHBORS ======================================

DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 13:24:46 was successful.

CN=Configuration,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 13:19:14 was successful.

CN=Schema,CN=Configuration,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 12:45:26 was successful.

DC=DomainDnsZones,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 12:45:26 failed, result 8614 (0x21a6):

            The directory service cannot replicate with this server because the time since the last replication with thi

s server has exceeded the tombstone lifetime.

        1887 consecutive failure(s).

        Last success @ 2014-07-11 07:58:30.

DC=ForestDnsZones,DC=contoso,DC=com

    Default-First-SiteCONTOSO-DC02 via RPC

        DSA object GUID: af01e71d-2516-42ca-8560-6c4f643c5b51

        Last attempt @ 2014-09-16 12:45:26 was successful.

Source: Default-First-SiteCONTOSO-DC02

******* 1887 CONSECUTIVE FAILURES since 2014-07-11 07:58:30

Last error: 8614 (0x21a6):

            The directory service cannot replicate with this server because the time since the last replication with thi

s server has exceeded the tombstone lifetime.

Один из механизмов Active Directory (AD), с которым могут быть связаны всевозможные затруднения, это репликация. Репликация – критически важный процесс в работе одного или более доменов или контроллеров домена (DC), и не важно, находятся они на одном сайте или на разных. Неполадки с репликацией могут привести к проблемам с аутентификацией и доступом к сетевым ресурсам. Обновления объектов AD реплицируются на контроллеры домена, чтобы все разделы были синхронизированы. В крупных компаниях использование большого количества доменов и сайтов – обычное дело. Репликация должна происходить внутри локального сайта, так же как дополнительные сайты должны сохранять данные домена и леса между всеми DC.

В этой статье речь пойдет о методах выявления проблем с репликацией в AD. Кроме того, я покажу, как находить и устранять неисправности и работать с четырьмя наиболее распространенными ошибками репликации AD:

• Error 2146893022 (главное конечное имя неверно);
• Error 1908 (не удалось найти контроллер домена);
• Error 8606 (недостаточно атрибутов для создания объекта);
• Error 8453 (доступ к репликации отвергнут).

Вы также узнаете, как анализировать метаданные репликации с помощью таких инструментов, как AD Replication Status Tool, встроенная утилита командной строки RepAdmin.exe и Windows PowerShell.

Для всестороннего рассмотрения я буду использовать лес Contoso, который показан на рисунке. В таблице 1 перечислены роли, IP-адреса и настройки DNS-клиента для компьютеров данного леса.

Рисунок. Архитектура леса

Для обнаружения неполадок с репликацией AD запустите AD Replication Status Tool на рабочей станции администратора в корневом домене леса. Например, вы открываете этот инструмент из системы Win8Client, а затем нажимаете кнопку Refresh Replication Status для уверенности в четкой коммуникации со всеми контроллерами домена. В таблице Discovery Missing Domain Controllers на странице Configuration/Scope Settings инструмента можно увидеть два недостающих контроллера домена, как показано на экране 1.

Экран 1. Два недостающих контроллера домена

В таблице Replication Status Collection Details вы можете проследить статус репликации контроллеров домена, которые никуда не пропадали, как показано на экране 2.

Экран 2. Статус репликации контроллеров домена

Пройдя на страницу Replication Status Viewer, вы обнаружите некоторые ошибки в репликации. На экране 3 видно, что возникает немалое число ошибок репликации, возникающих в лесу Contoso. Из пяти контроллеров домена два не могут видеть другие DC, а это означает, что репликация не будет происходить на контроллерах домена, которые не видны. Таким образом, пользователи, подключающиеся к дочерним DC, не будут иметь доступ к самой последней информации, что может привести к проблемам.

Экран 3. Ошибки репликации, возникающие в лесу Contoso

Поскольку ошибки репликации все же возникают, полезно задействовать утилиту командной строки RepAdmin.exe, которая помогает получить отчет о состоянии репликации по всему лесу. Чтобы создать файл, запустите следующую команду из Cmd.exe:

Repadmin /showrel * /csv > ShowRepl.csv

Проблема с двумя DC осталась, соответственно вы увидите два вхождения LDAP error 81 (Server Down) Win32 Err 58 на экране, когда будет выполняться команда. Мы разберемся с этими ошибками чуть позже. А теперь откройте ShowRepl.csv в Excel и выполните следующие шаги:

1. Из меню Home щелкните Format as table и выберите один из стилей.
2. Удерживая нажатой клавишу Ctrl, щелкните столбцы A (Showrepl_COLUMNS) и G (Transport Type). Правой кнопкой мыши щелкните в этих столбцах и выберите Hide.
3. Уменьшите ширину остальных столбцов так, чтобы был виден столбец K (Last Failure Status).
4. Для столбца I (Last Failure Time) нажмите стрелку вниз и отмените выбор 0.
5. Посмотрите на дату в столбце J (Last Success Time). Это последнее время успешной репликации.
6. Посмотрите на ошибки в столбце K (Last Failure Status). Вы увидите те же ошибки, что и в AD Replication Status Tool.

Таким же образом вы можете запустить средство RepAdmin.exe из PowerShell. Для этого сделайте следующее:

1. Перейдите к приглашению PowerShell и введите команду

Repadmin /showrepl * /csv | ConvertFrom-Csv | Out-GridView

2. В появившейся сетке выберите Add Criteria, затем Last Failure Status и нажмите Add.

3. Выберите подчеркнутое слово голубого цвета contains в фильтре и укажите does not equal.

4. Как показано на экране 4, введите 0 в поле, так, чтобы отфильтровывалось все со значением 0 (успех) и отображались только ошибки.

Экран 4. Задание фильтра

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

Исправление ошибки AD Replication Error -2146893022

Итак, начнем с устранения ошибки -2146893022, возникающей между DC2 и DC1. Из DC1 запустите команду Repadmin для проверки статуса репликации DC2:

Repadmin /showrepl dc2

На экране 5 показаны результаты, свидетельствующие о том, что репликация перестала выполняться, поскольку возникла проблема с DC2: целевое основное имя неверно. Тем не менее, описание ошибки может указать ложный путь, поэтому приготовьтесь копать глубже.

Экран 5. Проблема с DC2 — целевое основное имя неверно

Во-первых, следует определить, есть ли базовое подключение LDAP между системами. Для этого запустите следующую команду из DC2:

Repadmin /bind DC1

На экране 5 видно, что вы получаете сообщение об ошибке LDAP. Далее попробуйте инициировать репликацию AD с DC2 на DC1:

Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»

И на этот раз отображается та же ошибка с главным именем, как показано на экране 5. Если открыть окно Event Viewer на DC2, вы увидите событие с Event ID 4 (см. экран 6).

Экран 6. Сообщение о событии с Event ID 4

Выделенный текст в событии указывает на причину ошибки. Это означает, что пароль учетной записи компьютера DC1 отличается от пароля, который хранится в AD для DC1 в Центре распределения ключей – Key Distribution Center (KDC), который в данном случае запущен на DC2. Значит, следующая наша задача – определить, соответствует ли пароль учетной записи компьютера DC1 тому, что хранится на DC2. В командной строке на DC1 введите две команды:

Repadmin /showobjmeta dc1 «cn=dc1,ou=domain controllers,

dc=root,dc=contoso,dc=com» > dc1objmeta1.txt

Repadmin /showobjmeta dc2 «cn=dc1,ou=domain controllers,

dc=root,dc=contoso,dc=com» > dc1objmeta2.txt

Далее откройте файлы dc1objmeta1.txt и dc1objmeta2.txt, которые были созданы, и посмотрите на различия версий для dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet и lmPwdHistory. В нашем случае файл dc1objmeta1.txt показывает версию 19, тогда как версия в файле dc1objmeta2.txt – 11. Таким образом, сравнивая эти два файла, мы видим, что DC2 содержит информацию о старом пароле для DC1. Операция Kerberos не удалась, потому что DC1 не смог расшифровать билет службы, представленный DC2.

KDC, запущенный на DC2, не может быть использован для Kerberos вместе с DC1, так как DC2 содержит информацию о старом пароле. Чтобы решить эту проблему, вы должны заставить DC2 использовать KDC на DC1, чтобы завершить репликацию. Для этого вам, в первую очередь, необходимо остановить службу KDC на DC2:

Net stop kdc

Теперь требуется начать репликацию корневого раздела Root:

Repadmin /replicate dc2 dc1 «dc=root,dc=contoso,dc=com»

Следующим вашим шагом будет запуск двух команд Repadmin /showobjmeta снова, чтобы убедиться в том, что версии совпадают. Если все хорошо, вы можете перезапустить службу KDC:

Net start kdc

Обнаружение и устранение ошибки AD Replication Error 1908

Теперь, когда мы устранили ошибку -2146893022, давайте перейдем к ошибке репликации AD 1908, где DC1, DC2 и TRDC1 так и не удалось выполнить репликацию из ChildDC1. Решить проблему можно следующим образом. Используйте Nltest.exe для создания файла Netlogon.log, чтобы выявить причину ошибки 1908. Прежде всего, включите расширенную регистрацию на DC1, запустив команду:

Nltest /dbflag:2080fff

Теперь, когда расширенная регистрация включена, запустите репликацию между DC – так все ошибки будут зарегистрированы. Этот шаг поможет запустить три команды для воспроизведения ошибок. Итак, во-первых, запустите следующую команду на DC1:

Repadmin /replicate dc1 childdc1 dc=child,dc=root,
dc=contoso,dc=com

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

Экран 7. Репликация не состоялась, потому что DC домена не может быть найден

Во-вторых, из DC1 попробуйте определить местоположение KDC в домене child.root.contoso.com с помощью команды:

Nltest /dsgetdc:child /kdc

Результаты на экране 7 свидетельствуют, что такого домена нет. В-третьих, поскольку вы не можете найти KDC, попытайтесь установить связь с любым DC в дочернем домене, используя команду:

Nltest /dsgetdc:child

В очередной раз результаты говорят о том, что нет такого домена, как показано на экране 7.

Теперь, когда вы воспроизвели все ошибки, просмотрите файл Netlogon.log, созданный в папке C:Windowsdebug. Откройте его в «Блокноте» и найдите запись, которая начинается с DSGetDcName function called. Обратите внимание, что записей с таким вызовом будет несколько. Вам нужно найти запись, имеющую те же параметры, что вы указали в команде Nltest (Dom:child и Flags:KDC). Запись, которую вы ищете, будет выглядеть так:

DSGetDcName function called: client PID=2176,
Dom:child Acct:(null) Flags:KDC

Вы должны просмотреть начальную запись, равно как и последующие, в этом потоке. В таблице 2 представлен пример потока 3372. Из этой таблицы следует, что поиск DNS записи KDC SRV в дочернем домене был неудачным. Ошибка 1355 указывает, что заданный домен либо не существует, либо к нему невозможно подключиться.

Поскольку вы пытаетесь подключиться к Child.root.contoso.com, следующий ваш шаг – выполнить для него команду ping из DC1. Скорее всего, вы получите сообщение о том, что хост не найден. Информация из файла Netlogon.log и ping-тест указывают на возможные проблемы в делегировании DNS. Свои подозрения вы можете проверить, сделав тест делегирования DNS. Для этого выполните следующую команду на DC1:

Dcdiag /test:dns /dnsdelegation > Dnstest.txt

На экране 8 показан пример файла Dnstest.txt. Как вы можете заметить, это проблема DNS. Считается, что IP-адрес 192.168.10.1 – адрес для DC1.

Экран 8. Пример файла Dnstest.txt

Чтобы устранить проблему DNS, сделайте следующее:

1. На DC1 откройте консоль управления DNS.

2. Разверните Forward Lookup Zones, разверните root.contoso.com и выберите child.

3. Щелкните правой кнопкой мыши (как в родительской папке) на записи Name Server и выберите пункт Properties.

4. Выберите lamedc1.child.contoso.com и нажмите кнопку Remove.

5. Выберите Add, чтобы можно было добавить дочерний домен сервера DNS в настройки делегирования.

6. В окне Server fully qualified domain name (FQDN) введите правильный сервер childdc1.child.root.contoso.com.

7. В окне IP Addresses of this NS record введите правильный IP-адрес 192.168.10.11.

8. Дважды нажмите кнопку OK.

9. Выберите Yes в диалоговом окне, где спрашивается, хотите ли вы удалить связующую запись (glue record) lamedc1.child.contoso.com [192.168.10.1]. Glue record – это запись DNS для полномочного сервера доменных имен для делегированной зоны.

10. Используйте Nltest.exe для проверки, что вы можете найти KDC в дочернем домене. Примените опцию /force, чтобы кэш Netlogon не использовался:

Nltest /dsgetdc:child /kdc /force

11. Протестируйте репликацию AD из ChildDC1 на DC1 и DC2. Это можно сделать двумя способами. Один из них – выполнить команду

Repadmin /replicate dc1 childdc1 «dc=child,dc=root,
dc=contoso,dc=com»

Другой подход заключается в использовании оснастки Active Directory Sites и Services консоли Microsoft Management Console (MMC), в этом случае правой кнопкой мыши щелкните DC и выберите Replicate Now, как показано на экране 9. Вам нужно это сделать для DC1, DC2 и TRDC1.

Экран 9. Использование оснастки Active Directory Sites и?Services

После этого вы увидите диалоговое окно, как показано на экране 10. Не учитывайте его, нажмите OK. Я вкратце расскажу об этой ошибке.

Экран 10. Ошибка при репликации

Когда все шаги выполнены, вернитесь к AD Replication Status Tool и обновите статус репликации на уровне леса. Ошибки 1908 больше быть не должно. Ошибка, которую вы видите, это ошибка 8606 (недостаточно атрибутов для создания объекта), как отмечалось на экране 10. Это следующая трудность, которую нужно преодолеть.

Устранение ошибки AD Replication Error 8606

Устаревший объект (lingering object) – это объект, который присутствует на DC, но был удален на одном или нескольких других DC. Ошибка репликации AD 8606 и ошибка 1988 в событиях Directory Service – хорошие индикаторы устаревших объектов. Важно учитывать, что можно успешно завершить репликацию AD и не регистрировать ошибку с DC, содержащего устаревшие объекты, поскольку репликация основана на изменениях. Если объекты не изменяются, то реплицировать их не нужно. По этой причине, выполняя очистку устаревших объектов, вы допускаете, что они есть у всех DC (а не только DCs logging errors).

Чтобы устранить проблему, в первую очередь убедитесь в наличии ошибки, выполнив следующую команду Repadmin на DC1:

Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»

Вы увидите сообщение об ошибке, как показано на экране 11. Кроме того, вы увидите событие с кодом в Event Viewer DC1 (см. экран 12). Обратите внимание, что событие с кодом 1988 только дает отчет о первом устаревшем объекте, который вам вдруг встретился. Обычно таких объектов много.

Экран 11. Ошибка из-за наличия устаревшего объекта

Экран 12. Событие с кодом 1988

Вы должны скопировать три пункта из информации об ошибке 1988 в событиях: идентификатор globally unique identifier (GUID) устаревшего объекта, сервер-источник (source DC), а также уникальное, или различающееся, имя раздела – distinguished name (DN). Эта информация позволит определить, какой DC имеет данный объект.

Прежде всего, используйте GUID объекта (в данном случае 5ca6ebca-d34c-4f60-b79c-e8bd5af127d8) в следующей команде Repadmin, которая отправляет результаты в файл Objects.txt:

Repadmin /showobjmeta * «e8bd5af127d8>» > Objects.txt

Если вы откроете файл Objects.txt, то увидите, что любой DC, который возвращает метаданные репликации для данного объекта, содержит один или более устаревших объектов. DC, не имеющие копии этого объекта, сообщают статус 8439 (уникальное имя distinguished name, указанное для этой операции репликации, недействительно).

Затем вам нужно, используя GUID объект Directory System Agent (DSA) DC1, идентифицировать все устаревшие объекты в разделе Root на DC2. DSA предоставляет доступ к физическому хранилищу информации каталога, находящейся на жестком диске. В AD DSA – часть процесса Local Security Authority. Для этого выполните команду:

Repadmin /showrepl DC1 > Showrepl.txt

В Showrepl.txt GUID объект DSA DC1 появляется вверху файла и выглядит следующим образом:

DSA object GUID: 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e

Ориентируясь на эту информацию, вы можете применить следующую команду, чтобы удостовериться в существовании устаревших объектов на DC2, сравнив его копию раздела Root с разделом Root DC1.

Repadmin /removelingeringobjects DC2 70ff33ce-2f41-4bf4-
b7ca-7fa71d4ca13e «dc=root,dc=contoso,dc=com»
/Advisory_mode

Далее вы можете просмотреть журнал регистрации событий Directory Service на DC2, чтобы узнать, есть ли еще какие-нибудь устаревшие объекты. Если да, то о каждом будет сообщаться в записи события 1946. Общее число устаревших объектов для проверенного раздела будет отмечено в записи события 1942.

Вы можете удалить устаревшие объекты несколькими способами. Предпочтительно использовать ReplDiag.exe. В качестве альтернативы вы можете выбрать RepAdmin.exe.

Используем ReplDiag.exe. С вашей рабочей станции администратора в корневом домене леса, а в нашем случае это Win8Client, вы должны выполнить следующие команды:

Repldiag /removelingeringobjects
Repadmin /replicate dc1 dc2 «dc=root,dc=contoso,dc=com»

Первая команда удаляет объекты. Вторая команда служит для проверки успешного завершения репликации (иными словами, ошибка 8606 больше не регистрируется). Возвращая команды Repadmin /showobjmeta, вы можете убедиться в том, что объект был удален из всех, что объект был удален DC. Если у вас есть контроллер только для чтения read-only domain controller (RODC) и он содержал данный устаревший объект, вы заметите, что он все еще там находится. Дело в том, что текущая версия ReplDiag.exe не удаляет объекты из RODC. Для очистки RODC (в нашем случае, ChildDC2) выполните команду:

Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«dc=root,dc=contoso,dc=com» /Advisory_mode

После этого просмотрите журнал событий Directory Service на ChildDC2 и найдите событие с кодом 1939. На экране 13 вы видите уведомление о том, что устаревшие объекты были удалены.

Экран 13. Сообщение об удалении устаревших объектов

Используем RepAdmin.exe. Другой способ, позволяющий удалить устаревшие объекты – прибегнуть к помощи RepAdmin.exe. Сначала вы должны удалить устаревшие объекты главных контроллеров домена (reference DC) с помощью кода, который видите в листинге 1. После этого необходимо удалить устаревшие объекты из всех остальных контроллеров домена (устаревшие объекты могут быть показаны или на них могут обнаружиться ссылки на нескольких контроллерах домена, поэтому убедитесь, что вы удалили их все). Необходимые для этой цели команды приведены в листинге 2.

Как видите, использовать ReplDiag.exe гораздо проще, чем RepAdmin.exe, поскольку вводить команд вам придется намного меньше. Ведь чем больше команд, тем больше шансов сделать опечатку, пропустить команду или допустить ошибку в командной строке.

Устранение ошибки AD Replication Error 8453

Предыдущие ошибки репликации AD были связаны с невозможностью найти другие контроллеры домена. Ошибка репликации AD с кодом состояния 8453 возникает, когда контроллер домена видит другие DC, но не может установить с ними связи репликации.

Например, предположим, что ChildDC2 (RODC) в дочернем домене не уведомляет о себе как о сервере глобального каталога – Global Catalog (GC). Для получения статуса ChildDC2 запустите следующие команды на ChildDC2:

Repadmin /showrepl childdc2 > Repl.txt

Данная команда отправляет результаты Repl.txt. Если вы откроете этот текстовый файл, то увидите вверху следующее:

BoulderChildDC2
DSA Options: IS_GC DISABLE_OUTBOUND_REPL IS_RODC
WARNING: Not advertising as a global catalog

Если вы внимательно посмотрите на раздел Inbound Neighbors, то увидите, что раздел DC=treeroot,DC=fabrikam,DC=com отсутствует, потому что он не реплицируется. Взгляните на кнопку файла – вы увидите ошибку:

Source: BoulderTRDC1
******* 1 CONSECTUTIVE FAILURES since 2014-01-12 11:24:30
Last error: 8453 (0x2105):
Replication access was denied
Naming Context: DC=treeroot,DC=fabrikam,DC=com

Эта ошибка означает, что ChildDC2 не может добавить связь репликации (replication link) для раздела Treeroot. Как показано на экране 14, данная ошибка также записывается в журнал регистрации событий Directory Services на ChildDC2 как событие с кодом 1926.

Экран 14. Отсутствие связи репликации

Здесь вам нужно проверить, нет ли проблем, связанных с безопасностью. Для этого используйте DCDiag.exe:

Dcdiag /test:checksecurityerror

На экране 15 показан фрагмент вывода DCDiag.exe.

Экран 15. Фрагмент вывода DCDiag.exe

Как видите, вы получаете ошибку 8453, потому что группа безопасности Enterprise Read-Only Domain Controllers не имеет разрешения Replicating Directory Changes.

Чтобы решить проблему, вам нужно добавить отсутствующую запись контроля доступа – missing access control entry (ACE) в раздел Treeroot. В этом вам помогут следующие шаги:

1. На TRDC1 откройте оснастку ADSI Edit.

2. Правой кнопкой мыши щелкните DC=treeroot,DC=fabrikam,DC=com и выберите Properties.

3. Выберите вкладку Security.

4. Посмотрите разрешения на этот раздел. Отметьте, что нет записей для группы безопасности Enterprise Read-Only Domain Controllers.

5. Нажмите Add.

6. В окне Enter the object names to select наберите ROOTEnterprise Read-Only Domain Controllers.

7. Нажмите кнопку Check Names, затем выберите OK, если указатель объектов (object picker) разрешает имя.

8. В диалоговом окне Permissions для Enterprise Read-Only Domain Controllers снимите флажки Allow для следующих разрешений

*Read

*Read domain password & lockout policies («Чтение политики блокировки и пароля домена»)

*Read Other domain parameters

9. Выберите флажок Allow для разрешения Replicating Directory Changes, как показано на экране 16. Нажмите OK.

10. Вручную запустите Knowledge Consistency Checker (KCC), чтобы немедленно сделать перерасчет топологии входящей репликации на ChildDC2, выполнив команду

Repadmin /kcc childdc2

Экран 16. Включение разрешения Replicating Directory Change

Данная команда заставляет KCC на каждом целевом сервере DC незамедлительно делать перерасчет топологии входящей репликации, добавляя снова раздел Treeroot.

Состояние репликации критически важно

Репликация во всех отношениях в лесу AD имеет решающее значение. Следует регулярно проводить ее диагностику, чтобы изменения были видны всем контроллерам домена, иначе могут возникать различные проблемы, в том числе связанные с аутентификацией. Проблемы репликации нельзя обнаружить сразу. Поэтому если вы пренебрегаете мониторингом репликации (в крайнем случае, периодически делайте проверку), то рискуете столкнуться с трудностями в самый неподходящий момент. Моей задачей было показать вам, как проверять статус репликации, обнаруживать ошибки и в то же время как справиться с четырьмя типичными проблемами репликации AD.

REM Команды для удаления устаревших объектов
REM из раздела Configuration.
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«cn=configuration,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела ForestDNSZones.
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc1.child.
root.contoso.com 0b457f73-96a4-429b-ba81-
1a3e0f51c848 «dc=forestdnszones,dc=root,
dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела домена Root.
Repadmin /removelingeringobjects dc1.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела DomainDNSZones.
Repadmin /removelingeringobjects dc1.root.
contoso.com 3fe45b7f-e6b1-42b1-bcf4-2561c38cc3a6
«dc=root,dc=contoso,dc=com»

REM Команды для удаления устаревших объектов
REM из раздела Configuration.
Repadmin /removelingeringobjects dc1.root.
contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects dc2.root.
contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«cn=configuration,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects trdc1.treeroot.
fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«cn=configuration,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела ForestDNSZones.
Repadmin /removelingeringobjects dc1.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects dc2.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects trdc1.treeroot.
fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=forestdnszones,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела DomainDNSZones–Root.
Repadmin /removelingeringobjects dc2.child.root.
contoso.com 70ff33ce-2f41-4bf4-b7ca-7fa71d4ca13e
«dc=domaindnszones,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела домена Child.
Repadmin /removelingeringobjects dc1.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=child,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects dc2.root.contoso.
com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=child,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=child,dc=root,dc=contoso,dc=com»
Repadmin /removelingeringobjects trdc1.treeroot.
fabrikam.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=child,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела DomainDNSZones-Child.
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0c559ee4-0adc-42a7-8668-e34480f9e604
«dc=domaindnszones,dc=child,dc=root,dc=contoso,dc=com»
REM Команды для удаления устаревших объектов
REM из раздела домена TreeRoot.
Repadmin /removelingeringobjects childdc1.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»
Repadmin /removelingeringobjects childdc2.child.root.
contoso.com 0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»
Repadmin /removelingeringobjects dc1.root.contoso.com
0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»
Repadmin /removelingeringobjects dc2.root.contoso.com
0b457f73-96a4-429b-ba81-1a3e0f51c848
«dc=treeroot,dc=fabrikam,dc=com»

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

MySQL — это система управления реляционными базами данных, а также самая популярная реляционная база данных с открытым исходным кодом на сегодняшний день. Она поставляется с рядом уже встроенных функций репликации, позволяющих поддерживать несколько копий ваших данных. 

В этом руководстве мы настроим два сервера с MySQL: один в качестве исходной базы данных, «источника», а второй — в виде его «реплики». Также мы рассмотрим, как MySQL производит репликацию. 

Примечание: исторически сложилось, что этот тип репликации назывался «master-slave» («хозяин-раб», «мастер-слейв»). В посте, опубликованном в июле 2020 года, команда MySQL признала отрицательное происхождение этого термина и объявила о намерении обновить программу и сопутствующую документацию, чтобы использовать более инклюзивный язык. 

Тем не менее этот процесс завершён не до конца. Хотя документация и большая часть команд в 8 версии MySQL были обновлены так, чтобы ссылаться на серверы как «источник» и его «реплики», всё ещё остаются места со старой терминологией. По умолчанию в этом руководстве будут использоваться более современные термины и команды, но в некоторых случаях без понятий master и slave не обойтись. 

 Требования 

• Два сервера под управлением Ubuntu 20.04. На обоих должен быть административный непривилегированный пользователь с sudo правами и брандмауэр, настроенный с помощью утилиты UFW.

• MySQL, уже установленная на каждом сервере. В этом руководстве по умолчанию предполагается последняя версия MySQL, доступная из репозиториев Ubuntu. На момент написания руководства это 8.0.25.

Описанный здесь процесс включает назначение MySQL на одном сервере в качестве исходной базы данных, «источника», а затем настройку MySQL на другом сервере в качестве её копии, «реплики».

Также в этом руководстве есть дополнительные инструкции, как перенести данные в уже существующей базе из источника в реплику. Этот процесс включает создание копии (снапшота) исходной базы данных и перенос полученного файла в реплику. Для этого мы рекомендуем вам настроить SSH-ключи на исходном сервере, а затем убедиться, что открытый ключ источника был скопирован в реплику. 

Как работает репликация в MySQL 

В MySQL репликация заключается в записи базой-источником каждого изменения в данных одной или нескольких баз в специальный файл, известный как двоичный журнал или бинарный лог (binary log). После запуска реплики создаются два параллельных потока. Первый, называемый потоком ввода-вывода (IO thread), подключается к исходному экземпляру MySQL и построчно считывает события двоичного журнала, после чего копирует их в локальный файл на сервере реплики — журнал ретрансляции (relay log). Второй поток, называемый потоком SQL (SQL thread), считывает события из журнала ретрансляции и применяет их к реплике как можно быстрее. 

В последних версиях MySQL поддерживаются два метода репликации данных. Разница между ними заключается в том, как реплики отслеживают, какие события базы данных из источника они уже обработали. 

Традиционный метод репликации называется репликацией двоичного файла журнала на основе позиции. Если вы настроили реплику MySQL с помощью этого метода, вы должны предоставить ему набор координат из двоичного журнала. Они состоят из названия журнала в источнике, который реплика должна прочитать, и конкретной позиции в этом журнале. Эта позиция представляет собой первое событие в базе-источнике, которое реплика должна скопировать себе. 

Так как реплики получают копию всего двоичного журнала базы-источника, без правильных координат они начнут копировать каждое записанное в нём событие базы данных. Это может привести к проблемам, если вы хотите реплицировать данные только после определенного момента времени или продублировать только некоторое подмножество исходных данных. 

Репликация двоичного файла журнала на основе позиции подходит для многих случаев, но может стать неудобной в более сложных системах. Это привело к разработке нового метода репликации MySQL, который иногда называют репликацией на основе транзакций. Этот метод включает создание глобального идентификатора транзакции (GTID) для каждой транзакции — или изолированной части работы, выполняемой базой данных, — которую выполняет исходный экземпляр MySQL. 

Механизм такой репликации схож с репликацией на основе файла двоичного журнала: каждый раз, когда транзакция происходит в источнике, MySQL назначает и записывает для неё GTID в двоичный файл журнала вместе с самой транзакцией. Затем GTID и транзакция передаются репликам для обработки. 

Репликация на основе транзакций имеет ряд преимуществ по сравнению с традиционным методом. Например, и источник, и его реплики сохраняют GTID, поэтому если источник или реплика обнаруживают транзакцию с уже обработанным GTID, они её пропустят. Это помогает обеспечить согласованность между источником и его репликами. Кроме того, при репликации на основе транзакций репликам не нужно знать координаты двоичного журнала следующего события базы данных. Запуск новых реплик или изменение порядка реплик в цепочке репликации происходит намного проще. 

Имейте в виду, что это только общая теория того, как MySQL обрабатывает репликацию; MySQL предоставляет множество настроек, которые вы можете адаптировать под себя. В этом руководстве мы настраиваем репликацию двоичного файла журнала на основе позиции. Если же вы заинтересованы в настройке среды репликации другого типа, мы рекомендуем вам ознакомиться с официальной документацией MySQL. 

Ваши брандмауэры на обоих серверах должны быть настроены с помощью UFW. Это поможет защитить оба ваших сервера, однако теперь брандмауэр источника будет блокировать любые попытки подключения с реплики MySQL. 

Чтобы изменить это, вам необходимо включить новое правило в UFW, которое будет пропускать соединения с репликой через брандмауэр источника. Вы можете сделать это, выполнив следующую команду на исходном сервере. 

Эта команда разрешает любые соединения, исходящие от IP-адреса реплики — в примере это replica_server_ip — к дефолтному номеру порта MySQL, 3306: 

sudo ufw allow from replica_server_ip to any port 3306  

Не забудьте заменить replica_server_ip на фактический IP-адрес вашего сервера-реплики.

После этого вам не нужно что-либо менять в брандмауэре реплики, так как этот сервер не будет получать никаких входящих подключений, а исходящие подключения к исходному серверу MySQL не блокируются UFW. Теперь давайте перейдём к настройке источника. 

Шаг 2 — Настройка исходной базы данных для MySQL-репликации

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

В Ubuntu 20.04 файл конфигурации сервера MySQL по умолчанию называется mysqld.cnf и находится в директории /etc/mysql/mysql.conf.d/. Откройте этот файл на исходном сервере в любом текстовом редакторе. Здесь мы будем использовать nano: 

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf 

Найдите в файле директиву bind-address. По умолчанию она выглядит так: 

/etc/mysql/mysql.conf.d/mysqld.cnf 
...
bind-address        = 127.0.0.1 
...

127.0.0.1 — это адрес IPv4, представляющий localhost. Если указать это значение для директивы bind-address, то MySQL будет слушать соединения только по адресу localhost. Другими словами, этот экземпляр MySQL сможет принимать только соединения, исходящие от сервера, на котором он установлен. 

Не забывайте, что вы превращаете другой экземпляр MySQL в реплику этого, поэтому реплика должна иметь возможность читать все новые данные, записываемые в источник. Поэтому исходный сервер MySQL необходимо настроить так, чтобы он слушал соединения на адресе, доступном реплике, например, на публичном IP-адресе источника.

Замените 127.0.0.1 на IP-адрес исходного сервера. После этого директива bind-address будет выглядеть вот так, но с IP-адресом вашего сервера вместо source_server_ip: 

...
bind-address        = source_server_ip 
...

Затем найдите директиву server-id, определяющую идентификатор, с помощью которого MySQL различает серверы внутри системы репликации. Каждый сервер в системе, включая источник и все его реплики (мастера и все слейвы), должен иметь собственное уникальное значение server-id. По умолчанию эта директива закомментирована и выглядит так: 

/etc/mysql/mysql.conf.d/mysqld.cnf 
...
# server-id         = 1 
...

Раскомментируйте эту строку, удалив знак решетки (#). Вы можете выбрать любое число в качестве значения этой директивы, но помните, что номер должен быть уникальным и не может совпадать с другими server-id в вашей группе репликации. Для простоты в следующем примере это значение остаётся по умолчанию (1): 

/etc/mysql/mysql.conf.d/mysqld.cnf 
...
server-id         = 1 
...

Найдите директиву log_bin под строкой server-id. Она определяет имя и расположение двоичного журнала MySQL. 

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

/etc/mysql/mysql.conf.d/mysqld.cnf 
...
log_bin                   = /var/log/mysql/mysql-bin.log 
...

Наконец, прокрутите вниз до конца файла, чтобы найти закомментированную директиву binlog_do_db: 

/etc/mysql/mysql.conf.d/mysqld.cnf 
...
# binlog_do_db      = include_database_name

Удалите знак решетки, чтобы раскомментировать эту строку, и замените include_database_name именем базы данных, которую вы хотите дублировать. В этом примере показана директива binlog_do_db, указывающая на базу данных с именем db. Если у вас в источнике уже есть существующая база данных, которую вы хотите реплицировать, используйте ее имя вместо db: 

/etc/mysql/mysql.conf.d/mysqld.cnf 
...
binlog_do_db      = db  

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

/etc/mysql/mysql.conf.d/mysqld.cnf 
... 
binlog_do_db      = db 
binlog_do_db      = db_1 
binlog_do_db      = db_2

Либо же вы можете указать, какие базы данных MySQL не следует дублировать, добавив директиву binlog_ignore_db для каждой из них: 

/etc/mysql/mysql.conf.d/mysqld.cnf 
...
binlog_ignore_db      = db_to_ignore  
...

Внеся изменения, сохраните и закройте файл. Если вы использовали nano, сделайте это, нажав CTRL + X, Y, а затем ENTER.  

Перезапустите MySQL, выполнив следующую команду: 

sudo systemctl restart mysql  

Теперь этот экземпляр MySQL готов к работе в качестве исходной базы данных, которую ваш сервер MySQL будет реплицировать. Однако, прежде чем настраивать реплику, нам нужно провести еще несколько манипуляций с источником, чтобы обеспечить корректную работу репликации. Для начала нужно создать специальную учётную запись пользователя MySQL, который будет выполнять все действия, связанные с репликацией. 

Шаг 3 — Создание учётной записи пользователя для репликации MySQL

Каждая реплика в среде MySQL подключается к исходной базе данных с помощью имени пользователя и пароля. Реплики могут подключаться с использованием любого пользователя MySQL, который существует в исходной базе данных и имеет соответствующие права, но в этом руководстве для этой цели мы создадим специальную учётную запись. 

Начните с открытия оболочки MySQL: 

sudo mysql  

Примечание: если вы настроили учётную запись с аутентификацией по паролю, вы можете подключиться к MySQL с помощью следующей команды: 

mysql -u username -p  

Замените username именем своего пользователя и в нужный момент введите его пароль. 

Имейте в виду, что некоторые операции в этом руководстве, в том числе те, которые должны выполняться на сервере-реплике, требуют расширенных прав. Из-за этого может быть удобнее подключиться с правами администратора, как это можно сделать с помощью предыдущей команды sudo mysql. Если же вы хотите использовать пользователя MySQL с более ограниченными правами, ему как минимум должны быть предоставлены права CREATE USER, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE и REPLICATION_SLAVE_ADMIN. 

Создайте нового пользователя MySQL. В этом примере создается пользователь с именем replica_user, вы же можете вписать любое имя. Обязательно измените replica_server_ip на публичный IP-адрес сервера реплики и не забудьте задать более надёжный пароль вместо стоящего по умолчанию password: 

CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';  

Обратите внимание, что эта команда указывает, что replica_user будет использовать плагин mysql_native_password для аутентификации. Вместо этого можно использовать механизм, который стоит в MySQL по умолчанию — caching_sha2_password — но для этого потребуется установить зашифрованное соединение между источником и репликой. Такой тип может подходить для производственных сред, но настройка зашифрованных соединений выходит за рамки этого руководства. При желании вы можете найти инструкции по настройке среды репликации через зашифрованные соединения в документации MySQL. 

Создав нового пользователя, предоставьте ему соответствующие права. Как минимум, такой пользователь должен иметь разрешения REPLICATION SLAVE: 

GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';  

После этого рекомендуется запустить команду FLUSH PRIVILEGES. Это освободит всю память, кэшированную сервером для выполнения предыдущих операторов CREATE USER и GRANT: 

FLUSH PRIVILEGES;  

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

Шаг 4 — Получение координат двоичного журнала из базы-источника 

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

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

В командной строке открытой оболочки исходной MySQL выполните следующую команду. Она закроет все открытые таблицы в каждой базе данных в исходном экземпляре и заблокирует их: 

FLUSH TABLES WITH READ LOCK;

Затем выполните следующую операцию, которая выведет информацию о текущем состоянии двоичного журнала источника (мастера): 

SHOW MASTER STATUS;

С этой позиции реплика начнет копирование событий базы данных. Зафиксируйте (запомните или запишите) имя File и значение Position; они понадобятся вам позже, когда вы запустите репликацию. 

Ваши дальнейшие действия зависят от того, есть ли в исходной базе данных какие-либо данные, которые вы хотите перенести на свои реплики. Перейдите к подходящему вам подразделу. 

Если в вашем источнике нет данных для переноса 

Если вы только установили данную MySQL или в ней нет существующих данных, которые вы хотите перенести в слейв, на этом этапе вы можете разблокировать таблицы: 

UNLOCK TABLES; 

Вы можете создать базу данных для репликации master-slave, пока у вас еще открыта оболочка MySQL. Как в примере из шага 2, следующая команда создаст базу данных под именем db: 

CREATE DATABASE db; 

После этого закройте оболочку MySQL: 

exit  

Теперь вы можете перейти к следующему шагу. 

Если в вашем источнике есть данные для переноса 

Уже существующие данные из исходной базы данных в слейв можно перенести, создав снапшот (копию) базы данных с помощью утилиты mysqldump. Однако ваша база данных всё ещё заблокирована. Если вы сделаете какие-либо новые изменения в том же окне либо закроете его, она автоматически разблокируется, что может привести к проблемам. Разблокировка таблиц означает, что данные в базе могут быть изменены. Это потенциально может привести к несоответствию между вашей копией-снапшотом и координатами двоичного журнала, которые вы только что получили. 

Поэтому вы должны открыть новое окно или вкладку терминала на локальном компьютере. Так вы сможете создать снапшот базы данных без разблокировки MySQL. 

В новом окне или вкладке откройте еще один сеанс SSH на том сервере, где размещен исходный экземпляр MySQL: 

 ssh username@source_server_ip  

Затем из новой вкладки или окна экспортируйте свою базу данных с помощью mysqldump. В данном примере создается файл дампа с именем db.sql из базы с именем db. Убедитесь, что у вас стоит имя вашей собственной базы данных. Кроме того, не забудьте запустить эту команду в оболочке bash, а не в оболочке MySQL: 

 sudo mysqldump -u root db > db.sql  

Теперь вы можете закрыть это окно или вкладку и вернуться в начальное окно, где должна быть открыта оболочка MySQL. В командной строке MySQL разблокируйте базы данных, чтобы снова сделать их доступными для записи: 

UNLOCK TABLES;  

Выходите из оболочки MySQL: 

exit 

Теперь вы можете отправить снапшот на свой сервер-реплику. При условии, что вы уже настроили ключи SSH на исходном сервере и добавили открытый ключ источника в файл authorized_keys вашей реплики, вы можете защищённо отправить снапшот с помощью команды scp: 

scp db.sql username@replica_server_ip:/tmp/  

Не забудьте, что вам нужно заменить sammy именем административного профиля пользователя Ubuntu, созданного на сервере-реплике, а также сменить replica_server_ip на IP-адрес вашего сервера-реплики. Также обратите внимание, что эта команда помещает снапшот в директорию /tmp/ сервера-реплики. 

Отправив снапшот на сервер-реплику, подключитесь к нему по SSH: 

ssh username@replica_server_ip  

Откройте оболочку MySQL: 

sudo mysql

Создайте базу данных, которую будете копировать из источника: 

CREATE DATABASE db;  

Вам не нужно создавать таблицы или загружать в эту базу какие-либо образцы данных. Всё заполнится самостоятельно, когда вы импортируете базу данных, используя только что созданный снапшот. Вместо этого выйдите из оболочки MySQL: 

 exit  

Импортируйте снапшот: 

sudo mysql db < /tmp/db.sql  

Теперь ваша реплика master-slave содержит все существующие данные из исходной базы данных. Давайте перейдём к последнему шагу, чтобы настроить сервер-реплику на начало репликации. 

Шаг 5 — Настройка реплики 

Нам осталось только изменить конфигурацию реплики так же, как вы меняли исходную базу данных. Откройте файл конфигурации MySQL, mysqld.cnf, теперь уже на сервере-реплике: 

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Как упоминалось ранее, каждый экземпляр MySQL в среде должен иметь уникальное значение server-id. Найдите в реплике директиву server-id, раскомментируйте её и измените её значение на любое положительное целое число, отличающееся от значения исходной базы данных: 

/etc/mysql/mysql.conf.d/mysqld.cnf 
server-id           = 2  

После этого обновите значения log_bin и binlog_do_db, чтобы они соответствовали значениям, которые вы установили в файле конфигурации исходного сервера: 

/etc/mysql/mysql.conf.d/mysqld.cnf 
...
log_bin             = /var/log/mysql/mysql-bin.log 
...
binlog_do_db        = db 
...

Наконец, добавьте директиву relay-log, определяющую расположение файла журнала ретрансляции реплики. Включите данную строку в конец файла конфигурации: 

/etc/mysql/mysql.conf.d/mysqld.cnf 
...
relay-log           = /var/log/mysql/mysql-relay-bin.log

Внеся изменения, сохраните и закройте файл. Затем перезапустите MySQL на реплике, чтобы запустить новые настройки: 

sudo systemctl restart mysql  

После перезапуска службы mysql репликация будет готова к запуску. 

Шаг 6 — Запуск и тестирование репликации 

К данному моменту оба ваших экземпляра MySQL полностью настроены на начало репликации master-slave. Для её запуска откройте оболочку MySQL на сервере реплики: 

sudo mysql  

В командной строке выполните данную операцию; она настраивает несколько параметров репликации MySQL одновременно. Выполнив эту команду и запустив репликацию, сервер попытается подключиться к IP-адресу в SOURCE_HOST, используя логин и пароль (SOURCE_USER и SOURCE_PASSWORD, соответственно). Он также будет искать двоичный журнал с именем SOURCE_LOG_FILE, и начинать его чтение с позиции SOURCE_LOG_POS. 

Обязательно замените source_server_ip на IP-адрес исходного сервера. Аналогичным образом, replica_user и password должны соответствовать имени пользователя репликации, созданного вами на шаге 2; mysql-bin.000001 и 899 должны отражать координаты двоичного журнала, полученные на шаге 3. 

Вы можете ввести эту команду в текстовом редакторе, прежде чем запускать ее на сервере, так вам будет легче заменить всю нужную информацию: 

CHANGE REPLICATION SOURCE TO 
SOURCE_HOST='source_server_ip', 
SOURCE_USER='replica_user', 
SOURCE_PASSWORD='password', 
SOURCE_LOG_FILE='mysql-bin.000001', 
SOURCE_LOG_POS=899; 

Теперь активируйте сервер-реплику: 

START REPLICA;  

Если вы ввели все данные правильно, этот экземпляр начнёт репликацию всех изменений, внесенных в базу данных db в источнике. 

Все детали о текущем состоянии реплики можно получить следующей командой. Модификатор \G здесь перестраивает текст, делая его более читабельным: 

SHOW REPLICA STATUS\G; 

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

Примечание: если у реплики проблемы с подключением или репликация неожиданно останавливается, возможно, какое-то событие в двоичном журнале источника препятствует репликации. В таких случаях попробуйте запустить команду SET GLOBAL SQL_SLAVE_SKIP_COUNTER, чтобы пропустить некоторое количество событий, следующих за положением в двоичном журнале, определённым в предыдущей команде. Например, здесь пропускается только первое событие: 

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;  

После этого вам нужно будет перезапустить реплику: 

START REPLICA;  

Если же вам когда-нибудь будет нужно остановить репликацию, запустите данную команду на сервере-реплике: 

 STOP REPLICA;  

Теперь ваша реплика копирует данные из источника. Все изменения, внесенные в исходную базу данных, будут отражены в реплике экземпляра MySQL. Для теста давайте создадим проверочную таблицу и проверим успешность выполнения репликации. 

 Откройте оболочку MySQL на сервере-источнике: 

sudo mysql  

Выберите базу данных для репликации: 

USE db;  

Создайте в ней таблицу. В этом примере у нас таблица под названием example_table с одним столбцом example_column: 

CREATE TABLE example_table ( 
example_column varchar(30) 
); 

При желании можете добавить туда данных: 

INSERT INTO example_table VALUES 
('Первая строка'), 
('Вторая строка'), 
('Третья строка'); 

После этого вернитесь в оболочку MySQL вашего сервера-реплики и выберите копируемую базу данных: 

USE db;  

Затем запустите оператор SHOW TABLES, чтобы вывести список всех таблиц в выбранной базе данных: 

SHOW TABLES; 

Если репликация MySQL работает верно, вы увидите только что созданную таблицу в списке.

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

SELECT * FROM example_table; 

В SQL звёздочка (*) означает «все столбцы». По сути, этот запрос сообщает MySQL, что нужно вывести каждый столбец из example_table. Если репликация MySQL работает как надо, эта операция покажет эти данные.

Если ни одна из этих операций не вывела таблицу или данные из источника, возможно, у вас есть ошибка где-то в конфигурации. Чтобы найти проблему, вы можете попытаться запустить операцию SHOW REPLICA STATUS\G. Кроме того, вы можете обратиться к документации MySQL по устранению неполадок репликации. 

Заключение 

С помощью этого руководства мы настроили среду репликации MySQL на основе позиции в двоичном журнале с одним источником и одной репликой. Но помните, что это только один из способов настройки репликации в MySQL. В MySQL есть несколько различных вариантов синхронизации мастера и слейва, которые вы можете выбрать и настроить в соответствии с  вашими нуждами. Существует также ряд сторонних инструментов, к примеру Galera Cluster, которые можно использовать для расширения встроенных функций репликации MySQL на серверах https://timeweb.cloud.