Резервные копии базы данных Mediawiki растут и уменьшаются случайным образом?

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

-rw-r--r-- 1 root root  91M Mar 27 11:46 wiki_data_20220325.sql.gz
-rw-r--r-- 1 root root  93M Mar 27 11:46 wiki_data_20220326.sql.gz
-rw-r--r-- 1 root root  92M Mar 27 11:56 wiki_data_20220327.sql.gz
-rw-r--r-- 1 root root 110M Mar 28 03:15 wiki_data_20220328.sql.gz
-rw-r--r-- 1 root root  99M Mar 29 03:15 wiki_data_20220329.sql.gz
-rw-r--r-- 1 root root 103M Mar 30 03:15 wiki_data_20220330.sql.gz
-rw-r--r-- 1 root root 107M Mar 31 03:15 wiki_data_20220331.sql.gz
-rw-r--r-- 1 root root  78M Mar 27 11:47 wiki_html_20220320.tar.gz
-rw-r--r-- 1 root root 173M Mar 27 11:47 wiki_xml_20220321.xml
-rw-r--r-- 1 root root 173M Mar 27 11:47 wiki_xml_20220322.xml
-rw-r--r-- 1 root root 173M Mar 27 11:47 wiki_xml_20220323.xml
-rw-r--r-- 1 root root 173M Mar 27 11:47 wiki_xml_20220324.xml

Разница в размере сохраняется после распаковки архивов.

-rw-rw-r--  1 user user 280M Mar 31 10:27 wiki0328.sql
-rw-r--r--  1 user user 110M Mar 31 10:26 wiki0328.sql.gz
-rw-rw-r--  1 user user 267M Mar 31 10:27 wiki0329.sql
-rw-r--r--  1 user user  99M Mar 31 10:26 wiki0329.sql.gz

Это не обязательно проблема, но мне любопытно. Является ли это обычным/нормальным поведением для баз данных, сброшенных из сложного программного обеспечения, такого как Mediawiki?

Вот соответствующий фрагмент сценария резервного копирования, если это имеет значение...

echo "## Set ReadOnly on"
echo "\$wgReadOnly = 'Dumping Database, Access will be restored shortly';" >> $localSet

echo "## Dumping XML..." 
php $dumpXML --full --quiet > $saveLoc/"wiki_xml_"$(date +%Y%m%d)".xml"

echo "## Dumping database..."
mysqldump my_wiki | gzip -f > $saveLoc/"wiki_data_"$(date +%Y%m%d)".sql.gz"

echo "## Set ReadOnly off"
tail -n 1 "$localSet" | wc -c | xargs -I {} truncate "$localSet" -s -{}

Спасибо заранее за любую информацию!

Я не эксперт по медиавики, но я заметил, что в макет базы данных есть несколько таблиц «кеша». Они могут увеличиваться и уменьшаться при нормальном использовании.

Bill Karwin 31.03.2022 18:03

Возможны колебания размера резервной копии, но обычно не более 5%. Вы проверили самые маленькие резервные копии? Возможно, они были прерваны из-за ошибки или неисправности сети.

Alexander Mashin 31.03.2022 18:53

@BillKarwin О, в этом есть смысл! Я новичок в mysql и навигации по базам данных, поэтому некоторые базовые знания ускользают от меня. Это хорошо знать. Благодарю вас!

c0rnpuk3 31.03.2022 18:57

@AlexanderMashin Вот что меня насторожило. Я не нашел никаких ошибок в журналах, но хочу быть уверенным, что ничего не упускаю, так как колебания довольно велики. Думаю, мне нужно больше экспериментировать.

c0rnpuk3 31.03.2022 19:02

Чтобы быть уверенным в том, что отличается, вы можете восстановить несколько резервных копий разных размеров на тестовом экземпляре MySQL, а затем использовать SHOW TABLE STATUS, чтобы получить статистику по размерам таблиц, предполагаемому количеству строк и т. д. и сравнить их (предупреждение: количество строк из статус таблицы является приблизительной оценкой, используйте SELECT COUNT(*) для точного числа).

Bill Karwin 31.03.2022 19:13

@BillKarwin Еще раз спасибо! Я изучил несколько версий db, используя COUNT(*), и все основные изменения связаны с количеством строк в таблице objectcache. После прочтения некоторой документации Mediawiki, похоже, что я могу настроить производительность и даже могу пропустить таблицу objectcache в резервных копиях, поскольку она будет регенерироваться на лету и в настоящее время составляет 14 тыс. + строк; P Ваш совет был чрезвычайно полезен, потому что я понятия не имел, с чего даже начать разгадывать эту тайну. Ваше здоровье!

c0rnpuk3 02.04.2022 02:33
Освоение архитектуры микросервисов с Laravel: Лучшие практики, преимущества и советы для
Освоение архитектуры микросервисов с Laravel: Лучшие практики, преимущества и советы для
В последние годы архитектура микросервисов приобрела популярность как способ построения масштабируемых и гибких приложений. Laravel , популярный PHP...
Как построить CRUD-приложение в Laravel
Как построить CRUD-приложение в Laravel
Laravel - это популярный PHP-фреймворк, который позволяет быстро и легко создавать веб-приложения. Одной из наиболее распространенных задач в...
Освоение PHP и управление базами данных: Создание собственной СУБД - часть II
Освоение PHP и управление базами данных: Создание собственной СУБД - часть II
В предыдущем посте мы создали функциональность вставки и чтения для нашей динамической СУБД. В этом посте мы собираемся реализовать функции обновления...
Документирование API с помощью Swagger на Springboot
Документирование API с помощью Swagger на Springboot
В предыдущей статье мы уже узнали, как создать Rest API с помощью Springboot и MySql .
Роли и разрешения пользователей без пакета Laravel 9
Роли и разрешения пользователей без пакета Laravel 9
Этот пост изначально был опубликован на techsolutionstuff.com .
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
В предыдущей статье мы завершили установку базы данных, для тех, кто не знает.
0
6
44
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Резюме комментариев выше: таблица objectcache в базе данных Wordpress различается по размеру, и это нормально. Поэтому это приведет к изменению размера резервной копии базы данных. Чтобы свести к минимуму размер резервной копии, некоторые люди опускают таблицу objectcache из резервных копий.

Другие вопросы по теме