На днях разбирался с одной базой данных mysql на сервере, где есть пока неведомые проблемы с железом. Периодически бьются таблицы. Повезло, что база некритичная, будет плановый переезд. А пока занимался там частичным восстановлением. По ходу дела пришлось с дампами поработать. Сделаю несколько зарисовок оттуда на память. Возможно, кому-то будет полезна эта информация.
1️⃣ Я обычно использую следующий набор ключей при снятии дампа с помощью mysqldump:
Не буду их все пояснять, можно у ИИ спросить. Сделаю акцент на
Если какая-то таблица из-за ошибок не бэкапится и останавливает процесс снятия дампа, её можно исключить из дампа ключом
2️⃣ В таком дампе из-за ключа
Но это создаёт неудобство, если нужно из бэкапа восстановить копию базы на проде. Если забыть об этом, то при восстановлении базы данных, исходная удаляется. Поэтому перед восстановлением нужно заменить в дампе имя базы данных. Это нетривиальная задача, если дамп очень большой. Нельзя просто открыть его и вручную изменить имя базы. Сделать это проще всего с помощью sed. Меняем
После этого можно создавать базу данных dbname01_copy и восстанавливать в неё содержимое дампа:
Получили рядом копию рабочей базы.
3️⃣ Проще и удобнее делать полный дамп базы, особенно если в ней очень много таблиц. Можно бэкапить потаблично, но лично я так почти никогда не делаю. Из полного дампа легко получить бэкап отдельной таблицы, если это потребуется. Поможет awk:
Теперь можно восстановить отдельную таблицу.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mysql
# mysqldump -v --add-drop-database --add-locks --create-options --disable-keys --extended-insert --single-transaction --quick --set-charset --routines --events --triggers --comments --quote-names --order-by-primary --hex-blob --databases dbname01 > dbname01.sqlНе буду их все пояснять, можно у ИИ спросить. Сделаю акцент на
--single-transaction. Этот ключ позволяет избежать блокировок при снятии дампа, в отличие от ключа --opt, который используется по умолчанию и включает в том числе --lock-tables. Пришлось от него отказаться и вручную перечислить некоторые его ключи, убрав блокировку.Если какая-то таблица из-за ошибок не бэкапится и останавливает процесс снятия дампа, её можно исключить из дампа ключом
--ignore-table=dbname01.table_01.--add-drop-database в начале идёт команда на удаление базы данных: DROP DATABASE IF EXISTS `dbname01`;и создание новой: CREATE DATABASE IF NOT EXISTS `dbname01`; Я использую этот ключ, потому что удобно автоматически восстанавливать исходники и дамп базы по расписанию на каком-то тестовом сервере. Не нужно менять никакие настройки, не надо удалять старую базу и создавать новую. Берём бэкапы с прода и восстанавливаем их в неизменном виде.Но это создаёт неудобство, если нужно из бэкапа восстановить копию базы на проде. Если забыть об этом, то при восстановлении базы данных, исходная удаляется. Поэтому перед восстановлением нужно заменить в дампе имя базы данных. Это нетривиальная задача, если дамп очень большой. Нельзя просто открыть его и вручную изменить имя базы. Сделать это проще всего с помощью sed. Меняем
dbname01 на dbname01_copy, везде, где встречается:# sed -i 's/`dbname01`/`dbname01_copy`/g' dbname01.sqlПосле этого можно создавать базу данных dbname01_copy и восстанавливать в неё содержимое дампа:
# mysql> CREATE DATABASE dbname01_copy;> use dbname01_copy;> source ~/dbname01.sql;Получили рядом копию рабочей базы.
# cat dbname01.sql | /usr/bin/awk '/CREATE TABLE `table_01`/,/UNLOCK TABLES/' > /tmp/table_01.sqlТеперь можно восстановить отдельную таблицу.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mysql
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍138👎2
Продолжение утренней темы с Mysql. Не стал всё в одной публикации делать, чтобы не смешивать темы. У меня необычная ситуация возникла, с которой столкнулся впервые. Я ранее уже делал заметку по ошибке с базой данных. Это её продолжение.
Напомню, что в базе Mysql с движком InnoDB внезапно появляется ошибка такого вида:
При этом сама база работает нормально, данные пишутся, читаются. Просто спотыкается чтение определённых строк в проблемной таблице. Это становится заметно при снятии дампа, так как он останавливается на этих строках.
Никакие рекомендованные процедуры лично мне не помогли восстановить таблицу. Пришлось восстанавливать из бэкапа.
А странность тут вот в чём. Ещё когда первый раз я с этим столкнулся, то восстановил всю виртуалку из бэкапа на другой сервер. Запустил её там и спокойно всё прочитал в таблицах, снял дамп. Никаких повреждений данных, всё на месте. То есть данные на самом деле не пострадали.
И вот эта история повторилась на том же сервере спустя более чем полгода. Опять побилась таблица. Развернул ночной бэкап виртуалки – там всё в порядке. Все данные на месте. Делают тут же без остановки ещё один бэкап проблемной виртуалки с помощью PBS, восстанавливаю на другом сервере, снимаю дамп. Опять всё в порядке, все данные на месте.
Не понимаю, что происходит, и как такое возможно. Идея только одна – какие-то проблемы с железом. Так как это уже не первый случай, принял решение отказаться от аренды этого сервера. Перед окончанием оплаченного периода закажу другой и перееду туда, а этот сервер сдам с тикетом в поддержку с предложением проверить хорошенько память. По идее это она может давать такие проблемы, но лично я с подобным не сталкивался.
Мне непонятен такой момент. Если с памятью проблемы, то данные по идее должны всё же биться и теряться. А тут восстанавливаешь глючащую виртуалку в другом месте и с ней вдруг всё становится в порядке, данные на месте. СУБД обычно чувствительна к таким сбоям, база теряет свою целостность. А тут всё в порядке.
У кого-то есть ещё идеи по этой ошибке? Может кто-то сталкивался с подобным. А то сервер сдам и больше не узнаю, что с ним было. Особо нет времени и возможности полноценно тестировать чужой сервер, не имея к нему полного доступа.
#mysql #ошибка
Напомню, что в базе Mysql с движком InnoDB внезапно появляется ошибка такого вида:
[ERROR] InnoDB: Index corruption: rec offs 12361 next offs 0[page id: space=33355, page number=1250], index `PRIMARY` of table `dbname01`.`table_01`. Run CHECK TABLE. You may need to restore from a backup, or dump + drop + reimport the table.[ERROR] InnoDB: We detected index corruption in an InnoDB type table. You have to dump + drop + reimport the table or, in a case of widespread corruption, dump all InnoDB tables and recreate the whole tablespace.[ERROR] Got error 126 when reading table './dbname01/table_01'[ERROR] mariadbd: Index for table 'table_01' is corrupt; try to repair itПри этом сама база работает нормально, данные пишутся, читаются. Просто спотыкается чтение определённых строк в проблемной таблице. Это становится заметно при снятии дампа, так как он останавливается на этих строках.
Никакие рекомендованные процедуры лично мне не помогли восстановить таблицу. Пришлось восстанавливать из бэкапа.
А странность тут вот в чём. Ещё когда первый раз я с этим столкнулся, то восстановил всю виртуалку из бэкапа на другой сервер. Запустил её там и спокойно всё прочитал в таблицах, снял дамп. Никаких повреждений данных, всё на месте. То есть данные на самом деле не пострадали.
И вот эта история повторилась на том же сервере спустя более чем полгода. Опять побилась таблица. Развернул ночной бэкап виртуалки – там всё в порядке. Все данные на месте. Делают тут же без остановки ещё один бэкап проблемной виртуалки с помощью PBS, восстанавливаю на другом сервере, снимаю дамп. Опять всё в порядке, все данные на месте.
Не понимаю, что происходит, и как такое возможно. Идея только одна – какие-то проблемы с железом. Так как это уже не первый случай, принял решение отказаться от аренды этого сервера. Перед окончанием оплаченного периода закажу другой и перееду туда, а этот сервер сдам с тикетом в поддержку с предложением проверить хорошенько память. По идее это она может давать такие проблемы, но лично я с подобным не сталкивался.
Мне непонятен такой момент. Если с памятью проблемы, то данные по идее должны всё же биться и теряться. А тут восстанавливаешь глючащую виртуалку в другом месте и с ней вдруг всё становится в порядке, данные на месте. СУБД обычно чувствительна к таким сбоям, база теряет свою целостность. А тут всё в порядке.
У кого-то есть ещё идеи по этой ошибке? Может кто-то сталкивался с подобным. А то сервер сдам и больше не узнаю, что с ним было. Особо нет времени и возможности полноценно тестировать чужой сервер, не имея к нему полного доступа.
#mysql #ошибка
Telegram
ServerAdmin.ru
Недавно была заметка про знание СУБД. Видел комментарии, мол пусть DBA разбираются в нюансах СУБД, а админам это ни к чему. Расскажу про один случай, который со мной на днях случился. Сразу скажу, что это не будет рекомендацией к действиям, так как сам я…
2👍50👎2
В последних публикациях на тему бэкапа баз в Postgresql не раз всплывал вопрос: "А есть ли веб панели для управления бэкапами баз MySQL?". Я сам никогда их не использовал и не встречал. Знаю, что инструменты для подобного бэкапа есть в панелях по управлению веб серверами, типа Hestiacp, aaPanel и им подобным. Очевидно, если у вас не веб сервер, то такую панель ставить не имеет смысла. А специализированных панелей только для бэкапов не существует.
Решение, как оказалось, есть на поверхности. Существует известная веб панель для управления сервером - Webmin. Странно, что я по ней ни одной заметки ещё не написал. Хоть сам и не ставлю на свои сервера, но приходилось работать. Там есть интересные возможности, ради которых её можно использовать.
В Webmin есть модуль для управления MySQL. Я его попробовал. Настроек немного, но сделано вполне функционально. Я там немного покумекал, как сделать наиболее удобно и получилось неплохо. Расскажу по шагам, как я всё настроил.
1️⃣ Установка. Панель собрана в пакеты под популярные дистрибутивы. Подключить репозиторий можно автоматически через скрипт:
Либо вручную, добавив репозиторий и ключ от него. Для Debian это:
После установки можно идти по IP адресу сервера на порт 10000 и заходить под учёткой root. После этого в разделе Webmin ⇨ Webmin Configuration ⇨ IP Access Control ограничьте доступ к панели по IP адресам. Её нельзя выставлять в публичный доступ. В панели периодически находят уязвимости, а у неё полный доступ к серверу.
2️⃣ Если MySQL сервер устанавливался после установки Webmin, то модуль управления будет в списке Un-used Modules, если после, то в Servers. Чтобы модуль переехал из Un-used, нажмите на Refresh Modules.
3️⃣ В модуле есть возможность настроить подключение к MySQL серверу в разделе Configuration ⇨ Server Connections. По умолчанию используется localhost, но вы можете подключиться к любому другому серверу, в том числе в контейнере. Главное, чтобы к нему был доступ извне.
4️⃣ Можно настроить бэкап как конкретной базы, так и всех разом. При бэкапе всех баз, каждая из них сохраняется в отдельный файл и может при желании сразу сжиматься. Бэкап выполняется через стандартный
5️⃣ Для бэкапов есть планировщик. Работает в формате заданий cron. Да и сами задания добавляются в системный файл
6️⃣ Основное неудобство – задание бэкапа каждый раз перезаписывает файлы. Нет возможности хранить несколько копий и автоматически удалять старые. Я решил этот вопрос максимально просто в лоб.
Можно указать команды, которые будут выполняться до запуска бэкапа и после. Настроил бэкап в директорию
Она создаёт директорию вида
Для того, чтобы очищать старые бэкапы, добавил команду перед запуском:
Она оставляет 30 новых директорий, а более старые удаляет. Вопрос с ротацией бэкапов решён. Работает просто и наглядно. При желании можно добавить ещё одну команду, которая будет куда-нибудь во вне копировать эти файлы.
7️⃣ Для восстановления бэкапов достаточно создать новую базу или выбрать существующую, зайти в неё, выбрать раздел Execute SQL ⇨ Run SQL from file ⇨ From local file и выбрать один из дампов. При желании можно подключиться к другому серверу и восстановить бэкап туда.
Получилось простое в настройке и вполне функциональное решение.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #mysql
Решение, как оказалось, есть на поверхности. Существует известная веб панель для управления сервером - Webmin. Странно, что я по ней ни одной заметки ещё не написал. Хоть сам и не ставлю на свои сервера, но приходилось работать. Там есть интересные возможности, ради которых её можно использовать.
В Webmin есть модуль для управления MySQL. Я его попробовал. Настроек немного, но сделано вполне функционально. Я там немного покумекал, как сделать наиболее удобно и получилось неплохо. Расскажу по шагам, как я всё настроил.
# curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh# sh webmin-setup-repo.shЛибо вручную, добавив репозиторий и ключ от него. Для Debian это:
deb https://download.webmin.com/download/newkey/repository stable contrib# apt-get install webmin --install-recommendsПосле установки можно идти по IP адресу сервера на порт 10000 и заходить под учёткой root. После этого в разделе Webmin ⇨ Webmin Configuration ⇨ IP Access Control ограничьте доступ к панели по IP адресам. Её нельзя выставлять в публичный доступ. В панели периодически находят уязвимости, а у неё полный доступ к серверу.
mysqldump. Ключи запуска могут добавлять при необходимости. /var/spool/cron/crontabs/root.Можно указать команды, которые будут выполняться до запуска бэкапа и после. Настроил бэкап в директорию
/root/sql_backup а после бэкапа добавил команду:mkdir /mnt/backup/`date +"%Y-%m-%d_%H-%M"` && cp -R /root/sql_backup/* /mnt/backup/`date +"%Y-%m-%d_%H-%M"`/Она создаёт директорию вида
2025-07-23_16-27 и копирует туда созданные файлы. При следующем запуске имя директории будет другое.Для того, чтобы очищать старые бэкапы, добавил команду перед запуском:
find /mnt/backup -type d -printf '%T@ "%p"\n' | sort -n | head -n -30 | awk '{print $2}' | xargs -I {} rm -r {}Она оставляет 30 новых директорий, а более старые удаляет. Вопрос с ротацией бэкапов решён. Работает просто и наглядно. При желании можно добавить ещё одну команду, которая будет куда-нибудь во вне копировать эти файлы.
Получилось простое в настройке и вполне функциональное решение.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #mysql
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍75👎5