Реплика поддерживает другое размещение состояния. Пригодная резервная копия или сохранённая история нужны для возврата к более раннему состоянию, если ошибочное изменение уже распространилось.
Репликация данных
Определение
Репликация данных — это запись одних и тех же данных как минимум в двух отдельных местах, чтобы они существовали не в одном экземпляре. Режим репликации задаёт, нужно ли дождаться подтверждения от удалённой стороны до ответа об успешной записи.
Также ищут: Data replication · storage replication
Зачем это знать
Для выбора защиты нужны не только расстояние и режим, но и точное условие подтверждения, пригодная точка данных и безопасная передача права записи. Текущая копия может быть свежей и при этом уже содержать ошибочное изменение.
Карта понятия
Что подтверждено
NIST определяет репликацию данных как запись одинаковых данных как минимум в двух отдельных местах.
Граница применимости: Согласованность приложения и независимость площадок требуют отдельной проверки.
Синхронная репликация требует подтверждения заданного удалённого этапа до ответа об успешной записи. Асинхронная не включает это ожидание в условие ответа. Фактическое отставание измеряют отдельно: само его значение не определяет правило подтверждения.
Граница применимости: Сопоставление модели репликации NIST и режима ожидания PostgreSQL 18; порядок подтверждения и ожидаемый удалённый этап задаёт конкретная система.
Репликация без версий, журнала или неизменяемых точек восстановления не гарантирует возврат к состоянию до ошибочного изменения.
Граница применимости: Разграничение актуальной реплики и восстановления на выбранный момент времени.
Удалённое получение записи, её устойчивое сохранение и применение — разные этапы. В PostgreSQL 18 режим ожидания задаёт конкретный этап; перед обещанием нулевой потери при отказе проверяют именно его и уцелевшую копию, а не общее слово «синхронная».
Граница применимости: Вывод из модели репликации NIST и уровней ожидания PostgreSQL 18. Семантика другого хранилища проверяется по его документации; подтверждение получения не объявляется устойчивым сохранением при потере питания.
Для службы с единственным владельцем записи потеря связи не доказывает остановку прежнего владельца. Перед передачей записи другой стороне нужно подтвердить поддержанный механизм исключения конфликтующей записи; наличие копии данных само по себе этой гарантии не даёт.
Граница применимости: Редакторское правило для ресурса с одним писателем из репликации и изоляции узлов. Оно не запрещает специально спроектированные многопишущие системы; их правила согласованности рассматриваются отдельно.
- Рекомендация редакции
После выбора копии проверить доступ к ней, запуск зависимостей и нужную клиентскую операцию. Статус переноса данных не является результатом восстановления услуги.
Граница применимости: Разграничение механизма репликации и полного пути восстановления NIST. Свежесть состояния и рабочая услуга должны быть доказаны отдельно для выбранного сценария.
После работы на резервной стороне прежняя площадка может содержать устаревшее состояние. Возврат требует выбора актуальной копии, согласованного переноса изменений и проверки права записи; простое включение прежнего сервера этого не обеспечивает.
Граница применимости: Редакторский порядок возвращения к штатной работе из репликации и плана NIST. Конкретные команды и возможность обратного переноса определяет продукт; автоматическое объединение расходящихся записей не обещается.
Не путать
Режим репликации задаёт путь подтверждения, RPO — целевую потерю данных по времени. Итог проверяют по доступному состоянию после конкретного отказа, учитывая условия подтверждения и его устойчивость.
Что проверить
- Укажите правило ответа об успешной записи и ожидаемый удалённый этап.
- Проверьте сохранность подтверждённого состояния при выбранном отказе.
- Измеряйте фактическое отставание отдельно от названия режима.
- Определите владельца записи и его безопасную смену при потере связи.
- Сохраните пригодную историю для возврата до ошибочного изменения.
- Проверьте запуск услуги из выбранной копии через операцию клиента.
- Перед обратным переключением выберите актуальное состояние и путь его переноса.
Первоисточники
- PostgreSQL 18 Documentation: Log-Shipping Standby Servers
Фиксирует async default, synchronous commit wait points и связь replication delay с data loss.
- Backup — CSRC Glossary
Определяет backup как копию files и programs, созданную для recovery.
Утверждения: 03
- Pacemaker Explained
Прежняя точная пометка Pacemaker 3.0.1 снята после замечания редактора о непинованном URL. Фактически отдаваемая редакция и разделы требуют повторного открытия; новый номер и дата получения без документа не назначались.
Утверждения: 05
- Contingency Planning Guide for Federal Information Systems
Первичный planning guide по BIA, recovery strategies, RPO/RTO, contingency и disaster recovery plans.
- Recovery Point Objective — CSRC Glossary
Определяет RPO как точку во времени, до которой данные должны быть восстановлены после outage.