|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
Всем привет! Текущая версия PostgreSQL 10.9 (Ubuntu 10.9-1.pgdg16.04+1) on x86_64-pc-linux-gnu Требуется (срочно) обновиться на версию 13. Все красивые слова высечены в граните: https://www.postgresql.org/docs/10/pgupgrade.html И ютуб, говорит что все просто, однако ... после sudo service postgresql stop sudo apt install postgresql-13 /usr/lib/postgresql/13/bin/initdb -D /db/postgresql/13/data Хотим проверить, а можно ли идти в заманчивую прогулку ... Код: html 1. 2. 3. 4. 5. 6. 7.
А вот и нет! Журналы в жеской форме напоминают о нашей некомпетентности: cat pg_upgrade_utility.log cat pg_upgrade_server.log Код: html 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
cat pg_upgrade_utility.log cat pg_upgrade_internal.log Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Есть ли вариант остаться в живых после этого? Help! ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 15:01 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
ТукТум, где же ваши pg_wal в /db/postgresql/10/main ? Не прервали ли вы выключением базы эксклюзивный low-level backup? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 15:07 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
Melkij, /usr/lib/postgresql/10/bin/pg_archivecleanup -d /db/postgresql/10/main/pg_wal 0000000100000B58000000C6 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 15:23 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
Melkij, Бекап, не выполнялся. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 15:40 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
ТукТум Melkij, /usr/lib/postgresql/10/bin/pg_archivecleanup -d /db/postgresql/10/main/pg_wal 0000000100000B58000000C6 Это к чему? Сами удалили WAL и теперь спрашиваете, почему же это база не стартует? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 16:16 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
Melkij, Наверное можно как-то оправдаться, но не буду - удалил своими руками! Завтра, скорее всего там уже имплантанты будут стоять ... Если я правильно понял вопрос, - это приговор 10-му кластеру. RIP! Пойду искать букварь. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 17:00 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
Постоянно наблюдается ситуация, когда по не аккуратности удаляются wal-ы. И это приводит к тому, что теряется вся база данных, т.е. её нельзя запустить. Сами данные в таблицах есть, пусть они не полные, т.к. не проиграны wal. Вопрос. Почему в такой ситуации нельзя реализовать возможность запуска БД без wal-ов и получить хотя бы хоть какую-то рабочую базу данных, пусть без каких-то данных, на последний чекпоинт (ну или как-то еще). А так wal-ы становятся критически важным ресурсом, хотя основной массив данных находится в каталоге base, а он (каталог) без wal-ов становиться никому не нужным. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 17:30 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
ТукТум, да, без wal'ов что-то сделать весьма нетривиально. Впрочем, если по controlfile база успешно себя записала как shut down (pg_controlfile -D .. покажет), то pg_resetwal вероятно может помочь без фатальных последствий для данных. Тот единственный случай. Но после resetwal всё равно только дамп и пересобирать базу через initdb. Можно сразу на новой версии. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 17:31 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
big-trot, - wal'ы и есть критичный ресурс - такой способ давным давно есть. Кто бы ещё предупреждения к нему читал - вопрос не в "пусть без каких-то данных" - а в полной мешанине данных из-за нарушения механизма консистентности базы ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 17:37 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
Melkij, Как-то не укладывается в голове такая ситуация (пусть гипотетическая), например в каталоге WAL находится в корректной ситуацию один файл wal размером 16MG, и если его удалить, то базу данных размером несколько теробайт можно выкинуть, т.к. без этого файла база данных не запуститься. Это как в той сказке, выдернули гвоздь из дома и весь дом развалился. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 17:49 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
big-trot Постоянно наблюдается ситуация, когда по не аккуратности удаляются wal-ы. И это приводит к тому, что теряется вся база данных, т.е. её нельзя запустить. Сами данные в таблицах есть, пусть они не полные, т.к. не проиграны wal. Вопрос. Почему в такой ситуации нельзя реализовать возможность запуска БД без wal-ов и получить хотя бы хоть какую-то рабочую базу данных, пусть без каких-то данных, на последний чекпоинт (ну или как-то еще). А так wal-ы становятся критически важным ресурсом, хотя основной массив данных находится в каталоге base, а он (каталог) без wal-ов становиться никому не нужным. Почитайте теорию про РСУБД. Там подробно объясняется, что такое "журналы транзакций", зачем они нужны и почему они - становятся являются критически важным ресурсом. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 17:53 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
big-trot Melkij, Как-то не укладывается в голове такая ситуация (пусть гипотетическая), например в каталоге WAL находится в корректной ситуацию один файл wal размером 16MG, и если его удалить, то базу данных размером несколько теробайт можно выкинуть, т.к. без этого файла база данных не запуститься. Это как в той сказке, выдернули гвоздь из дома и весь дом развалился. не выкинуть а никто не гарантирует его консистентности после этого... так что запустить можно конечно через специальную вышеупомянутую утилиту... но на свой страх и риск. В нормальной ситуации консиcтентность важнее и для этого есть реплики и backup/wal archive. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 17:54 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
mefman, Да, надо начинать читать теорию, а задаю какие-то глупые вопросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.03.2021, 17:55 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
Melkij, После pg_resetwal DATADIR Продолжаем глумиться над полутрупом... применяем /usr/lib/postgresql/13/bin/pg_upgrade \ --old-datadir /db/postgresql/10/main \ --new-datadir /db/postgresql/13/data \ --old-bindir /usr/lib/postgresql/10/bin \ --new-bindir /usr/lib/postgresql/13/bin \ --old-options '-c config_file=/etc/postgresql/10/main/postgresql.conf' \ --new-options '-c config_file=/etc/postgresql/13/main/postgresql.conf' --link --check Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Теперь упираемся в расширения 10-го кластера could not load library "$libdir/pg_cron": ERROR: could not access file "$libdir/pg_cron": No such file or directory could not load library "$libdir/tds_fdw": ERROR: could not access file "$libdir/tds_fdw": No such file or directory Причем pg_cron в числе досnупных select * from pg_available_extensions; а tds_fdw - нет оба находятся в каталоге /usr/lib/postgresql/10/lib Если так, какмы обычно умеем,то: DROP EXTENSION tds_fdw cascade; ERROR: extension "tds_fdw" does not exist Как быть, может кто-то уже упражнялся с этим? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 11:33 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
ТукТум, Melkij Но после resetwal всё равно только дамп и пересобирать базу через initdb. Можно сразу на новой версии. Пользоваться базой после resetwal небезопасно для данных. Используемые в старой версии базы расширения, конечно, должны быть установлены и в новой версии базы. Если считаете, что расширение не нужно - то его нужно удалить. Находите в этом инстансе все базы, где оно установлено, удаляете в каждой из них. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 12:00 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
Melkij, Добавил недостающие расширения в 13-й кластер Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Но, перед запуском очень нужны ваши разъяснения: Что означает "только дамп и пересобирать базу через initdb"? Сейчас создан пустой 13-й кластер и есть "недобитый" 10-й Если выполнить Код: sql 1. 2. 3. 4. 5. 6. 7.
без --link, 13-й кластер не будет пересобран? Что нужно сделать, чтобы спасти кластер? Help! ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 16:53 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
ТукТум, в этом состоянии базу через pg_upgrade переносить можно но не нужно. Вам же написали прямым русским языком - pg_dump c 10 версии и pg_restore на 13 версию. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
26.03.2021, 18:01 |
|
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
|
|||
---|---|---|---|
#18+
Maxim Boguk ТукТум, в этом состоянии базу через pg_upgrade переносить можно но не нужно. Вам же написали прямым русским языком - pg_dump c 10 версии и pg_restore на 13 версию. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru They also wrote to you in direct Russian - pg_dump from version 10 and pg_restore for version 13. Да, на английском тоже предельно доходчево звучит. As you wish master, will be done! Нужно было сразу так и делать переход с 10 на 13, а то я затеял сначала сделать vacuum full some_table; --большая и дефрагментированная https://www.sql.ru/forum/1334581/vacuum-full-vo-vlasti-temnyh-sil а потом pg_upgrade Зачем? вот наивный ... Сразу прошу прощения у всех кто это читает, я не волшебник в postgres - только учусь. И спасибо всем, кто тратит свое время и помогает другим! ... |
|||
:
Нравится:
Не нравится:
|
|||
28.03.2021, 10:00 |
|
|
start [/forum/topic.php?fid=53&msg=40056894&tid=1994119]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
29ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 256ms |
total: | 379ms |
0 / 0 |