Как восстановить базу mysql

Введение

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

1. Установка CentOS 8.
2. Настройка CentOS 8.
3. Установка и настройка zabbix сервера.

То же самое на Debian 10, если предпочитаете его:

1. Установка Debian 10.
2. Базовая настройка Debian.
3. Установка и настройка zabbix на debian.

Несколько слов о том, что именно мы будем мониторить. Посмотреть статус репликации можно с помощью простой команды в консоли mysql:

MariaDB > show slave status\G;

Нас будут интересовать три параметра:

• Seconds_Behind_Master — то, насколько слейв сервер отстает от мастера в репликации.
• Slave_IO_Running — индикатор работы демона по сбору бинарного лога с мастера и записи его в локальный relay лог.
• Slave_SQL_Running — индикатор выполнения команд из локального relay лога.

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

Реализовывать будем так же как и в случае с мониторингом nginx и php-fpm через скрипт и UserParameter. Если у вас репликация master-mastert, то настраиваете мониторинг на обоих серверах.

Я буду настраивать мониторинг на сервере CentOS 7, но в данном случае это не имеет принципиального значения. Настройки будут идентичны практически на любом linux дистрибутиве.

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

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

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

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

Примечание

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

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

В простой модели восстановления резервные копии файлов для чтения и записи должны создаваться вместе. Это гарантирует восстановление базы данных до согласованного момента времени. Вместо того чтобы указывать каждый файл или файловую группу для чтения и записи, воспользуйтесь параметром READ_WRITE_FILEGROUPS. Этот параметр создает резервные копии всех файловых групп, доступных для чтения и записи, в базе данных. С помощью параметра READ_WRITE_FILEGROUPS создаются так называемой частичной резервной копией. Дополнительные сведения см. в разделе Частичные резервные копии (SQL Server).

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

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

Восстановить базу данных лишь из файла и резервных копий журналов может оказаться сложно. Поэтому лучше выполнить полное резервное копирование базы данных, а затем начать резервное копирование журнала, чем сразу создавать резервную копию файлов. На следующем рисунке показана стратегия, согласно которой создается полная резервная копия базы данных (за время t1) вскоре после создания базы данных (за время t0). Эта первая резервная копия базы данных позволяет начать резервное копирование журнала транзакций. Резервное копирование журнала транзакций запланировано через определенные промежутки времени. Резервные копии файлов создаются через некоторый интервал времени, оптимально соответствующий требованиям предприятия. На данном рисунке показана каждая из четырех файловых групп, резервное копирование которых происходит одновременно. Порядок, в котором оно производится (группы A, C, B, A), отражает требования предприятия к базе данных.

Примечание

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

Проверяем, кто занимает всю память на сервере

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

Я пошел на сервер и стал разбираться, в чем дело. Начал с того, что посмотрел, кто занимает оперативную память.

# ps aux --sort -rss

или

# ps aux --sort -vsz

Не удивился, увидев, что mysql. Первое, что сделал — перезапустил его и стал наблюдать. Увидел такую картинку в zabbix.

Дальше сервер кушал весь своп и прибивал процесс mysql с сообщением в системном логе:

kernel: Out of memory: Kill process 30609 (mysqld) score 97 or sacrifice child

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

Восстановление резервной копии

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

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

Как заменить данные в datadir?

Рассмотрим два варианта.

Вариант 1

Воспользоваться утилитой XtraBackup. Нужно указать опцию —copy-baсk.

Команда ниже перенесёт резервную копию в datadir целевого сервера:

Вариант 2

Можно поступить иначе, обойтись без утилиты XtraBackup.

Всё, что вам нужно — это скопировать резервную копию в datadir. Вы можете сделать это при помощи cp или rsync.

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

Перед тем, как начать восстановление резервной копии на целевом сервере необходимо:

• Остановить MySQL сервер.

• Очистить папку datadir или перенести её содержимое в другое место. Каталог datadir обязательно должен быть пустым.

После завершения переноса данных в datadir сервер MySQL можно запустить.

Полный бэкап Mysql сервера

Итак, база данных у нас работает, утилиту для бэкапа мы установили. Давайте теперь сделаем полный backup всех баз данных нашего сервера mysql.

# xtrabackup --backup --user=root --password='R(zDXcVUmI[zwx%aNBTN' --target-dir=/root/backupdb/full

