Обновление Postgres 12.1

 

Подготовительные действия:
1. Выключаем экземпляр БД 12.1 предварительно посмотрев параметр

SHOW wal_segment_size;

2. Кладем в /u01/distr дистрибутив 13.2

3. Ставим по инструкции как написано в тут
Но не делаем шаги:
- Необходимые пакеты
- Настройка параметров ядра
- Лимиты
- Параметры монтирования

4. Что делаем но с правками: - Создание необходимых директорий

mkdir -p /u01/postgres/13.2/pgsql/data

chown -R postgres:postgres /u01/postgres/13.2/

5. Cборка Postgres 13.2 из исходников

cd /u01/distr

tar xvzf postgresql-13.2.tar.gz

cd ./postgresql-13.2

./configure --prefix=/u01/postgres/13.2/pgsql 

make -C /u01/distr/postgresql-13.2 world

make -C /u01/distr/postgresql-13.2 install-world

chown -R postgres:postgres /u01/postgres/13.2/

6. Правка сервиса systemd
vim /etc/systemd/system/postgresql.service

[Unit]

Description=PostgreSQL database server

Documentation=man:postgres(1)

[Service]

User=postgres

ExecStart=/u01/postgres/13.2/pgsql/bin/postgres -D /u01/postgres/13.2/pgsql/data

ExecReload=/bin/kill -HUP $MAINPID

KillMode=mixed

KillSignal=SIGINT

TimeoutSec=0

[Install]

WantedBy=multi-user.target

7. Перечитаем конфигурацию systemd Обязательно

systemctl daemon-reload

8. Правка профиля пользователя postgres
Здесь важно не забыть поменять пути до bin постгресовых
иначе кластер будет иницилизироваться старой версии но по новому пути
вобщем меняем везде
vim  /u01/postgres/.profile

export LD_LIBRARY_PATH=/u01/postgres/13.2/pgsql/lib

export PATH=/u01/postgres/13.2/pgsql/bin:$PATH

export MANPATH=/u01/postgres/13.2/pgsql/share/man:$MANPATH

export PGDATA=/u01/postgres/13.2/pgsql/data

export PGDATABASE=postgres

export PGUSER=postgres

export PGPORT=5432

9. Инициализация и запуск кластера  делаем из под su -l postgres

Проверяем версию initdb

initdb --version

если ответ 13.2 все ок можно инициализировать (ну или на какую версию вы обновляетесь)

Для того, что бы понять какой у нас размер wal сегмента мы ранее выполняли команду

Далее либо:

Для больших систем можно сделать больший размер wal-лога. Для небольших оставить по умолчанию (16 МБ).

# Для небольших баз

initdb --data-checksums  --pgdata=/u01/postgres/13.2/pgsql/data --encoding=utf8 --username=postgres --pwprompt

# Для больших баз

initdb --data-checksums --wal-segsize=256 --pgdata=/u01/postgres/13.2/pgsql/data --encoding=utf8 --username=postgres --pwprompt

С подготовлениями закончили, теперь само обновление.
Обновление на 13.2 с копированием содержимого data в новый экземляр *(дальше будет пояснение)
Оба экземпляра БД 12.1 и 13.2 должны быть выключены

В режиме check проверяем все ли у нас ок.
Везде ответы должны быть, что ок. Если что то не так, обязательно напишет.
(Отступы и кавычки исторически менялись пару раз от версии к версии, о том что актуально в настоящий момент можно почитать к версии на которую обновляемся в утилите pg_upgrade)

/u01/postgres/13.2/pgsql/bin/pg_upgrade \

 --old-datadir "/u01/postgres/12.1/pgsql/data" \

 --new-datadir "/u01/postgres/13.2/pgsql/data" \

 --old-bindir "/u01/postgres/12.1/pgsql/bin" \

 --new-bindir "/u01/postgres/13.2/pgsql/bin" \

 --old-options "-c config_file=/u01/postgres/12.1/pgsql/data/postgresql.conf" \

 --new-options "-c config_file=/u01/postgres/13.2/pgsql/data/postgresql.conf" \

 --check

