Бэкап бд mysql: Создание резервной копии базы данных MySQL

Резервное копирование и восстановление СУБД MySQL / Хабр

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

Следующий раздел предназначен для тех, кто не читал статью по бэкапам PostgreSQL, так как он повторяет основные моменты теории резервного копирования.

Сколько терять и за сколько восстанавливать

Итак, вспомним такие понятия как RPO и RTO.

Recovery Point Objective – максимально допустимый интервал за который мы можем позволить себе потерять данные. Например, если у нас RPO равно двум часам, то в случае сбоя мы потеряем данные максимум за последние два часа.

Recovery Time Objective — промежуток времени, в течение которого БД может оставаться недоступной в случае сбоя. То есть это то время, за которое мы обязуемся восстановить наши данные из бэкапа.

На картинке расстояние до сбоя это RPO (обычно измеряется в часах) а RTO это то расстояние-время, которое у нас останется на восстановление.

 

 Однако, RTO и RPO нельзя назвать чисто техническим понятиями, в определенной степени это характеристики, позволяющие обеспечивать непрерывность бизнес процессов. Значения величин RTO и RPO должны указываться владельцами бизнес систем, а ИТ специалисты должны в ответ выдвинуть свои требования относительно оборудования и программного обеспечения для выполнения этих требований. Например, если бизнесу необходимо, чтобы в случае аварии данные были потеряны не более чем за час, а процесс восстановления должен занимать не более 30 минут, то админы в ответ должны сказать хранилища какого размера им необходимы, с какими характеристиками по скорости работы дисков и каналов передачи данных. То есть ИТ готовит спецификацию на необходимое оборудование и ПО с ценами, бизнес посмотрев на все это пони мает, что может быть два или даже три часа простоя это не так уж и страшно, да и восстанавливаться можно подольше. В результате согласовываются новые значения RTO и RPO и стоимость спецификации снижается. Такой подход позволяет разделить ответственность между всеми сторонами. Однако очень часто присутствует другой подход к политике резервного копирования, когда ИТ сами устанавливают значения RTO и RPO и сами пытаются их выполнять без согласования с бизнесом, что является в корне неверным.

Виды бэкапов в MySQL

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

Физический бэкап предполагает создание резервных копий на файловом уровне. В простейшем случае, мы просто останавливаем базу и копируем файлы из рабочей папки (/var/lib/mysql/db/). Просто и быстро. Но не стоит забывать, что при использовании для бэкапа команд операционной системы (например cp) возможны ситуации, когда полученные после копирования файлы окажутся поврежденными и база не будет работать корректно. Такое может произойти, например при копировании в моменты высокой загрузки сервера или при копировании по сети. 

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

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

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

Альтернативным вариантом является использование сторонних средств резервного копирования, например Percona XtraBackup.

Логический бэкап

Для экспорта информации из базы данных в формате SQL можно использовать утилиту mysqldump. Вот ее синтаксис:

$ mysqldump опции имя_базы [имя_таблицы] > файл.sql

Например:

mysqldump --all-databases > dump-data. sql

То есть мы указываем имя базы или таблицы и перенаправляем вывод в файл. Но бэкап можно делать также удаленно. Как правило в сети имеется централизованный сервер резервного копирования с которого осуществляются подключения к узлам для выполнения бэкапов. В таком случае синтаксис команды будет следующий:

mysqldump -h хост -P порт -u имя_пользователя -p имя_базы > data-dump.sql

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

mysql> CREATE DATABASE new_database;

shell> mysql < dump-data.sql

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

В следующем примере мы делаем бэкап базы,заданной в переменной DBNAME и затем сжимаем полученный файл с помощью gzip.

mysqldump -uroot -p ${DBNAME} | gzip > /tmp/${DBNAME}. sql.gz

Когда нужно не все

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

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

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

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

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

nano /etc/mysql/mysql.cnf

Укажем значение параметров log-bin, expire_log_days, max_binlog_size.

Далее перезапустим сервис.

service mysql restart

Каждая инкрементальная копия содержит изменения, которые были созданы с момента последней резервной копии, но самая первая резервная копия должна быть полной копией. Вам необходимо создать полную резервную копию через mysqldump, используя параметры —flush-log и —delete-master-logs, ––delete-master-logs удалит старые двоичные файлы журнала, а —flush-log инициализирует запись нового двоичного файла журнала.

