Я ищу замену стареющему и явно неоптимальному mysqldumpна основе стратегии резервного копирования базы данных с помощью Percona Xtrabackup. Все это выглядит довольно просто, за исключением того, что мне интересно: сколько инкрементных резервных копий я должен хранить между полными резервными копиями?
Я понимаю, что восстановление из длинного набора инкрементальных значений было бы несколько утомительным, но похоже, что это будет довольно легко написать сценарий.
Я также предполагаю, что если я каким-то образом потеряю инкремент, который является частью резервного набора, с этого момента я потеряю все. Вроде бы маловероятно (эти ребята отправятся на S3), но все равно плохой день.
Есть ли в подобных вещах практические правила? Будет ли почасовое приращение с полным резервным копированием в неделю (то есть 168 файлов на резервный набор) безумным или нормальным для некоторых рабочих нагрузок?
FWIW, мы смотрим на базу данных с ~ 10 миллионами строк, растущую на ~ 20 тысяч строк в день, очень мало измененных строк (то есть в основном добавляемые). Таким образом, приращения будут довольно маленькими.
Довольно сложно сказать, какова лучшая стратегия резервного копирования - все зависит от ценности ваших данных и от штрафа, который вы заплатите, если потеряете последние X часов.
Вы правильно определили проблему с инкрементами - если вы потеряете одну, вы потеряете все после нее. Другая проблема заключается в том, что если полная версия повреждена, вы все потеряете, и точка.
Теперь, понимая это, планирование резервного копирования - это прекрасное искусство балансирования между стоимостью резервного копирования и стоимостью потери данных.
Если вы полагаетесь только на одну главную базу данных и хотите делать инкрементные резервные копии каждый час, я бы посоветовал вам делать полные резервные копии так часто, как ваша ссылка может загружать их в S3. Так, например, если вы можете загрузить полную резервную копию на S3 за 4 часа, делайте это каждый день.
Но, чтобы быть лучше, я бы предложил настроить репликацию master-slave, а также резервное копирование двоичных журналов. Таким образом, вы можете планировать инкрементальные вычисления до тех пор, пока ваши двоичные журналы хранят данные. В случае инкрементного сбоя вы можете выполнить полное восстановление из резервной копии, а затем воспроизвести журналы. Дополнительным преимуществом является резервное копирование на ведомом устройстве, что не снижает производительности на ведущем устройстве (и пользователях).