backup	инициируем процедуру бэкапа
user=root	пользователь mysql
password=’R(zDXcVUmI[zwx%aNBTN’	пароль пользователя, взятый в одинарные кавычки
target-dir=/root/backupdb/full	директория для создания полного бэкапа mysql

В дальнейших примерах я не буду указывать пользователя и пароль, чтобы упростить команды. Эти данные я указал в файле ~/.my.cnf.

user=root
password='R(zDXcVUmI[zwx%aNBTN'

Мы сделали полный архив всего mysql сервера. В таком виде данные не консистентны, так как они могли меняться во время архивации. Если восстановить их как есть, сервер mysql не запустится. Будет ругаться на поврежденные данные. Чтобы восстановить целостность данных, необходимо выполнить еще одну команду.

# xtrabackup --prepare --target-dir=/root/backupdb/full

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

# xtrabackup --backup --compress --target-dir=/root/backupdb/full

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

# xtrabackup --decompress --target-dir=/root/backupdb/full

Для того, чтобы команда decompress отработала без ошибки:

sh: qpress: command not found
cat: write error: Broken pipe
Error: decrypt and decompress thread 0 failed.

Необходимо установить пакет qpress.

# yum install qpress

Он есть в репозитории percona. После этого распаковка пройдет штатно.

Лично я не вижу большого смысла использовать ключи compress и decompress. Можно сделать полный бэкап, подготовить его, а потом сжать тем же gzip.

# tar -czvf /root/backupdb/full.tar.gz -C /root/backupdb full

На выходе получите тот же архив, только сжат лучше и нет необходимости ставить дополнительный софт. Gzip и tar обычно есть во всех дистрибутивах. К тому же архив в виде единого файла проще и быстрее передать на сервер бэкапов и там хранить.

В завершении раздела про полный backup, предлагаю простенький скрипт для автоматизации процесса через cron — mysql-full-backup.sh.

#!/bin/bash

DATA=`date +%Y-%m-%d`

mkdir -p /root/backupdb/$DATA
xtrabackup --backup --target-dir=/root/backupdb/$DATA/full
xtrabackup --prepare --target-dir=/root/backupdb/$DATA/full
tar -czvf /root/backupdb/$DATA/full.tar.gz -C /root/backupdb/$DATA full
rm -rf /root/backupdb/$DATA/full

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

Бэкап и восстановление mysql с помощью mysqldump

Теперь просто для справки приведу примеры бэкапа и восстановления баз данных mysql с помощью mysqldump. Для небольших баз этого инструмента хватает за глаза и использовать что-то другое не имеет смысла. Преимущество xtrabackup в скорости работы и в возможности без проблем сделать инкрементный бэкап. Если он вам не нужен и база не большая, достаточно будет старого доброго mysqldump.

Бэкап всех баз mysql сервера с его помощью:

# /usr/bin/mysqldump -uroot -hlocalhost -p'password' --all-databases > /root/backupdb/all.sql

Можно сразу же сжимать его.

# /usr/bin/mysqldump -uroot -hlocalhost -p'password' --all-databases | /usr/bin/gzip -c > /root/backupdb/`date "+%Y-%m-%d"`sql.gz

Бэкап конкретной базы данных.

/usr/bin/mysqldump sitemanager -uroot -p'password' | /usr/bin/gzip -c > /root/backupdb/sitemanager_`date "+%Y-%m-%d"`sql.gz

Мне чаще всего мешают в дампе команды на создание базы данных — CREATE DATABASE, поэтому я их убираю ключом no-create-db.

/usr/bin/mysqldump --no-create-db sitemanager -uroot -p'password' | /usr/bin/gzip -c > /root/backupdb/sitemanager_`date "+%Y-%m-%d"`sql.gz

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

# mysql -uroot -p
mysql> use sitemanager;
mysql> source /root/backupdb/sitemanager.sql;

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

mysql> use sitemanager;
mysql> \. /root/backupdb/sitemanager.sql

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

#!/bin/bash

for i in `mysql -uroot -p'password' -e'show databases;' | grep -v information_schema | grep -v Database`; 
    do 
	/usr/bin/mysqldump -uroot -p'password' $i | /usr/bin/gzip -c > /root/backupdb/`date +%Y-%m-%d`-$i.sql.gz;
    done

Так же могу порекомендовать вот этот скрипт для бэкапа — https://github.com/adegtyarev/mysqlbackup. Описывать его не буду, по комментариям в скрипте понятен его функционал.

Если вам нужно из полного бэкапа mysql восстановить отдельную таблицу, то ее можно выделить из полного дампа через обычный awk примерно вот так.

# cat sitemanager.sql | /usr/bin/awk '/CREATE TABLE `b_catalog_discount`/,/UNLOCK TABLES/' > /tmp/b_catalog_discount.sql

Дальше через source можно восстановить данные из этого дампа отдельной таблицы.

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

#!/bin/bash

USER='root'
PASS='R(zDXcVUmI[zwx%aNBTN'

MYSQL="mysql --user=$USER --password=$PASS --skip-column-names";
DIR="/root/backupdb"

for s in mysql `$MYSQL -e "SHOW DATABASES"`;
    do
    mkdir $DIR/$s;
    for t in `$MYSQL -e "SHOW TABLES FROM $s"`;
	do
	    /usr/bin/mysqldump --user="$USER" --password="$PASS" --opt $s $t | /usr/bin/gzip -c > $DIR/$s/$t.sql.gz;
	done
    done

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

for s in mysql sitemanager;

Восстановить потом всю базу из такого потабличного бэкапа можно таким образом.

#!/bin/bash
#

DB=sitemanager;
USER='root'
PASS='R(zDXcVUmI[zwx%aNBTN'
DIR="/root/backupdb/sitemanager"

for s in `ls -1 $DIR`;
    do
    echo "--> $s restoring... ";
    zcat $DIR/$s | /usr/bin/mysql --user=$USER --password=$PASS $DB;
    done

При использовании пароля в открытом виде в mysql или mysqldump, в консоль постоянно сыпятся предупреждения.

mysql:  Using a password on the command line interface can be insecure.

Чтобы их не было, перенесите, как я показывал выше, пароль в отдельный файл ~/.my.cnf, а из скрипта уберите авторизацию вообще.

На этом, пожалуй, насчет бэкапа баз mysql сервера все. Поделился основными своими наработками.

Установка Percona XtraBackup

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

# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

Дальше ставим нужную нам версию программы. Самую последнюю 8.0:

# yum install percona-xtrabackup-80

или 2.4

# yum install percona-xtrabackup-24

Обращаю внимание, что если на сервере с установленным bitrixenv установить просто пакет xtrabackup, без указания версии, будет установлена версия 2.3, которая не работает с уставленным там же по дефолту сервером mysql 5.7. Устанавливаем в Debian/Ubuntu:

Устанавливаем в Debian/Ubuntu:

# wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
# dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb

И сам пакет:

# apt update && apt install percona-xtrabackup-80

Что такое mysqldump?

MySQLdump
– это серверное приложение, которое позволяет делать резервное копирование
(далее дамп) баз данных и сохранять их в отдельном файле. При этом можно
осуществлять гибкие настройки дампа: несколько или все базы данных, архивация в
gzip, добавление команд
lock, drop и многое
другое. Также возможнен обратный импорт резервных копий БД. Осуществлять бэкап базы данных
можно с помощью PHP, но
это неприемлемо для больших проектов, которые имеют большой вес данных.

Эта программа очень полезна при реализации экспорта и
импорта данных с БД. Она может быть стандартно установленной на вашем хостинге
(точнее mysql сервере). Но для того, чтобы отточить мастерство работы с mysqldump и
научится устанавливать, можно поставить ее на denwer. Что мы сейчас и сделаем.

Установка MySQL в Kali Linux

Если вы уже работали с производными Debian (Linux Mint, Ubuntu), то в них присутствуют два пакета:

• mysql-server — сервер MySQL
• mysql-client — клиент MySQL

По умолчанию MySQL уже предустановлена в Kali Linux, но если у вас минимальная сборка, то вам может понадобиться установить СУБД вручную. Если вы попытаетесь установить пакет mysql-server, то получите следующую ошибку:

Пакет mysql-server недоступен, но упомянут в списке зависимостей другого
пакета. Это может означать, что пакет отсутствует, устарел или
доступен из источников, не упомянутых в sources.list

E: Для пакета «mysql-server» не найден кандидат на установку

Дело в том, что в Kali Linux (и видимо в свежих Debian, а также во всех её производных) этот пакет называется по-другому:

• default-mysql-server (исполнимые файлы СУБД и настройка системной базы данных)
• default-mysql-server-core (только исполнимые файлы СУБД)

Поэтому для установки MySQL используйте следующую команду:

sudo apt install default-mysql-server

Настройка MySQL в Kali Linux

Конфигурационные файлы MySQL:

• /etc/mysql/my.cnf (ссылка на /etc/alternatives/my.cnf)
• /etc/mysql/debian.cnf (устаревший файл, будет удалён в будущих версиях)
• /etc/mysql/conf.d/mysql.cnf
• /etc/mysql/conf.d/mysqldump.cnf
• /etc/mysql/mariadb.conf.d/50-client.cnf
• /etc/mysql/mariadb.conf.d/50-mysqld_safe.cnf
• /etc/mysql/mariadb.conf.d/60-galera.cnf
• /etc/mysql/mariadb.conf.d/50-mysql-clients.cnf
• /etc/mysql/mariadb.conf.d/50-server.cnf

Большинство настроек собраны в файле 50-server.cnf. По умолчанию служба MySQL прослушивает входящие подключения только на localhost (невозможны подключения с других компьютеров).

Делаем бэкап баз MySQL

Posted by Makc — 13.04.2010

На моем сервере под управлением FreeBSD 8.0-RELEASE работает mysql-server-5.0.90. В данной статье рассматривается простейший способ выполнения задачи бэкапа и восстановления из архивной копии баз данных MySQL. Для создания архивной копии любой базы данных MySQL существует команда mysqldump. Рассмотрим пример ее использования.

Для этого в командной строке вашего shell выполним:

# mysqldump -u root -p -h localhost -x -F base > /var/backups/base_`date +%Y-%m-%d%n`.sql

где флаги обозначают:-u – указываем привилегированного пользователя на базы MySQL (в данном примере это root);-h – указываем имя хоста, на котором работает MySQL (в данном примере это localhost);-p – указывает на то, что для входа в MySQL привилегированному пользователю (root) требуется ввести пароль;-x – блокируем все таблицы бэкапируемой базы данных от изменений на время работы выгрузки дампа;-F – сбрасываем на диск журнал регистрации сервера MySQL прежде, чем запустить дамп;base – имя бекапируемой базы данных MySQL;/var/backups/base_`date +%Y-%m-%d%n`.sql – путь и имя файла дампа бэкапируемой базы данных MySQL, где `date +%Y-%m-%d%n` припишет к имени файла дату его создания.

В результате работы это команды мы получим файл дампа необходимой нам базы base, который будет выглядеть как:

# ls -Al /var/backups/ | grep base
-rw-r--r--  1 root  wheel   2738944 13 апр 10:03 base_2010-04-13.sql

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

# mysql -u root -h localhost -p

где флаги обозначают:-u – указываем привилегированного пользователя на базы MySQL (в данном примере это root);-h – указываем имя хоста, на котором работает MySQL (в данном примере это localhost);-p – указывает на то, что для входа в MySQL привилегированному пользователю (root) требуется ввести пароль.

В приглашении оболочки MySQL введем команду создания новой базы данных:

mysql> CREATE DATABASE base;

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

mysql> SHOW DATABASES;

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

mysql> USE base;
Database changed
mysql> source /var/backups/base_2010-04-13.sql;

Все, мы создали новую базу данных и загрузили в нее архивную копию. Выйдем из оболочки MySQL:

mysql> exit
Bye

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

# nano -w /var/backups/base_2010-04-13.sql
CREATE DATABASE base;
USE base;

Сохраним внесенные изменения, сделанные в nano, нажав CTRL+x, и подтвердим, нажав по запросу y. Теперь в командной строке вашего shell выполните команду:

# mysql -u root -h localhost -p < /var/backups/base_2010-04-13.sql

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

Вот и все, удачи!

• Currently 4.60/5

Rating: 4.6/5(5 votes cast)

В Kali Linux MySQL заменена на MariaDB

Мы говорим MySQL, но MySQL полностью отсутствует в репозиториях Kali Linux. Независимо от того, была ли эта СУБД предустановлена в вашу систему или вы установили её вручную, вместо неё устанавливается MariaDB.

Вы можете убедиться в этом сами командой:

apt show default-mysql-server

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

MariaDB — это тоже система управления базами данных. Она является ответвлениями от MySQL. Задача MariaDB выполнять все функции MySQL, но быть лучше. Название службы, название конфигурационных файлов не изменились. Просто по привычке я и дальше в этой инструкции буду говорить «MySQL», но мы будем работать исключительно с MariaDB.

Установка Percona Mysql Server

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

Отключаем стандартный модуль mysql и активируем репозиторий перконы.

Устанавливаем Percona Mysql Server на Centos 8. Заодно поставим xstrabackup и другие утилиты, которые нам могут понадобиться в процессе эксплуатации.

После установки запускаем mysql сервер и добавляем в автозагрузку.

Во время установки был автоматически сгенерирован временный пароль root. Посмотреть его можно в логе /var/log/mysqld.log.

Используя этот пароль, выполним начальную настройку сервера, удалив все лишнее и указав свой пароль. Имейте ввиду, что по умолчанию установлен Password Validation Plugin, который не позволит вам создать простой пароль. Он должен удовлетворять следующим требованиям:

• Длина от 8-ми символов;
• Минимум 1 цифра;
• Минимум 1 спецсимвол.

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

Серверы Mysql установили на обоих виртуальных машинах. Двигаемся дальше.

Параметры MySQL

key_buffer

Изменение выделяет больше памяти MySQL, что существенно ускоряет работу базы данных при условии наличия свободной памяти. Размер обычно должен занимать не более 25% системной памяти при использовании MyISAM и до 70% для InnoDB. Если значение установлено слишком высоко, ресурсы расходуются впустую.

Согласно документации MySQL, для серверов с 256MB (или более) ОЗУ с множеством таблиц рекомендуется настройка 64M. Серверы с 128MB ОЗУ и меньшим количеством таблиц могут быть настроены на 16M — это значение по умолчанию. Веб-сайты с еще меньшим числом ресурсов и таблиц могут быть ограничены даже меньшим объемом.

max_allowed_packet

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

thread_stack

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

thread_cache_size

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

max_connections

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

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

table_cache

Это значение должно быть больше, чем значение . Для определения этого значения используйте:

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

Синтаксис и базовая команда

Создание дампа выполняется из командной строки Linux или Microsoft. Общий синтаксис:

mysqldump -p <база> > <в какой файл сделать дамп>

Пример базовой команды для резервирования базы:

mysqldump -v -uroot -p base > /tmp/dump.sql

* в данном примере мы создадим резервную копию базы base и поместим его в папку /tmp, назвав сам файл dump.sql. Подключение к базе происходит от пользователя root. Это самый простой пример создания дампа MySQL.

Базовые параметры команды mysqldump:

Параметр	Описание
-u	Учетная запись, от которой выполняется резервное копирование. Необходимо, чтобы у пользователя были соответствующие права.
-p	Пароль учетной записи. Его можно ввести в команде, например -p12345 (для скрипта) или оставить -p (безопаснее).

* полный перечень параметров смотрите в официальном руководстве.

Заключение

Для мониторинга состояния репликации mysql мы воспользовались самописным скриптом, который парсит вывод значения show slave status\G и анализирует необходимые нам параметры реплики. На основе этих параметров он передает zabbix агенту необходимые значения для отправки на сервер.

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

Заключение

Вот так относительно просто настраивается обычная master — slave репликация mysql. Подобным же образом настраивается и master-master репликация, но на практике она очень нестабильно работает. Я пробовал в свое время, но в итоге отказался, так как надоело ее чинить и исправлять ошибки. Для полноценного кластера с мультизаписью лучше использовать какие-то специализированные решения типа Percona XtraDB Cluster.

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

Онлайн курс «DevOps практики и инструменты»

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите программу детальнее по .

Заключение

Решение задачи по бэкапу mysql баз, что я описал, не претендует на уникальность и 100% правильность. Это просто мой личный опыт. Никаких особых изысканий и поиска наилучшего решения не проводил. Просто сделал, как сделал, чем с вами и поделился. В моих задачах такой подход достаточен.

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

Для мониторинга бэкапов в целом, можете воспользоваться моей объемной статьей по теме — Мониторинг бэкапов с помощью zabbix.

Онлайн курсы по Mikrotik

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

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

• Знания, ориентированные на практику;
• Реальные ситуации и задачи;
• Лучшее из международных программ.