powered by simpleCommunicator - 2.0.41     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Upgrade 10 to 13 Все как всегда, а хотели по другому ...
18 сообщений из 18, страница 1 из 1
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056892
ТукТум
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем привет!

Текущая версия
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.
/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



А вот и нет!
Журналы в жеской форме напоминают о нашей некомпетентности:

cat pg_upgrade_utility.log cat pg_upgrade_server.log
Код: html
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
command: "/usr/lib/postgresql/10/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/db/postgresql/10/main" -o "-p 50432 -b -c config_file=/etc/postgresql/10/main/postgresql.conf -c listen_addresses='' -c unix_socket_permissions=0700 -c unix$
waiting for server to start....2021-03-25 13:29:36 MSK [2277-1] LOG:  listening on Unix socket "/db/postgresql/.s.PGSQL.50432"
2021-03-25 13:29:36 MSK [2278-1] LOG:  database system was shut down at 2021-03-25 09:27:04 MSK
2021-03-25 13:29:36 MSK [2278-2] LOG:  invalid primary checkpoint record
2021-03-25 13:29:36 MSK [2278-3] LOG:  invalid secondary checkpoint record
2021-03-25 13:29:36 MSK [2278-4] PANIC:  could not locate a valid checkpoint record
2021-03-25 13:29:36 MSK [2277-2] LOG:  startup process (PID 2278) was terminated by signal 6: Aborted
2021-03-25 13:29:36 MSK [2277-3] LOG:  aborting startup due to startup process failure
2021-03-25 13:29:37 MSK [2277-4] LOG:  database system is shut down
 stopped waiting
pg_ctl: could not start server
Examine the log output.



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.
Performing Consistency Checks
-----------------------------


Checking cluster versions                                   ok

*failure*
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure.

connection to database failed: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/db/postgresql/.s.PGSQL.50432"?
could not connect to source postmaster started with the command:
"/usr/lib/postgresql/10/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/db/postgresql/10/main" -o "-p 50432 -b -c config_file=/etc/postgresql/10/main/postgresql.conf -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_d$



Есть ли вариант остаться в живых после этого?

Help!
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056894
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТукТум,

где же ваши pg_wal в /db/postgresql/10/main ?
Не прервали ли вы выключением базы эксклюзивный low-level backup?
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056902
ТукТум
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Melkij,

/usr/lib/postgresql/10/bin/pg_archivecleanup -d /db/postgresql/10/main/pg_wal 0000000100000B58000000C6
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056910
ТукТум
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Melkij,
Бекап, не выполнялся.
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056920
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТукТум
Melkij,

/usr/lib/postgresql/10/bin/pg_archivecleanup -d /db/postgresql/10/main/pg_wal 0000000100000B58000000C6

Это к чему?
Сами удалили WAL и теперь спрашиваете, почему же это база не стартует?
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056937
ТукТум
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Melkij,

Наверное можно как-то оправдаться, но не буду - удалил своими руками!
Завтра, скорее всего там уже имплантанты будут стоять ...

Если я правильно понял вопрос, - это приговор 10-му кластеру. RIP!

Пойду искать букварь.
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056947
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Постоянно наблюдается ситуация, когда по не аккуратности удаляются wal-ы. И это приводит к тому, что теряется вся база данных, т.е. её нельзя запустить. Сами данные в таблицах есть, пусть они не полные, т.к. не проиграны wal.

Вопрос.

Почему в такой ситуации нельзя реализовать возможность запуска БД без wal-ов и получить хотя бы хоть какую-то рабочую базу данных, пусть без каких-то данных, на последний чекпоинт (ну или как-то еще).

А так wal-ы становятся критически важным ресурсом, хотя основной массив данных находится в каталоге base, а он (каталог) без wal-ов становиться никому не нужным.
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056949
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТукТум,

да, без wal'ов что-то сделать весьма нетривиально.

