Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / PostgreSQL Новый топик    Ответить
 Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
ТукТум
Member

Откуда:
Сообщений: 26
Всем привет!

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

Хотим проверить, а можно ли идти в заманчивую прогулку ...

/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
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

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!
25 мар 21, 15:01    [22299872]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 1280
ТукТум,

где же ваши pg_wal в /db/postgresql/10/main ?
Не прервали ли вы выключением базы эксклюзивный low-level backup?

Сообщение было отредактировано: 25 мар 21, 15:02
25 мар 21, 15:07    [22299878]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
ТукТум
Member

Откуда:
Сообщений: 26
Melkij,

/usr/lib/postgresql/10/bin/pg_archivecleanup -d /db/postgresql/10/main/pg_wal 0000000100000B58000000C6
25 мар 21, 15:23    [22299892]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
ТукТум
Member

Откуда:
Сообщений: 26
Melkij,
Бекап, не выполнялся.
25 мар 21, 15:40    [22299908]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 1280
ТукТум
Melkij,

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

Это к чему?
Сами удалили WAL и теперь спрашиваете, почему же это база не стартует?
25 мар 21, 16:16    [22299929]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
ТукТум
Member

Откуда:
Сообщений: 26
Melkij,

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

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

Пойду искать букварь.
25 мар 21, 17:00    [22299955]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
big-trot
Member

Откуда: Тверь
Сообщений: 293
Постоянно наблюдается ситуация, когда по не аккуратности удаляются wal-ы. И это приводит к тому, что теряется вся база данных, т.е. её нельзя запустить. Сами данные в таблицах есть, пусть они не полные, т.к. не проиграны wal.

Вопрос.

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

А так wal-ы становятся критически важным ресурсом, хотя основной массив данных находится в каталоге base, а он (каталог) без wal-ов становиться никому не нужным.
25 мар 21, 17:30    [22299976]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 1280
ТукТум,

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

Впрочем, если по controlfile база успешно себя записала как shut down (pg_controlfile -D .. покажет), то pg_resetwal вероятно может помочь без фатальных последствий для данных. Тот единственный случай.
Но после resetwal всё равно только дамп и пересобирать базу через initdb. Можно сразу на новой версии.
25 мар 21, 17:31    [22299978]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 1280
big-trot,

- wal'ы и есть критичный ресурс
- такой способ давным давно есть. Кто бы ещё предупреждения к нему читал
- вопрос не в "пусть без каких-то данных" - а в полной мешанине данных из-за нарушения механизма консистентности базы
25 мар 21, 17:37    [22299981]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
big-trot
Member

Откуда: Тверь
Сообщений: 293
Melkij,

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

Это как в той сказке, выдернули гвоздь из дома и весь дом развалился.
25 мар 21, 17:49    [22299992]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
mefman
Member

Откуда:
Сообщений: 3372
big-trot
Постоянно наблюдается ситуация, когда по не аккуратности удаляются wal-ы. И это приводит к тому, что теряется вся база данных, т.е. её нельзя запустить. Сами данные в таблицах есть, пусть они не полные, т.к. не проиграны wal.

Вопрос.

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

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

Почитайте теорию про РСУБД. Там подробно объясняется, что такое "журналы транзакций", зачем они нужны и почему они - становятся являются критически важным ресурсом.

Сообщение было отредактировано: 25 мар 21, 17:46
25 мар 21, 17:53    [22299997]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4691
big-trot
Melkij,

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

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


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

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

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
25 мар 21, 17:54    [22299999]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
big-trot
Member

Откуда: Тверь
Сообщений: 293
mefman,

Да, надо начинать читать теорию, а задаю какие-то глупые вопросы.
25 мар 21, 17:55    [22300000]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
ТукТум
Member

Откуда:
Сообщений: 26
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

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

Как быть, может кто-то уже упражнялся с этим?
26 мар 21, 11:33    [22300263]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
Melkij
Member

Откуда: Санкт-Петербург
Сообщений: 1280
ТукТум,

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

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

Используемые в старой версии базы расширения, конечно, должны быть установлены и в новой версии базы.
Если считаете, что расширение не нужно - то его нужно удалить. Находите в этом инстансе все базы, где оно установлено, удаляете в каждой из них.
26 мар 21, 12:00    [22300285]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
ТукТум
Member

Откуда:
Сообщений: 26
Melkij,

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

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-й

Если выполнить
/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!
26 мар 21, 16:53    [22300449]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
Maxim Boguk
Member

Откуда: Melbourne, Австралия
Сообщений: 4691
ТукТум,

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

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
26 мар 21, 18:01    [22300502]     Ответить | Цитировать Сообщить модератору
 Re: Upgrade 10 to 13 Все как всегда, а хотели по другому ...  [new]
ТукТум
Member

Откуда:
Сообщений: 26
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 мар 21, 10:00    [22301001]     Ответить | Цитировать Сообщить модератору
Все форумы / PostgreSQL Ответить