Dump базы данных что это

Путеводитель по резервному копированию баз данных

– О, никакое убежище не выдержит попадания метеорита. Но ведь у вас, как и у каждого, есть резерв, так что можете не беспокоиться.

Станислав Лем, «Звёздные дневники Ийона Тихого»

Резервным копированием называется сохранение копии данных где-то вне основного места их хранения.

Главное назначение резервного копирования – восстановление данных после их потери. В связи с этим нередко приходится слышать, что при наличии реплики базы данных с неё всегда можно восстановить данные, и резервное копирование не нужно. На самом деле резервное копирование позволяет решить как минимум три задачи, которые не могут быть решены при помощи реплики, да и реплику без резервной копии не инициализировать.

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

Во-вторых, современные СУБД – весьма надёжные программные комплексы, однако изредка всё же происходит повреждение внутренних структур базы данных, после которого доступ к данным пропадает. Что особенно обидно, такое нарушение происходит обычно при высокой нагрузке или при установке какого-нибудь обновления. Но как высокая нагрузка, так и регулярные обновления говорят о том, что база данных – отнюдь не тестовая, и данные, хранящиеся в ней, ценны.

Наконец, третья задача, решение которой требует наличия резервной копии, – это клонирование базы, например, для целей тестирования.

Резервное копирование баз данных так или иначе базируется на одном из двух принципов:

Выгрузка данных

В наборе утилит, прилагающихся к любой СУБД, обязательно есть инструменты для выгрузки и загрузки данных. Данные сохраняются либо в текстовом формате, либо в двоичном формате, специфичном для конкретной СУБД. В таблице ниже приведён список таких инструментов:

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

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

Самым же распространённым методом резервного копирования баз данных является копирование файлов базы.

«Холодное» сохранение файлов БД

Очевидная идея – остановить базу данных и скопировать все её файлы. Такая резервная копия называется «холодной». Способ крайне надёжный и простой, но у него есть два очевидных недостатка:

«Горячее» сохранение файлов

Большинство резервных копий современных баз данных выполняется путём копирования файлов базы данных без остановки базы. Здесь видны несколько проблем:

Вот как выглядит подготовка к резервному копированию в СУБД с изменяемыми дисковыми структурами, т. е. во всех традиционных дисковых реляционных системах:

По окончании резервного копирования нужно перевести базу данных обратно в обычное состояние. В Oracle это делается командой ALTER DATABASE/TABLESPACE END BACKUP, в PostgreSQL – вызовом функции pg_stop_backup(), а в других базах – внутренними подпрограммами соответствующих команд или внешних сервисов.

Вот как выглядит временнáя диаграмма процесса резервного копирования:

Восстановление на точку

Резервная копия позволяет восстановить состояние базы данных на момент, когда завершилась команда возврата из режима резервного копирования. Однако авария, после которой потребуется восстановление, может произойти в любой момент. Задача восстановления состояния БД на произвольный момент называется «восстановлением на точку» (point-in-time recovery).

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

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

Инкрементальное резервное копирование

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

Решение задачи – инкрементальное резервное копирование, то есть копирование только тех страниц данных, которые изменились с момента предыдущего резервного копирования.
Инкрементальное резервное копирование имеет смысл только для СУБД, использующих изменяемые структуры данных.

Инкремент может отсчитываться как от полной резервной копии (кумулятивная копия), так и от любой предыдущей копии (дифференциальная копия).

К сожалению, единой терминологии не существует, и разные производители используют разные термины:

При наличии инкрементальных копий процесс восстановления на точку выглядит следующим образом:

Есть три способа создания инкрементальной копии:

Второй и третий способ отличаются механизмом определения списка изменённых страниц. Разбор журналов более ресурсоёмкий, плюс для его реализации необходимо знать структуру журнальных файлов. Спросить у самой базы, какие именно страницы изменились, проще всего, но для этого ядро СУБД должно иметь функциональность отслеживания изменённых блоков (block change tracking).

Впервые функциональность инкрементального резервного копирования была создана в ПО Oracle Recovery Manager (RMAN), появившемся в релизе Oracle 8i. Oracle сразу реализовал отслеживание изменённых блоков, поэтому необходимости в разборе журналов нет.

PostgreSQL не отслеживает изменённые блоки, поэтому утилита pg_probackup, разработанная российской компанией Postgres Professional, определяет изменённые страница путём анализа журнала. Однако компания поставляет и СУБД PostgresPro, которая включает расширение ptrack, отслеживающее изменение страниц. При использовании pg_probackup с СУБД PostgresPro утилита запрашивает изменённые страницы у самой базы – точно так же, как и RMAN.

Microsoft SQL Server так же, как и Oracle, отслеживает изменённые страницы, но команда BACKUP позволяет делать только полные и кумулятивные резервные копии.

