Огромный каталог, медленное выполнение команды restore

[metallic]

Проблема следующего характера:

Начал пользоваться бакулой для резервного копирования на ленточную
библиотеку, записал первый бекап (данных много, 25ТБ примерно).
Система следующая: bacula 5, Mysql 5.1.42, FreeBSD 8.0

Решил попробовать восстановить пару файлов, запустил команду restore,
там выбрал задание из которого восстанавливать (Enter list of comma
separated JobIds to select) и увидел следующее:
Select item: (1-13): 3
Enter JobId(s), comma separated, to restore: 5
You have selected the following JobId: 5

Building directory tree for JobId(s) 5 ...

Типа составляет список каталогов и файлов, но это длится несколько
часов, в мониторинге mysql видно, что выполняется следующий запрос:

SELECT Path.Path, Filename.Name, Temp.FileIndex, Temp.JobId, LStat,
MD5
FROM (

SELECT FileId, Job.JobId AS JobId, FileIndex, File.PathId AS PathId,
File.FilenameId AS FilenameId, LStat, MD5
FROM Job,
FILE , (

SELECT MAX( JobTDate ) AS JobTDate, PathId, FilenameId
FROM (

SELECT JobTDate, PathId, FilenameId
FROM FILE JOIN Job
USING ( JobId )
WHERE File.JobId
IN ( 5 )
UNION ALL SELECT JobTDate, PathId, FilenameId
FROM BaseFiles
JOIN FILE USING ( FileId )
JOIN Job ON ( BaseJobId = Job.JobId )
WHERE BaseFiles.JobId
IN ( 5 )
) AS tmp
GROUP BY PathId, FilenameId
) AS T1
WHERE (
Job.JobId
IN (

SELECT DISTINCT BaseJobId
FROM BaseFiles
WHERE JobId
IN ( 5 )
)
OR Job.JobId
IN ( 5 )
)
AND T1.JobTDate = Job.JobTDate
AND Job.JobId = File.JobId
AND T1.PathId = File.PathId
AND T1.FilenameId = File.FilenameId
) AS Temp
JOIN Filename ON ( Filename.FilenameId = Temp.FilenameId )
JOIN Path ON ( Path.PathId = Temp.PathId )
WHERE FileIndex >0
ORDER BY Temp.JobId, FileIndex ASC

Судя по этому запросу, он затрагивает таблицы Filename, Path, File
Я поглядел их размеры:
File: 836.8 МБ
Filename: 200.0 МБ
Path: 60.1 МБ

Это получается бакула мне за один бекап нагенерила 1ГБ мета-данных в
базе, что же дальше-то будет? Можно как-то оптимизировать?

[Yuri Timofeev]

Возможно не хватает каких-то индексов.
Смотрите планы запросов. Или пересоздайте индексы основываясь на
make_mysql_tables например.

On 15 мар, 14:17, metallic <metallic...@gmail.com> wrote:
> Проблема следующего характера:
>
> Начал пользоваться бакулой для резервного копирования на ленточную
> библиотеку, записал первый бекап (данных много, 25ТБ примерно).

Какое количество файлов в одном бэкапе ?

Оно уже оптимизировано. Размер БД Каталога зависит также от кол-ва
_уникальных_ имен файлов и каталогов.

[metallic]

> Какое количество файлов в одном бэкапе ?

Кол-во файлов в одном бекапе 6.000.000
Я уже разобрался, помогло добавление дополнительного индекса:
СREATE INDEX FilenameId_2 ON File (FilenameId, PathId);

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

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