New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge при типе бэкапа PAGE Archive #582
Comments
Если у вас только один FULL, то при таких настройках это работать не будет, да и не "безопасно" это иметь всего один "фулл" ... Побился "фулл" или один из "пейджев" в цепочке и вся цепочка идет в "ведро" ... |
Так а какая разница, один фулл, 5, 12? Я главного не пойму - почему оно не будет работать, вот на что хочется услышать ответ. А сколько фуллов, и как их хранить - дело вкуса и нюансов инфраструктуры. |
говорит о том что у вас должна всегда оставаться одна "неизменная" полная копия! Если хотите, то поставьте
и получите ожидаемое поведение |
Я выставил retention-redundancy = 2. И делаю раз в неделю FULL. |
Полагаю формулировка в документации должна быть
вместо
Но в целом, авторам виднее ;) |
Авторы отвечать не спешат. Хотя их мнение хотелось бы услышать, все-таки они же как-то задумыали механизм. Почему бы не раскрыть тайну его работы (в документации, либо здесь ответить). |
Всё там правильно описано в документации. Да, поведение не совсем ожидаемое, но так только кажется. 1 instance 2023-01-25 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, если он единственный? Что-то ничего не понятно. Тоесть, когда фулла два - то можно, а когда один - нельзя? А почему? Потому что есть риск получить поломанную цепочку, если что-то пойдет не так? Ну так это и так понятно, если единственный фулл сломается, это ожидаемое поведение при такой стратегии. Плохая стратегия или хорошая - зависит от ситуации, если я ее сознательно выбрал, занчит, для меня хорошая, зачем это обсуждать вообще?
Не надо его удалять. Его надо смержить. Зачем удалять? Я не хочу удалят, я выбираю: мержить. Почему не происходит мержинг? Где тут про удаление? Сделали новый инкремент, смержили единственный фулл и последующий инкремент, получили более свежий фулл, последующий от него инкремент не сломается, в чем проблема? Все, цепочка не нарушена, единственный фулл есть, окно тоже соблюдено. Инкременты последующие продолжают зависеть от единственного, но более свежего фулла, по-сути, пристрелили один самый старый инркемент и освежили фулл. В чем ошибка? Почему это поведение должно соотвествовать r-r=0, когда не ноль же, а один фулл? |
Потому что в вашем случае настройка |
Ну так я и говорю - одна копия фулл должна быть. И она равна единцице, не нулю. Т.к. у нас в терминологии фулл копия = retention-redundancy =1, то все соблюдается в моем примере. С чего бы ей становиться равной 0, но при этом фактически она есть? Пока что все это выглядит как натягивание совы (в виде официальной документации) на глобус реального поведения. Путем нехитрых манипуляций с терминами, словами и примерами, можно добиться того, что описанное в документации станет похожим на то, что происходит на самом деле (но с определенными оговорками, условностями и пр.). |
Давайте "плясать от печки"! |
Кто сказал, что у Кутузова не было глаза? Был у него глаз!! :) |
Добрый день.
Задумка сделать "вечный инкремент" со слиянием таким образом, чтобы 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
The text was updated successfully, but these errors were encountered: