Мануал по созданию и востоновлению резервных копий баз данных с помощью Mysqldump
Создание резервных копий баз данных с помощью Mysqldump
В общем случае, команда для создания резервной копии базы данных, с помощью программы Mysqldump, выглядит следующим образом: Цитата:
Цитата:
Цитата:
Цитата:
Так-же есть возможность создавать дампы, только необходимых таблиц, определенной базы данных: Цитата:
Для создания дампа только структуры таблиц, без данных, используется та-же опция --no-data. Цитата:
Цитата:
Цитата:
Восстановление данных из резервной копии Восстановить базу данных или таблицу из сохраненного ранее дампа, еще проще, чем этот дамп создать. Для этого достаточно воспользоваться стандартной программой-клиентом Mysql, перенаправив в нее файл резервной копии. Делается это так: Цитата:
Цитата:
Вообще с помощью программы Mysqldump, очень удобно копировать таблицы с данными или только структуры таблиц, из одной базы данных в другую. Небольшой пример: Цитата:
Цитата:
Параметры программы Mysqldump --help, -? Вывод справки по опциям и используемым переменным. --add-drop-database Добавляет команду, DROP DATABASE перед каждой командой CREATE DATABASE --add-drop-table Добавляет команду, DROP TABLE перед каждой командой CREATE TABLE --add-locks Обрамляет дамп командами LOCK TABLES и UNLOCK TABLES, для ускорения операций вставки. --all-databases, -A Создает полную резервную копию всех баз данных, текущего сервера. --allow-keywords Разрешить имена столбцов, совпадающие с зарезервированными ключевыми словами. К имени такого столбца, добавляется префикс таблицы. --character-sets-dir= путь Директории с установленными наборами символов кодировок --comments, -i Добавить в файл дампа, дополнительную информацию ( например, версию программы, версию MySQL, имя хоста ), отменяется опцией --skip-comments --compact Создает более компактный дамп. Использование данного параметра, автоматически включает опции: --skip-add-drop-table, --skip-add-locks, --skip-comments, --skip-disable-keys и --skip-set-charset. --compatible= имя Данная опция, пытается повысить совместимость создаваемого дампа, с базой данных другого типа или с более старой версией MySQL. Возможные значения: ansi, mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb, no_key_options, no_table_options или no_field_options. Можно использовать несколько значений, разделенных запятыми. --complete-insert, -c Использовать полную форму оператора INSERT, включая имена столбцов. --compress, -C Использовать компрессию, при пересылке данных между клиентом и сервером, при условии, что они оба поддерживают компрессию. --create-options Включать все MySQL опции при использовании оператора CREATE TABLE. --databases, -B Делать дамп нескольких баз данных, перечисленных после данной опции. Без этого параметра, mysqldump, воспринимает в качестве имени базы данных, первое значение, остальные интерпретируются как имена таблиц. --default-character-set= кодировка Донная опция устанавливает кодировку по-умолчанию. Если не определена, используется utf8, в ранних версиях latin1. --delayed-insert Вместо оператора INSERT, использовать INSERT DELAYED. --delete-master-logs Удалять бинарный лог на основном сервере репликаций после создания дампа. При использовании этой опции, автоматически включается опция --master-data. --disable-keys, -K Оператор INSERT для каждой таблицы, обрамляется выражением /*!40000 ALTER TABLE tbl_name DISABLE KEYS */ и /*!40000 ALTER TABLE tbl_name ENABLE KEYS */. Данная опция ускоряет загрузку при восстановлении из дампа, для таблиц типа MyISAM, за счет того, что индексы создаются после вставки всех данных. --dump-date Если включена опция --comments, добавлять дату создания дампа. --extended-insert, -e Использовать многострочный синтаксис оператора INSERT. Уменьшает размер дампа и ускоряет последующую вставку данных. --flush-logs, -F Переоткрыть лог файлы, перед созданием резервной копии. Старый файл будет сохранен с суффиксом -old. При использовании с опцией --all-databases ( сокращенный вариант -A ), будут переоткрыты лог-файлы каждой базы данных, для которой делается дамп. --flush-privileges Выполнять команду FLUSH PRIVILEGES после создания дампа базы данных. --force, -f Продолжать создание резервной копии даже в случае возникновения ошибки. --host= имя_хоста, -h имя_хоста Указывает хост MySQL сервера. По-умолчанию резервная копия делается для хоста localhost --hex-blob Представлять бинарные данные полей BINARY, VARBINARY, BLOB и BIT в шестнадцатиричном формате ( hex ). --ignore-table= имя_базы.имя_таблицы Не скидывать в дамп таблицу "имя_таблицы" из базы "имя_базы". Опцию нужно использовать повторно, для каждой игнорируемой таблицы. --insert-ignore Дописывать в оператор INSERT, опцию IGNORE. --lock-all-tables, -x Блокировка всех таблиц, во всех базах, на время создания резервной копии. Данная опция автоматически отключает --single-transaction и --lock-tables. --lock-tables, -l Блокировка таблиц базы данных, на время создания резервной копии. При дампе всех баз данных с этой опцией, таблицы каждой базы блокируются отдельно. Для транзакционных таблиц, типа InnoDB и BDB, предпочтительней использовать опцию --single-transaction. --log-error= имя_файла Писать ошибки и предупреждения в файл "имя_файла". --no-autocommit Включает операторы INSERT для каждой таблицы, в операторы SET AUTOCOMMIT и COMMIT, для увеличения скорости выполнения большого количества запросов INSERT --no-create-db, -n Данная опция подавляет вывод в дамп оператора CREATE DATABASE, при использовании опций --databases и --all-databases. --no-create-info, -t Не писать оператор CREATE TABLE, для пересоздания каждой таблицы из резервной копии. --no-data, -d Не скидывать в дамп содержимое таблиц. Оставляет только операторы CREATE TABLE для создания структуры. --opt Групповая опция. Синоним включения опций, --add-drop-table, --add-locks, --create-options, --disable-keys, --extended-insert, --lock-tables, --quick, --set-charset. Ускоряет общий процесс создания резервной копии, включена по-умолчанию. Отключается опцией --skip-opt. --order-by-primary Сортировать ряды таблиц по первичному ключу или по первому уникальному индексу, если индекс существует. Полезна в случае создания дампа таблиц MyISAM с последующей вставкой в таблицы типа InnoDB. --password[=password], -p[password] Пароль пользователя, для подключения к серверу. Не забывайте, что имя должно идти сразу за опцией, без разделяющего пробела. Если указаны только сама опция, без пароля, пароль будет запрошен из командной строки. --port= номкр_порта, -P номкр_порта Номер порта, для подключения к серверу по протоколу TCP/IP. --protocol={TCP|SOCKET|PIPE|MEMORY} Использовать для подключения к серверу MySQL, указанный протокол. --quick, -q Данная опция вынуждает Mysqldump, восстанавливать строки, по одной за раз, вместо того что-бы скидывать весь объем строк в буфер памяти и выписывать их оттуда. Очень полезна при создании резервных копий больших таблиц. --quote-names, -Q Обрамлять имена баз данных, таблиц и колонок, ковычками. Включена по-умолчанию. --replace Использовать оператор REPLACE вместо INSERT. Начиная с версии MySQL 5.1.3. --result-file= имя_файла, -r имя_файла Вывод результатов в указанный файл. Имейте в виду, если файл с таким именем уже существует, он будет перезаписан и в случае возникновения ошибки, данные могут быть потеряны. --routines, -R Записывать в дамп хранимые процедуры и функции. Для использования данной опции, необходимы права SELECT на таблицу proc, системной базы данных mysql. Дамп будет содержать операторы CREATE PROCEDURE и CREATE FUNCTION. При использовании этой опции, эти операторы не будут содержать атрибутов времени создания и модификации хранимых процедур и функций и после восстановления дампа они будут равны времени восстановления. Если вам необходимо сохранить исходные атрибуты времени, вместо использования данной опции, сделайте отдельный дамп таблицы mysql.proc, под именем пользователя, который имеет на это достаточные права. Опция появилась с версии MySQL 5.1.2. --set-charset Добавляет в дамп оператор SET NAMES со значением кодировки по-умолчанию. По-умолчанию, данная опция включена, что-бы подавить, используйте --skip-set-charset. --single-transaction Выполняет оператор BEGIN SQL, перед началом создания резервной копии. Опция используется только для транзакционных таблиц, типа InnoDB. Только этот тип таблиц может быть сохранен в дамп в актуальном состоянии, после выполнения BEGIN SQL, и без блокирования приложения. Например таблицы типа MyISAM или MEMORY, могут измениться в процессе создания резервной копии с использованием данной опции, в итоге, информация в дампе будет противоречивой, неактуальной. Опции --single-transaction и --lock-tables, являются взаимоисключающими. --socket= путь_к_файлу_сокета, -S путь_к_файлу_сокета Использовать файл unix-сокета, для подключения к localhost. --tables Имена идущие за этой опцией, считаются именами таблиц. --triggers Включать в резервную копию триггеры, для каждой таблицы. Отменить действие опции можно с помощью --skip-triggers. --user= имя_пользователя, -u имя_пользователя Имя пользователя для подключения к MySQL серверу. --verbose, -v Вывод служебной информации о ходе выполнения программы. --where='where_условие', -w 'where_условие' Скидывать в дамп информацию, выбранную по условию WHERE. --xml, -X Создать дамп в формате XML Цитата:
|
Re: Мануал по созданию и востоновлению резервных копий баз данных с помощью Mysqldump
а как сделать что бы база авт сохранялось например каждый 1час
|
Re: Мануал по созданию и востоновлению резервных копий баз данных с помощью Mysqldump
Цитата:
Если Линукс, то должен быть здесь -- /etc/crontab Если Виндовс, то там есть служба автозапуска Относительно бекапов, я использую backup-manager for linux. Проблем с конфигами нет совсем! Отлично бекапит как всю БД, так и может бекапить ФС. Огромний плюс в том, что после бекапа она может заливать весь бекап на другой либо по ФТП либо по ССШ + еще много разных фич. |
Re: Мануал по созданию и востоновлению резервных копий баз данных с помощью Mysqldump
Мне кстати всегда было интересно: при подаче команды на полный дамп БД умеет ли MySQL Demon отслеживать изменения в базе, с момента начала отдачи первого элемента и до окончания самого процесса с последующей отдачей накопившихся изменений.
К примеру: - живой сервер онлайн на 10-20 человек, которые активно бегают бьют МОБ'ов, крафтят дуэлятся и прочее к тому же и сам сервер периодически скидывает кэш и оно приходится как раз на середину процесса копирования. - запускаем снятие дампа - операция длится 10 минут - за эти 10 минут происходят изменения как в ещё не сохрянённых таблицах так и в уже сохрянённых - как ведёт себя MySQL и таком случает? - Можно ли дать команду javaServer - скинуть кэш и следом запустить создание дампа? Вот Oracle, вроде, умеет по началу создания резервной копии открывать буфер и все операции по записи в базу складывает в него до окончания бэкапа или до достижения определённой наполненности буфера, а в 10й версии, вроде, может отслеживает какие из сохранённых в буфере запросов на запись можно применить т.к. эти таблицы уже сохранены и соответственно накладывает на базу в процессе. Что имеем по итогу - действительный снимок базы на начало выполнения резервного копирования, а не винегрет из таблиц частично от начала резервирования и частично от изменённых в процессе записи. З.Ы. Может кто просветит неуча, как с этим в MySQL? |
Re: Мануал по созданию и востоновлению резервных копий баз данных с помощью Mysqldump
На мой взляд нет.
Даже по логике действий МуСКЛ... Любой дампер начинает считывать сначала БД, после того, переходит каждую БД и достает все таблицы и т.д. по цепочке. Припустим есть две БД -- бд1, бд2, у нех есть куча таблиц. Сначала читает бд1. Прочитал, создал бекап. Читает бд2. На это время, все, что будет подано в бд1, не будет в бекапе, поскольку бекап уже создан. Также происходит из таблицами. Если нужно бекапить все бд, то лучше делать это крном, где-то в часом 5 утра, когда онлайна на сервере будет очень мало, и потери будут незначительные, тем более, лучше делать бекап прямо на сервере!!! Из-за того, что если делать с удаленного хоста, то огромные БД будут очень долго бекапится. Был собственный пример. На серве БД -- 148 МБ. Друг бекапил из своего компа, зайняло приблизительно -- 10 мин. Я бекапил при помощи -- backup-manager, и минуты не зайняло. Добавлено через 11 часов 28 минут Да, еще один совет. В любой БД есть множество таблиц, записи которых давно уже не используются!!! Желательно после бекапа производить чистку таблиц, чтобы они не засорялись и на время следующего бекапа не были по 1 Гб. Сделать можно просто (только алгоритм): 1. Делаем бекап. 2. Проверям БД собственными скриптами, поскольку автоматизировать такой процес под всех не возможно. Припустим если у нас запись уже не будет использоватся, и она там стоит уже 1 месяц, так нах она. 3. Варианта два - Удаляем запись, либо переносим в резервное хранилище (таже копия БД, то в ней сохраняются старые записи) В результате, старые записи будет удалены из активной БД, что ускорит работу БД + уменьшит нагрузку при более сложных запросах + в любой момент Вы сможете востоновить то или инное поле с резервной БД. На заметку: Если на сервере БД используются сложные запросы, то тогда нужно проставлять индексы в таблицах, что достаточно ускорит поиск. Дело в том, что если установлен первичный индекс, то при поиске [WHERE], если искомое поле совпадает с названием индекса, первоначально проверяются индексы, а аж потом вся таблица. Для элементарного примера: Некая таблица id, iw, im 11 12 13 21 22 23 31 32 33 41 42 43 Предположим, что индекса нет, то при запросе типа -- SELECT * FROM table WHERE id=41 -- буду проверятся все ячейки по порядку (11 - 12 - 13 - 21 - 22 - 23 ...). А если записей милион, и полей 100? Предположим, что индекс -- id. При таком же запросе, сначала проверится поле индекса так же по порядку (11 - 21 - 31 - 41), а потом, если уже не найдет, начнет искать далее. -------------- ПРИ УСЛОВИИ, ЧТО ЕСТЬ НЕСКОЛЬКО ВЫБОРОК -------------- Также следует знать, что есть замечательная фича, как Views. Припустим в запросе Вы очень часто юзаете LEFT JOIN | RIGHT JOIN, либо делаете груповые запросы. Такие запросы дают нагрузку на серв, и иногда даже фатальную. Виход. Создать вюшку (в инете есть документации), а потом обращатся к вюшке как к обычной таблице -- SELECT * FROM name_view WHERE `field` = '123123'; Когда вюшка создается она проверяет таблицы, достает результаты и формирует вюшку. Данные вюшки летят в кеш. После, при запросе, все берется с кеша, а не а активным таблицам. Также при создании вюшки создаються типа тригеры (в МуСКЛ они тоже есть, но не то) на редактирование таблиц, которые принадлежат вюшке. В результате, при редактировании одной из таблиц, кеш немного перезапишется (именно то что было поправлено). Результат: При более сложных запросах и при их ОГРОМНОМ количестве, можно снизить нагрузку БД в 2, а то и более раз. P.S. С БД нужно быть немного острожным, поскольку на ней держится все -- сервер, сайт, фтп, квоты и т.д (кто что придумает). И если впадет мускула, можно сказать, УПАЛО ВСЕ!!! |
Текущее время: 12:42. Часовой пояс GMT +3. |
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot