Параллельная обработка incremental backup в XtraBackup снижает время prepare и меняет поведение I/O под нагрузкой.
Проблема проявляется не сразу — до момента, когда incremental backup начинает состоять из тысяч .delta файлов. В классической модели XtraBackup обрабатывал их последовательно. Это означало высокий per-file overhead и линейный рост времени на стадии prepare. На больших инсталляциях с множеством таблиц (.ibd) prepare становился узким местом и тормозил восстановление (recovery time).
Решение — добавить параллелизм в фазу применения изменений. В версиях XtraBackup 8.0.35-33 и 8.4.0-3 появился флаг —parallel для команды xtrabackup —prepare —apply-log-only. Теперь система сначала сканирует каталог backup и строит очередь .delta файлов. Затем несколько потоков обрабатывают эту очередь параллельно. Это компромисс: ускорение достигается за счёт роста конкуренции за диск (disk I/O) и накладных расходов на управление потоками.
Реализация изменила саму модель выполнения. Ранее файл обрабатывался сразу после обнаружения. Теперь вводится явная очередь задач. Каждый поток читает .delta файл и применяет изменения к соответствующему InnoDB файлу (.ibd). Это лучше масштабируется при большом количестве мелких файлов. Но при меньшем числе или большем размере файлов эффект ограничен. После примерно 16 потоков производительность может выйти на плато или даже немного деградировать из-за overhead.
Результаты показывают, что выигрыш зависит от структуры backup. В сценарии с 20 608 файлами по 2.5 MB увеличение —parallel с 1 до 64 дало рост Disk Write IOPS с 18.2K до 85K. Время prepare сократилось с 3.76 минут до примерно одной минуты. Это около 3.5x ускорения при росте I/O в 4.67 раза. В другом кейсе время сократилось с 237 минут до 6 минут, что даёт до 40x ускорения. Универсального значения нет, но практическая отправная точка — 8 потоков.
Важно понимать причинно-следственную связь: ускорение достигается не «магией», а за счёт лучшей утилизации диска и распараллеливания мелких операций. Если система уже упирается в пределы IOPS или CPU, рост —parallel не поможет. В таких условиях возможен даже регресс. Это типичный trade-off между latency отдельной операции и общим throughput системы.
С точки зрения эксплуатации, это изменение сдвигает фокус настройки. Раньше ключевым фактором была структура backup. Теперь — баланс между количеством потоков и возможностями storage. Наблюдаемость (observability) через метрики IOPS становится критичной для подбора оптимального значения.
В индустрии такой подход давно используется для задач с высоким количеством мелких файлов. XtraBackup фактически догоняет этот паттерн. Это эволюционное улучшение, которое закрывает реальное узкое место без изменения формата backup.