Впрочем, если по controlfile база успешно себя записала как shut down (pg_controlfile -D .. покажет), то pg_resetwal вероятно может помочь без фатальных последствий для данных. Тот единственный случай.
Но после resetwal всё равно только дамп и пересобирать базу через initdb. Можно сразу на новой версии.
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056952
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
big-trot,

- wal'ы и есть критичный ресурс
- такой способ давным давно есть. Кто бы ещё предупреждения к нему читал
- вопрос не в "пусть без каких-то данных" - а в полной мешанине данных из-за нарушения механизма консистентности базы
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056960
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Melkij,

Как-то не укладывается в голове такая ситуация (пусть гипотетическая),
например в каталоге WAL находится в корректной ситуацию один файл wal размером 16MG, и если его удалить, то базу данных размером несколько теробайт можно выкинуть, т.к. без этого файла база данных не запуститься.

Это как в той сказке, выдернули гвоздь из дома и весь дом развалился.
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056963
Фотография mefman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
big-trot
Постоянно наблюдается ситуация, когда по не аккуратности удаляются wal-ы. И это приводит к тому, что теряется вся база данных, т.е. её нельзя запустить. Сами данные в таблицах есть, пусть они не полные, т.к. не проиграны wal.

Вопрос.

Почему в такой ситуации нельзя реализовать возможность запуска БД без wal-ов и получить хотя бы хоть какую-то рабочую базу данных, пусть без каких-то данных, на последний чекпоинт (ну или как-то еще).

А так wal-ы становятся критически важным ресурсом, хотя основной массив данных находится в каталоге base, а он (каталог) без wal-ов становиться никому не нужным.

Почитайте теорию про РСУБД. Там подробно объясняется, что такое "журналы транзакций", зачем они нужны и почему они - становятся являются критически важным ресурсом.
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056965
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
big-trot
Melkij,

Как-то не укладывается в голове такая ситуация (пусть гипотетическая),
например в каталоге WAL находится в корректной ситуацию один файл wal размером 16MG, и если его удалить, то базу данных размером несколько теробайт можно выкинуть, т.к. без этого файла база данных не запуститься.

Это как в той сказке, выдернули гвоздь из дома и весь дом развалился.


не выкинуть а никто не гарантирует его консистентности после этого...
так что запустить можно конечно через специальную вышеупомянутую утилиту... но на свой страх и риск.

В нормальной ситуации консиcтентность важнее и для этого есть реплики и backup/wal archive.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40056966
big-trot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mefman,

Да, надо начинать читать теорию, а задаю какие-то глупые вопросы.
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40057111
ТукТум
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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.
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Checking for presence of required libraries                 fatal
Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
    loadable_libraries.txt



Теперь упираемся в расширения 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

Как быть, может кто-то уже упражнялся с этим?
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40057123
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТукТум,

Melkij
Но после resetwal всё равно только дамп и пересобирать базу через initdb. Можно сразу на новой версии.

Пользоваться базой после resetwal небезопасно для данных.

Используемые в старой версии базы расширения, конечно, должны быть установлены и в новой версии базы.
Если считаете, что расширение не нужно - то его нужно удалить. Находите в этом инстансе все базы, где оно установлено, удаляете в каждой из них.
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40057211
ТукТум
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Melkij,

Добавил недостающие расширения в 13-й кластер

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

*Clusters are compatible*



Но, перед запуском очень нужны ваши разъяснения:
Что означает "только дамп и пересобирать базу через initdb"?

Сейчас создан пустой 13-й кластер и есть "недобитый" 10-й

Если выполнить
Код: sql
1.
2.
3.
4.
5.
6.
7.
/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, 13-й кластер не будет пересобран?

Что нужно сделать, чтобы спасти кластер? Help!
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40057245
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТукТум,

в этом состоянии базу через pg_upgrade переносить можно но не нужно.
Вам же написали прямым русским языком - pg_dump c 10 версии
и pg_restore на 13 версию.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
    #40057510
ТукТум
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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 - только учусь.

И спасибо всем, кто тратит свое время и помогает другим!
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Upgrade 10 to 13 Все как всегда, а хотели по другому ...
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]