postgrespro
реализация режима разностного бэкапа
планируется ли реализация режима разностного бэкапа? Чтобы можно было выполнить отдельно бэкап типа DELTA относительно последнего успешного FULL, а не относительно последнего успешного DELTA. На больших БД (порядок >10ТБ) и с большим объемом модификаций выходит так, что несколько бэкапов DELTA в течении дня будут занимать значительный объем (и соответственно время восстановления тоже вырастет), поэтому было бы удобно иметь такой тип бэкапа. Можно было реализовывать схемы расписания вида FULL - раз в неделю DELTA - в течении дня DIFF - раз в сутки
Можем запланировать на 2.4.0. Встаёт вопрос об интерфейсе. Лично я вижу два варианта:
-
Дешево и сердито. Просто даем возможность указывать айдюк родительского бэкапа, чтобы юзер, при запуске инкрементального бэкапа, мог самостоятельно задавать родителя. Получается довольно гибко, но потребует дополнительных телодвижений со стороны юзера. И, глядя в show, отличить просто инкрементальный бэкап от дифференциального "на глаз" не получится. Потребуется чекать родителя, а это опять лишние телодвижения.
-
Добавляем флаг
--diffи при снятии инкрементального бэкапа автоматически ищем ближайший full и считаем его своим родителем. В show добавляем новое поле, чтобы различать инкрементальные и дифференциальные:
=============================================
ID Recovery Time Type Mode
=============================================
Q9S3WI 2020-05-04 02:29:14+03 INCR PAGE
Q9S3V0 2020-05-04 02:28:27+03 INCR DELTA
Q9S3U7 2020-05-04 02:28:02+03 INCR PAGE
Q9S3T1 2020-05-04 02:27:21+03 INCR PAGE
Q9S3QO 2020-05-04 02:25:59+03 INCR DELTA
Q9S3OK 2020-05-04 02:24:36+03 INCR PAGE
Q9S3NI 2020-05-04 02:24:04+03 INCR PAGE
Q9S3JZ 2020-05-04 02:21:59+03 DIFF PAGE
Q9S3GT 2020-05-04 02:20:23+03 INCR PAGE
Q9S365 2020-05-04 02:13:32+03 INCR PAGE
Q9S354 2020-05-04 02:13:01+03 INCR PAGE
Q9S33U 2020-05-04 02:12:20+03 INCR PAGE
Q9S31A 2020-05-04 02:11:32+03 INCR DELTA
Q9S2XN 2020-05-04 02:08:41+03 INCR PAGE
Q9R1T8 2020-05-03 12:46:42+03 FULL FULL
Каково ваше мнение по данному вопросу?
Есть еще довольно радикальное мнение. Единственный профит от DIFF бэкапа - это ускорение восстановления за счет того, что блоки не перезаписываются несколько раз подряд, как это происходит при восстановлении длинной цепочки инкрементальных бэкапов. pg_probackup даже подсчитывает эффективность инкрементального восстановления, чтобы иметь представление о том, какой объем работы был выполнен впустую:
INFO: Start restoring backup files. PGDATA size: 1554MB
INFO: Backup files are restored. Transfered bytes: 4382MB, time elapsed: 40s
INFO: Approximate restore efficiency ratio: 35% (1554MB/4382MB)
Однако того же эффекта мы можем добиться, если оптимизируем восстановление инкрементальных бэкапов таким образом, чтобы каждый блок был записан ровно один раз.
помимо этого преимущества, DIFF будет занимать места меньше, чем набор DELTA. Иногда это будет играть роль в случаях, когда экстренно нужно освободить место на хранилище бэкапов, чтобы смог завершиться очередной FULL, при этом пожертвовав цепочкой DELTA, зная, что есть DIFF. По интерфейсу, я сначала предполагал, что будет просто новый режим DIFF по аналогии с DELTA/PAGE/FULL. Ведь по сути этот тип бэкапа актуален только для механизма на уровне изменений блоков (DELTA) в плане скорости выполнения при наличии на БД высокой генерации WAL (для PAGE ничего не выигрывается, т.к. нет разницы, сколько WAL в целом нужно будет проанализировать).
помимо этого преимущества, DIFF будет занимать места меньше, чем набор DELTA.
Почему? При неизменности RTO (например, бэкап на каждый час), DIFF наоборот съест больше места из-за дублирования данных. Вообще DIFF бэкап - это про ускорение восстановления за счет потребления дополнительного свободного места.
Иногда это будет играть роль в случаях, когда экстренно нужно освободить место на хранилище бэкапов, чтобы смог завершиться очередной FULL, при этом пожертвовав цепочкой DELTA, зная, что есть DIFF.
Ну по идее Вы можете добиться аналогичного этого эффекта с помощью merge.
По интерфейсу, я сначала предполагал, что будет просто новый режим DIFF по аналогии с DELTA/PAGE/FULL. Ведь по сути этот тип бэкапа актуален только для механизма на уровне изменений блоков (DELTA) в плане скорости выполнения при наличии на БД высокой генерации WAL (для PAGE ничего не выигрывается, т.к. нет разницы, сколько WAL в целом нужно будет проанализировать).
У нас DELTA/PAGE описывают именно физический механизм снятия инкрементальной копии, а DIFF - это логическое понятие, означающее, что у этого инкрементальной копии родителем является FULL. Необходимость указывать физический механизм при этом остается. Поэтому такой вариант интерфейса не подходит.
помимо этого преимущества, DIFF будет занимать места меньше, чем набор DELTA.Почему?
Всё-таки предполагается, что DIFF запускается намного реже DELTA.
По поводу интерфейса: вариант с добавление параметра --diff и колонки Type в show выглядит вполне понятным
Всё-таки предполагается, что DIFF запускается намного реже DELTA.
А общее кол-во DELTA при этой остаётся прежним? Если да, то Вы теряете дополнительное место. Если нет и их кол-во уменьшится, то Вы ухудшите свой RPO/RTO.
Предположим, что есть требование к RPO/RTO, выражающееся в том, что вам нужен бэкап на каждые два часа. Ваша дневная цепочка выглядит так:
22:00 I11
20:00 I10
18:00 I9
16:00 I8
14:00 I7
12:00 I6
10:00 I5
08:00 I4
06:00 I3
04:00 I2
02:00 I1
00:00 F
F - полный, I - инкрементальный (DELTA/PAGE/PTRACK)
Что именно Вы хотите выиграть с помощью DIFF бэкапа? Как бы Вы организовали эту цепочка, если бы можно было бы снимать DIFF бэкапы?
Да, при использовании DIFF естественно больше затраты на место, но есть весомый довод в скорости восстановления.
В моём случае FULL выполняется раз в три дня (т.к. он выполняется более суток), DELTA каждые 2 часа. Хотелось бы иметь DIFF раз/два в сутки.
При такой цепочке FULL2 INCR INCR -если нужно ресторится сюда, то ресторим FULL->DIFF->INCR12,... .. INCR12 DIFF INCR11 INCR10 ... INCR1 FULL1
Будет ли ломаться цепочка DELTA после выполнения DIFF?
Да, при использовании DIFF естественно больше затраты на место, но есть весомый довод в скорости восстановления.
Вот хочется и рыбку съесть и в воду не лезть, т.е. получить константную скорость восстановления при неизменном потреблении свободного места. Так оптимизировать восстановление инкрементальной цепочки, чтобы не было нужды создавать еще одну сущность в виде дифференциального бэкапа. Кое-какую работу в этом направлении мы уже начали: https://github.com/postgrespro/pg_probackup/issues/201
Есть ли у Вас возможность выполнить тестовое восстановление из бэкапа для замера скорости?