В DB2 есть возможность отслеживания измененных страниц, но по умолчанию она выключена. После включения DB2 позволит делать полные, дифференциальные и кумулятивные резервные копии.

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

Ещё раз обратите внимание, что наличие инкрементальных копий не отменяет требований к наличию журналов для восстановления на произвольную точку во времени. Поэтому в промышленных базах данных журналы постоянно переписываются на внешний носитель, а резервные копии, полные и/или инкрементальные, создаются по расписанию.

Наилучшей на сегодня реализацией идеи инкрементального резервного копирования является программно-аппаратный комплекс (в терминологии Oracle – engineered system) Zero Data Loss Recovery Appliance – специализированное решение Oracle для резервного копирования собственной БД. Комплекс представляет собой кластер серверов с большим объёмом дисков, на которые установлена модифицированная версия ПО Recovery Manager и может работать как с другими программно-аппаратными комплексами Oracle (Database Appliance, Exadata, SPARC Supercluster), так и с базами Oracle на традиционной инфраструктуре. В отличие от «обычного» RMAN, в ZDLRA реализована концепция «вечного инкремента» (incremental forever). Система единственный раз создаёт полную копию базы данных, а потом делает только инкрементальные копии. Дополнительные модули RMAN позволяют объединять копии, создавая новые полные копии из инкрементальных.

К чести российских разработчиков нужно заметить, что и pg_probackup умеет объединять инкрементальные копии.

В отличие от многих похожих вопросов, вопрос «какой метод резервного копирования лучше» имеет однозначный ответ – лучше всего родная для используемой СУБД утилита, обеспечивающая возможность инкрементального копирования.

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

Источник

Что такое дамп базы данных и как его создать

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

Что такое дамп базы данных

Копирование базы данных может быть полезно, когда нужно выполнить:

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

Создаем дамп базы данных MySQL

Существует несколько способов создания дампов: через консольное окно или с помощью phpMyAdmin. Рассмотрим последовательно каждый из методов, а также попробуем восстановить БД из дампа.

Способ 1: Консольное окно MySQL

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

Для подключения вы можете воспользоваться такими программами, как PuTTY и WinSCP – они распространяются в бесплатном доступе. Остановимся на первой утилите и посмотрим, как с ее помощью можно сделать дамп базы данных MySQL.

Обратите внимание, что если на компьютере функционирует сервер с БД, то соединение через порт 3306 будет некорректно. В таких случаях рекомендуется использовать другие значения, например, 3307, 3308 и так далее.

Теперь мы можем переходить к удаленному администрированию БД: создадим дамп базы данных MySQL. Для этого введем в консоль следующий запрос:

В целях безопасности рекомендуется вообще не использовать логин и пароль. В таком случае команда примет следующий вид:

Для понимания можете взглянуть на пример с использованием пользователя и пароля:

Таким образом будет создан файл WordPressDump.sql, содержащий в себе все нужные данные для точного копирования. Посмотрим, как этот файл импортировать в проект через консоль:

Аналогично подставляем свои данные в команду и в итоге получаем:

Также при импорте мы можем указать кодировку — для этого достаточно добавить ключ default-character-set. В итоге код преобразуется:

Вот такими несложными действиями можно сделать копирование через консольное окно. Теперь давайте «покопаемся» в phpMyAdmin и выполним в нем копирование БД.

Способ 2: Инструмент phpMyAdmin

PhpMyAdmin по умолчанию предустановлен на каждой CMS. Доступ к нему осуществляется через личный кабинет пользователя на хостинге либо через локальный веб-сервер на домашнем ПК.

Подключаемся к phpMyAdmin и экспортируем БД:

После этого нам будет предложен выбор места сохранения файла. В последующем мы сможем его использовать через вкладку «Импорт». Для этого достаточно загрузить файл и указать подходящую для него кодировку:

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

Источник

Что такое дамп базы данных MySQL и как его сделать?

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

Dump может понадобиться, если вы запланировали миграцию БД на другой хостинг. С инструмента помощью вы сможете без каких-либо трудностей воссоздать точную копию старой базы данных.

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

Как создать дамп базы без ошибок?

Существуют различные способы создания дампа, и далее мы рассмотрим основные варианты:

В этом случае для создания SQL дампа БД используется командная строка или консоль MySQL. Выполните подключение по SSH и введите команду «mysqldump», запустите утилиту и укажите специальные параметры:

Файл можно открыть в текстовом редакторе, как пример, для поиска записей и строк по части слова или темы. Обратите внимание, что не все редакторы поддерживают файлы больших размеров.

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

Если вы предпочитаете использовать дополнительное программное обеспечение, то можно создать dump базы данных средствами PHP при помощи, например, phpMyAdmin. Для этого выполните следующие действия:

