У меня есть сценарий резервного копирования, который использует 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 -{}
Спасибо заранее за любую информацию!
Возможны колебания размера резервной копии, но обычно не более 5%. Вы проверили самые маленькие резервные копии? Возможно, они были прерваны из-за ошибки или неисправности сети.
@BillKarwin О, в этом есть смысл! Я новичок в mysql и навигации по базам данных, поэтому некоторые базовые знания ускользают от меня. Это хорошо знать. Благодарю вас!
@AlexanderMashin Вот что меня насторожило. Я не нашел никаких ошибок в журналах, но хочу быть уверенным, что ничего не упускаю, так как колебания довольно велики. Думаю, мне нужно больше экспериментировать.
Чтобы быть уверенным в том, что отличается, вы можете восстановить несколько резервных копий разных размеров на тестовом экземпляре MySQL, а затем использовать SHOW TABLE STATUS
, чтобы получить статистику по размерам таблиц, предполагаемому количеству строк и т. д. и сравнить их (предупреждение: количество строк из статус таблицы является приблизительной оценкой, используйте SELECT COUNT(*)
для точного числа).
@BillKarwin Еще раз спасибо! Я изучил несколько версий db, используя COUNT(*), и все основные изменения связаны с количеством строк в таблице objectcache. После прочтения некоторой документации Mediawiki, похоже, что я могу настроить производительность и даже могу пропустить таблицу objectcache в резервных копиях, поскольку она будет регенерироваться на лету и в настоящее время составляет 14 тыс. + строк; P Ваш совет был чрезвычайно полезен, потому что я понятия не имел, с чего даже начать разгадывать эту тайну. Ваше здоровье!
Резюме комментариев выше: таблица objectcache
в базе данных Wordpress различается по размеру, и это нормально. Поэтому это приведет к изменению размера резервной копии базы данных. Чтобы свести к минимуму размер резервной копии, некоторые люди опускают таблицу objectcache
из резервных копий.
Я не эксперт по медиавики, но я заметил, что в макет базы данных есть несколько таблиц «кеша». Они могут увеличиваться и уменьшаться при нормальном использовании.