Лабораторная работа №11. Исправление убд после программных или аппаратных сбоев

Цель работы: приобрести практический навык восстановления или исправления содержимого удалённой базы данных после программного или аппаратного сбоя.

1. Теоретические сведения

Типы сбоев, приводящие к потере данных:

1. Сбой операционной системы

2. Отказы электропитания

3. Сбой файловой системы

4. Аппаратные сбои (жесткого диска, материнской платы...)

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

Для случаев 1 и 2 можем предположить, что диск с данными MySQL доступен после рестарта операционной системы. Во время рестарта непротиворечивость данных в файлах InnoDB из-за сбоя оказывается нарушенной, но InnoDB считывает свои протоколы, находит там список задержанных (чьи результаты не сброшены в файл) завершенных и незавершенных транзакций, автоматически откатывает незавершенные, и сбрасывает в файл результаты завершенных транзакций. Информация о процессе восстановления после сбоя передается пользователю через протокол ошибок MySQL. Извлечение из протокола:

InnoDB: Database was not shut down normally.

InnoDB: Starting recovery from log files...

InnoDB: Starting log scan based on checkpoint at

InnoDB: log sequence number 0 13674004

InnoDB: Doing recovery: scanned up to log sequence number 0 13739520

InnoDB: Doing recovery: scanned up to log sequence number 0 13805056

InnoDB: Doing recovery: scanned up to log sequence number 0 13870592

InnoDB: Doing recovery: scanned up to log sequence number 0 13936128

...

InnoDB: Doing recovery: scanned up to log sequence number 0 20555264

InnoDB: Doing recovery: scanned up to log sequence number 0 20620800

InnoDB: Doing recovery: scanned up to log sequence number 0 20664692

InnoDB: 1 uncommitted transaction(s) which must be rolled back

InnoDB: Starting rollback of uncommitted transactions

InnoDB: Rolling back trx no 16745

InnoDB: Rolling back of trx no 16745 completed

InnoDB: Rollback of uncommitted transactions completed

InnoDB: Starting an apply batch of log records to the database...

InnoDB: Apply batch completed

InnoDB: Started

mysqld: ready for connections

Для случаев 3 и 4 необходимо периодическое создание резервных копий (откатов). Полные откаты (моментальные снимки данных на определенный момент времени) создаются при помощи нескольких инструментальных средств MySQL. Горячий откат (Hot Backup) InnoDB обеспечивает онлайновый (не блокирующий) физический (копии файлов данных) откат. mysqldump обеспечивает онлайновый логический откат, который рассмотрим далее в ходе выполнения лабораторной работы. Пример:

mysqldump --single-transaction --all-databases > backup_sunday_1_PM.sql

Так создается откат всех InnoDB-таблиц из всех баз данных, не препятствующий выполнению текущих операций чтения/записи этих таблиц. Содержимое .sql-файла - это набор SQL-операторов INSERT. (Предположим, что это полный откат на 1 час дня воскресенья, когда загрузка сервера мала.)

Делать полные резервные копии необходимо, но не всегда удобно. Они порождают большие файлы отката и требуют времени. Они не оптимальны в том смысле, что снова сохраняют те данные, которые не менялись со времени создания предыдущего полного отката. Более оптимально делать откаты изменений (хотя, они экономят время отката за счет времени восстановления).

Чтобы делать откаты изменений, необходимо их фиксировать. Чтобы сервер сохранял информацию об изменениях в файле во время модификации данных, он должен быть запущен с опцией --log-bin. Тогда каждый SQL-оператор, модифицирующий данные, будет записан в файл (который называется "двоичным протоколом MySQL"). Посмотрим на содержимое директория данных сервера MySQL, работающего несколько дней в режиме --log-bin - увидим двоичные протоколы MySQL:

-rw-rw---- 1 guilhem guilhem 1277324 Nov 10 23:59 gbichot2-bin.001

-rw-rw---- 1 guilhem guilhem 4 Nov 10 23:59 gbichot2-bin.002

-rw-rw---- 1 guilhem guilhem 79 Nov 11 11:06 gbichot2-bin.003

-rw-rw---- 1 guilhem guilhem 508 Nov 11 11:08 gbichot2-bin.004

-rw-rw---- 1 guilhem guilhem 220047446 Nov 12 16:47 gbichot2-bin.005

-rw-rw---- 1 guilhem guilhem 998412 Nov 14 10:08 gbichot2-bin.006

-rw-rw---- 1 guilhem guilhem 361 Nov 14 10:07 gbichot2-bin.index

Каждый раз во время рестарта сервер MySQL прекращает запись в текущий файл двоичного протокола, создает новый и с этого момента новый файл станет текущим (тем, в который происходит запись). Такое переключение можно осуществить вручную по команде SQL FLUSH LOGS. .index-файл содержит список всех двоичных протоколов, сохраненных в директории (он используется для репликации).

Эти двоичные протоколы MySQL отражают изменения. Немного изменим поведение mysqldump, чтобы произошло переключение двоичного протокола в момент создания полной резервной копии; давайте посмотрим, какое имя присвоено новому текущему двоичному протоколу:

mysqldump --single-transaction --flush-logs --master-data=2 --all-databases > backup_sunday_1_PM.sql

Теперь мы видим в директории данных файл gbichot2-bin.007. Наш .sql-файл содержит строки:

-- Position to start replication or point-in-time recovery from

-- CHANGE MASTER TO MASTER_LOG_FILE='gbichot2-bin.007',MASTER_LOG_POS=4;

Это значит, что все модификации данных, отраженные в двоичных протоколах, более старых чем gbichot2-bin.007, присутствуют в .sql-файле, а все модификации данных, отраженные в файле gbichot2-bin.007 или более новых, отсутствуют в .sql-файле. В понедельник в 1 час дня мы, чтобы сделать откат изменений, всего лишь введем команду mysqladmin --flush-logs, которая создаст gbichot2-bin.008. Все изменения, сделанные между 1 часом дня воскресенья, когда был сделан полный откат, и 1 часом дня понедельника отражены в файле gbichot2-bin.007. Копируем этот драгоценный файл в место безопасного хранения резервных копий (на ленту, резервную машину, DVD-диск и т.д.).

Во вторник, в 1 час дня, снова выполним mysqladmin --flush-logs. Все изменения, сделанные между 1 часом дня понедельника и 1 часом дня вторника, отражены в файле gbichot2-bin.008. Копируем и его в место безопасного хранения.

Эти двоичные протоколы MySQL занимают дисковое пространство; время от времени его нужно освобождать. Хорошей идеей является удалять двоичные протоколы, которые уже никогда не понадобятся, т.е. после создания полной резервной копии:

mysqldump --single-transaction --flush-logs

--delete-master-logs --master-data=2

--all-databases

> backup_sunday_1_PM.sql