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

Текущая версия
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
25.03.2021, 15:07
    #40056894
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
ТукТум,

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

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

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

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

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

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

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

Вопрос.

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

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

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

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

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

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

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

Вопрос.

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

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

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

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

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


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

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

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

Да, надо начинать читать теорию, а задаю какие-то глупые вопросы.
...
Рейтинг: 0 / 0
26.03.2021, 11:33
    #40057111
ТукТум
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
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
26.03.2021, 12:00
    #40057123
Melkij
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
ТукТум,

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

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

Используемые в старой версии базы расширения, конечно, должны быть установлены и в новой версии базы.
Если считаете, что расширение не нужно - то его нужно удалить. Находите в этом инстансе все базы, где оно установлено, удаляете в каждой из них.
...
Рейтинг: 0 / 0
26.03.2021, 16:53
    #40057211
ТукТум
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
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
26.03.2021, 18:01
    #40057245
Maxim Boguk
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
ТукТум,

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

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
28.03.2021, 10:00
    #40057510
ТукТум
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Upgrade 10 to 13 Все как всегда, а хотели по другому ...
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
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Upgrade 10 to 13 Все как всегда, а хотели по другому ... / 18 сообщений из 18, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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