ServerAdmin.ru
31.6K subscribers
853 photos
57 videos
23 files
3K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru

Ресурс включён в перечень Роскомнадзора
Download Telegram
Продолжение утренней темы с Mysql. Не стал всё в одной публикации делать, чтобы не смешивать темы. У меня необычная ситуация возникла, с которой столкнулся впервые. Я ранее уже делал заметку по ошибке с базой данных. Это её продолжение.

Напомню, что в базе Mysql с движком InnoDB внезапно появляется ошибка такого вида:

[ERROR] InnoDB: Index corruption: rec offs 12361 next offs 0[page id: space=33355, page number=1250], index `PRIMARY` o
f 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 #ошибка
2👍50👎2
В последних публикациях на тему бэкапа баз в Postgresql не раз всплывал вопрос: "А есть ли веб панели для управления бэкапами баз MySQL?". Я сам никогда их не использовал и не встречал. Знаю, что инструменты для подобного бэкапа есть в панелях по управлению веб серверами, типа Hestiacp, aaPanel и им подобным. Очевидно, если у вас не веб сервер, то такую панель ставить не имеет смысла. А специализированных панелей только для бэкапов не существует.

Решение, как оказалось, есть на поверхности. Существует известная веб панель для управления сервером - Webmin. Странно, что я по ней ни одной заметки ещё не написал. Хоть сам и не ставлю на свои сервера, но приходилось работать. Там есть интересные возможности, ради которых её можно использовать.

В Webmin есть модуль для управления MySQL. Я его попробовал. Настроек немного, но сделано вполне функционально. Я там немного покумекал, как сделать наиболее удобно и получилось неплохо. Расскажу по шагам, как я всё настроил.

1️⃣ Установка. Панель собрана в пакеты под популярные дистрибутивы. Подключить репозиторий можно автоматически через скрипт:

# 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 адресам. Её нельзя выставлять в публичный доступ. В панели периодически находят уязвимости, а у неё полный доступ к серверу.

2️⃣ Если MySQL сервер устанавливался после установки Webmin, то модуль управления будет в списке Un-used Modules, если после, то в Servers. Чтобы модуль переехал из Un-used, нажмите на Refresh Modules.

3️⃣ В модуле есть возможность настроить подключение к MySQL серверу в разделе Configuration ⇨ Server Connections. По умолчанию используется localhost, но вы можете подключиться к любому другому серверу, в том числе в контейнере. Главное, чтобы к нему был доступ извне.

4️⃣ Можно настроить бэкап как конкретной базы, так и всех разом. При бэкапе всех баз, каждая из них сохраняется в отдельный файл и может при желании сразу сжиматься. Бэкап выполняется через стандартный mysqldump. Ключи запуска могут добавлять при необходимости.

5️⃣ Для бэкапов есть планировщик. Работает в формате заданий cron. Да и сами задания добавляются в системный файл /var/spool/cron/crontabs/root.

6️⃣ Основное неудобство – задание бэкапа каждый раз перезаписывает файлы. Нет возможности хранить несколько копий и автоматически удалять старые. Я решил этот вопрос максимально просто в лоб.

Можно указать команды, которые будут выполняться до запуска бэкапа и после. Настроил бэкап в директорию /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 новых директорий, а более старые удаляет. Вопрос с ротацией бэкапов решён. Работает просто и наглядно. При желании можно добавить ещё одну команду, которая будет куда-нибудь во вне копировать эти файлы.

7️⃣ Для восстановления бэкапов достаточно создать новую базу или выбрать существующую, зайти в неё, выбрать раздел Execute SQL ⇨ Run SQL from file ⇨ From local file и выбрать один из дампов. При желании можно подключиться к другому серверу и восстановить бэкап туда.

Получилось простое в настройке и вполне функциональное решение.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#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