Первоначально Вадим Ткаченко
В моем недавнем посте « TokuDB получил: медленно INFORMATION_SCHEMA TABLES » я видел пару вопросов и твитов, спрашивающих, будем ли мы использовать TokuDB в производстве. На самом деле я упомянул об этом в этом посте, и мы также написали об этом в нескольких других недавних постах:
- Знакомство с TokuDB для MySQL
- Percona Server с TokuDB: упаковка 15 ТБ в локальные твердотельные накопители
Итак, да, мы используем Percona Server + TokuDB в качестве основного механизма хранения в Percona Cloud Tools для хранения данных временных рядов .
И, да, Percona Server + TokuDB доступен GA Percona Server 5.6.19-67.0 с TokuDB (GA) .
Просто иметь хорошую производительность недостаточно, чтобы сделать это в производство; Есть также оперативные вопросы, и один такой вопрос о резервных копиях. Я хочу объяснить, как мы выполняем резервное копирование для Percona Server + TokuDB в Percona Cloud Tools .
Я должен сказать , авансом, что мы НЕ имеем поддержку TokuDB в Percona XtraBackup . Внутренние компоненты TokuDB значительно отличаются от InnoDB / XtraDB, поэтому это будет серьезный проект по добавлению этого в Percona XtraBackup, и в настоящее время у нас нет никаких планов работать над этим.
Это не значит, что у пользователей TokuDB нет опций для резервного копирования. Существует резервная копия Tokutek Hot, включенная в подписку Tokutek Enterpise . И есть метод, который мы используем в Percona Cloud Tools : резервные копии LVM. Для этой задачи мы используем сценарии mylvmbackup, и у нас это работает довольно хорошо.
Однако есть некоторые ошибки, о которых нужно знать. Если вы понимаете механику резервного копирования LVM, это в основном процесс аварийного восстановления после восстановления из резервной копии.
Теперь нам нужно немного подробнее рассказать о TokuDB. Для поддержки транзакций, в которых задействованы как движки TokuDB, так и InnoDB, TokuDB использует двухфазный механизм фиксации в MySQL. При двухфазной фиксации требуются двоичные журналы, представленные для правильных процедур восстановления.
Но теперь нам нужно взглянуть на то, как мы настраиваем двоичный журнал в Percona Cloud Tools. Мы использовали SSD для основного хранилища данных (раздел LVM здесь), и мы используем аппаратный RAID1 на двух жестких дисках для двоичных журналов. Мы выбираем эту настройку, поскольку заботимся о сроке службы SSD. В рабочих нагрузках с интенсивной записью двоичные журналы будут производить много операций записи, и в наших расчетах мы просто сожжем эти твердотельные накопители, поэтому мы должны хранить их на чем-то менее дорогом.
Таким образом, проблема заключается в том, что когда мы делаем снимок LVM над основным хранилищем, у нас нет согласованного представления двоичных журналов (хотя возможно изменить сценарии резервного копирования, чтобы копировать текущий двоичный журнал в операции FLUSH TABLES WITH READ LOCK, это вероятно, что мы будем делать дальше) . Но двоичные журналы необходимы для восстановления, без них мы сталкиваемся с такими ошибками при восстановлении из резервной копии:
2014-DD-MM 02:15:16 16414 [Note] Found 1 prepared transaction(s) in TokuDB 2014-DD-MM 02:15:16 16414 [ERROR] Found 1 prepared transactions! It means that mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash. You have to start mysqld with --tc-heuristic-recover switch to commit or
Сообщение об ошибке на самом деле подсказывает выход. К сожалению, кажется, что мы первые, кто когда-либо пробовал эту опцию, так как tc-heuristic-recoverона полностью сломана в текущем MySQL и не должна работать… и было бы замечено, если бы кто-то действительно пробовал ее до нас (что создает у меня впечатление, что Oracle / MySQL никогда не проверял это должным образом, но это другая история) .
Мы скоро исправим это в Percona Server .
Таким образом, способ обработки восстановления из резервной копии LVM без двоичных журналов состоит в том, чтобы запустить mysqld с ключом -tc-heuristic-recovery (к сожалению, я пока не выяснил, должно ли это быть значение COMMIT или ROLLBACK, хе-хе) .
Правильный способ использовать резервную копию LVM — иметь соответствующий двоичный файл журнала, как я уже говорил, для этого потребуется изменить скрипт mylvmbackup.
Должен сказать, что это не единственный способ создания резервных копий в Percona Cloud Tools. В этом проекте мы используем Percona Backup Service, предоставляемый командой Percona Managed Services , и наша команда также использует mydumper для выполнения логического резервного копирования данных.
Хотя он работает приемлемо для резервного копирования данных объемом в сотни гигабайт (это просто последовательное сканирование, которое должно быть простым для TokuDB) , полное восстановление является болезненным и занимает недопустимо много времени. Таким образом, резервное копирование (восстановление) mydumper будет использовано, если нам когда-либо потребуется выполнить детальное восстановление (т. Е. Только небольшое количество конкретных таблиц) .
Поэтому я надеюсь, что этот совет будет полезен, если вы ищете информацию о том, как сделать резервные копии для TokuDB.