postgrespro
Merge при типе бэкапа PAGE Archive
Добрый день. Задумка сделать "вечный инкремент" со слиянием таким образом, чтобы FULL бэкап все время находился "на расстоянии" двухнедельной отметки от текущего бэкапа.
Делаю ретеншен
Retention parameters
retention-redundancy = 1 retention-window = 14 wal-depth = 7
запускаю командой с ключами --delete-expired --merge-expired ежедневно pg_probackup-14 backup --instance=$INSTANCE -j 2 -b PAGE --compress --delete-expired --merge-expired --delete-wal
ожидаю, что как только произойдет превышение времени хранения, у меня FULL должен "слиться" с последующим после него инкрементом, тоесть фулл займет место инкремента и так же останется на двухнедельной отметке в прошлом.
инкрементные бэкапы делаются, но при этом FULL не сливается с последующим PAGE. Или я не верно понимаю логику работы ключей --delete-expired --merge-expired?
pg_probackup-14 show --instance=utprof -B /backup/pg/probackup
Instance Version ID Recovery Time Mode WAL Mode TLI Time Data WAL Zratio Start LSN Stop LSN Status
utprof 14 RNP3HZ 2022-12-30 15:27:52+07 PAGE ARCHIVE 1/1 52s 17MB 16MB 1.92 12/A1000028 12/A2050D98 OK utprof 14 RNP3AO 2022-12-30 15:23:25+07 PAGE ARCHIVE 1/1 48s 96MB 16MB 1.34 12/9D0000D8 12/9E11F2E0 OK utprof 14 RNP2JL 2022-12-30 15:07:18+07 PAGE ARCHIVE 1/1 53s 48MB 16MB 3.21 12/95000028 12/9609FE08 OK utprof 14 RNNTS1 2022-12-29 23:00:33+07 PAGE ARCHIVE 1/1 1m:2s 136MB 16MB 1.99 12/4F000028 12/5003F870 OK utprof 14 RNLZ41 2022-12-28 23:00:33+07 PAGE ARCHIVE 1/1 1m:6s 68MB 16MB 3.27 11/DB000028 11/DC0C0340 OK utprof 14 RNK4G1 2022-12-27 23:00:32+07 PAGE ARCHIVE 1/1 1m:8s 131MB 16MB 1.90 11/68000028 11/690000F0 OK utprof 14 RNI9S2 2022-12-26 23:00:32+07 PAGE ARCHIVE 1/1 1m:2s 69MB 16MB 2.66 10/F3000028 10/F40000F0 OK utprof 14 RNGF41 2022-12-25 23:00:25+07 PAGE ARCHIVE 1/1 1m:1s 187MB 16MB 2.35 10/8F000028 10/900000F0 OK utprof 14 RNEKG1 2022-12-24 23:00:20+07 PAGE ARCHIVE 1/1 51s 27MB 16MB 2.13 10/69000028 10/6A0000F0 OK utprof 14 RNCPS1 2022-12-23 23:00:28+07 PAGE ARCHIVE 1/1 1m:3s 129MB 16MB 1.85 10/54000028 10/550000F0 OK utprof 14 RNAV41 2022-12-22 23:00:30+07 PAGE ARCHIVE 1/1 1m:4s 58MB 16MB 3.11 10/E000028 10/F0000F0 OK utprof 14 RN90G1 2022-12-21 23:00:41+07 PAGE ARCHIVE 1/1 53s 227MB 16MB 4.78 F/B1000028 F/B20312F0 OK utprof 14 RN75S1 2022-12-20 23:00:28+07 PAGE ARCHIVE 1/1 59s 55MB 16MB 2.85 E/DD000028 E/DE0000F0 OK utprof 14 RN5B41 2022-12-19 23:00:30+07 PAGE ARCHIVE 1/1 1m:40s 137MB 16MB 1.83 E/84000028 E/8501E060 OK utprof 14 RN3GG1 2022-12-18 23:00:26+07 PAGE ARCHIVE 1/1 59s 82MB 16MB 2.94 E/24000028 E/250000F0 OK utprof 14 RN1LS1 2022-12-17 23:00:22+07 PAGE ARCHIVE 1/1 56s 99MB 16MB 1.38 E/5000028 E/60000F0 OK utprof 14 RMZR41 2022-12-16 23:00:31+07 PAGE ARCHIVE 1/1 1m:5s 59MB 16MB 3.41 D/F2000028 D/F301E018 OK utprof 14 RMXWG1 2022-12-15 23:00:30+07 PAGE ARCHIVE 1/1 1m:3s 130MB 16MB 1.75 D/A1000028 D/A2015830 OK utprof 14 RMW1SB 2022-12-14 23:01:17+07 PAGE ARCHIVE 1/1 1m:56s 51MB 16MB 3.30 D/4F000028 D/5001EC60 OK utprof 14 RMU741 2022-12-13 23:00:30+07 PAGE ARCHIVE 1/1 1m:3s 52MB 16MB 3.19 C/F0000028 C/F10000F0 OK utprof 14 RMSCG2 2022-12-12 23:00:33+07 PAGE ARCHIVE 1/1 1m:3s 52MB 16MB 3.18 C/9D000028 C/9E029388 OK utprof 14 RMQHS1 2022-12-11 23:00:24+07 PAGE ARCHIVE 1/1 45s 96MB 16MB 2.24 C/3A000028 C/3B0000F0 OK utprof 14 RMON42 2022-12-10 23:00:22+07 PAGE ARCHIVE 1/1 41s 64MB 16MB 1.47 C/1E000028 C/1F0000F0 OK utprof 14 RMMSG2 2022-12-09 23:00:26+07 PAGE ARCHIVE 1/1 58s 32MB 16MB 3.34 C/7000028 C/80000F0 OK utprof 14 RMLYJD 2022-12-09 12:14:24+07 PAGE ARCHIVE 1/1 58s 34MB 16MB 3.49 B/DF000028 B/E00EE308 OK utprof 14 RMKXS1 2022-12-08 23:00:25+07 PAGE ARCHIVE 1/1 58s 34MB 16MB 2.98 B/B0000028 B/B10000F0 OK utprof 14 RMK3VD 2022-12-08 12:14:22+07 PAGE ARCHIVE 1/1 53s 22MB 16MB 3.24 B/83000028 B/84047BC8 OK utprof 14 RMJ341 2022-12-07 23:00:27+07 PAGE ARCHIVE 1/1 1m:1s 44MB 16MB 3.10 B/69000028 B/6A02FBB8 OK utprof 14 RMI97E 2022-12-07 12:14:24+07 PAGE ARCHIVE 1/1 55s 35MB 16MB 3.43 B/30000028 B/3113CAE8 OK utprof 14 RMH8G5 2022-12-06 23:00:39+07 PAGE ARCHIVE 1/1 1m:37s 42MB 16MB 3.21 B/C000028 B/D01DE88 OK utprof 14 RMGEJD 2022-12-06 12:14:25+07 PAGE ARCHIVE 1/1 55s 26MB 16MB 3.60 A/D3000028 A/D40843E0 OK utprof 14 RMFDS1 2022-12-05 23:00:33+07 PAGE ARCHIVE 1/1 1m:5s 44MB 16MB 3.15 A/AF000028 A/B001BC90 OK utprof 14 RMDJ41 2022-12-04 23:04:04+07 FULL ARCHIVE 1/0 5m:23s 7711MB 16MB 3.03 A/72000028 A/730F4B30 OK
Если у вас только один FULL, то при таких настройках это работать не будет, да и не "безопасно" это иметь всего один "фулл" ... Побился "фулл" или один из "пейджев" в цепочке и вся цепочка идет в "ведро" ... При ваших настройках делайте FULL, например, каждый выходной и тогда получите то что хотите. У вас будет один "фулл" в "середине" цепочки, и один всегда будет "подтягиваться" до 2-х недельного "окна"
Так а какая разница, один фулл, 5, 12? Я главного не пойму - почему оно не будет работать, вот на что хочется услышать ответ. А сколько фуллов, и как их хранить - дело вкуса и нюансов инфраструктуры. У фулла истек период хранения, при этом в политике стоит - хранить один фулл за 14 дневное окно. Вот он постепенно дополз до границы окна, но вместо того, чтобы его удалять, он должен (по логике) смержиться с предыдущим пейджем. Что здесь не будет работать, и, главное, почему? Вот в чем вопрос. Я логику не понимаю. А ваш совет ни на один из поставленных вопросов не ответил. Только лишь на те, которые я не задавал. И в вашем случае фулл "в середине" будет ровно один день. А потом поползет ко второму фуллу.. И будет момент, когда их будет два, один 13 дневной давности, второй - 14дневной. Не намного надежней.
retention-redundancy = 1
говорит о том что у вас должна всегда оставаться одна "неизменная" полная копия! Слияние может привести к тому что полная копия станет "тыквой", поэтому при таких настройках единственная полная копия не сливается с инкрементальными.
Если хотите, то поставьте
retention-redundancy = 0
и получите ожидаемое поведение
Если хотите, то поставьте retention-redundancy = 0 и получите ожидаемое поведение
Я выставил retention-redundancy = 2. И делаю раз в неделю FULL. Теперь мержинг происходит корректно. Но. Вместо двух полных копий я наблюдаю три :) Ну, тоесть у меня всегда есть "самая старая", которая мержится постоянно и "подтягивается", и еще две, которые плавно "сползают" в процессе копирования. Это похоже на то поведение, которое озвучено выше. Но это не совпадает с тем, что написано в официальной доке. Я не пробовал пока retention-redundancy = 0 но уже станно, что поведение именно такое: ставим 0 там, где ожидаем увидеть 1. Тоесть, гурбо гвооря, кол-во FULL копий должно всегда быть retention-redundancy +1? Так, чтоли? Какое-то это не явное поведение, расходящееся с поведением, описанным в документации..
Какое-то это не явное поведение, расходящееся с поведением, описанным в документации..
Полагаю формулировка в документации должна быть
Определяет количество неизменяемых (не попадающих под действие MERGE) полных резервных копий, которое должно сохраняться в каталоге копий.
вместо
Определяет количество полных резервных копий, которое должно сохраняться в каталоге копий.
Но в целом, авторам виднее ;)
Авторы отвечать не спешат. Хотя их мнение хотелось бы услышать, все-таки они же как-то задумыали механизм. Почему бы не раскрыть тайну его работы (в документации, либо здесь ответить). Т.к. фактическое поведение отличается от того, что указано в документации.
Всё там правильно описано в документации. Да, поведение не совсем ожидаемое, но так только кажется. retention-redundancy=1 значит, что минимум 1 фулл должен существовать. Важный момент, который необходимо учитывать - это retention-window. Смотрите пример ниже. Настройки retention-redundancy = 1, retention-window = 7, фуллы по средам и воскресеньям.
1 instance 2023-01-25 FULL 2 instance 2023-01-24 DELTA 3 instance 2023-01-23 DELTA 4 instance 2023-01-22 FULL 5 instance 2023-01-21 DELTA 6 instance 2023-01-20 DELTA 7 instance 2023-01-19 DELTA 8 instance 2023-01-18 FULL
Как видите, фуллов вообще 3. А бекапов 8, а не 7. retention-window - сколько дней хранить. Например, retention-window = 1 означает хранить 1 день. Сколько будет бекапов? Правильно 2. Сегодня минус 1 день.
То же самое с retention-redundancy = 1. Фуллов будет минимум 2, т.к. один последний, а за ним, инкременты, которые от него зависят, это фулл нельзя удалить. Да, будет идти мёрж, количество промежуточных, между фуллами инкрементов будет уменьшаться, пока фуллы не встанут друг за другом и не будет удалён первый от которого не зависит ни один инкремент. В какой-то момент, при r-r=1, r-w=7, и бекапе раз в неделю, фуллов может быть даже 3, т.к. сначала будет сделан свежий фулл и потом будет удалён самый старый. А в моём примере выше вообще 4 фулла будет. Хотя да, как бы r-r=1.
Хотите 1 фулл и инкременты? Пожалуйста. Как писали выше - retention-redundancy = 0, retention-window = <нужная глубина>. Да, это фиговый вариант, если у вас нет плана Б. У меня есть, я иногда использую такую схему.
Всё там правильно описано в документации.
Да где же правильно то? Где сказано, что нельзя мержит один фулл с последующим PAGE, если он единственный? Что-то ничего не понятно. Тоесть, когда фулла два - то можно, а когда один - нельзя? А почему? Потому что есть риск получить поломанную цепочку, если что-то пойдет не так? Ну так это и так понятно, если единственный фулл сломается, это ожидаемое поведение при такой стратегии. Плохая стратегия или хорошая - зависит от ситуации, если я ее сознательно выбрал, занчит, для меня хорошая, зачем это обсуждать вообще? В документации написано: retention-window - количество дней, в течении которых необходимо держать как минимум retention-redundancy фуллов. Я ставлю r-w=14, r-r=1 и ожидаю, как сказано в документации, что у меня будет один фулл за это время, при учете, что я больше не делаю фуллов вообще, а делаю только PAGE. И ожидаю, что у меня по истечении политики хранения фулл будет сливаться с последующим после него PAGE, чтобы получить вечный инкремент с постоянно обновленным фуллом. Где тут ошибка в логике? Или какая заложена "неявная" логика, которая мешает это сделать? Почему нельзя сделать? Я упорно не могу понять. Если она есть (логика), я хочу понять ее механизм. И желаетльно, описанный явно, а не реверс инжинирингом, исследуя поведение в том или ином случае. То, что бэкапы могут все в тыкву превратиться, я понимаю, но если меня это устраивает, то почему нет? Почему r-r = 0 должно быть при этом? Это занчит вообще не хранить фуллов, а у меня условие не такое, у меня условие - как минимум один. И в случае, когда делаешь фулл первый раз, а потом всегда PAGE - почему это не выполняется? Можете пояснить? Не понимаю.
То же самое с retention-redundancy = 1. Фуллов будет минимум 2, т.к. один последний, а за ним, инкременты, которые от него зависят, это фулл нельзя удалить.
Не надо его удалять. Его надо смержить. Зачем удалять? Я не хочу удалят, я выбираю: мержить. Почему не происходит мержинг? Где тут про удаление? Сделали новый инкремент, смержили единственный фулл и последующий инкремент, получили более свежий фулл, последующий от него инкремент не сломается, в чем проблема? Все, цепочка не нарушена, единственный фулл есть, окно тоже соблюдено. Инкременты последующие продолжают зависеть от единственного, но более свежего фулла, по-сути, пристрелили один самый старый инркемент и освежили фулл. В чем ошибка? Почему это поведение должно соотвествовать r-r=0, когда не ноль же, а один фулл?
Почему r-r = 0 должно быть при этом? Это занчит вообще не хранить фуллов, а у меня условие не такое, у меня условие - как минимум один.
Потому что в вашем случае настройка --retention-redundancy не имеет какого-либо смыла, ибо нельзя соблюсти ваше --retention-window не имея хотя бы одной полной копии! Посему, для выполнения вашего сценария достаточно просто указать --retention-window и не загонятся на тему --retention-redundancy от слова "совсем" ;)
Потому что в вашем случае настройка
--retention-redundancyне имеет какого-либо смыла, ибо нельзя соблюсти ваше--retention-windowне имея хотя бы одной полной копии!
Ну так я и говорю - одна копия фулл должна быть. И она равна единцице, не нулю. Т.к. у нас в терминологии фулл копия = retention-redundancy =1, то все соблюдается в моем примере. С чего бы ей становиться равной 0, но при этом фактически она есть?
Пока что все это выглядит как натягивание совы (в виде официальной документации) на глобус реального поведения. Путем нехитрых манипуляций с терминами, словами и примерами, можно добиться того, что описанное в документации станет похожим на то, что происходит на самом деле (но с определенными оговорками, условностями и пр.).
Ну так я и говорю - одна копия фулл должна быть. И она равна единцице, не нулю. Т.к. у нас в терминологии фулл копия = retention-redundancy =1, то все соблюдается в моем примере. С чего бы ей становиться равной 0, но при этом фактически она есть?
Давайте "плясать от печки"! retention-redundancy дословно "избыточность хранения"!
Таким образом --retention-redundancy=1 означает, что в вашем "хранилище" резервных копий должна быть одна "избыточная" полная копия! Т..е. по факту для соблюдения вашей настройки --retention-window, получается что не может быть только одна полная копия.
Т..е. по факту для соблюдения вашей настройки
--retention-window, получается что не может быть только одна полная копия.
Кто сказал, что у Кутузова не было глаза? Был у него глаз!! :) благодарю за разъяснения, в любом случае..