По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этом руководстве мы рассказываем, как выполнить резервное копирование и восстановление баз данных MySQL или MariaDB из командной строки с помощью утилиты mysqldump.
Файлы резервных копий, созданные утилитой mysqldump, представляют собой набор операторов SQL, которые можно использовать для воссоздания исходной базы данных. Команда mysqldump также может генерировать файлы в формате CSV и XML. Вы также можете использовать утилиту mysqldump для переноса вашей базы данных MySQL на другой сервер MySQL.
Синтаксис команды Mysqldump
Прежде чем приступить к использованию команды mysqldump, начнем с обзора основного синтаксиса.
Выражения утилиты mysqldump имеют следующую форму:
mysqldump [options] > file.sql
options - параметры mysqldump
file.sql - дамп (резервная копия) файла
Для использования команды mysqldump сервер MySQL должен быть доступен и запущен.
Резервное копирование одной базы данных MySQL
Наиболее распространенный вариант использования инструмента mysqldump - резервное копирование одной базы данных.
Например, чтобы создать резервную копию базы данных с именем database_name, используя пользователя root, и сохранить ее в файл с именем database_name.sql, вы должны выполнить следующую команду:
mysqldump -u root -p database_name > database_name.sql
Вам будет предложено ввести пароль root. После успешной аутентификации начнется процесс дампа. В зависимости от размера базы данных процесс может занять некоторое время.
Если вы вошли в систему как тот же пользователь, которого вы используете для выполнения экспорта, и этот пользователь не требует пароля, вы можете пропустить опции -u и -p:
mysqldump database_name > database_name.sql
Резервное копирование нескольких баз данных MySQL
ля резервного копирования нескольких баз данных MySQL одной командой вам нужно использовать параметр --database, за которым следует список баз данных, которые вы хотите сделать резервную копию. Каждое имя базы данных должно быть разделено пробелом.
mysqldump -u root -p --databases database_name_a database_name_b > databases_a_b.sql
Команда выше создаст файл дампа, содержащий обе базы данных.
Резервное копирование всех баз данных MySQL
Используйте опцию --all-database для резервного копирования всех баз данных MySQL:
mysqldump -u root -p --all-databases > all_databases.sql
Как и в предыдущем примере, команда выше создаст один файл дампа, содержащий все базы данных.
Резервное копирование всех баз данных MySQL в отдельные файлы
Утилита mysqldump не предоставляет возможность резервного копирования всех баз данных в отдельные файлы, но мы легко достигаем этого с помощью простого цикла bash FOR:
for DB in $(mysql -e 'show databases' -s --skip-column-names); do
mysqldump $DB > "$DB.sql";
done
Команда выше создаст отдельный файл дампа для каждой базы данных, используя имя базы данных в качестве имени файла.
Создание сжатой резервной копии базы данных MySQL
Если размер базы данных очень большой, рекомендуется сжать вывод. Для этого просто перенаправьте вывод в утилиту gzip и перенаправьте его в файл, как показано ниже:
mysqldump database_name | gzip > database_name.sql.gz
Создать резервную копию с отметкой времени
Если вы хотите сохранить более одной резервной копии в одном месте, вы можете добавить текущую дату в имя файла резервной копии:
mysqldump database_name > database_name-$(date +%Y%m%d).sql
Команда выше создаст файл в следующем формате database_name-20200223.sql
Восстановление дампа MySQL
Вы можете восстановить дамп MySQL с помощью инструмента mysql. Общий синтаксис команды выглядит следующим образом:
mysqld database_name < file.sql
В большинстве случаев вам необходимо создать базу данных куда вы будете производить импорт. Если база данных уже существует, сначала вам нужно удалить ее.
В следующем примере первая команда создаст базу данных с именем database_name, а затем импортирует в нее дамп database_name.sql:
mysql -u root -p -e "create database database_name";
mysql -u root -p database_name < database_name.sql
Восстановление одной базы данных MySQL из полного дампа MySQL
Если вы создали резервную копию всех своих баз данных с помощью параметра -all-database и хотите восстановить одну базу данных из файла резервной копии, который содержит несколько баз данных, используйте параметр --one-database, как показано ниже:
mysql --one-database database_name < all_databases.sql
Экспорт и импорт базы данных MySQL одной командой
Вместо того, чтобы создавать файл дампа из одной базы данных и затем импортировать резервную копию в другую базу данных MySQL, вы можете использовать следующую однострочную команду:
mysqldump -u root -p database_name | mysql -h remote_host -u root -p remote_database_name
Команда выше передаст вывод клиенту mysql на удаленном хосте и импортирует его в базу данных с именем remote_database_name. Перед выполнением команды убедитесь, что база данных уже существует на удаленном сервере.
Автоматизация резервного копирования с помощью Cron
Автоматизация процесса резервного копирования баз данных так же проста, как создание задания cron, которое будет запускать команду mysqldump в указанное время.
Подробно про cron можно прочитать в нашей статье.
Чтобы настроить автоматическое резервное копирование базы данных MySQL с помощью cronjob, выполните следующие действия:
Создайте файл с именем .my.cnf в вашем домашнем каталоге пользователя:
sudo nano ~/.my.cnf
Скопируйте и вставьте следующий текст в файл .my.cnf.
[client]
user = dbuser
password = dbpasswd
Не забудьте заменить dbuser и dbpasswd на пользователя базы данных и пароль пользователя.
Ограничьте права доступа к файлу учетных данных, чтобы только ваш пользователь имел к нему доступ, используя команду cmod (подробнее про которую можно прочесть тут):
chmod 600 ~/.my.cnf
Создайте каталог для хранения резервных копий при помощи комадны mkdir (про нее тоже есть статья):
mkdir ~/db_backups
Откройте ваш пользовательский файл crontab:
crontab -e
Добавьте следующее задание cron, которое будет создавать резервную копию имени базы данных mydb каждый день в 3 часа ночи:
0 3 * * * /usr/bin/mysqldump -u dbuser mydb > /home/username/db_backups/mydb-$(date +%Y%m%d).sql
Не забудьте заменить username вашим реальным именем пользователя.
Вы также можете создать еще один cron job, чтобы удалить любые резервные копии старше 30 дней:
find /path/to/backups -type f -name "*.sql" -mtime +30 -delete
Конечно, вам нужно настроить команду в соответствии с вашим местоположением резервной копии и именами файлов. Чтобы узнать больше о команде find, ознакомьтесь с нашим Руководством по поиску файлов в Linux с помощью командной строки.
Заключение
Это руководство охватывает только основы, но оно должно быть хорошим началом для тех, кто хочет научиться создавать и восстанавливать базы данных MySQL из командной строки с помощью утилиты mysqldump. Если вы хотите найти больше материалов про базы данных, то просто наберите sql в нашем поиске!
Веб-разработчики являются неотъемлемой частью эпохи Интернета. Веб-сайты и мобильные страницы, с которых мы получаем большую часть нашей информации, совершаем покупки, бронируем билеты и так далее, созданы и управляются веб-разработчиками. Веб-разработчики - это люди, которые проектируют и разрабатывают веб-сайты и мобильные приложения. Они используют несколько языков программирования для реализации необходимых функций. Веб-приложение или мобильное приложение имеют множество различных компонентов, которые взаимодействуют друг с другом для создания всей функциональности системы. Из-за этого сложного характера веб-разработчиков можно разделить на Front-End, Back-End и Full-stack разработчиком.
Как стать веб-разработчиком
Front-End веб-разработчики также известны как разработчики на стороне клиента. Они работают над внешним видом и ощущением веб-приложения. Вы, наверное, не раз слышали эти модные аббревиатуры UX и UI, которые как раз обозначают User Experience (пользовательский опыт) и User Interface (пользовательский интерфейс), за которые ответственен фронтенд разработчик.
Back-End разработчики используют языки программирования и реляционные базы данных для интеграции внешнего интерфейса с внутренним. Со временем наборы умений фронт-энда и бэк-энда разработчиков пересекались, и в настоящее время индустрия предпочитает разработчиков с мастерством в обоих. Такие эксперты называются Full Stack Developers, и они обладают навыками как Front-End, так и Back-End разработки.
Давайте рассмотрим навыки, необходимые для того, чтобы стать веб-разработчиком.
1. Графика или пользовательский интерфейс (UI)
Знание графики или пользовательского интерфейса имеет большое значение для понимания эстетического аспекта веб-дизайна. Это позволяет выявлять и устранять проблемы совместимости между веб-браузерами при отображении страниц.
2. HTML, CSS, JavaScript
Это строительные блоки веб-разработки. Они позволяют разработчику создавать структуру, стиль и содержание веб-сайта. Дополнительное знание сторонних библиотек, таких как jQuery, LESS, Angular и React JS, крайне желательно. HTML определяет структуру представления страниц. CSS обеспечивает контроль над макетом, позволяя создавать точные секционные модули, а также позволяет разработчикам настраивать макет страницы, цвета, шрифты и добавлять эффекты анимации. JavaScript является продвинутым по своей природе, что помогает сделать веб-страницу более интерактивной. Он предлагает изысканные функции, которые помогают сделать веб-страницы более отзывчивыми. Зная DOM, JSON позволяет вам манипулировать Javascript кодом.
3. CMS
Система управления контентом (Content Management Systems) - это приложение, которое позволяет пользователям эффективно публиковать и управлять контентом веб-сайта. Это интуитивно понятный пользовательский интерфейс, который помогает в создании и изменении содержимого веб-страницы. Несмотря на то, что здесь не требуется опыта в программировании бэкэнда, знание HTML и CSS необходимо. В зависимости от используемой CMS вы можете реализовать расширенные функции, установив плагины и расширения. Wordpress, Joomla, Drupal, Magento, Laravel, Typo3, Serendipity, Chamilo - вот некоторые из них, которые стоит добавить в вашу базу знаний.
4. UX
Пользовательский опыт не имеет прямого отношения к знаниям о дизайне; напротив, это относится к аналитическому и техническому пониманию того, как должно работать веб-приложение. Это понимание факторов, которые удерживают пользователей на сайте, помогают им найти то, что они ищут, и оптимизируют поддерживаемые функции.
5. Языки программирования
Языки программирования помогают внедрять интерактивные функции на сайт. Они несут ответственность за возможность хранить, обновлять, манипулировать и получать доступ к данным из базы данных в пользовательский интерфейс. Для веб-разработки основными языками программирования, с которыми нужно ознакомиться, являются Java, Javascript, .NET, PHP, Perl, Python, C, C ++ и Ruby. Выбор языка программирования в основном зависит от программного стека и типа разрабатываемого проекта. Про выбор языка программирования можно прочитать в нашей статье.
6. СУБД
Веб-приложения должны хранить данные, с возможностью для доступа к ним, и когда это необходимо, что требует хорошего знания системы управления реляционными базами данных. Веб-разработчик должен хорошо понимать его синтаксис для создания, обновления, манипулирования и доступа к базе данных до ее оптимального уровня. Он должен понимать разницу между реляционной и нереляционной базой данных наряду со знанием XML/JSON. Понимание особенностей реляционной базы данных, веб-хранилища, знание NoSQL и связей с базами данных укрепляют карьеру веб-разработчика.
7. Программный стек
Это совокупность программных подсистем, которые вместе работают вместе, чтобы создать платформу для поддержки приложения без необходимости в дополнительном программном обеспечении. Говорят, что приложение «работает поверх» определенного программного стека. Независимо от программного стека, всегда существует сходство в архитектуре программного стека. Примеры программных стеков для веб-разработки:
LAMP [Linux | Apache | MySQL | PHP]
MERN [MongoDB | Express | React | Node.js]
MEAN [MongoDB | Express | Angular | Node.js]
Понимание стека программного обеспечения требуется при работе над проектом, поскольку оно дает лучшее техническое представление о разрабатываемом программном обеспечении. Вы можете оптимизировать производительность, предлагать изменения и устранять технические проблемы.
8. SEO
Поисковая оптимизация (Search Engine Optimization) не может считаться обязательным требованием для веб-разработчика. Но знания в этой области помогут вам с самого начала структурировать веб-сайт как оптимизированный для SEO. Это, в конечном счете, облегчит работу профессионалов SEO, но более того, веб-приложение имеет больше шансов на успех.
Итог
Наличие всех вышеперечисленных навыков дает вам возможность выбора из нескольких карьерных возможностей. На сегодняшнем рынке веб-разработчики должны иметь более одного определенного набора навыков.
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через SSH, клонировать клонировать репозиторий с новым кодом, собрать его и запустить через командную строку. Да, такой способ работает, но он малоэффективен. Сегодня мы поговорим об автоматизации процесса разработки и выхода новых версий.
CI и CD – это два сокращения, которые означают Continuous Integration (Непрерывная интеграция) и Continuous Delivery (Непрерывное развертывание).
CI
CI описывает процесс добавления изменений в репозиторий. Ниже схематически представлен простой пример коллективной разработки.
Одновременно может работать целая группа людей, но все изменения передаются в главную ветку master поэтапно. Хотя даже в такой простой схеме возникает несколько вопросов.
Как мы узнаем, что код, который идет в ветку master, компилируется?
Мы хотим, чтобы разработчики писали тесты для кода. Как быть уверенными в том, что тестовое покрытие не уменьшится?
Все сотрудники команды должны форматировать код в соответствие с определенным стилем. Как отследить возможные нарушения?
Конечно же, все это можно проверить вручную. Но такой подход весьма хаотичен. Кроме того, по мере разрастания команды выполнять подобные проверки становится сложнее.
CI используется для автоматизации выше обозначенных пунктов.
Начнем с первого пункта. Как можно проверить, что новые изменения не сломают сборку? Для этого нам потребуется еще один блок в схеме.
Большинство CI-процессов можно описать по следующему алгоритму.
При открытии каждого Pull Request (запроса на включение изменений) и отправке новых изменений, Git-сервер отправляет уведомление CI-серверу.
CI-сервер клонирует репозиторий, проверяет исходную ветку (например bugfix/wrong-sorting) и сливает ее с основной веткой master.
Затем запускается скрипт сборки. Например ./gradlew build.
Если команда возвращает код «0», то сборка прошла успешно. Все остальные значения считаются ошибкой.
CI-сервер отправляет запрос на Git-сервер с результатом сборки.
Если сборка прошла без ошибок, то Pull Request разрешается слить. В противном случае он блокируется.
Данный процесс гарантирует, что код, попадающий в ветку master, не сломает дальнейшие сборки.
Проверка тестового покрытия
Давайте немного усложним задачу. Предположим, нам захотелось установить минимальный охват тестового покрытия. Это означает, что в любой момент времени покрытие ветки master должно быть не менее 50%. Плагин Jacoco идеально справляется с этой задачей. Вы просто настраиваете его так, чтобы при охвате тестового покрытия ниже допустимого, сборка уходила в ошибку.
Реализовать такой подход проще некуда. Но есть небольшая оговорка. Этот метод работает только при условии, что плагин настраивался на старте проекта.
Представим ситуацию: вы работаете над проектом, которому уже 5 лет. С момента первого коммита никто не проверял тестовое покрытие. Разработчики добавляли тесты в случайном порядке и без какой-либо организации. Но вот однажды вы решаете увеличить количество тестов. Вы настраиваете плагин Jacoco на минимальную планку в 60%. Спустя какое-то время разработчик открывает новый Pull Request. Затем разработчики вдруг понимают, что покрытие – всего лишь 30%. Так что для успешного закрытия задачи нужно покрыть не менее 30% кода продукта. Как вы можете догадаться, для проекта 5-летней давности – это практически неразрешимая проблема.
Но что, если будут проверяться только будущие изменения в коде, а не весь продукт? Если в Pull Request разработчик изменит 200 строк, то нужно будет охватить не менее 120 из них (при тестовом покрытии в 60%). Тогда не придется проходить по множеству модулей, которые не относятся к задаче. В принципе, проблема решаема. Но как применить все это к проекту? К счастью, есть решение.
Отчет Jacoco отправляется на сервер тестового покрытия.
Одно из самых популярных решений – SonarCloud.
Сервер хранит статистику по предыдущим вычислениям. Это очень удобно: вычислять тестовое покрытие не только всего кода, но и будущих изменений. Затем результат анализа отправляется на CI-сервер, который перенаправляет его на Git-сервер.
Такая рабочая модель позволяет применять культуру обязательного тестирования на любой стадии развития продукта, поскольку проверяется лишь часть изменений.
Если говорить о стиле оформления кода, то отличий практически нет. Можете попробовать плагин Checkstyle. Он автоматически отклоняет сборку, которая нарушает любое из заявленных требований. Например, в коде есть неиспользованный импорт. Кроме того, вы можете присмотреться к облачным сервисам, которые выполняют анализ кода и визуально отображают результаты в виде графиков (SonarCloud это тоже умеет).
CD
CD описывает процесс автоматического развертывания новой версии продукта.
Давайте еще немного подкорректируем схему CI. Вот так конвейерный процесс CI/CD мог бы выглядеть в реальном проекте.
Первое отличие – теперь CI-сервер называется CI/CD-сервером. Дело в том, что зачастую оба процесса (CI и CD) выполняются одним и тем же диспетчером задач. Так что мы будем рассматривать именно этот случай.
Но так бывает не всегда. Например, задачи по интеграции могут делегироваться на GitLab CI, а задачи по доставке – отдаваться в Jenkins.
Правая часть схемы изображает CI. Мы обсудили ее выше. Слева показана CD. Задача по CD создает проект (или повторно использует артефакты, полученные на стадии CI) и развертывает его на конечном сервере.
Стоит отметить, что сервер в нашем случае – это понятие абстрактное. Например, развертывание может выполняться в кластер Kubernetes. Так что самих серверов может быть несколько.
Обычно после стадии развертывания на почту приходят сообщения о выполнении. Например, CD-сервер может уведомлять подписчиков об успешном развертывании/ошибках.
В любом случае, возникает важный вопрос. В какой момент мы должны запускать задачи по CD? Триггеры могут быть разными.
Развертывание после каждого слияния Pull Request.
Развертывание по расписанию.
Развертывание после каждого слияния Pull Request с определенной веткой.
Сочетание нескольких вариантов.
В первом пункте процесс выстроен так, что задачи по CI и CD всегда выполняются последовательно. Данный подход весьма популярен при разработке программ с исходным кодом. Библиотека Semantic Release помогает настроить проект для прозрачной интеграции данной модели.
Важно помнить о трактовке понятия deploy (развертывание). Это не всегда «что-то где-то запустить». Например, при разработке библиотеки, нет никакого запуска. В данном случае процесс развертывания означает выпуск новой версии библиотеки.
Второй пункт не зависит от процесса CI, ведь проект развертывается по определенному расписанию. Например, ежедневно в 01:00.
Третий пункт аналогичен первому, но с небольшими отличиями. Предположим, в репозитории у нас есть 2 основные ветки: develop и master. В develop содержатся самые последние изменения, а в master – только релизы версий. Если мы хотим развертывать только ветку master, то не нужно вызывать CD-задачу по слиянию в develop.
Последний пункт – это сочетание подходов. Например, ветку develop можно развертывать по расписанию в среду разработки. А ветку master – в реальную среду по каждому слиянию Pull Request.
Инструменты
На рынке доступно множество решений по автоматизации процессов CI/CD. Ниже представлено несколько продуктов.
Jenkins. Один из самых востребованных инструментов CI/CD в мире. Свою популярность он заслужил, благодаря политике открытого кода (open-source). То есть вам не нужно ни за что платить. В Jenkins вы можете императивно описывать конвейеры сборки с помощью Groovy. С одной стороны это достаточно гибкое решение, но с другой – требует более высокого уровня квалификации.
GitHub Actions. Этот инструмент для CI/CD доступен для GitHub и GitHub Enterprise. В отличие от Jenkins, GitHub Actions предлагает декларативные сценарии сборки с YAML-конфигурацией. Кроме того, в данном решении доступна интеграция с различными системами обеспечения качества (например SonarCube). Таким образом, сборку можно описать в нескольких текстовых строках.
GitLab CI. Во многом похож на GitHub Actions, но со своими особенностями. Например, GitLab CI может указывать на определенные тесты, вызывающие ошибку в сборке.
Travis CI. Облачный CI/CD-сервис. Предлагает множество возможностей, не требующих сложных настроек. Например, шифрование данных, которые следует скрыть в публичном репозитории. Есть и приятный бонус в том, что Travis CI можно совершенно бесплатно использовать в публичных open-source проектах на GitHub, GitLab и BitBucket.