Результаты заархивируем.

mysqldump --flush-logs --delete-master-logs --single-transaction --all-databases | gzip > /var/backups/mysql/$(date +%d-%m-%Y_%H-%M-%S)-inc.gz

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

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

#путь к файлу с двоичными журналами
binlogs_path=/var/log/mysql/
#путь к каталогу с бэкапами
backup_folder=/var/backups/mysql/
#создаем новый двоичный журнал
sudo mysql -E --execute='FLUSH BINARY LOGS;' mysql
#получаем список журналов
binlogs=$(sudo mysql -E --execute='SHOW BINARY LOGS;' mysql | grep Log_name | sed -e 's/Log_name://g' -e 's/^[[:space:]]*//' -e 's/[[:space:]]*$//')
#берем все, кроме последнего
binlogs_without_Last=`echo "${binlogs}" | head -n -1`
#отдельно последний, который не нужно копировать
binlog_Last=`echo "${binlogs}" | tail -n -1`
#формируем полный путь 
binlogs_fullPath=`echo "${binlogs_without_Last}" | xargs -I % echo $binlogs_path%`
#сжимаем журналы
zip $backup_folder/$(date +%d-%m-%Y_%H-%M-%S). zip $binlogs_fullPath
#удаляем сохраненные файлы журналов
echo $binlog_Last | xargs -I % sudo mysql -E --execute='PURGE BINARY LOGS TO "%";' mysql

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

cron -e

0 0 * * * sudo mysqldump --flush-logs --delete-master-logs --single-transaction --all-databases | gzip > /var/backups/mysql/full_$(date +%d-%m-%Y_%H-%M-%S).gz

*/60 * * * * sudo bash ~/scripts/скрипт_инкрментального_бэкапа

Восстановление

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

gunzip < 01-10-2020_20-08-41-full.gz

unzip \*.zip -d logs

cd logs

В отличие от полной резервной копии, созданной с помощью mysqldump, двоичные файлы журнала содержат двоичные данные. Перед их восстановлением их необходимо преобразовать в sql-выражения, и за это отвечает утилита mysqlbinlog. Эта утилита получает двоичные файлы журнала в качестве входных данных и возвращает инструкции sql. Несколько файлов можно перечислить через пробел. Не забываем о том, что порядок перечисления файлов очень важен, именно в таком порядке SQL операторы и будут выполнены.

mysqlbinlog mysql-bin.000040 mysql-bin.000059  mysql-bin.000123 | sudo mysql -u root

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

mysqlbinlog $(ls) | sudo mysql -u root

Таким образом можно снизить время, необходимое на создание бэкапов и сэкономить место для их хранения.

Заключение

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

Также напоминаю о том, что уже скоро в OTUS пройдет открытое занятие, посвященное погружению в PostgreSQL. Урок будет включать в себя:

1. Знакомство с базой данных – особенности, немножко истории, полезность и актуальность.

2. Способы развертывания и установки, сама установка.

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

Записаться можно на странице курса «Базы данных».

Как сделать бэкап и восстановить БД MySQL

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

• Как сделать бэкап через командную строку (используя mysqldump)
• Как сделать бэкап MySQL БД со сжатием
• Как восстановить БД MySQL из бэкапа
• Бэкап и восстановление через adminer

Как сделать бэкап через командную строку (используя mysqldump)

Если у вас есть доступ к серверу через консоль (SSH) вы можете быстро делать бэкапы и разварачивать их обратно. Эта позволяет быстро создавать дамп базы данных (дамп — это текстовый вариант БД) и восстанавливать их обратно, быстрее чем через phpmyadmin, adminer и прочее. Дамп базы будет состоять из SQL-команд для создания копии вашей БД. Вот команда создания дампа: 

$ mysqldump --opt -u [uname] -p[pass] [dbname] > [backupfile.sql]

[uname] — Имя пользователя БД (возможно root)
[pass] — пароль к вашему пользователю, можно писать слитно если он без каких-то особых знаков и пробелов, например -proot, -ppassword
[dbname] — имя вашей БД
[backupfile.sql] — имя файлу куда будет сохранен бэкап
[—opt] — опции к команде mysqldump, можно пропустить и не писать

Допустим у вас есть база данных Drupal, а имя пользователя root с паролем password и имя файла будет backup.sql, тогда команда будет такая:

