Windows: "Призраки" в Active Directory. Охота на Lingering Objects

Это один из самых коварных и трудноуловимых багов репликации AD.

Что это: "Зависший объект" (Lingering Object) — это объект (например, пользователь), который был удален на одном контроллере домена (DC), но остался на другом DC, который был в оффлайне дольше, чем "время жизни" удаленного объекта (Tombstone Lifetime, обычно 60-180 дней).

Чем опасно: Ваш HelpDesk не может создать пользователя с именем ivanov (потому что "призрак" ivanov еще существует на одном из DC), Exchange падает с ошибками, GPO не применяются.

Как найти и уничтожить "призраков":

1. Включить строгую проверку репликации (Strict Replication Consistency): Это обязательно на всех DC! Это не ищет, а предотвращает появление новых "призраков".
PowerShell

repadmin /regkey * +strict

2. Найти "призраков": Эта команда — ваш сканер. Ее нужно запустить на каждом DC, используя в качестве "эталона" самый авторитетный DC.
PowerShell

# Запускаем в режиме "Advisory Mode" (только отчет)
# DC-Source - это ваш "чистый" DC (например, владелец FSMO)
# DC-Dest - это DC, который мы проверяем на "призраков"
repadmin /removelingeringobjects DC-Dest.corp.local DC-Source.corp.local-GUID corp.local /ADVISORY_MODE

Проанализируйте dcdiag.log, который будет создан. Если там есть "lingering objects" — переходим к шагу 3.

3. Уничтожить (если найдены на шаге 2):
PowerShell

# Убираем /ADVISORY_MODE, чтобы запустить реальное удаление
repadmin /removelingeringobjects DC-Dest.corp.local DC-Source.corp.local-GUID corp.local

Взгляд архитектора: Архитектор не просто чинит. Он строит надежную топологию репликации. Проблема "призраков" — это симптом. Коренная причина — плохая связность, выключенные на месяц DC или неправильное восстановление из бэкапа. repadmin — ваш скальпель, но лечить нужно саму архитектуру.

#windows #activedirectory #ad #replication #powershell #security #гайд #architect

🎓 Собеседование сисадмина. Выпуск #6: Базы данных (Reliability & Scalability)

Привет, коллеги! Сегодня разберем три вопроса, которые проверяют твое понимание того, как данные «живут» на дисках и в сети.

❓ Вопрос 1: «Что такое репликация и в чем разница между Synchronous (Синхронной) и Asynchronous (Асинхронной) репликацией?»

❌ Ответ новичка: «Репликация — это когда данные копируются на другой сервер. Синхронная — это быстро, асинхронная — медленнее».
✅ Ответ инженера:

Репликация — это механизм синхронизации данных между Master (Writer) и Replica (Reader).
* Асинхронная: Мастер записывает данные и тут же подтверждает успех клиенту, не дожидаясь реплики.
* *Плюс:* Максимальная скорость.
* *Минус:* Риск потери данных при падении Мастера (те миллисекунды данных, что не успели улететь на реплику).

* Синхронная: Мастер ждет, пока реплика подтвердит получение данных, и только потом отвечает клиенту.
* *Плюс:* Гарантия сохранности данных.
* *Минус:* Если реплика «залагает» или упадет сеть — встанет и запись на Мастере.

❓ Вопрос 2: «Что такое индексы в БД, и почему нельзя просто навесить их на каждую колонку таблицы "на всякий случай"?»

❌ Ответ новичка: «Индексы нужны для ускорения поиска. Если их много, то всё будет летать».
✅ Ответ инженера:

Индекс — это отдельная структура (обычно B-Tree), которая позволяет не сканировать всю таблицу целиком.
* Проблема: Каждый индекс занимает место на диске. Но главное — любой индекс замедляет запись (INSERT/UPDATE). При каждом изменении данных базе приходится обновлять и все связанные с этой колонкой индексы.
* Вывод: Индексы нужно создавать только на те колонки, по которым реально идет частая фильтрация (WHERE) или сортировка (ORDER BY).

❓ Вопрос 3: «Как вы будете делать бэкап базы объемом в 1 ТБ, чтобы не "положить" сервис во время процесса?»

❌ Ответ новичка: «Сделаю mysqldump или pg_dump ночью, когда никто не пользуется».
✅ Ответ инженера:

Логический бэкап (dump) на терабайтной базе — это плохая идея. Он будет делаться вечно и создаст огромную нагрузку.
* Правильный путь: 1. Снапшоты на уровне ФС/LVM: Замораживаем ФС на секунду, делаем снапшот, размораживаем и спокойно копируем данные.
2. Физический бэкап: Инструменты вроде `pg_backrest` для PostgreSQL или `Percona XtraBackup` для MySQL. Они копируют сами файлы данных «на лету», не блокируя чтение и запись.
3. Бэкап с реплики: Самый надежный способ. Снимаем бэкап с репликационного сервера, чтобы вообще не нагружать основной Master-сервер.

💡 Золотое правило собеса: Если тебя спрашивают про базы, всегда упоминай мониторинг. Фраза «Я обязательно настрою алерты на Replication Lag (задержка репликации) и Disk Space» — это музыка для ушей любого тимлида.

Сохраняйте пост, чтобы не «поплыть», когда база скажет «ой»!

#собеседование_AF #database #mysql #postgresql #replication #backup #sysadmin #devops #admin_future