Администратор должен обязательно резервировать базы данных на случай повреждения или потери данных. Только благодаря резервированию все таблицы могут быть восстановлены до прежнего состояния в случае сбоя в работе системы. Кроме того, не исключен вариант, когда резервирование может оказаться единственным путем отступления, если какой-либо неопытный пользователь случайно выполнит операторы DROP database или drop table. Иногда сбой может произойти по вине собственно администратора MySQL. Так, автору этих лекций известны случаи, когда администраторы разрушали файлы таблиц, пытаясь изменить их с помощью таких редакторов, как vi или emacs. Это далеко не самый лучший способ отредактировать таблицы.
Существует два основных способа резервирования баз данных: использование программы mysqldump и непосредственное копирование файлов базы данных (с помощью команд ср, tar или cpio ). Каждый метод имеет свои преимущества и недостатки.
Программа mysqldump тесно взаимодействует с сервером MySQL. Методы непосредственного копирования являются внешними по отношению к серверу и требуют проверки, чтобы клиенты не пытались изменить таблицы баз данных в процессе копирования. Эта же проблема возникает при использовании для резервирования баз данных средств резервирования файловой системы. Если в процессе резервирования кто-то из пользователей изменяет таблицы, их файлы окажутся несовместимыми и не подлежащими восстановлению. Разница между резервированием файловой системы и непосредственным копированием файлов заключается в том, что в первом случае имеется возможность управлять расписанием резервирования.
Программа mysqldump медленней резервирует данные, чем методы непосредственного копирования.
Программа mysqldump создает простые текстовые файлы, которые можно легко переносить на другие компьютеры, даже с другой аппаратной архитектурой. Копируемые вручную файлы не могут переноситься на другие компьютеры, если, конечно, не используется специальный формат хранения MylSAM.
Независимо от выбранного метода резервирования существуют определенные принципы, которым необходимо следовать для достижения эффективных результатов.
Регулярно выполняйте резервирование. На этапе планирования разработайте расписание и четко его придерживайтесь.
Обязательно активизируйте регистрацию обновлений (как это сделать, рассказывается в лекции "Ведение файлов журналов"). Журналы обновлений помогут восстановить базу данных после сбоя, вернее, после восстановления заархивированных файлов дадут возможность вернуть ее в состояние, в котором база данных находилась непосредственно перед сбоем. Для этого необходимо заново внести все изменения, сделанные с момента последнего резервирования, просто запустив запросы
Согласно терминологии резервирования, заархивированные файлы баз данных представляют полный архив, а журналы обновлений — дополнительный.
Используйте постоянную и легко понятную схему присвоения имен файлам архива. Имена типа backupl, backup2 и т.д. не несут никакой смысловой нагрузки, и когда приходит время восстанавливать информацию, много времени тратится на изучение их содержимого. Гораздо эффективней присваивать архивным файлам имена баз данных и дат резервирования. Например:
% mysqldump samp_db > /usr/archives/mysql/samp_db.1999-10-02 % mysqldump menagerie > /usr/archives/mysql/menagerie.1999-10-02
Иногда сразу после создания файлы архивов лучше сжать, ведь они занимают много места. Время от времени рекомендуется также удалять ненужные файлы архивов, так же как и файлы журналов, чтобы не заполнять жесткий диск ненужной информацией. Более детально эта процедура рассматривается в лекции "Ведение файлов журналов". Описанные в ней способы можно применять и к файлам архивов.
Резервируйте впоследствии архивные файлы MySQL с помощью средств резервирования файловой системы. В случае фатального сбоя операционной системы потерянным может оказаться не только каталог данных, но и вся остальная информация, находящаяся на жестком диске. Поэтому для большей надежности необходимо резервировать также файлы архивов и журналов обновлений.
Размещайте файлы архивов на отдельном диске. Это снизит вероятность переполнения этими файлами диска, содержащего каталог данных.
Описанные выше методы резервирования баз данных оказываются эффективными и для копирования этих баз на другой сервер. Наиболее часто база данных переносится на другой сервер, работающий на отдельном компьютере, однако можно перенести ее в отдельный каталог для другого сервера, работающего на этом же локальном компьютере. Необходимость в этом может возникнуть после выхода новой версии MySQL, когда администратор захочет протестировать ее работу перед полным переходом, либо при установке нового более производительного компьютера, на который со временем планируется перенести все базы данных.
При резервировании базы данных с помощью программы mysqldump создается файл, который состоит из создающих таблицы операторов create table и операторов insert с данными строк таблиц. Другими словами, в процессе работы программа mysqldump создает набор операторов, которые впоследствии можно отправить серверу mysql для воссоздания базы данных.
Для резервирования целой базы данных в одном текстовом файле достаточно запустить следующую команду:
% mysqldump samp_db > /usr/archives/mysql/samp_db.1999-10-02
В результате ее выполнения будет создан файл, начинающийся следующим образом:
# MySQL dump 6.0
#
# Host: localhost Database: samp db
# --------------------------------------------
# Server version 3.23.2-alpha-log
#
# Table structure for table ‘adsence’
#
CREATE TABLE adsence {
student id int (10) unsigned DEFAULT ‘0’ NOT NULL,
date date DEFAULT ‘0000-00-00’ NOT NULL,
PRIMARY KEY (student id, date)
};
#
# Dumpling data for table ‘adsence’
#
INSERT INTO adsence VALUES (3, ‘1999-09-03’);
INSERT INTO adsence VALUES (5, ‘1999-09-03’);
INSERT INTO adsence VALUES (10, ‘1999-09-06’);
Остальная часть файла также состоит из операторов CREATE TABLE и INSERT.
Чтобы сразу после создания сжать файл архива, необходимо ввести вместо представленной выше следующую команду:
% mysqldump samp_db | gzip > /usr/archives/mysql/samp_db.1999-10-02.gz
Результатом резервирования большой базы данных станет создание большого файла архива, с которым трудно работать. В таком случае можно зарезервировать отдельные таблицы, указав их имена после имени базы данных в строке команды mysqldump. Это приведет к созданию меньших, а следовательно, и более удобных для обработки файлов. Резервирование отдельных таблиц базы данных sampdb можно выполнить с помощью следующих команд:
% mysqldump samp_db student score event adsence > gradebook.sql % mysqldump samp_db member president > hist-league.sql
Если создаваемые файлы архивов планируется использовать для периодического обновления содержимого другой базы данных, можно добавить в командную строку mysqldump опцию -add-drop-table. В этом случае в файл архива будут заноситься операторы drop table if EXISTS. При загрузке файла архива с этими операторами в другой базе данных сообщения о существовании таблиц появляться не будут. Администраторы, управляющие двумя серверами, могут применять этот способ для периодической загрузки данных из баз данных одного сервера в базы другого.
Для переноса содержимого базы данных на другой сервер вовсе необязательно создавать файлы архива. Достаточно убедиться в существовании этой базы данных на другом компьютере, а затем создать канал (pipe), чтобы mysql смог напрямую считывать вывод команды mysqldump. Так, например,
% mysqladmin -h boa.snake.net create samp db % mysqldump samp_db | mysql -h boa.snake.net samp_db
Чтобы впоследствии обновить информацию базы данных на компьютере
% mysqldump -add-drop-table samp_db | mysql -h boa.snake.net samp_db
В строке команды mysqladmin можно использовать и другие полезные опции.
Комбинация опций -flush-logs и —lock-tables полезна для контроля состояния базы данных. Первая опция закрывает и повторно открывает файлы журналов обновлений, а вторая —блокирует все резервируемые таблицы. Если сервер создает журналы обновлений с порядковыми именами, каждый новый журнал будет содержать все запросы на изменение базы данных с момента ее последнего резервирования. (Блокировка таблиц закрывает доступ к
Если опция -flush-logs применяется для согласования времени создания
Команда mysqldump по умолчанию перед записью таблицы в архив считывает ее всю в память. В этом, однако, нет необходимости. Более того, подобная обработка больших таблиц вообще может привести к сбою. Поэтому администратор может воспользоваться опцией —quick, определяющей построчное считывание и запись информации. Чтобы еще больше оптимизировать процесс резервирования, вместо опции —quick можно применить опцию —opt. Она, в свою очередь, активизирует все остальные опции, ускоряющие считывание и резервирование данных.
Выполнение резервирования с помощью опции —opt — наиболее распространенный (благодаря скорости) метод выполнения. Однако следует проявлять осторожность, поскольку опция —opt оптимизирует процедуру резервирования, закрывая на время доступ к базе данных. Она блокирует все таблицы сразу, запрещая внесение каких-либо изменений. Эффект от применения этой опции заметить очень легко. Попробуйте запустить команду резервирования с этой опцией днем, во время наиболее частого использования базы данных. Пользователи не заставят себя долго ждать, и скоро телефон администратора начнет звонить не переставая.
Эффекта, прямо противоположного результатам опции —opt, можно достичь с помощью опции —delayed. Эта опция заставляет команду mysqldump записывать в файл архива операторы INSERT DELAYED вместо операторов INSERT. Опция —delayed оказывается весьма полезной, если при загрузке файла архива в другую базу данных администратор желает уменьшить влияние этой операции на выполнение текущих запросов.
Для уменьшения передаваемого объема информации при —compress. Однако эта опция предназначается для программ, взаимодействующих с сервером удаленного, а не локального компьютера:
% mysqldump --opt samp_db | mysql --compress -h boa.snake.net samp_db
Команда mysqldump имеет и множество других опций.
Второй метод резервирования баз данных и таблиц заключается в непосредственном копировании файлов таблиц. Как правило, эта процедура выполняется с помощью таких утилит, как ср, tar или cpio. В примерах этой лекции используется программа ср.
Как уже отмечалось, применяя методы прямого копирования, обязательно нужно убедиться, что таблицы в процессе резервирования не используются другими пользователями. Если сервер изменяет какую-либо таблицу во время копирования, ее копия окажется искаженной.
Лучший способ обеспечить целостность копий — временно приостановить работу сервера, скопировать файлы и затем снова запустить сервер.
Итак, предположим, что работа сервера временно приостановлена либо подлежащие копированию таблицы защищены от изменения. В таком случае резервирование всей базы данных samp_db в каталог резервирования ( DATADIR в этом примере — каталог данных сервера) выполняется посредством следующих команд:
% cd DATADIR % cp -r samp_db /usr/archive/mysql
Для резервирования отдельных таблиц введите следующие команды:
% cd DATADIR/samp_db % ср member.* /usr/archive/mysql/samp_db % ср score.* /usr/archive/mysql/samp_db
По завершению процедуры резервирования можно перезапустить сервер (если его работа была приостановлена) или
Для переноса зарезервированных методом прямого копирования файлов на другой компьютер достаточно еще раз скопировать их в соответствующий каталог базы данных другого компьютера. Однако прежде необходимо убедиться, что файлы соответствуют
Термин
Повреждение данных может происходить по самым разным причинам и значительно варьироваться по масштабам. В наилучшем случае поврежденными оказываются одна-две таблицы (например, если работа компьютера была внезапно завершена из-за отключения электричества). В наихудшем — придется восстанавливать весь каталог данных (например, если сломался и не подлежит ремонту жесткий диск). Восстановление данных может потребоваться и в некоторых других ситуациях, например, когда пользователи случайно удалят базы данных или таблицы либо сотрут их содержимое. Независимо от причин повреждения, администратору немедленно нужно выполнить процедуру восстановления.
Если таблицы не утеряны, а лишь повреждены, попытайтесь отладить их с помощью команд myisamchk и issamchk. Вполне вероятно, что проблему можно решить с их помощью, и необходимость в восстановлении файлов архивов отпадет. Процедура отладки таблиц описывается в лекции 4, "Поддержка и восстановление баз данных". Если же таблицы потеряны или не подлежат отладке, самое время приступить к их восстановлению.
Для восстановления используются два источника информации: файлы архива и журналы обновлений. Первые позволяют восстановить таблицы до состояния, в котором они были в момент выполнения резервирования. Однако зачастую таблицы значительно изменяются пользователями между моментами резервирования и сбоя. В такой ситуации эффективными оказываются журналы обновлений, содержащие все последние запросы на внесение изменений. Чтобы восстановить все эти изменения, достаточно запустить запросы
Сначала, если речь идет о восстановлении базы данных mysql с таблицами разрешений, необходимо запустить сервер с опцией —skip-grant-tables. Иначе сервер выдаст сообщение о невозможности поиска таблиц разрешений. После восстановления таблиц разрешений выполните команду mysqladmin flush-privileges, чтобы заставить сервер загрузить и использовать таблицы разрешений.
Скопируйте содержимое каталога базы данных в другое место. Оно может потребоваться в будущем для изучения оставшихся данных поврежденных таблиц.
Загрузите базу данных, используя файлы самых последних архивов. Если эти файлы были созданы программой mysqldump, используйте их в качестве ввода в mysql. Если же восстановление информации выполняется из файлов, непосредственно скопированных из каталога базы данных (например, с помощью команд tar или ср ), скопируйте их обратно в каталог данных. В последнем случае перед копированием файлов необходимо временно приостановить работу сервера, а по завершении переноса — снова запустить.
Используя журналы обновлений, повторно запустите все запросы на изменение базы данных, которые были исполнены с момента последнего резервирования. Для этого содержимое —one-database, чтобы сервер mysql исполнил запросы только к той базе данных, которая представляет интерес. Если для восстановления информации необходимо использовать все журналы обновлений, запустите в каталоге с этими журналами следующую команду:
%ls -t -r -l update.[0-9]*|xargs cat|mysq| —one-database db_name
Команда Is воспроизводит список файлов журналов обновлений, отсортированный сервером в порядке создания. (Об этом следует помнить, поскольку неаккуратное изменение имен файлов журналов может привести к восстановлению их запросов в неправильном порядке.)
В большинстве же случаев используются не все, а только часть журналов обновлений. Например, если запросы к базе данных, выполненные после последнего резервирования, хранятся в файлах с именами update.392, update.393 и т.д., повторно запустить их можно с помощью следующих команд:
% mysql —one-database db_name < update.392 % mysql -one-database db_name < update.393
Если процедура восстановления применяется для устранения результатов случайного выполнения операторов DROP database, drop table или delete, не забудьте перед запуском команды удалить эти операторы из журнала!
Восстанавливать отдельные таблицы сложней. Если для восстановления применяется файл архива, созданный утилитой mysqldump и содержащий данные для множества таблиц, администратору придется извлечь из него строки, соответствующие требуемой таблице, и использовать их в качестве ввода для mysql. Это самая легкая часть процедуры восстановления. После нее необходимо из mysqlfindrows, возможности которой позволяют извлекать многострочные запросы из
Администратор должен обязательно резервировать базы данных на случай повреждения или потери данных. Только благодаря резервированию все таблицы могут быть восстановлены до прежнего состояния в случае сбоя в работе системы. Кроме того, не исключен вариант, когда резервирование может оказаться единственным путем отступления, если какой-либо неопытный пользователь случайно выполнит операторы DROP database или drop table. Иногда сбой может произойти по вине собственно администратора MySQL. Так, автору этих лекций известны случаи, когда администраторы разрушали файлы таблиц, пытаясь изменить их с помощью таких редакторов, как vi или emacs. Это далеко не самый лучший способ отредактировать таблицы.
Существует два основных способа резервирования баз данных: использование программы mysqldump и непосредственное копирование файлов базы данных (с помощью команд ср, tar или cpio ). Каждый метод имеет свои преимущества и недостатки.
Программа mysqldump тесно взаимодействует с сервером MySQL. Методы непосредственного копирования являются внешними по отношению к серверу и требуют проверки, чтобы клиенты не пытались изменить таблицы баз данных в процессе копирования. Эта же проблема возникает при использовании для резервирования баз данных средств резервирования файловой системы. Если в процессе резервирования кто-то из пользователей изменяет таблицы, их файлы окажутся несовместимыми и не подлежащими восстановлению. Разница между резервированием файловой системы и непосредственным копированием файлов заключается в том, что в первом случае имеется возможность управлять расписанием резервирования.
Программа mysqldump медленней резервирует данные, чем методы непосредственного копирования.
Программа mysqldump создает простые текстовые файлы, которые можно легко переносить на другие компьютеры, даже с другой аппаратной архитектурой. Копируемые вручную файлы не могут переноситься на другие компьютеры, если, конечно, не используется специальный формат хранения MylSAM.
Независимо от выбранного метода резервирования существуют определенные принципы, которым необходимо следовать для достижения эффективных результатов.
Регулярно выполняйте резервирование. На этапе планирования разработайте расписание и четко его придерживайтесь.
Обязательно активизируйте регистрацию обновлений (как это сделать, рассказывается в лекции "Ведение файлов журналов"). Журналы обновлений помогут восстановить базу данных после сбоя, вернее, после восстановления заархивированных файлов дадут возможность вернуть ее в состояние, в котором база данных находилась непосредственно перед сбоем. Для этого необходимо заново внести все изменения, сделанные с момента последнего резервирования, просто запустив запросы
Согласно терминологии резервирования, заархивированные файлы баз данных представляют полный архив, а журналы обновлений — дополнительный.
Используйте постоянную и легко понятную схему присвоения имен файлам архива. Имена типа backupl, backup2 и т.д. не несут никакой смысловой нагрузки, и когда приходит время восстанавливать информацию, много времени тратится на изучение их содержимого. Гораздо эффективней присваивать архивным файлам имена баз данных и дат резервирования. Например:
% mysqldump samp_db > /usr/archives/mysql/samp_db.1999-10-02 % mysqldump menagerie > /usr/archives/mysql/menagerie.1999-10-02
Иногда сразу после создания файлы архивов лучше сжать, ведь они занимают много места. Время от времени рекомендуется также удалять ненужные файлы архивов, так же как и файлы журналов, чтобы не заполнять жесткий диск ненужной информацией. Более детально эта процедура рассматривается в лекции "Ведение файлов журналов". Описанные в ней способы можно применять и к файлам архивов.
Резервируйте впоследствии архивные файлы MySQL с помощью средств резервирования файловой системы. В случае фатального сбоя операционной системы потерянным может оказаться не только каталог данных, но и вся остальная информация, находящаяся на жестком диске. Поэтому для большей надежности необходимо резервировать также файлы архивов и журналов обновлений.
Размещайте файлы архивов на отдельном диске. Это снизит вероятность переполнения этими файлами диска, содержащего каталог данных.
Описанные выше методы резервирования баз данных оказываются эффективными и для копирования этих баз на другой сервер. Наиболее часто база данных переносится на другой сервер, работающий на отдельном компьютере, однако можно перенести ее в отдельный каталог для другого сервера, работающего на этом же локальном компьютере. Необходимость в этом может возникнуть после выхода новой версии MySQL, когда администратор захочет протестировать ее работу перед полным переходом, либо при установке нового более производительного компьютера, на который со временем планируется перенести все базы данных.
При резервировании базы данных с помощью программы mysqldump создается файл, который состоит из создающих таблицы операторов create table и операторов insert с данными строк таблиц. Другими словами, в процессе работы программа mysqldump создает набор операторов, которые впоследствии можно отправить серверу mysql для воссоздания базы данных.
Для резервирования целой базы данных в одном текстовом файле достаточно запустить следующую команду:
% mysqldump samp_db > /usr/archives/mysql/samp_db.1999-10-02
В результате ее выполнения будет создан файл, начинающийся следующим образом:
# MySQL dump 6.0
#
# Host: localhost Database: samp db
# --------------------------------------------
# Server version 3.23.2-alpha-log
#
# Table structure for table ‘adsence’
#
CREATE TABLE adsence {
student id int (10) unsigned DEFAULT ‘0’ NOT NULL,
date date DEFAULT ‘0000-00-00’ NOT NULL,
PRIMARY KEY (student id, date)
};
#
# Dumpling data for table ‘adsence’
#
INSERT INTO adsence VALUES (3, ‘1999-09-03’);
INSERT INTO adsence VALUES (5, ‘1999-09-03’);
INSERT INTO adsence VALUES (10, ‘1999-09-06’);
Остальная часть файла также состоит из операторов CREATE TABLE и INSERT.
Чтобы сразу после создания сжать файл архива, необходимо ввести вместо представленной выше следующую команду:
% mysqldump samp_db | gzip > /usr/archives/mysql/samp_db.1999-10-02.gz
Результатом резервирования большой базы данных станет создание большого файла архива, с которым трудно работать. В таком случае можно зарезервировать отдельные таблицы, указав их имена после имени базы данных в строке команды mysqldump. Это приведет к созданию меньших, а следовательно, и более удобных для обработки файлов. Резервирование отдельных таблиц базы данных sampdb можно выполнить с помощью следующих команд:
% mysqldump samp_db student score event adsence > gradebook.sql % mysqldump samp_db member president > hist-league.sql
Если создаваемые файлы архивов планируется использовать для периодического обновления содержимого другой базы данных, можно добавить в командную строку mysqldump опцию -add-drop-table. В этом случае в файл архива будут заноситься операторы drop table if EXISTS. При загрузке файла архива с этими операторами в другой базе данных сообщения о существовании таблиц появляться не будут. Администраторы, управляющие двумя серверами, могут применять этот способ для периодической загрузки данных из баз данных одного сервера в базы другого.
Для переноса содержимого базы данных на другой сервер вовсе необязательно создавать файлы архива. Достаточно убедиться в существовании этой базы данных на другом компьютере, а затем создать канал (pipe), чтобы mysql смог напрямую считывать вывод команды mysqldump. Так, например,
% mysqladmin -h boa.snake.net create samp db % mysqldump samp_db | mysql -h boa.snake.net samp_db
Чтобы впоследствии обновить информацию базы данных на компьютере
% mysqldump -add-drop-table samp_db | mysql -h boa.snake.net samp_db
В строке команды mysqladmin можно использовать и другие полезные опции.
Комбинация опций -flush-logs и —lock-tables полезна для контроля состояния базы данных. Первая опция закрывает и повторно открывает файлы журналов обновлений, а вторая —блокирует все резервируемые таблицы. Если сервер создает журналы обновлений с порядковыми именами, каждый новый журнал будет содержать все запросы на изменение базы данных с момента ее последнего резервирования. (Блокировка таблиц закрывает доступ к
Если опция -flush-logs применяется для согласования времени создания
Команда mysqldump по умолчанию перед записью таблицы в архив считывает ее всю в память. В этом, однако, нет необходимости. Более того, подобная обработка больших таблиц вообще может привести к сбою. Поэтому администратор может воспользоваться опцией —quick, определяющей построчное считывание и запись информации. Чтобы еще больше оптимизировать процесс резервирования, вместо опции —quick можно применить опцию —opt. Она, в свою очередь, активизирует все остальные опции, ускоряющие считывание и резервирование данных.
Выполнение резервирования с помощью опции —opt — наиболее распространенный (благодаря скорости) метод выполнения. Однако следует проявлять осторожность, поскольку опция —opt оптимизирует процедуру резервирования, закрывая на время доступ к базе данных. Она блокирует все таблицы сразу, запрещая внесение каких-либо изменений. Эффект от применения этой опции заметить очень легко. Попробуйте запустить команду резервирования с этой опцией днем, во время наиболее частого использования базы данных. Пользователи не заставят себя долго ждать, и скоро телефон администратора начнет звонить не переставая.
Эффекта, прямо противоположного результатам опции —opt, можно достичь с помощью опции —delayed. Эта опция заставляет команду mysqldump записывать в файл архива операторы INSERT DELAYED вместо операторов INSERT. Опция —delayed оказывается весьма полезной, если при загрузке файла архива в другую базу данных администратор желает уменьшить влияние этой операции на выполнение текущих запросов.
Для уменьшения передаваемого объема информации при —compress. Однако эта опция предназначается для программ, взаимодействующих с сервером удаленного, а не локального компьютера:
% mysqldump --opt samp_db | mysql --compress -h boa.snake.net samp_db
Команда mysqldump имеет и множество других опций.
Второй метод резервирования баз данных и таблиц заключается в непосредственном копировании файлов таблиц. Как правило, эта процедура выполняется с помощью таких утилит, как ср, tar или cpio. В примерах этой лекции используется программа ср.
Как уже отмечалось, применяя методы прямого копирования, обязательно нужно убедиться, что таблицы в процессе резервирования не используются другими пользователями. Если сервер изменяет какую-либо таблицу во время копирования, ее копия окажется искаженной.
Лучший способ обеспечить целостность копий — временно приостановить работу сервера, скопировать файлы и затем снова запустить сервер.
Итак, предположим, что работа сервера временно приостановлена либо подлежащие копированию таблицы защищены от изменения. В таком случае резервирование всей базы данных samp_db в каталог резервирования ( DATADIR в этом примере — каталог данных сервера) выполняется посредством следующих команд:
% cd DATADIR % cp -r samp_db /usr/archive/mysql
Для резервирования отдельных таблиц введите следующие команды:
% cd DATADIR/samp_db % ср member.* /usr/archive/mysql/samp_db % ср score.* /usr/archive/mysql/samp_db
По завершению процедуры резервирования можно перезапустить сервер (если его работа была приостановлена) или
Для переноса зарезервированных методом прямого копирования файлов на другой компьютер достаточно еще раз скопировать их в соответствующий каталог базы данных другого компьютера. Однако прежде необходимо убедиться, что файлы соответствуют
Термин
Повреждение данных может происходить по самым разным причинам и значительно варьироваться по масштабам. В наилучшем случае поврежденными оказываются одна-две таблицы (например, если работа компьютера была внезапно завершена из-за отключения электричества). В наихудшем — придется восстанавливать весь каталог данных (например, если сломался и не подлежит ремонту жесткий диск). Восстановление данных может потребоваться и в некоторых других ситуациях, например, когда пользователи случайно удалят базы данных или таблицы либо сотрут их содержимое. Независимо от причин повреждения, администратору немедленно нужно выполнить процедуру восстановления.
Если таблицы не утеряны, а лишь повреждены, попытайтесь отладить их с помощью команд myisamchk и issamchk. Вполне вероятно, что проблему можно решить с их помощью, и необходимость в восстановлении файлов архивов отпадет. Процедура отладки таблиц описывается в лекции 4, "Поддержка и восстановление баз данных". Если же таблицы потеряны или не подлежат отладке, самое время приступить к их восстановлению.
Для восстановления используются два источника информации: файлы архива и журналы обновлений. Первые позволяют восстановить таблицы до состояния, в котором они были в момент выполнения резервирования. Однако зачастую таблицы значительно изменяются пользователями между моментами резервирования и сбоя. В такой ситуации эффективными оказываются журналы обновлений, содержащие все последние запросы на внесение изменений. Чтобы восстановить все эти изменения, достаточно запустить запросы
Сначала, если речь идет о восстановлении базы данных mysql с таблицами разрешений, необходимо запустить сервер с опцией —skip-grant-tables. Иначе сервер выдаст сообщение о невозможности поиска таблиц разрешений. После восстановления таблиц разрешений выполните команду mysqladmin flush-privileges, чтобы заставить сервер загрузить и использовать таблицы разрешений.
Скопируйте содержимое каталога базы данных в другое место. Оно может потребоваться в будущем для изучения оставшихся данных поврежденных таблиц.
Загрузите базу данных, используя файлы самых последних архивов. Если эти файлы были созданы программой mysqldump, используйте их в качестве ввода в mysql. Если же восстановление информации выполняется из файлов, непосредственно скопированных из каталога базы данных (например, с помощью команд tar или ср ), скопируйте их обратно в каталог данных. В последнем случае перед копированием файлов необходимо временно приостановить работу сервера, а по завершении переноса — снова запустить.
Используя журналы обновлений, повторно запустите все запросы на изменение базы данных, которые были исполнены с момента последнего резервирования. Для этого содержимое —one-database, чтобы сервер mysql исполнил запросы только к той базе данных, которая представляет интерес. Если для восстановления информации необходимо использовать все журналы обновлений, запустите в каталоге с этими журналами следующую команду:
%ls -t -r -l update.[0-9]*|xargs cat|mysq| —one-database db_name
Команда Is воспроизводит список файлов журналов обновлений, отсортированный сервером в порядке создания. (Об этом следует помнить, поскольку неаккуратное изменение имен файлов журналов может привести к восстановлению их запросов в неправильном порядке.)
В большинстве же случаев используются не все, а только часть журналов обновлений. Например, если запросы к базе данных, выполненные после последнего резервирования, хранятся в файлах с именами update.392, update.393 и т.д., повторно запустить их можно с помощью следующих команд:
% mysql —one-database db_name < update.392 % mysql -one-database db_name < update.393
Если процедура восстановления применяется для устранения результатов случайного выполнения операторов DROP database, drop table или delete, не забудьте перед запуском команды удалить эти операторы из журнала!
Восстанавливать отдельные таблицы сложней. Если для восстановления применяется файл архива, созданный утилитой mysqldump и содержащий данные для множества таблиц, администратору придется извлечь из него строки, соответствующие требуемой таблице, и использовать их в качестве ввода для mysql. Это самая легкая часть процедуры восстановления. После нее необходимо из mysqlfindrows, возможности которой позволяют извлекать многострочные запросы из
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.