Если все ок, то можем обновляться

(убираем check)

/u01/postgres/13.2/pgsql/bin/pg_upgrade \

 --old-datadir "/u01/postgres/12.1/pgsql/data" \

 --new-datadir "/u01/postgres/13.2/pgsql/data" \

 --old-bindir "/u01/postgres/12.1/pgsql/bin" \

 --new-bindir "/u01/postgres/13.2/pgsql/bin" \

 --old-options "-c config_file=/u01/postgres/12.1/pgsql/data/postgresql.conf" \

 --new-options "-c config_file=/u01/postgres/13.2/pgsql/data/postgresql.conf" \

 --check

Как только обновление завершилось, будет предложено провести analyze нового кластера и удаление старого.
Не удаляем старый.

Запускаем новый 13.2

systemctl start postgresql.service

чекаем в процессах или статусе systemd или в psql, что работает новая версия

ps auxf | grep postgres

psql -c "SELECT version();"

На новом кластере нет никакой статистики. Нужно запустить ANALYZE по кластеру

./analyze_new_cluster.sh

Может так получится что наш кастомный postgresql.conf и pg_hba.conf после обновления станут стандартными.
Правим все из старых в новые. Рестартуем PG.

*Пояснение к обновлению
У меня указано обновление по сути с переносом data в новый кластер.
Тоесть потребуется место по размеру как уже существующая БД.
Но можно с помощью параметра --link сделать жесткую ссылку на data старого кластера это будет без копирования data

При режиме --link
при обновлении будет нотка(для отката)
If you want to start the old cluster, you will need to remove
the ".old" suffix from /u01/postgres/12.1/pgsql/data/global/pg_control.old.
Because "link" mode was used, the old cluster cannot be safely
started once the new cluster has been started.

Так же есть параметр --clone но мне он не совсем понятен пока.
Вот описание.
(Использовать эффективное клонирование файлов (в ряде систем это называется «reflink») вместо копирования файлов в новый кластер. В результате файлы данных могут копироваться практически мгновенно, как и с использованием -k/--link, но последующие изменения не будут затрагивать старый кластер.)

Залипший archive wal log

 На версии 12.

бывает что залипает архивирование wal логов. Логи онлайновые в pg_wal начинают копиться.
В логах Postgres будет примерно такое сообщение об ошибках.

2021-03-06 09:54:40.319 MSK [9448] LOG:  archive command failed with exit code 1

2021-03-06 09:54:40.319 MSK [9448] DETAIL:  The failed archive command was: test ! -f /u01/postgres/12.1/pgsql/pg_wal_archive/00000001000034F400000094 && cp pg_wal/00000001000034F400000094 /u01/postgres/12.1/pgsql/pg_wal_archive/00000001000034F400000094

2021-03-06 09:54:40.319 MSK [9448] WARNING:  archiving write-ahead log file "00000001000034F400000094" failed too many times, will try again later

Что бы этого избежать, нужно создать временную директорию для перекладывания логов

archive_command = 'rm -rf /u01/postgres/12.1/pgsql/pg_wal_archive_tmp/* && cp %p /u01/postgres/12.1/pgsql/pg_wal_archive_tmp/%f && test ! -f /u01/postgres/12.1/pgsql/pg_wal_archive/%f && mv /u01/postgres/12.1/pgsql/pg_wal_archive_tmp/%f /u01/postgres/12.1/pgsql/pg_wal_archive/%f'

Предварительно создав временную папку:

/u01/postgres/12.1/pgsql/pg_wal_archive_tmp

Файл создается в временной директории, а потом перемещается в pg_wal_archive

Но иногда даже после создания временной директории может случится такая ошибка.
Все равно залипает архивация. Главное удалить косячный архив лог(не в коем случае не !wal!)

2021-03-06 10:19:47.152 MSK [13137] LOG:  archive command failed with exit code 1

