Какой командой можно выполнить обновление конфигурации postgresql
pg_upgrade — обновить экземпляр сервера PostgreSQL
Синтаксис
pg_upgrade -b старый_каталог_bin -B новый_каталог_bin -d старый_каталог_конфигурации -D новый_каталог_конфигурации [ параметр . ]
Описание
Программа pg_upgrade (ранее называвшаяся pg_migrator ) позволяет обновить данные в каталоге базы данных PostgreSQL до последней основной версии PostgreSQL без операции выгрузки/перезагрузки данных, обычно необходимой при обновлениях основной версии, например, при переходе от 9.5.8 к 9.6.4 или от 10.7 к 11.2. Эти действия не требуются при установке корректирующей версии, например, при переходе от 9.6.2 к 9.6.3 или от 10.1 к 10.2.
С выходом новых основных версий в PostgreSQL регулярно добавляются новые возможности, которые часто меняют структуру системных таблицы, но внутренний формат хранения меняется редко. Учитывая этот факт, pg_upgrade позволяет выполнить быстрое обновление, создавая системные таблицы заново, но сохраняя старые файлы данных. Если при обновлении основной версии формат хранения данных изменится так, что данные в старом формате окажутся нечитаемыми, pg_upgrade не сможет произвести такое обновление. (Сообщество разработчиков постарается не допустить подобных ситуаций.)
Программа pg_upgrade делает всё возможное, чтобы убедиться в том, что старый и новый кластеры двоично-совместимы, в частности проверяя параметры времени компиляции и разрядность (32/64 бита) исполняемых файлов. Важно, чтобы и все внешние модули тоже были двоично-совместимыми, хотя это pg_upgrade проверить не может.
pg_upgrade поддерживает обновление с версии 8.4.X и новее до текущей основной версии PostgreSQL , включая бета-выпуски и сборки снимков кода.
Параметры
pg_upgrade принимает следующие аргументы командной строки:
-b каталог_bin
—old-bindir= каталог_bin
каталог с исполняемыми файлами старой версии PostgreSQL; переменная окружения PGBINOLD -B каталог_bin
—new-bindir= каталог_bin
каталог с исполняемыми файлами новой версии PostgreSQL; переменная окружения PGBINNEW -c
—check
только проверить кластеры, не изменять никакие данные -d каталог_конфигурации
—old-datadir= каталог_конфигурации
каталог конфигурации старого кластера; переменная окружения PGDATAOLD -D каталог_конфигурации
—new-datadir= каталог_конфигурации y
каталог конфигурации нового кластера; переменная окружения PGDATANEW -j число_заданий
—jobs= число_заданий
число одновременно задействуемых процессов или потоков -k
—link
использовать жёсткие ссылки вместо копирования файлов в новый кластер -o параметры
—old-options параметры
параметры, передаваемые непосредственно старой программе postgres ; несколько параметров складываются вместе -O параметры
—new-options параметры
параметры, передаваемые непосредственно новой программе postgres ; несколько параметров складываются вместе -p порт
—old-port= порт
номер порта старого кластера; переменная окружения PGPORTOLD -P порт
—new-port= порт
номер порта нового кластера; переменная окружения PGPORTNEW -r
—retain
сохранить SQL и журналы сообщений даже при успешном завершении -U имя_пользователя
—username= имя_пользователя
имя пользователя, установившего кластер; переменная окружения PGUSER -v
—verbose
включить подробные внутренние сообщения -V
—version
показать версию, а затем завершиться -?
—help
показать справку, а затем завершиться
Использование
Далее описан план обновления с использованием pg_upgrade :
Переместить старый кластер (необязательно)
Если ваш каталог инсталляции привязан к версии, например, /opt/PostgreSQL/10 , перемещать его не требуется. Все графические инсталляторы выбирают при установке каталоги, привязанные к версии.
Если ваш каталог инсталляции не привязан к версии, например /usr/local/pgsql , необходимо переместить каталог текущей инсталляции PostgreSQL, чтобы он не конфликтовал с новой инсталляцией PostgreSQL . Когда текущий сервер PostgreSQL отключён, каталог этой инсталляции PostgreSQL можно безопасно переместить; если старый каталог /usr/local/pgsql , его можно переименовать, выполнив:
mv /usr/local/pgsql /usr/local/pgsql.old
Собрать новую версию при установке из исходного кода
Соберите из исходного кода новую версию PostgreSQL с флагами configure , совместимыми с флагами старого кластера. Программа pg_upgrade проверит результаты pg_controldata , чтобы убедиться, что все параметры совместимы, прежде чем начинать обновление.
Установить новые исполняемые файлы PostgreSQL
Установите новые исполняемые файлы сервера и вспомогательные файлы. Программа pg_upgrade включена в инсталляцию по умолчанию.
При установке из исходного кода, если вы хотите разместить сервер в нестандартном каталоге, воспользуйтесь переменной prefix :
make prefix=/usr/local/pgsql.new install
Инициализировать новый кластер PostgreSQL
Инициализируйте новый кластер, используя initdb . При этом так же необходимо указать флаги initdb , совместимые с флагами в старом кластере. Многие готовые инсталляторы выполняют это действие автоматически. Запускать новый кластер не требуется.
Установить разделяемые объектные файлы расширения
Многие расширения и пользовательские модули, как из contrib , так и из других источников, используют разделяемые объектные файлы (или библиотеки DLL), например, pgcrypto.so . Если они использовались в старом кластере, разделяемые объектные файлы, соответствующие новому исполняемому файлу сервера, должны быть установлены в новом кластере, обычно средствами операционной системы. Не загружайте определения схемы, например, выполняя CREATE EXTENSION pgcrypto , потому что они будут скопированы из старого кластера. Если доступны обновления расширений, pg_upgrade сообщит об этом и создаст скрипт, который можно будет запустить позже, чтобы обновить эти расширения.
Скопируйте пользовательские файлы полнотекстового поиска
Скопировать пользовательские файлы полнотекстового поиска (словари, тезаурусы, списки синонимов и стоп-слов) из старого кластера в новый.
Настроить аутентификацию
Программа pg_upgrade будет подключаться к новому и старому серверу несколько раз, так что имеет смысл установить режим аутентификации peer в pg_hba.conf или использовать файл ~/.pgpass (см. Раздел 33.15).
Остановить оба сервера
Убедитесь в том, что оба сервера баз данных остановлены. Для этого в Unix можно выполнить:
pg_ctl -D /opt/PostgreSQL/9.6 stop pg_ctl -D /opt/PostgreSQL/10 stop
А в Windows, с соответствующими именами служб:
NET STOP postgresql-9.6 NET STOP postgresql-10
Ведомые серверы с потоковой репликацией и трансляцией журнала могут продолжать работать до последнего шага.
Подготовиться к обновлению ведомых серверов
Если вы производите обновление ведомых серверов (как описано в разделе Шаг 11), удостоверьтесь, что эти серверы находятся в актуальном состоянии, запустив pg_controldata в старых ведущем и ведомых кластерах. Убедитесь в том, что « Положение последней контрольной точки » во всех кластерах одинаковое. (Несовпадение будет иметь место, если старые ведомые серверы будут отключены раньше, чем старый ведущий, или если старые ведомые серверы всё ещё продолжают работать.) Также убедитесь в том, что в файле postgresql.conf нового ведущего кластера значение wal_level выше minimal .
Запустить pg_upgrade
Всегда запускайте программу pg_upgrade от нового сервера, а не от старого. pg_upgrade требует указания каталогов данных старого и нового кластера, а также каталогов исполняемых файлов ( bin ). Вы можете также определить имя пользователя и номера портов, и нужно ли копировать файлы данных (по умолчанию) или создавать ссылки на них.
Если выбрать вариант со ссылкой на данные, обновление выполнится гораздо быстрее (так как файлы не копируются) и потребует меньше места на диске, но вы лишитесь возможности обращаться к вашему старому кластеру, запустив новый после обновления. Этот вариант также требует, чтобы каталоги данных старого и нового кластера располагались в одной файловой системе. (Табличные пространства и pg_wal могут находиться в других файловых системах.) Полный список параметров вы можете получить, выполнив pg_upgrade —help .
Параметр —jobs позволяет задействовать для копирования/связывания файлов и для выгрузки/перезагрузки схем баз данных несколько процессорных ядер. В качестве начального значения параметра стоит выбрать максимум из числа процессорных ядер и числа табличных пространств. Этот параметр может радикально сократить время обновления сервера со множеством баз данных, работающего в многопроцессорной системе.
В Windows вы должны войти в систему с административными полномочиями, затем запустить командную строку от имени пользователя postgres , задать подходящий путь:
RUNAS /USER:postgres "CMD.EXE" SET PATH=%PATH%;C:\Program Files\PostgreSQL\10\bin;
Наконец, запустить pg_upgrade с путями каталогов в кавычках, например, так:
pg_upgrade.exe --old-datadir "C:/Program Files/PostgreSQL/9.6/data" --new-datadir "C:/Program Files/PostgreSQL/10/data" --old-bindir "C:/Program Files/PostgreSQL/9.6/bin" --new-bindir "C:/Program Files/PostgreSQL/10/bin"
При запуске pg_upgrade проверит два кластера на совместимость и, если всё в порядке, выполнит обновление. Также возможно запустить pg_upgrade —check , чтобы ограничиться только проверками (при этом старый сервер может продолжать работать). Команда pg_upgrade —check также сообщит, какие коррективы вам нужно будет внести вручную после обновления. Если вы планируете использовать режим ссылок на данные, укажите вместе с —check параметр —link , чтобы были проведены специальные проверки для этого режима. Программе pg_upgrade требуются права на запись в текущий каталог.
Очевидно, никто не должен обращаться к кластерам в процессе обновления. Программа pg_upgrade по умолчанию запускает серверы с портом 50432, чтобы не допустить нежелательных клиентских подключений. В процессе обновления оба кластера могут использовать один номер порта, так как они не будут работать одновременно. Однако для проверки старого работающего сервера новый порт должен отличаться от старого.
Если при восстановлении схемы базы данных происходит ошибка, pg_upgrade завершает свою работу и вы должны вернуться к старому кластеру, как описывается ниже в Шаг 17. Чтобы попробовать pg_upgrade ещё раз, вы должны внести коррективы в старом кластере, чтобы pg_upgrade могла успешно восстановить схему. Если проблема возникла в модуле contrib , может потребоваться удалить этот модуль contrib в старом кластере, а затем установить его в новом после обновления (предполагается, что этот модуль не хранит пользовательские данные).
Обновить ведомые серверы с потоковой репликацией и трансляцией журнала
Если вы используете режим ссылок и у вас реализована потоковая репликация (см. Подраздел 26.2.5) или трансляция журнала (см. Раздел 26.2) для ведомых серверов, вы можете быстро обновить эти серверы следующим образом. Вам не нужно будет запускать на них pg_upgrade , вместо этого вы выполните rsync на ведущем. Не запускайте никакие серверы на этом этапе.
Установите новые исполняемые файлы PostgreSQL на ведомых серверах
Убедитесь в том, что на всех ведомых серверах установлены новые исполняемые и вспомогательные файлы.
Убедитесь в том, что новые каталоги данных на ведомых серверах не существуют
Новые каталоги данных ведомых серверов должны отсутствовать либо быть пустыми. Если запускалась программа initdb , удалите новые каталоги данных на ведомых.
Установить разделяемые объектные файлы расширения
Установите на новых ведомых серверах те же разделяемые объектные файлы расширения, что вы установили в новом ведущем кластере.
Остановите ведомые серверы
Если ведомые серверы продолжают работу, остановите их, следуя приведённым выше инструкциям.
Сохраните файлы конфигурации
Сохраните все нужные вам файлы конфигурации из старых каталогов конфигурации ведомых серверов, в частности postgresql.conf (и все файлы, включённые в него), postgresql.auto.conf , recovery.conf и pg_hba.conf , так как они будут перезаписаны или удалены на следующем этапе.
Запустите rsync
Когда используется режим ссылок, ведомые серверы можно быстро обновить, применив rsync . Для этого в каталоге, внутри которого находятся каталоги старого и нового кластера, для каждого ведомого сервера выполните на ведущем :
rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster new_cluster remote_dir
Здесь каталоги old_cluster и new_cluster задаются относительно текущего каталога на ведущем, а remote_dir находится над каталогами старого и нового кластера на ведомом. Структура подкаталогов в заданных каталогах на ведущем и ведомых серверах должна быть одинаковой. Обратитесь к странице руководства rsync , где подробно описано, как указать удалённый каталог, например так:
rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/9.5 \ /opt/PostgreSQL/9.6 standby.example.com:/opt/PostgreSQL
Проверить, что будет делать команда, можно, воспользовавшись параметром rsync —dry-run . Выполнить rsync на ведущем необходимо как минимум с одним ведомым, но затем, пока обновлённый ведомый остаётся остановленным, можно запускать rsync на нём для обновления других ведомых.
В ходе этой операции записываются ссылки, созданные режимом ссылок pg_upgrade , связывающие файлы нового и старого кластера на ведущем сервере. Затем в старом кластере ведомого находятся соответствующие файлы и в новом кластере ведомого создаются ссылки на них. Файлы, не связанные ссылками на ведущем, копируются с него на ведомый. (Обычно их объём невелик.) Это позволяет произвести обновление ведомого быстро. К сожалению, при этом rsync будет напрасно копировать файлы, связанные с временными и нежурналируемыми таблицами, так как они обычно не будут существовать на ведомых серверах.
Если у вас есть табличные пространства, вам потребуется выполнить подобную команду rsync для каталогов всех табличных пространств, например:
rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_9.5_201510051 \ /vol1/pg_tblsp/PG_9.6_201608131 standby.example.com:/vol1/pg_tblsp
Если вы вынесли pg_wal за пределы каталогов данных, нужно будет запустить rsync и для этих каталогов.
Настройте ведомые серверы с потоковой репликацией и трансляцией журнала
Восстановить pg_hba.conf
Если вы изменяли pg_hba.conf , восстановите его исходное состояние. Также может потребоваться скорректировать другие файлы конфигурации в новом кластере, чтобы они соответствовали старому, например, postgresql.conf (и файлы, включённые в него) и postgresql.auto.conf .
Запустить новый сервер
Теперь можно безопасно запустить новый сервер, а затем ведомые серверы, синхронизированные с ним с помощью rsync .
Действия после обновления
Если после обновления требуются какие-то дополнительные действия, программа pg_upgrade выдаст предупреждения об этом по завершении работы. Она также сгенерирует файлы скриптов, которые должны запускаться администратором. Эти скрипты будут подключаться к каждой базе данных, требующей дополнительных операций. Каждый такой скрипт следует выполнять командой:
psql --username=postgres --file=script.sql postgres
Эти скрипты могут выполняться в любом порядке, а после выполнения их можно удалить.
Внимание
Обычно к таблицам, задействованным в перестраивающих базу скриптах, опасно обращаться, пока эти скрипты не сделают свою работу; при этом можно получить некорректный результат или плохую производительность. К таблицам, не задействованным в таких скриптах, можно обращаться немедленно.
Статистика
Так как статистика оптимизатора не передаётся в процессе работы pg_upgrade , вы получите указание запустить соответствующую команду для воссоздания этой информации после обновления. Возможно, для этого вам понадобится установить параметры подключения к новому кластеру.
Удалить старый кластер
Если вы удовлетворены результатами обновления, вы можете удалить каталоги данных старого кластера, запустив скрипт, упомянутый в выводе pg_upgrade после обновления. (Автоматическое удаление невозможно, если в старом каталоге данных находятся дополнительные табличные пространства.) Также вы можете удалить каталоги старой инсталляции (например, bin , share ).
Возврат к старому кластеру
Если выполнив команду pg_upgrade , вы захотите вернуться к старому кластеру, возможны следующие варианты:
Если использовался ключ —check , в старом кластере ничего не меняется; его можно просто перезапустить.
Если не использовался ключ —link , в старом кластере ничего не меняется; его можно просто перезапустить.
Если использовался ключ —link , у старого и нового кластера могут оказаться общие файлы данных:
Если работа pg_upgrade была прервана до начала расстановки ссылок, в старом кластере ничего не меняется; его можно просто перезапустить.
Если вы не запускали новый кластер, старый кластер не претерпел никаких изменений, за исключением того, что при создании ссылки на данные к имени $PGDATA/global/pg_control было добавлено окончание .old . Чтобы продолжить использование старого кластера, достаточно убрать окончание .old из имени файла $PGDATA/global/pg_control ; после этого старый кластер можно будет перезапустить.
Замечания
pg_upgrade не поддерживает обновление баз данных, содержащих следующие ссылающиеся на OID системные типы данных reg* : regproc , regprocedure , regoper , regoperator , regconfig и regdictionary . (Обновление regtype возможно.)
Программа pg_upgrade сообщит обо всех актуальных для вашей инсталляции ошибках и потребностях перестроения или переиндексации базы; при этом будут созданы завершающие обновление скрипты, перестраивающие таблицы или индексы. Если вы попытаетесь автоматизировать обновление множества серверов, вы обнаружите, что для кластеров с одинаковыми схемами баз данных потребуются одинаковые действия после обновления; это объясняется тем, что эти действия диктуются схемой базы данных, а не данными пользователей.
Для проверки развёртывания новой версии создайте копию только схемы старого кластера, наполните этот кластер фиктивными данными, и попробуйте обновить его.
Если вы производите обновление кластера PostgreSQL версии до 9.2, в которой используется каталог только с файлами конфигурации, вы должны передать расположение собственно каталога с данными программе pg_upgrade , а расположение каталога конфигурации передать серверу, например -d /каталог-данных -o ‘-D /каталог-конфигурации’ .
Если вы используете старый сервер версии до 9.1, работающий с нестандартным каталогом Unix-сокетов, либо его стандартное расположение отличается от принятого в новой версии, задайте в PGHOST расположение сокета старого сервера. (К Windows это не относится.)
Если вы хотите использовать режим ссылок на данные, но не хотите каких-либо изменений в старом кластере при запуске нового, сделайте копию старого кластера и обновите его в этом режиме. Чтобы получить рабочую копию старого кластера, воспользуйтесь командой rsync и создайте предварительную копию кластера при работающем сервере, а затем отключите старый сервер и ещё раз запустите rsync —checksum , чтобы привести эту копию в согласованное состояние. (Ключ —checksum необходим, потому что rsync различает время с точностью только до секунд.) При этом вы можете исключить некоторые файлы, например postmaster.pid , как описано в Подразделе 25.3.3. Если ваша файловая система поддерживает снимки файловой системы или копирование при записи, вы можете воспользоваться этим для создания копии старого кластера и табличных пространств; при этом важно, чтобы такие снимки и копии файлов создавались одномоментно или когда сервер баз данных отключён.
См. также
| Пред. | Наверх | След. |
| pg_test_timing | Начало | pg_waldump |
HOWTO: Обновление версии PostgreSQL
В данном разделе описана процедура обновления сервера PostgreSQL на новую основную версию (например, с 9.х на 11.х). Вы также можете обновиться на максимально доступную версию на момент выполнения обновления — все они обратно совместимы.
Мы рекомендуем выполнять процедуру обновления сервера квалифицированным сотрудником используя официальную инструкцию: https://postgrespro.ru/docs/postgresql/11/upgrading.
Обновление в пределах основной версии (например, с 11.1 на 11.3) осуществляется без каких либо дополнительных действий.
Существует несколько способов обновления. Здесь будет рассмотрен способ с полным дампом перед восстановлением и затем восстановлением из дампа после обновления. Также процедура будет описана для ОС Debian и ее производных (Ubuntu и т.д.). Для других дистрибутивов и ОС процедура практически точно такая же, но используются другие утилиты, специфичные для конкретного дистрибутива или ОС.
Предполагается, что установка PostgreSql осуществлялась по этой инструкции и в систему добавлены репозитории PostgreSql, предоставляющие доступ к различным версиям PostgreSql и расширениям, а также установка производилась по этой инструкции и был установлен пакет postgresql-9.6, а не метапакет postgresql. Если у вас установлен метапакет, то обновление должно произойти автоматически при обновлении метапакета, но не факт, что оно пройдет корректно. Мы рекомендуем использовать конкретные пакеты (с указанием версии) вместо метапакетов.
Если в процессе обновления не удается успешно выполнить какую-то команду, пожалуйста, не продолжайте выполнять остальные пункты, пока не решите проблему. К сожалению, мы не являемся специалистами по всем проблемам PostgreSql, а также остальных служб, поэтому не всегда сможем дать квалифицированный ответ.
1. Остановите работу всех систем, использующих базу данных. Остановите работу php-fpm или apache2, а также временно отключите задачи в cron и остановите работающие модули usm_*.
2. Проверьте, какие версии PostgreSql и PostGis у вас установлены на данный момент:
sudo -u postgres psql -d userside -A -c "SELECT VERSION()" sudo -u postgres psql -d userside -A -c "SELECT PostGIS_full_version()"
3. Обновите текущие версии, а также, если у вас установлен PostGis 2.4, установите PostGis 2.5 и обновите это расширение в базе данных, затем убедитесь, что расширение в базе данных обновлено:
sudo apt-get update sudo apt-get --only-upgrade install postgresql-9.6 postgresql-9.6-postgis-2.4 -y sudo apt-get install postgresql-9.6-postgis-2.5 -y sudo -u postgres psql -d userside -A -c "ALTER EXTENSION postgis UPDATE" sudo -u postgres psql -d postgres -A -c "ALTER EXTENSION postgis UPDATE" sudo -u postgres psql -d userside -A -c "SELECT PostGIS_full_version()" sudo -u postgres psql -d postgres -A -c "SELECT PostGIS_full_version()"
4. Установите новую версию PostgreSql и PostGis не удаляя старой(!).
sudo apt-get install postgresql-11 postgresql-11-postgis-2.5 -y
5. Выполните запасное резервное копирование всех баз данных сервера (в данном случае будет использоваться последняя версия утилиты pg_dumpall, но база данных будет использоваться все еще прежняя):
sudo -u postgres pg_dumpall > /tmp/dump_9.6_before_update.dump
6. Посмотрите, как выглядят ваши кластеры. Сейчас вы должны видеть две версии, обе в состоянии онлайн:
pg_lsclusters
Вы должны увидеть таблицу:
Ver Cluster Port Status Owner Data directory 9.6 main 5432 online postgres /var/lib/postgresql/9.6/main 11 main 5433 online postgres /var/lib/postgresql/11/main
7. При установке PostgreSql, установщик автоматически создает кластер с конфигурацией и базами данных, чтобы можно было начинать работу с базой данных сразу же. В случае обновления это лишняя операция и кластер для 11 версии нужно удалить. Мы будем его создавать на основе кластера версии 9.6:
sudo pg_dropcluster 11 main --stop
8. Остановите работу службы:
sudo systemctl stop postgresql
9. Сделайте запасное резервное копирование текущих каталогов с файлами базы данных и файлами конфигураций. Будьте осторожны, файлы базы данных могут занимать очень много места, поэтому, возможно, будет лучше выбрать другое место для их размещения. Позже, если обновление пройдет успешно, эти каталоги нужно будет удалить:
sudo cp -r /var/lib/postgresql/9.6/main/ /tmp/pg9.6-lib sudo cp -r /etc/postgresql/9.6/main/ /tmp/pg9.6-etc
10. Запустите процедуру создания нового кластера на основе старого (обновление версии кластера):
sudo pg_upgradecluster -m upgrade 9.6 main
11. Запустите службу:
sudo systemctl start postgresql
12. Посмотрите, как выглядят ваши кластеры:
pg_lsclusters
Теперь вы должны увидеть вот такую таблицу, в которой версия 9.6 находится в состоянии down:
Ver Cluster Port Status Owner Data directory 9.6 main 5433 down postgres /var/lib/postgresql/9.6/main 11 main 5432 online postgres /var/lib/postgresql/11/main
13. Проверьте версии:
sudo -u postgres psql -d userside -A -c "SELECT VERSION()" sudo -u postgres psql -d userside -A -c "SELECT PostGIS_full_version()"
14. Запустите все службы, которые вы остановили в п.1 и проверьте работу USERSIDE и модулей. Убедитесь, что всё работает корректно.
15. После того, как вы убедились, что всё работает корректно, можно удалить временные резервные копии, а также старые пакеты:
sudo pg_dropcluster 9.6 main --stop sudo apt-get purge postgresql-9.6 postgresql-9.6-postgis-2.4 postgresql-9.6-postgis-2.5 -y sudo apt autoremove -y sudo rm -rf /tmp/pg9.6-* /tmp/dump_9.6_before_update.dump
Обновление PostgreSQL завершено.
Работа с конфигурацией в PostgreSQL
При работе с конфигурацией в PostgreSQL вам может потребоваться найти и изменить расположение экземпляра кластера, получить перечень доступных типов данных, изменить настройки СУБД без перезагрузки. Давайте посмотрим, как это лучше сделать.
Находим и меняем расположение экземпляра кластера
В некоторых случаях на одной ОС настроено сразу несколько экземпляров PostgreSQL, и «сидят» они на разных портах. В такой ситуации найти путь к физическому размещению каждого экземпляра — та ещё задачка. Чтобы её упростить, давайте для получения нужной информации, выполним следующий запрос:
SHOW data_directory;А теперь изменим расположение на другое, используя следующую команду:
SET data_directory to new_directory_path;И не забудем выполнить перезагрузку, чтобы изменения вступили в силу.
Получаем перечень доступных типов данных
Здесь всё просто, вот наша команда:
SELECT typname, typlen from pg_type where typtype='b';Обратите внимание, что typname — это имя типа данных, а typlen — размер типа данных.
Меняем настройки СУБД без перезагрузки
Как известно, настройки PostgreSQL располагаются в специальных файлах типа pg_hba.conf и postgresql.conf. Если вы эти файлы измените, потребуется, чтобы система управления БД вновь получила настройки. Естественно, если выполнить перезагрузку, всё буде ок. Но иногда перезагрузка нежелательна. Как раз для таких случаев в PostgreSQL предусмотрена функция, позволяющая применять изменения без перезагрузки:
SELECT pg_reload_conf();Правда, она применима, увы, не ко всем параметрам, поэтому иногда без перезагрузки всё же не обойтись.
Обновление PostgreSQL с 11 до 12 версии
PostgreSQL 12 вышел 03.10.2019. Обновится со старой версии можно через pg_dumpall и pg_upgrade. Ниже описан вариант обновления через pg_upgrade.
Установите PostgreSQL 12:
sudo apt-get update
sudo apt-get install postgresql-12 postgresql-server-dev-12Перенесите ваши кастомные настройки из старых конфигов в новые. Различия конфигов разных версий удобно посмотреть командами:
diff /etc/postgresql/11/main/postgresql.conf /etc/postgresql/12/main/postgresql.conf
diff /etc/postgresql/11/main/pg_hba.conf /etc/postgresql/12/main/pg_hba.confОстановите запущенный PostgreSQL:
sudo systemctl stop postgresql.serviceПерейдите в каталог с временными файлами. Туда будут записаны логи и добавлены некоторые скрипты:
cd /tmpЗапускаем работу в командной строке от пользователя postgres:
sudo su postgresБезопасно проверяем кластеры, без изменения каких-либо данных:
/usr/lib/postgresql/12/bin/pg_upgrade \
— old-datadir=/var/lib/postgresql/11/main \
— new-datadir=/var/lib/postgresql/12/main \
— old-bindir=/usr/lib/postgresql/11/bin \
— new-bindir=/usr/lib/postgresql/12/bin \
— old-options ‘-c config_file=/etc/postgresql/11/main/postgresql.conf’ \
— new-options ‘-c config_file=/etc/postgresql/12/main/postgresql.conf’ \
— checkЕсли ошибок нет, проводим миграцию данных (если у Вас нет необходимости в копировании файлов в новый кластер, то используйте параметр — link. Будут использованы жесткие ссылки на старый кластер, без копирования):
/usr/lib/postgresql/12/bin/pg_upgrade \
— old-datadir=/var/lib/postgresql/11/main \
— new-datadir=/var/lib/postgresql/12/main \
— old-bindir=/usr/lib/postgresql/11/bin \
— new-bindir=/usr/lib/postgresql/12/bin \
— old-options ‘-c config_file=/etc/postgresql/11/main/postgresql.conf’ \
— new-options ‘-c config_file=/etc/postgresql/12/main/postgresql.conf’Возвращаемся к обычному пользователю
exitВаш старый PostgreSQL, скорее всего, использовал порт 5432, а для нового, по-умолчанию, используется 5433. Меняем друг на друга.
sudo vim /etc/postgresql/12/main/postgresql.conf
# меняем "port = 5433" на "port = 5432"
sudo vim /etc/postgresql/11/main/postgresql.conf
# меняем "port = 5432" на "port = 5433"sudo systemctl start postgresql.serviceРаботаем от пользователя postgres
sudo su postgresПроверяем версию запущенного PostgreSQL
psql -c "SELECT version();"На новом кластере нет никакой статистики. Нужно запустить ANALYZE по кластеру. Для этого pg_upgrade создал скрипт analyze_new_cluster.sh . Запускаем.
./analyze_new_cluster.shВозвращаемся к обычному пользователю
exitСмотрим, какие старые версии PostgreSQL остались в системе.
apt list --installed | grep postgresqlУдаляем старые версии PostgreSQL, например:
sudo apt-get remove postgresql-11Удаляем старую конфигурацию:
sudo rm -rf /etc/postgresql/11/В последний раз заходим под пользователем postgres
sudo su postgresУдаляем данные старого кластера
./delete_old_cluster.sh