Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«ОМСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

Кафедра «Комплексная защиты информации»

Лабораторная работа

по курсу «Безопасность систем баз данных»

Лабораторная работа №5

Выполнили:

Студенты 2-го курса

Принял:

Самотуга А.Е.

Омск 2023

Рисунок 1. Начальная конфигурация

Рисунок 2 Диспетчер устройств

Рисунок 3. Создаем RAID5

Рисунок 4. Продолжение создания

Рисунок 5. Финальный этап создания

Рисунок 6. Перенесли файлы в массив

Рисунок 7. Диспетчер дисков после удаления 1 диска из массива

Рисунок 8. Восстановление массива с помощью нового диска

Рисунок 9. Процесс восстановления

Рисунок 10. После восстановления

Рисунок 11. Создаем RAID 0

Рисунок 12. Успешное создание

Рисунок 13. Перенесли файл в массив

Рисунок 14. Также создали Raid1

Рисунок 15. Перенесли файл в raid1

Рисунок 16. Удалили по 1 диску с каждого массива

Рисунок 17. Состояние массивов

Рисунок 18. Восстановить удалось лишь RAID1

Рисунок 19. Файл остался

Рисунок 20. Создали контейнер master

Рисунок 21.Проверили что создалась таблица world

Рисунок 22. Запустили контейнер slave и подлюкчили оба контейнера к общей сети

Рисунок 23. Созадли пользователя для репликации

Рисунок 24. На мастере добавили ид сервера и сделали бинарный лог

Рисунок 25. Проверка внесенных настроек

Рисунок 26. Заблокировали таблицы

Рисунок 27. Сделали дамп sql из контейнера в хост машину и разблокировали таблциы

Рисунок 28. Копировали дамп в контейнер слэйв

Рисунок 29. Добавили сервер ид и бинарный лог на слэйв

Рисунок 30. Изменили натстройки для репликации

Рисунок 31. Посмотрели работают ли внесенные изменения

Рисунок 32. Внесли данные на мастере

Рисунок 33. Проверили репликацию на слэйве

Вопросы

1)Задача репликации получает события из источника и переадресовывает их в целевой объект. Большинство задач репликации переадресовывают события без изменений и в лучшем случае выполняют сопоставление структур метаданных, если исходный и целевой протоколы различаются.

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

• 2) однонаправленная, асинхронная репликация, при которой один сервер является источником, а остальные - репликами. При этом, реплика тоже может быть источником. Именно эту схему репликации и рассмотрим (CHANGE MASTER TO...)

• синхронная репликация - такая конфигурация используется при работе NDB Cluster.

• полусинхронная (semisynchronous) репликация - commit транзакции будет подтвержден, только тогда, когда хотябы одна из реплик подтвердит, что событие получено и зафиксировано/логировано.

• репликация с задержкой (delayed) - между данными источника и репликой будет задержка, заданная администратором. Обычно используется для тестирования или для защиты от ошибок на мастере.