7.3. Стратегия резервного копирования и восстановления в качестве примера

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

Команды в качестве примера не включают опции такой как --user и --password для mysqldump и mysql клиентских программ. Следует включать такие опции по мере необходимости, чтобы позволить клиентским программам соединиться с сервером MySQL.

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

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

InnoDB: Database was not shut down normally.InnoDB: Starting recovery from log files...InnoDB: Starting log scan based on checkpoint atInnoDB: log sequence number 0 13674004InnoDB: Doing recovery: scanned up to log sequence number 0 13739520InnoDB: Doing recovery: scanned up to log sequence number 0 13805056InnoDB: Doing recovery: scanned up to log sequence number 0 13870592InnoDB: Doing recovery: scanned up to log sequence number 0 13936128...InnoDB: Doing recovery: scanned up to log sequence number 0 20555264InnoDB: Doing recovery: scanned up to log sequence number 0 20620800InnoDB: Doing recovery: scanned up to log sequence number 0 20664692InnoDB: 1 uncommitted transaction(s) which must be rolled backInnoDB: Starting rollback of uncommitted transactionsInnoDB: Rolling back trx no 16745InnoDB: Rolling back of trx no 16745 completedInnoDB: Rollback of uncommitted transactions completedInnoDB: Starting an apply batch of log records to the database...InnoDB: Apply batch completedInnoDB: Startedmysqld: ready for connections

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