оптимизировать вывод mysqldump для дедупликации zfs

Question

Моя задача - хранить как можно больше дампов mysql в заданном пуле ZFS.

В самом пуле разрешены дедупликация и сжатие. Для хранения нескольких версий дампов используются снимки (каждые 15 минут, каждый час, каждый день, каждую неделю и каждый месяц).

Большинство таблиц в различных базах данных на MySQL Server растут и меняются не очень часто. Я думал сделать дамп для таблицы вместо базы данных, чтобы у zfs была возможность дедупликации на уровне блоков.

Сценарий резервного копирования использует вывод mysqldump и передает его в файл (с помощью mysqldmup -u$user -p$pass $db $table > $outputfile.sql

• Способна ли дедупликация ZFS выводить поток с stdout с хорошей скоростью?
• Нужно ли вручную настраивать размер блока данных назначения? (и если да - какой размер?)
• Должны ли быть применены какие-либо буферы вывода (кроме буферизации строк)?
• Является ли запись из перенаправления синхронизации или асинхронной?

РЕДАКТИРОВАТЬ, чтобы придать ему гвоздь: Что необходимо, чтобы сделать файл, записанный построчно, как файл, который был скопирован, если содержимое (почти (например, отличается только последняя строка)) одинаково?

Answer 1

Дедупликация всегда находится на уровне блоков (как снимки и копминг), структура данных выше не имеет значения. Таким образом, вы можете иметь один файл вместо тысячи маленьких файлов, и это не повлияет на дедупликацию.

С другой стороны, размер вашего блока имеет значение по нескольким причинам:

• Чем больше ваши блоки, тем больше отходов может произойти, потому что некоторые байты очень маленького файла могут зарезервировать размер большого блока (размер вашего блока является наименьшей единицей и не может быть разделен далее)
• Чем меньше ваши блоки, тем медленнее будет ваша производительность в среднем, потому что для чтения одного и того же файла вам теперь нужно прочитать намного больше блоков (каждое чтение имеет небольшие накладные расходы, и каждый блок вполне может находиться в совершенно другой позиции на весь диск)
• Дедупликация работает на блоках, поэтому небольшой размер, возможно, даст лучшие результаты
• С другой стороны, это увеличивает количество блоков, на которые ссылаются в памяти, и может ухудшить вашу производительность. Для компромисса и примеров расчетов см. Этот пост в блоге - главное, что вам нужно большое количество памяти, и это зависит от ваших данных

Поэтому определение размера важно, но не так просто. Кажется, у вас уже достаточно данных, поэтому я бы просто протестировал их: создайте две файловые системы (если возможно, потом, но не одновременно, чтобы минимизировать влияние друг на друга), одну с очень маленьким размером блока (4 КБ), одну с очень большим размером (128K), а затем скопируйте ваши данные и сравните результаты. Вы также можете смоделировать производительность дедупликации с помощью zdb -b poolname , сравнив количество блоков и рассчитав экономию. Если ни один из этих результатов вам не подходит, попробуйте другие размеры, такие как 16K, 32K или 64K.