$ mysqldump -u root -ppassword DrupalDB > backup.sql

Можно опустить пароль или пароль содержит пробелы и другие особые знаки (#!,-_), то тогда вам придется вводить пароль отдельно и команда будет такая: 

$ mysqldump -u root -p DrupalDB > backup. sql

Вы можете также бэкапить отдельные таблицы, для этого нужно перечислять таблицы через пробел, например nodes users: 

$ mysqldump -u root -p DrupalDB nodes users > backup.sql

Помимо того чтобы бэкапить отдельные таблицы, можно бэкапить сразу несколько БД, для этого нужно указать параметр —databases это позволит через пробел указать нужные БД:

$ mysqldump -u root -p --databases DrupalDB Drupal7 Drupal8 > backup.sql

Если вы хотите перенести сервер MySQL полностью, то вы можете скопировать все данные с помощью параметра —all-databases:

$ mysqldump -u root -p --all-databases > alldb_backup.sql

Команда mysqldump имеет также несколько полезных параметров:

—add-drop-table — позволяет удалять таблицы перед разварачиваем этого бекапа (то есть в дамп будет добавлены SQL-запросы DROP TABLE перед CREATE TABLE той же таблицы).

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

—add-lock

— позволяет добавить LOCK TABLES и UNLOCK TABLES. Если размер БД большой то таблицы могут быть залочены на продолжительное время.

 Как сделать бэкап MySQL БД со сжатием

Пожалуй наиболее подходящий варинт, потому что сжать удается в 10-20 раз и бэкапы из больших баз данных становится вполне небольших размеров. Для сжатия мы будем пользоваться командой gzip:

$ mysqldump -u root -p DrupalDB | gzip -9 > backup.sql.gz

Если вы хотите разархивировать файл (не восстановить БД, а просто разархивировать), то воспользуйтесь этой командой:

$ gunzip backup.sql.gz

Как восстановить БД MySQL из бэкапа

Для восстановления БД из дампа, вам нужна чистая БД, можете удалить таблицы с помощью adminer’а или phpmyadmin’а. Если вы использовали параметр —add-drop-table, то таблицы сами удаляться и зальются и ничего удалять прежде не нужно. Вот команда чтобы восстановить БД из дампа:

$ mysql -u root -p DrupalDB < backup. sql

Если у вас был сжатый бэкап, то воспользуйтесь этой командой:

gunzip < backup.sql.gz | mysql -u root -p DrupalDB

 Бэкап и восстановление через Adminer (замена PhpMyAdmin)

 Adminer — это замена PhpMyAdmin. Он такой же по функционалу, только сделан в виде одного небольшого файла, что весьма удобно:

http://www.adminer.org/

Просто копируем файл в корень нашего сайта и обращаемся к нему через браузер:

http://имя_вашего_сайта/adminer-4.2.1.php (можете переименовать в adminer.php для удобства):

Авторизируемся и заходим в нужную нам БД, у меня это Drupal7.

Теперь нажимаем Экспорт (Dump) и выгружаем данные. Причем мы можем не выгружать ненужные нам данные кэша:

Для загрузки дампа обратно используйте вкладку Импорт (Import):

Как создать резервную копию и восстановить базу данных MySQL {Простое руководство}

Введение

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

В этом руководстве мы представляем два простых способа резервного копирования и восстановления базы данных MySQL.

Необходимые условия

• Операционная система Linux
• Установленная MySQL
• Существующая база данных
• Утилита Mysqldump (должна быть включена в программное обеспечение MySQL)

Резервное копирование из командной строки с помощью mysqldump база данных.

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

Общий синтаксис для резервного копирования базы данных MySQL:

 sudo mysqldump -u [пользователь] -p [имя_базы_данных] > [имя_файла].sql 

• Замените [ user ] своим именем пользователя и паролем (при необходимости).
• [ имя_базы_данных ] — это путь и имя файла базы данных.
• Команда > определяет вывод.
• [ имя файла ] — это путь и имя файла, под которым вы хотите сохранить файл дампа.

Другие примеры:

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

 mysqldump --all-databases --single-transaction --quick --lock-tables=false > full-backup-$(date + %F).sql -u корень -p 

Чтобы включить более одной базы данных в файл дампа резервной копии:

 sudo mysqldump -u [пользователь] -p [база_1] [база_2] [база_данных] > [имя_файла].sql 

Как восстановить MySQL с помощью mysqldump

Шаг 1: Создайте новую базу данных

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

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

Шаг 2: Восстановите дамп MySQL

Чтобы восстановить резервную копию MySQL, введите:

 mysql -u [пользователь] -p [имя_базы_данных] < [имя_файла].sql 

Обязательно включите [имя_базы_данных] и [имя файла ] в пути.

Вполне вероятно, что на хост-компьютере [имя_базы_данных] может находиться в корневом каталоге, поэтому вам может не понадобиться добавлять путь. Убедитесь, что вы указали точный путь к файлу дампа, который вы восстанавливаете, включая имя сервера (при необходимости).

Использование phpMyAdmin для резервного копирования или восстановления MySQL

Если вы используете phpMyAdmin для резервного копирования и восстановления базы данных MySQL  , это просто.

Функция экспорта используется в качестве резервной копии, а функция импорта используется для восстановления.

Шаг 1: Создайте резервную копию базы данных MySQL

1. Откройте phpMyAdmin. В дереве каталогов слева щелкните базу данных, резервную копию которой вы хотите создать.

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

2. Нажмите Экспорт в меню в верхней части дисплея.

Вы увидите раздел «Метод экспорта». Используйте Quick , чтобы сохранить копию всей базы данных. Выберите Пользовательский , чтобы выбрать отдельные таблицы или другие специальные параметры.

Оставьте в поле Format значение SQL, , если у вас нет веской причины изменить его.

3. Щелкните Перейти. Если вы выберете Quick, ваш веб-браузер загрузит копию базы данных в указанную вами папку загрузок. Вы можете скопировать это в безопасное место.

Шаг 2. Удаление старой информации из базы данных  

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

1. Откройте phpMyAdmin, на панели навигации слева выберите базу данных, которую хотите восстановить.

2. Нажмите на поле отметить все внизу. Затем используйте раскрывающееся меню с пометкой С выбранными  , чтобы выбрать Drop.

3. Инструмент должен предложить вам подтвердить, что вы хотите продолжить. Нажмите да.

Это позволит избавиться от всех существующих данных, расчистив путь для вашего восстановления.

Шаг 3. Восстановите резервную копию базы данных MySQL

В phpMyAdmin для восстановления базы данных используется инструмент Import .

1. В верхнем меню выберите Import .

2. Первая секция имеет маркировку Файл для импорта. Парой строк ниже есть строка, начинающаяся с «Просмотрите свой компьютер» с кнопкой с надписью «Выбрать файл». Нажмите эту кнопку.

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

4. Нажмите Перейти.

Заключение

Теперь вы знаете, как сделать резервную копию и восстановить базу данных MySQL с помощью phpMyAdmin или mysqldump.

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

Если вы хотите узнать больше о том, как выполнять регулярное резервное копирование MySQL, ознакомьтесь с нашей статьей о настройке репликации master-slave в MySQL. А чтобы узнать о различных способах анализа и восстановления базы данных, обязательно прочитайте нашу статью о том, как восстановить базу данных MySQL.

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

• Фейсбук
• Твиттер
• LinkedIn

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

Прежде чем мы начнем, наше руководство «Создание резервной копии базы данных MySQL с помощью MySQL Workbench» охватывает часть уравнения резервного копирования (с использованием MySQL Workbench).

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

Настройка MySQL Workbench для подключения к вашей базе данных

Многие коммерческие хосты блокируют внешние подключения к базе данных, поэтому вам может потребоваться добавить свой домашний или офисный IP-адрес в список удаленного доступа. Узнайте у своего хоста, каковы их требования. Если на вашем веб-сайте используется cPanel, вы можете настроить удаленное подключение в разделе Базы данных > Удаленный MySQL.

Откройте MySQL Workbench и щелкните значок +, чтобы начать новое подключение к базе данных.

Заполните пять полей подключения и авторизации, подчеркнутых ниже.

• Дайте имя соединению.
• Выберите «Стандартный (TCP/IP)» в качестве «Способа подключения» (конфигурация подключения SSH доступна, если этого требует ваш хост).
• Введите имя хоста или IP-адрес сервера MySQL.
• Введите имя пользователя базы данных MySQL.
• Нажмите кнопку «Сохранить в хранилище…», чтобы ввести пароль базы данных (если вы не хотите сохранять пароль, пропустите это поле).

Нажмите кнопку «Проверить соединение».

Если вы получаете сообщение об ошибке «Не удается подключиться к серверу базы данных», проверьте свои записи в полях подключения.

Если все верно, вы увидите окно успешного подключения. Нажмите кнопку «ОК» и двигайтесь дальше.

Теперь нажмите кнопку «ОК» в «Управление подключениями к серверу», чтобы закрыть окно проверки подключения.

Настройка MySQL Workbench для восстановления (импорта) базы данных

Установите флажок для соединения с базой данных, которое вы только что установили.

Щелкните ссылку «Импорт/восстановление данных».

В этом руководстве мы предполагаем, что вы восстанавливаете резервную копию «Автономный файл». См. «Создание резервной копии базы данных MySQL с помощью MySQL Workbench» для объяснения разницы между автономным файлом и папкой проекта дампа.

Выберите «Импорт из автономного файла» и найдите файл резервной копии, который будет использоваться для восстановления.

В раскрывающемся списке выберите «Целевая схема по умолчанию». Раскрывающийся список должен быть предварительно заполнен именем схемы из файла резервной копии.

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

Убедитесь, что в раскрывающемся списке выбран пункт «Дамп структуры и данных».

Перейдите на вкладку «Ход импорта».

Нажмите кнопку «Начать импорт».

Когда восстановление будет завершено, вы увидите диалоговое окно «Импорт завершен».

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

Пока вы здесь, давайте немного поговорим о том, что такое MySQL и его интересная история.

Что такое MySQL?

Часто произносится как «мой сиквел», давайте посмотрим, откуда это взялось. Шведская компания под названием MySQL AB, которая первоначально разработала MySQL с открытым исходным кодом еще в 1994. Правильное произношение — «МОЙ-ЕС-КЬЮ-ЭЛЬ». MySQL считается открытым исходным кодом, хотя иногда кажется, что это не так.

Шли годы, когда американская технологическая компания Sun Microsystems приобрела полную собственность, купив MySQL AB еще в 2008 году. После этого крупный американский технологический гигант Oracle приобрел Sun Microsystems, а MySQL перешла в Оракул с тех пор.

Теперь, когда у вас есть немного истории, давайте взглянем на фактическое определение. По сути, MySQL — это система управления реляционными базами данных (RDBMS) с открытым исходным кодом и моделью клиент-сервер. СУБД — это на самом деле программное обеспечение, которое используется для создания и управления базами данных в реляционной модели.

Если вы работаете с чем-то вроде WordPress, то вы хотя бы немного знакомы с базой данных MySQL. Если у вас все еще есть небольшие проблемы с некоторыми из приведенных выше терминов, давайте быстро рассмотрим их вместе.

База данных

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

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

Открытый исходный код

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

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

Модель клиент-сервер

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

MySQL на самом деле является лишь одним из многих вариантов программного обеспечения РСУБД. Многие думают, что это одно и то же из-за популярности MySQL. На самом деле кажется, что все используют его в эти дни.

Крупные организации, которые мы все знаем, такие как Facebook, Twitter, YouTube, Google и Yahoo, используют MySQL для хранения данных. Когда он был впервые создан, MySQL был создан для ограниченного использования. Однако теперь он совместим со многими важными вычислительными платформами, такими как Linux, macOS, Microsoft Windows и Ubuntu.

Отличия MySQL и SQL

Небольшое понимание поможет вам восстановить базу данных MySQL. Важно помнить, что MySQL и SQL — это не одно и то же, и между ними есть несколько очень важных отличий. Прежде чем я покажу вам, как восстановить базу данных MySQL из резервной копии, давайте кратко рассмотрим различия между SQL и MySQL.

• SQL — это язык, используемый для работы с базой данных. MySQL — одна из первых доступных для использования баз данных с открытым исходным кодом.
• SQL — это способ доступа, обновления и управления данными. MySQL — это СУБД, которая позволяет хранить данные, существующие в базе данных, организованно, как описано выше в видео и примере с телефоном.
• SQL — это «язык структурированных запросов». MySQL — это РСУБД для хранения, извлечения, изменения и администрирования базы данных.
• SQL — это язык запросов. MySQL — это программное обеспечение для работы с базами данных.

Заключительные мысли

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

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