— Добавить SQL строчку «DROP TABLE/VIEW/PROCEDURE/FUNCTION/EVENT»

Нажать соответствующую кнопку.

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

Теперь вы знаете, как сделать полный дамп, если вам вдруг потребуется перенос базы на другой сервер или возникнет любая другая ситуация, когда может пригодиться резервная копия БД. Конечно, существует еще достаточно много способов создания дампа, помимо описанных выше. Но даже владение самыми простыми вариантами и регулярное применение их на практике позволит вам более уверенно чувствовать себя в любой непредвиденной ситуации, ведь достаточно будет просто развернуть дамп MySQL и сразу восстановить все базы данных.

Если вы решились купить dedicated server в нашей компании, то Вам выдается 100 ГБ на удаленном хранилище бекапов, куда можно настроить автоматическое резервное копирование информации. В таком случае, у вас всегда будет свежий дамп.

Важная информация: Не храните и не публикуйте файлы с доступом по ссылке. Вся информацию (data) необходимо хранить в надежном месте.

Источник

Дамп базы данных

Что такое дамп базы данных

Web-сайты состоят из файлов и базы данных. Именно в базе данных хранится вся часто изменяемая информация сайта:

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

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

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

Работа с дампом базы данных MySQL

Как индустриальный стандарт MySQL поддерживается у всех провайдеров хостинга. Популярные CMS WordPress, Joomla, Bitrix используют в качестве хранилища информации именно MySQL.

На виртуальном хостинге пользователь не имеет доступа на сервер и не может работать с командной строкой, поэтому для него остается вариант работы с дампами базы данных с использованием web-интерфейса, который либо встроен в панель управления хостинга, либо предоставляется утилитой phpMyAdmin.

Чтобы получить дамп базы данных MySQL на VPS/VDS и выделенном сервере, можно воспользоваться командной строкой сервера или специальным web-интерфейсом.

Использование функций панели управления

На примере провайдера Reg.ru и панели ISPManager разберем, как сделать дамп базы данных.

1. Зайдите в меню “Базы данных”.
2. Нажмите на кнопку “Скачать”, чтобы скачать дамп базы данных на локальный компьютер.

3. Чтобы импортировать дамп базы данных с локального компьютера на сервер, перейдите в раздел “Закачать” и нажмите на кнопку “Выберите файл”. Затем выберите файл с дампом на компьютере и запустите процесс закачки файла на сервер нажатием кнопки “Ok”.

Также имеется пункт меню “Локальный дамп”, который позволяет осуществить процедуру импорта дампа базы данных из предварительного закачанного на сервер файла. Достаточно просто найти и выбрать предварительно загруженный файл с дампом в одном из каталогов сайта:

Функция “Локальный дамп” полезна для тех случаев, когда нужно импортировать большой файл с дампом размером в несколько сотен мегабайт. Процедура импорта с файла на сервере работает намного быстрее, чем импорт файла с локального компьютера.

Использование web-интерфейса PHPMyAdmin

Практически у всех провайдеров виртуального хостинга в панель управления хостингом включена утилита PHPMyAdmin. Она используется в качестве удобного web-интерфейса для работы с базой данных MySQL. Например, у провайдера Beget ссылка на запуск phpMyAdmin располагается в разделе управления базами данных:

В числе прочих функций в PHPMyAdmin встроен механизм получения дампа базы данных. Для этого следует воспользоваться пунктом меню “Экспорт”:

При просмотре этого файла в блокноте видно, что он состоит из отдельных команд SQL

Обратной операцией по отношению к экспорту дампа базы данных является восстановление данных из этого дампа. Для этого в PHPMyAdmin нужно воспользоваться меню “Импорт”:

Кнопкой “Choose file” выбирается нужный файл на локальном компьютере, после нажатия кнопки “Вперед” происходит процедура импорта.

Таким образом, web-интерфейс работы с базой данных PHPMyAdmin можно применять как для создания дампа базы данных, так и для его импорта. PHPMyAdmin возможно установить и на свой виртуальный или выделенный сервер вместе с другим программным обеспечением. Кроме того, такие популярные панели управления хостингом, как VestaCP или ISPManager, также предоставляют этот web-интерфейс.

К недостаткам использования PHPMyadmin можно отнести возможные проблемы при работе с дампами очень больших баз данных размерами в сотни мегабайт. Импорт большого дампа связан с ограничениями web-сервера и PHP на размер загружаемого файла, и может потребовать предварительно разделить его на несколько частей, что представляет собой кропотливую и трудоемкую работу.

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

Использование командной строки сервера

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

Для создания дампа пользователю необходимо знать название базы данных, имя пользователя и пароль. Сохранить данные в дамп можно утилитой mysqldump.

Синтаксис команды для создания дампа:

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