2021-03-06 10:19:47.152 MSK [13137] DETAIL:  The failed archive command was: rm -rf /u01/postgres/12.1/pgsql/pg_wal_archive_tmp/* && cp pg_wal/00000001000034F400000094 /u01/postgres/12.1/pgsql/pg_wal_archive_tmp/00000001000034F400000094 && test ! -f /u01/postgres/12.1/pgsql/pg_wal_archive/00000001000034F400000094 && mv /u01/postgres/12.1/pgsql/pg_wal_archive_tmp/00000001000034F400000094 /u01/postgres/12.1/pgsql/pg_wal_archive/00000001000034F400000094

2021-03-06 10:19:47.152 MSK [13137] WARNING:  archiving write-ahead log file "00000001000034F400000094" failed too many times, will try again later

После
этого архивирование должно работать ок. Но обязательно нужно попросить
ответсвенного за РК , что бы был сделан Full backup т.к система резервного копирования может ругаться на пропуск 
инкрементальных
бекапов - PostgreSQL Database: [~Archive Log files are missing. Please run a FULL backup~] Data Backup Failed.




СРК
видит, что образовался пробел в  архив логах на опр момент времени.

Поэтому нужно запустить fullbackup. Дальше инкрементальные бекапы будут
создаваться в штатном режиме.

Настройка памяти в PostgreSQL

Обсуждение

Я не претендую на истину, так как мнения коллег очень расходятся.

Возьмем очень условный пример для нашей среды.
Предположим. 8 ГБ, 4 ЦПУ, 300 коннектов к бд.

Если воспользоваться pgtune автор инструмента считает почти по формулам, которые описаны в офф вики постгреса.

Вот как он считает память. Рассмотрим основное.
Но тут не соблюдается условие 1гб под ОС.

max_connections = 300

work_mem = 1747kB

shared_buffers = 2GB

effective_cache_size = 6GB

maintenance_work_mem = 512MB

 

Мы задаем лимит для потсгреса в 7гб(7168MB/7340032KB) памяти в limits.conf
Теперь работает с тем, что есть.

max_connections(тут уже cколько мы планируем предполагаем)

Параметр max_connections устанавливает максимальное количество клиентов, которые могут подключиться к PostgreSQL. Поскольку для каждого клиента требуется выделять память (work_mem), то этот параметр предполагает максимально возможное использование памяти для всех клиентов. Как правило, PostgreSQL может поддерживать несколько сотен подключений, но создание нового является дорогостоящей операцией. Поэтому, если требуются тысячи подключений, то лучше использовать пул подключений (отдельная программа или библиотека для продукта, что использует базу). - PGbouncer к примеру.

work_mem

work_mem параметр определяет максимальное количество оперативной памяти, которое может выделить одна операция сортировки, агрегации и др. Это не разделяемая память, work_mem выделяется отдельно на каждую операцию (от одного до нескольких раз за один запрос). Разумное значение параметра определяется следующим образом: количество доступной оперативной памяти (после того, как из общего объема вычли память, требуемую для других приложений, и shared_buffers) делится на максимальное число одновременных запросов умноженное на среднее число операций в запросе, которые требуют памяти.

Т.к мы не знаем сколько у нас сортировок/агрегаций в одном запросе то рекумендуется в качестве начального значения для параметра можно взять 2–4% доступной памяти.

так же есть мнение от leopard

Для веб-приложений обычно устанавливают низкие значения work_mem, так как запросов обычно много, но они простые, обычно хватает от 512 до 2048 КБ

ВАЖНО!

общее количество

памяти, которое может быть выделено серверным процессам

определяется как work_mem * max_connections.

тоесть если мы берем

work_mem = 1747kB * 300 активных коннектов то получаем примерно 512МБ расход памяти на все 300 подключение в которых происходит сложный запрос.

еще пример с ruhighload.com

Следовательно, если у Вас 10 активных клиентов и каждый выполняет 1 сложный запрос, то значение в 10Мб для этого параметра скушает 100Мб оперативной

мои выводы и наблюдения.

что к базе не бывает никогда такого открытого кол-ва коннектов до "потолка" , если смотреть в графану то есть минимальное значение и среднее за минуту.

обычно до 100

значит можно

начать с стандарта для веб приложений что делают другие дба в 32/64MB

при этом тоже наблюдение..

Если в логах или explain видно, что создаются временные файлы для 

для внутренних операций сортировки и хеш-таблиц

То стоит увеличить в 2-3 раза это значение. После изменения этого параметра может дать большой прирост в производительности.

у нас же он 128МБ и 1000 коннектов.

Если реально столько будет соединений то база ляжет(?)

shared_buffers

25% от памяти сервера

PostgreSQL не читает данные напрямую с диска и не пишет их сразу на диск. Данные загружаются в общий буфер сервера, находящийся в разделяемой памяти, серверные процессы читают и пишут блоки в этом буфере, а затем уже изменения сбрасываются на диск.

shared_buffers = 7168/100*25=1792MB

effective_cache_size

Этот параметр не влияет на размер разделяемой памяти, выделяемой Postgres Pro, и не задаёт размер резервируемого в ядре дискового кеша; он используется только в качестве ориентировочной оценки.

Не выделяет память, это лишь указание оптимизатору запросов о количестве оперативной памяти используемой в ОС для кэша файловой системы.

Что нашел:

1/2 стандартная настройка. Планировщик будет сам определять как ему лучше поступить.

3/4 ( более 50% )от памяти выделенной ПГ. - будут чаще использоваться индексы

effective_cache_size = 7/4*3 = 5,25 (5GB)

maintenance_work_mem

Задаёт максимальный объём памяти для операций обслуживания БД, в частности VACUUM, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. По умолчанию его значение — 64 мегабайта (64MB). Так как в один момент времени в сеансе может выполняться только одна такая операция и обычно они не запускаются параллельно, это значение вполне может быть гораздо больше work_mem. Увеличение этого значения может привести к ускорению операций очистки и восстановления БД из копии.

Есть мнение

от aka leopard(pgtune)

Неплохо бы устанавливать его значение от 50 до 75% размера вашей самой большой таблицы или индекса или, если точно определить не возможно, от 32 до 256 МБ. Следует устанавливать большее значение, чем для work_mem. Слишком большие значения приведут к использованию свопа.Например, при памяти 1–4 ГБ рекомендуется устанавливать 128–512 MB

Есть еще мнение что 

стоит сделать 10% от памяти сервера

увидел в гитхабе одного ДБА

т.е

7168 память под ПГ - 10% = 716.8 ˜ = 700 MB

Установка расширения jsonknife

 

Качаем тут https://github.com/niquola/jsonknife

1. Закидываем архив jsonknife-master.zip в /u01/distr

2. unzip jsonknife-master.zip

3.  chown -R postgres:postgres jsonknife-master chmod 755 -R jsonknife-master cp -r jsonknife-master /u01/distr/postgresql-12.1/contrib/ cd /u01/distr/postgresql-12.1/contrib/jsonknife-master

4.Т.к сборка идет под пользователем postgres и у него обьявлены все переменные

EDITOR=vim visudo 
postgres ALL=(ALL:ALL) NOPASSWD:ALL

5. make && sudo make install && make installcheck

В конце должно выдать, что то типо:

============== dropping database "contrib_regression" ============== NOTICE: database "contrib_regression" does not exist, skipping DROP DATABASE ============== creating database "contrib_regression" ============== CREATE DATABASE ALTER DATABASE ============== running regression test queries ============== test test ... ok 26 ms ===================== All 1 tests passed. ===================== 

Тестовую таблицу "contrib_regression" можно дропнуть, она не нужна. Далее \c имя_бд и create extension jsonknife; \dx можно глянуть расширения.

Установка сторонних расширений в Postgres

 Рассмотрим установку расширения на примере pgsentinel

Стоит отметить, что расширение загружается в конкретную базу, а не в экземпляр.

pgsentinel – хранение истории активных сессий

Расширение pgsentinel предоставляет возможность собирать и просматривать историю активных сессий в PostgreSQL.

Требуется установленная версия PostgreSQL  не ниже PostgreSQL 9.6  или выше.
Перед сборкой убедится что есть:

•  PostgreSQL version is 9.6 или выше.
  
•  Установлен пакет разработки PostgreSQL(postgresql(номер версии)-devel)(gcc,llvm,clang  ) или собран PostgreSQL из исходников(у нас из снепшота в 12.1 уже все стоит, можно ничего не ставить)
  Если это не 12.1 из снепшотов , то каких пакетов не хватает в конкретном случае, можно узнать из сообщений об ошибках при компиляции.
• Переменная PATH настроена таким образом, что команда pg_config доступна и запускается. (у нас запускается в 12.1) (команду можно запустить для проверки она безопасная)

Типичная установка для 12.1
Поскольку pgsentinel использует расширение pg_stat_statements (официально связанное с PostgreSQL) для отслеживания того, какие запросы выполняются в  базе данных, нужно добавить следующие записи в postgresql.conf:

$ shared_preload_libraries = 'pg_stat_statements,pgsentinel'

$ # Icncrease the max size of the query strings Postgres records

$ track_activity_query_size = 2048 -- можно больше если запросы очень большие

$ # Track statements generated by stored procedures as well

$ pg_stat_statements.track = all

После добавления этих строк нужно перезапустить экземпляр бд.
Важно: Лучше конечно pg_stat_statements,pgsentinel ставить до запуска прода в эксплуатацию, но если забыли то лучше сделать после 18-00 по согласованию с командой продукта.

После того, как экземпляр БД перезапущен
Создаем в /u01/postgres директорию external_extensions
владелец директории и все что внутри postgres

В эту директорию (external_extensions) закидываем  архив с расширением скачать можно тут → https://github.com/pgsentinel/pgsentinel
и разархивируем

unzip pgsentinel-master.zip

Далее

$ cd pgsentinel/src

$ make

$ sudo make install

После чего можно уже создать расширение:

Коннект в БД

\c имя_БД

create extension pg_stat_statements;

create extension pgsentinel;

Проверить можно так:

Коннект в нужную бд и выполняем

\dx

Закачка видео с ютуб и конвертация

youtube-dl --extract-audio --audio-format mp3 -i 'ссылка на плейлист на ютубе"

Как проверить iso образ linux

Как проверить iso образ linux? Обезопасить себя от дистрибутива модифицированного хакерами? Всего пара шагов.
На примере Linux Mint 18.

1)Качаем .iso образ с ОФФИЦИАЛЬНОГО ftp или другого хранилища производителя дистрибутива.
2)Оттуда так же качаем sha256sum.txt  sha256sum.txt.gpg.
3) Пункт сравниваем.

Открываем терминал и пишем.

gpg --verify sha256sum.txt.gpg sha256sum.txt

Ответ

pg: Подпись создана Чт 30 июн 2016 14:13:33 MSK ключом RSA с ID A25BAE09
gpg: Действительная подпись от "Linux Mint ISO Signing Key <root@linuxmint.com>"
gpg: ВНИМАНИЕ: Данный ключ не заверен доверенной подписью!
gpg:          Нет указаний на то, что подпись принадлежит владельцу.
Отпечаток главного ключа: 27DE B156 44C6 B3CF 3BD7  D291 300F 846B A25B AE09

Идем на сайт и видим. Что совпадет строка выделенная красным

Fingerprint 27DE B156 44C6 B3CF 3BD7 D291 300F 846B A25B AE09 UID Linux Mint ISO Signing Key

Далее

sha256sum -b linuxmint-18-cinnamon-64bit.iso

2238dca5b51f9e2674a7e31c46f19141fbdecff6e44c06ecbc9a7bb59b75a816 *linuxmint-18-cinnamon-64bit.iso

Сохраняем это в файл

И в программе Meld сравниваем ваш файл и sha256sum.txt

Совпадение есть. Можно ставить.