Дампы базы данных что это

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

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

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 с синтаксисом:

Источник

Как создать дамп базы данных

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

Сервер с панелью управления ISPmanager

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

ISPmanager

phpMyAdmin

Вы будете автоматически авторизованы в phpMyAdmin под пользователем, которому принадлежит выбранная база данных. Чтобы скачать дамп, перейдите в раздел «Экспорт» :

Здесь можно выбрать метод экспорта: быстрый — с минимумом настроек, или обычный — полностью настраиваемый экспорт, и нажать «Вперёд» — скачается дамп вашей базы данных.

Сервер без панели управления

Adminer

Админер — это php-скрипт, который предоставляет все основные возможности для управления базами данных сайта через графический интерфейс в браузере.

Чтобы начать работать с ним, достаточно скачать его с официального сайта на сервер и открыть в браузере:

Скачиваем скрипт на сервер в корневую папку нашего сайта:

Ссылку на актуальную версию скрипта можно найти на официальном сайте.

Настраиваем права доступа на скачанный скрипт:

Открываем загруженный скрипт в браузере по адресу:

После таких нехитрых манипуляций откроется интерфейс для управления базами данных. Для авторизации вам потребуются:

Чтобы создать дамп базы, после подключения в меню слева выберите «Экспорт» :

Выберите, какие данные хотите включить в дамп.

Чтобы скачать дамп, в строке «Выходные данные» выберите пункт «Сохранить» и нажмите «Экспорт»: дамп будет загружен на ваш компьютер.

Ручной дамп базы

Создать дамп базы вручную можно одной командой:

где db-username — имя пользователя базы данных, db-name — название базы данных, dump.sql — имя файла, в который будет записан дамп. Система запросит пароль указанного пользователя базы и запишет дамп в текущую рабочую директорию на сервере.

Если нужно скачать несколько баз, можно использовать модифицированную версию команды:

А так можно сделать дамп сразу всех баз данных:

Синтаксис команды прост:

Источник

Что такое дамп базы данных 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) необходимо хранить в надежном месте.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По окончании резервного копирования нужно перевести базу данных обратно в обычное состояние. В 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 умеет объединять инкрементальные копии.

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

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

Источник