Пример: после запуска процедуры создания дампа командой mysqldump, с помощью команды “ls” проверили, что в папке сайта появился файл dump.sql с дампом базы данных.

Для импорта дампа базы данных нужно будет воспользоваться командой “mysql” с синтаксисом:

Пример: после использования команды pg_dump дамп базы данных сохранен в файл dump.sql

Для импорта дампа в базу данных используется команда psql с синтаксисом:

Источник

Перенос базы данных MySQL в базу данных Azure для MySQL с помощью дампа и восстановления

Область применения: Отдельный сервер Базы данных Azure для MySQL Гибкий сервер Базы данных Azure для MySQL

В этой статье описываются два распространенных способа архивации и восстановления баз данных в базе данных Azure для MySQL:

Дополнительные сведения и примеры использования переноса баз данных в Базу данных Azure для MySQL см. в руководстве по переносу баз данных. Это руководство содержит инструкции, которые позволят успешно спланировать и выполнить миграцию с MySQL на Azure.

Перед началом

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

Если вы хотите перенести большие базы данных размером более 1 ТБ, попробуйте использовать такие средства сообщества, как mydumper/myloader, которые поддерживают параллельный экспорт и импорт. Узнайте, как перенести большие базы данных MySQL.

Распространенные варианты использования дампа и восстановления

Типичные варианты использования:

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

Миграция из локальной среды или виртуальной машины. База данных Azure для MySQL не поддерживает восстановление физических резервных копий, что делает логическое резервное копирование и восстановление единственным возможным подходом.

Перемещение хранилища резервных копий из локально избыточного в геоизбыточное хранилище. База данных Azure для MySQL позволяет настроить локально избыточное или геоизбыточное хранилище для резервного копирования только при создании сервера. После подготовки сервера невозможно изменить тип избыточности для хранилища резервных копий. Чтобы переместить хранилище резервных копий из локально избыточного хранилища в геоизбыточное хранилище, единственным вариантом является дамп и восстановление.

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

Вопросы производительности

Для оптимизации производительности при дампе больших баз данных мы рекомендуем ознакомиться с рекомендациями ниже.

Создание базы данных в целевой службе базы данных Azure для сервера MySQL Server

Создайте пустую базу данных в целевой базе данных Azure для сервера MySQL, куда необходимо перенести данные. Для этого используйте такое средство, как MySQL Workbench или mysql.exe. База данных может иметь то же имя, что и база данных, содержащая данные дампа. Вы также можете создать базу данных с другим именем.

Чтобы подключиться, найдите сведения о подключении на странице Обзор базы данных Azure для MySQL.

Добавьте сведения о подключении в MySQL Workbench.

Подготовка целевого сервера базы данных Azure для MySQL для быстрой загрузки данных

Чтобы подготовить целевой сервер базы данных Azure для MySQL для ускорения загрузки данных, необходимо изменить следующие параметры и конфигурацию сервера.

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

Создание дампа и восстановление с помощью служебной программы mysqldump

Создание файла резервной копии из командной строки с помощью mysqldump

Чтобы создать резервную копию существующей базы данных MySQL на локальном сервере или виртуальной машине, выполните команду ниже:

Необходимо указать следующие параметры:

Чтобы выбрать для создания резервной копии конкретные таблицы в базе данных, укажите имена этих таблиц в виде списка, разделенного пробелами. Например, чтобы создать резервную копию только для таблиц table1 и table2 из базы данных testdb, используйте этот пример:

Восстановление базы данных MySQL с помощью командной строки или MySQL Workbench

После создания целевой базы данных можно воспользоваться командой mysql или клиентом MySQL Workbench, чтобы восстановить данные в определенную вновь созданную базу данных из файла дампа.

В этом примере восстановите данные в созданную базу данных в целевой базе данных Azure для сервера MySQL Server.

Ниже приведен пример использования команды mysql для отдельного сервера.

Ниже приведен пример использования команды mysql для гибкого сервера.

дамп и восстановление с помощью PHPMyAdmin.

Выполните указанные ниже действия, чтобы создать дамп базы данных и восстановить ее, используя PHPMyadmin.

Для отдельного сервера имя пользователя должно иметь формат «username@servername», а для гибкого сервера можно просто использовать формат username. Если использовать «username@servername» для гибкого сервера, то произойдет сбой подключения.

Экспорт с помощью PHPMyadmin

Для экспорта можно использовать распространенный инструмент phpMyAdmin, который уже может быть установлен в вашей локальной среде. Чтобы экспортировать базу данных MySQL с помощью PHPMyAdmin, выполните следующие действия:

Импорт с помощью PHPMyAdmin

Импорт базы данных выполняется подобно экспорту. Выполните следующие действия:

Известные проблемы

Сведения об известных проблемах, советы и рекомендации см. в блоге технического сообщества.

Источник